glassfish
  1. glassfish
  2. GLASSFISH-19794

Improving fighterfish it test using different HTTP verbs

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.0_dev
    • Component/s: OSGi, OSGi-JavaEE
    • Labels:
      None

      Description

      [Sahoo]
      If you look at SamplesTest or T2_Test.java or T1_SamplesTest.java in it/src/test/java dir, you shall notice that they issue HTTP GET request even when modifying resources. e.g.: you shall see code like this in T1_SamplesTest.java:

      // now let's register a user and retry
      response = uas_simple_webapp.getResponse(registrationRequest);

      Since this is a GET request, if the request is stuck in server side for whatever reason, the HttpUrlConnection automatically retries the request and that can cause exception like this:
      > [#|2013-03-07T06:32:37.709-0800|WARNING|glassfish 4.0|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=35;_ThreadName=http-listener-1(4);_TimeMillis=1362666757709;_LevelValue=900;_MessageID=enterprise_distributedtx.before_completion_excep;ClassName=com.sun.enterprise.transaction.JavaEETransactionImpl;MethodName=commit;|
      > DTX5014: Caught exception in beforeCompletion() callback:
      > javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130226-e0971b1): org.eclipse.persistence.exceptions.DatabaseException
      > Internal Exception: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL130307063207440' defined on 'USERCREDENTIAL'.
      > Error Code: 20000
      > Call: INSERT INTO USERCREDENTIAL (NAME, PASSWORD) VALUES (?, ?)
      > bind => [2 parameters bound]
      > Query: InsertObjectQuery(org.glassfish.fighterfish.test.app2.UserCredential@6be6d6)
      > at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl$1.handleException(EntityManagerSetupImpl.java:691)
      > at org.eclipse.persistence.transaction.AbstractSynchronizationListener.handleException(AbstractSynchronizationListener.java:275)
      > at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:170)
      > at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
      > at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:452)
      > at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:824)
      > at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
      > at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
      > at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4493)
      > at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2027)
      > at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1997)
      > at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
      > at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
      > at $Proxy348.register(Unknown Source)
      > at org.glassfish.fighterfish.test.app2._EJB31_GeneratedUserAuthServiceEJBIntf__Bean_.register(Unknown Source)
      > at org.glassfish.fighterfish.test.app2.RegistrationServlet.service(RegistrationServlet.java:73)
      > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
      > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
      > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
      > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
      > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
      > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
      > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:176)
      > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
      > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
      > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
      > at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
      > at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
      > at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
      > at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:273)
      > at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
      > at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
      > at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
      > at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
      > at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:820)
      > at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
      > at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
      > at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
      > at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
      > at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
      > at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
      > at java.lang.Thread.run(Thread.java:722)
      > Caused by: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130226-e0971b1): org.eclipse.persistence.exceptions.DatabaseException
      > Internal Exception: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL130307063207440' defined on 'USERCREDENTIAL'.
      > Error Code: 20000
      > Call: INSERT INTO USERCREDENTIAL (NAME, PASSWORD) VALUES (?, ?)
      > bind => [2 parameters bound]
      > Query: InsertObjectQuery(org.glassfish.fighterfish.test.app2.UserCredential@6be6d6)
      > at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:331)
      > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:895)
      > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeNoSelect(DatabaseAccessor.java:957)
      > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:630)
      > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
      > at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1979)
      > at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:294)
      > at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:223)
      > at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:209)
      > at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:358)
      > at org.eclipse.persistence.internal.queries.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:165)
      > at org.eclipse.persistence.internal.queries.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:180)
      > at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.insertObjectForWrite(DatabaseQueryMechanism.java:485)
      > at org.eclipse.persistence.queries.InsertObjectQuery.executeCommit(InsertObjectQuery.java:80)
      > at org.eclipse.persistence.queries.InsertObjectQuery.executeCommitWithChangeSet(InsertObjectQuery.java:90)
      > at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:300)
      > at org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
      > at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
      > at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798)
      > at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
      > at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
      > at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
      > at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1781)
      > at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1763)
      > at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1714)
      > at org.eclipse.persistence.internal.sessions.CommitManager.commitNewObjectsForClassWithChangeSet(CommitManager.java:226)
      > at org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:125)
      > at org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4184)
      > at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1439)
      > at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1529)
      > at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3166)
      > at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:352)
      > at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:158)
      > ... 39 more
      > Caused by: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL130307063207440' defined on 'USERCREDENTIAL'.
      > at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
      > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
      > at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
      > at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
      > at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
      > at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
      > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
      > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
      > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
      > at org.apache.derby.iapi.jdbc.BrokeredPreparedStatement.executeUpdate(Unknown Source)
      > at com.sun.gjc.spi.base.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:125)
      > at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:885)
      > ... 70 more
      > Caused by: java.sql.SQLException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL130307063207440' defined on 'USERCREDENTIAL'.
      > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
      > at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
      > ... 82 more
      > Caused by: ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL130307063207440' defined on 'USERCREDENTIAL'.
      > at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
      > at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown Source)
      > at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown Source)
      > at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source)
      > at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown Source)
      > at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown Source)
      > at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown Source)
      > at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
      > at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
      > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
      > ... 76 more

      Do you have any better suggestion here? If we can somehow configure HttpUrlConnection to not retry a GET request, that will be less disruptive. Else, we may have to use different HTTP verbs like GET for read requests, PUT for creations and POST for modifications. That will require the test to change. I would love to know what you think of.

        Activity

        Hide
        TangYong added a comment -

        I have seen the source and done an investigation as following,

        1) some issues about current T2_Test and T1_SamplesTest
        The way of obtaining http response is not consistency.

        I have found that in T2_Test, some tests use getResponse method and other tests use getHttpResponse method.

        2) about getHttpResponse method
        The method uses post request and sets sun.net.http.retryPost
        not to retry a post request. From the point, this is good because post request is non-idempotent. However, getResponse method behavior is not the same as getHttpResponse.

        So, my idea is that just as you said, we must create/refactor the two method to name them better based on different HTTP verbs,

        1. for get request, we do not set sun.net.http.retryPost and we call it as "getHttpGetResponse"

        2. for post request, we must set sun.net.http.retryPost and call it as "getHttpPostResponse"

        About sun.net.http.retryPost property, please seeing [1], this is old issue.
        [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6382788

        Show
        TangYong added a comment - I have seen the source and done an investigation as following, 1) some issues about current T2_Test and T1_SamplesTest The way of obtaining http response is not consistency. I have found that in T2_Test, some tests use getResponse method and other tests use getHttpResponse method. 2) about getHttpResponse method The method uses post request and sets sun.net.http.retryPost not to retry a post request. From the point, this is good because post request is non-idempotent. However, getResponse method behavior is not the same as getHttpResponse. So, my idea is that just as you said, we must create/refactor the two method to name them better based on different HTTP verbs, 1. for get request, we do not set sun.net.http.retryPost and we call it as "getHttpGetResponse" 2. for post request, we must set sun.net.http.retryPost and call it as "getHttpPostResponse" About sun.net.http.retryPost property, please seeing [1] , this is old issue. [1] : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6382788
        Hide
        TangYong added a comment -

        [Sahoo]
        Makes sense to rename the methods and use them as you mentioned in points 1 & 2. I am aware of that bug, so we actually do the following in WebAppBundle.java:

        System.getProperties().setProperty("sun.net.http.retryPost", "false" );

        We should move that to pom.xml some day.

        Will you then make the changes and submit a patch? I will look at the patch once before you commit. Does it sound OK?

        Show
        TangYong added a comment - [Sahoo] Makes sense to rename the methods and use them as you mentioned in points 1 & 2. I am aware of that bug, so we actually do the following in WebAppBundle.java: System.getProperties().setProperty("sun.net.http.retryPost", "false" ); We should move that to pom.xml some day. Will you then make the changes and submit a patch? I will look at the patch once before you commit. Does it sound OK?
        Hide
        TangYong added a comment -

        OK, the feature is in progress.

        Show
        TangYong added a comment - OK, the feature is in progress.
        Hide
        TangYong added a comment -

        A patch is in revewing by Sahoo.

        Show
        TangYong added a comment - A patch is in revewing by Sahoo.
        Hide
        TangYong added a comment -

        test.util patch has been checked in.
        [Revisions]
        60283

        Show
        TangYong added a comment - test.util patch has been checked in. [Revisions] 60283
        Hide
        Sanjeeb Sahoo added a comment -

        In svn #60347, I have checked in test.it.patch with minor adjustment to pom.xml. Thanks.

        Show
        Sanjeeb Sahoo added a comment - In svn #60347, I have checked in test.it.patch with minor adjustment to pom.xml. Thanks.
        Hide
        Sanjeeb Sahoo added a comment - - edited

        I am now seeing a new issue in our hudson environment. It has happened only once. It was running on Solaris 10. See stack below:

        Caused by: java.net.SocketException: Unexpected end of file from server
        at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:718)
        at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:579)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1322)
        at org.glassfish.fighterfish.test.util.WebAppBundle.getHttpResponse(WebAppBundle.java:193)
        at org.glassfish.fighterfish.test.util.WebAppBundle.getHttpPostResponse(WebAppBundle.java:172)
        at org.glassfish.fighterfish.test.it.T2_Test.empDeptCrud(T2_Test.java:875)
        at org.glassfish.fighterfish.test.it.T2_Test.testapp8(T2_Test.java:306)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
        at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
        at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
        at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
        ... 26 more

        #]

        I don't see it in my local environment. Can you please look into it?

        Show
        Sanjeeb Sahoo added a comment - - edited I am now seeing a new issue in our hudson environment. It has happened only once. It was running on Solaris 10. See stack below: Caused by: java.net.SocketException: Unexpected end of file from server at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:718) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:579) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1322) at org.glassfish.fighterfish.test.util.WebAppBundle.getHttpResponse(WebAppBundle.java:193) at org.glassfish.fighterfish.test.util.WebAppBundle.getHttpPostResponse(WebAppBundle.java:172) at org.glassfish.fighterfish.test.it.T2_Test.empDeptCrud(T2_Test.java:875) at org.glassfish.fighterfish.test.it.T2_Test.testapp8(T2_Test.java:306) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:292) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108) ... 26 more #] I don't see it in my local environment. Can you please look into it?
        Hide
        Sanjeeb Sahoo added a comment -

        Tang,

        Don't waste your time analyising the aforementioned failure. I noticed the following error during tests:

        org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: com.sun.xml.ws.transport.http.servlet

        This is due to GLASSFISH-19712, so this must have caused the other failure. We will wait and watch.

        Show
        Sanjeeb Sahoo added a comment - Tang, Don't waste your time analyising the aforementioned failure. I noticed the following error during tests: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: com.sun.xml.ws.transport.http.servlet This is due to GLASSFISH-19712 , so this must have caused the other failure. We will wait and watch.
        Hide
        TangYong added a comment -

        fixing GLASSFISH-19794 related some exceptions found in hudson job

        Revisions:
        ----------
        60368

        Here, there is an important point while sending POST request as following:

        Based on many articles, especially [1]and[2], "SocketException: Unexpected end of file from server” from servlet can be fixed by executing "connection.getOutputStream().close()" before connection.getInputStream() while the request is a POST request.

        Then, according to [2]'s standard writing and combining with current getHttpResponse source, I added the following:

        WebAppBundle.java
        if ("POST".endsWith(mode)){
                	connection.setDoOutput(true);
                	connection.getOutputStream().close();
                }else{
                	connection.connect();
                }
        

        After I have done an it test using the fixing, I have found that not only the exception has been disappeared, but also other curious exceptions has been disappeared. Now, Sahoo and I will pay attention to hudson job.

        [1]: http://stackoverflow.com/questions/11265464/socketexception-unexpected-end-of-file-from-server-from-servlet-but-not-from

        [2]: http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html

        Show
        TangYong added a comment - fixing GLASSFISH-19794 related some exceptions found in hudson job Revisions: ---------- 60368 Here, there is an important point while sending POST request as following: Based on many articles, especially [1] and [2] , "SocketException: Unexpected end of file from server” from servlet can be fixed by executing "connection.getOutputStream().close()" before connection.getInputStream() while the request is a POST request. Then, according to [2] 's standard writing and combining with current getHttpResponse source, I added the following: WebAppBundle.java if ( "POST" .endsWith(mode)){ connection.setDoOutput( true ); connection.getOutputStream().close(); } else { connection.connect(); } After I have done an it test using the fixing, I have found that not only the exception has been disappeared, but also other curious exceptions has been disappeared. Now, Sahoo and I will pay attention to hudson job. [1] : http://stackoverflow.com/questions/11265464/socketexception-unexpected-end-of-file-from-server-from-servlet-but-not-from [2] : http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html

          People

          • Assignee:
            TangYong
            Reporter:
            TangYong
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: