Axis2
  1. Axis2
  2. AXIS2-761

SimpleHttpServer based on Jakarta HttpComponents HttpCore

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Component/s: transports
    • Labels:
      None

      Description

      The following patch replaces the SimpleHttpServer implementation based on the testing framework of Commons HttpClient 3.x with a one based on Jakarta HttpComponents HttpCore. Compiled against Axis2 trunk and HttpCore trunk

      • Removes all references to Commons HttpClient classes
      • Enables streaming of schema definitions and similar content
      • Improves content buffering of SOAP response
      • Improves handling of fault conditions and exception handling
      • Fixes a number of NPEs in AxisEngine
      • Improves performance and reliability of the HTTP transport
      1. simplehttpserver.patch
        92 kB
        Oleg Kalnichevski
      2. ConfigurableSimpleHTTPServer.patch
        30 kB
        Chuck Williams
      3. ConfigurableSimpleHTTPServer.consolidated.patch
        124 kB
        Chuck Williams
      4. ConfigurableSimpleHTTPServer.complete.patch
        118 kB
        Chuck Williams
      5. ConfigurableSimpleHTTPServer.complete.patch
        122 kB
        Chuck Williams
      6. ConfigurableSimpleHTTPServer.complete.patch
        122 kB
        Chuck Williams
      7. ConfigurableSimpleHTTPServer.complete.patch
        124 kB
        Chuck Williams
      8. ConfigurableSimpleHTTPServer.complete.patch
        128 kB
        Oleg Kalnichevski

        Issue Links

          Activity

          Hide
          Oleg Kalnichevski added a comment -

          In order to simplify testing I am attaching a snapshot of HttpCore the patch has been compiled against

          Show
          Oleg Kalnichevski added a comment - In order to simplify testing I am attaching a snapshot of HttpCore the patch has been compiled against
          Hide
          Oleg Kalnichevski added a comment -

          The new SimpleHttpServer appears fully functional to me, but I am certain I may have broken a few things because I do not have an in-depth knowledge of the AxisEngine.

          Comments, critique, feedback will be hugely appreciated

          Should you find the overall design acceptable, I could add a number of incremental improvements on top of this patch. Streaming of the response content for synchronous messages might be one (this might require code refactoring beyond SimpleHttpServer). Cookie management is another area where I see room for improvement.

          Cheers,

          Oleg

          Show
          Oleg Kalnichevski added a comment - The new SimpleHttpServer appears fully functional to me, but I am certain I may have broken a few things because I do not have an in-depth knowledge of the AxisEngine. Comments, critique, feedback will be hugely appreciated Should you find the overall design acceptable, I could add a number of incremental improvements on top of this patch. Streaming of the response content for synchronous messages might be one (this might require code refactoring beyond SimpleHttpServer). Cookie management is another area where I see room for improvement. Cheers, Oleg
          Hide
          Chuck Williams added a comment -

          Oleg, did you get all of the axis2 tests to pass?

          I am getting failures in 5 of the modules/integration tests. I would pursue diagnosis and debugging, but have reached the point of maximal frustration trying to get maven to not swallow the test failure information (where a failure occurred and the stack trace for an error), much less let me debug.

          Perhaps someone could explain how to get the failure information out of maven? I've tried maven from the command line and the mevenide plug-in for netbeans, including trying test-single, mevenide:test-single-debug and -e, all to no avail. I have gotten failure/error information out of mevenide, but never for tests in integration. Additionally, there are chronic problems in integration tests run singly with hung jvm's listening on 8888, even when runnin maven test-single from the command line.

          Here is what I did specifically:
          1. Apply the patch against my local axis2 1.0 sources. The patch applies cleanly, except for the first hunk of the changes to AxisEngine, which apply about 20 some-odd lines earlier in the file. It is possible the test errors are due to using the 1.0 distro, but it seems unlikely.

          2. Add dependencies on the jakarta-httpcore jar to modules core, codegen, jibx and integration. Other dependencies may be required, but I haven't gotten past integration yet.

          I'm getting failures or errors in these 5 tests in integration. The rest all pass.

          [junit] Running org.apache.axis2.rpc.MultirefTest
          [junit] Tests run: 9, Failures: 0, Errors: 1, Time elapsed: 10.553 sec
          [junit] [ERROR] TEST org.apache.axis2.rpc.MultirefTest FAILED

          [junit] Running org.apache.axis2.engine.ServiceGroupContextTest
          [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 9.802 sec
          [junit] [ERROR] TEST org.apache.axis2.engine.ServiceGroupContextTest FAILED

          [junit] Running org.apache.axis2.engine.CallUnregisteredServiceTest
          [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.691 sec
          [junit] [ERROR] TEST org.apache.axis2.engine.CallUnregisteredServiceTest FAILED

          [junit] Running org.apache.axis2.engine.FaultHandlingTest
          [junit] Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 7.267 sec
          [junit] [ERROR] TEST org.apache.axis2.engine.FaultHandlingTest FAILED

          [junit] Running org.apache.axis2.engine.HandlerFailureTest
          [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.628 sec
          [junit] [ERROR] TEST org.apache.axis2.engine.HandlerFailureTest FAILED

          Show
          Chuck Williams added a comment - Oleg, did you get all of the axis2 tests to pass? I am getting failures in 5 of the modules/integration tests. I would pursue diagnosis and debugging, but have reached the point of maximal frustration trying to get maven to not swallow the test failure information (where a failure occurred and the stack trace for an error), much less let me debug. Perhaps someone could explain how to get the failure information out of maven? I've tried maven from the command line and the mevenide plug-in for netbeans, including trying test-single, mevenide:test-single-debug and -e, all to no avail. I have gotten failure/error information out of mevenide, but never for tests in integration. Additionally, there are chronic problems in integration tests run singly with hung jvm's listening on 8888, even when runnin maven test-single from the command line. Here is what I did specifically: 1. Apply the patch against my local axis2 1.0 sources. The patch applies cleanly, except for the first hunk of the changes to AxisEngine, which apply about 20 some-odd lines earlier in the file. It is possible the test errors are due to using the 1.0 distro, but it seems unlikely. 2. Add dependencies on the jakarta-httpcore jar to modules core, codegen, jibx and integration. Other dependencies may be required, but I haven't gotten past integration yet. I'm getting failures or errors in these 5 tests in integration. The rest all pass. [junit] Running org.apache.axis2.rpc.MultirefTest [junit] Tests run: 9, Failures: 0, Errors: 1, Time elapsed: 10.553 sec [junit] [ERROR] TEST org.apache.axis2.rpc.MultirefTest FAILED [junit] Running org.apache.axis2.engine.ServiceGroupContextTest [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 9.802 sec [junit] [ERROR] TEST org.apache.axis2.engine.ServiceGroupContextTest FAILED [junit] Running org.apache.axis2.engine.CallUnregisteredServiceTest [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.691 sec [junit] [ERROR] TEST org.apache.axis2.engine.CallUnregisteredServiceTest FAILED [junit] Running org.apache.axis2.engine.FaultHandlingTest [junit] Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 7.267 sec [junit] [ERROR] TEST org.apache.axis2.engine.FaultHandlingTest FAILED [junit] Running org.apache.axis2.engine.HandlerFailureTest [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.628 sec [junit] [ERROR] TEST org.apache.axis2.engine.HandlerFailureTest FAILED
          Hide
          Dennis Sosnoski added a comment -

          What, you're having problems understanding Maven? But the whole point of Maven is that you're not supposed to have to understand it, everything just happens by magic.

          I dealt with exactly this same frustration on the test results about a month ago. Check the target/test-reports folder under the module.

          Show
          Dennis Sosnoski added a comment - What, you're having problems understanding Maven? But the whole point of Maven is that you're not supposed to have to understand it, everything just happens by magic. I dealt with exactly this same frustration on the test results about a month ago. Check the target/test-reports folder under the module.
          Hide
          Oleg Kalnichevski added a comment -

          > Oleg, did you get all of the axis2 tests to pass?

          Sadly, I can't even compile Axis2 trunk using Maven, let alone running integration tests. (Apparently a maven repository hosted at the openejb.org is not available or some such). By looking at the source code of the failed test cases they do not seem dependent on SimpleHttpServer in any way.

          If that helps, I can package the code as an add-on to Axis2 1.0 release, so it could be compiled against Axis2 1.0 binary and dropped into the standard Axis2 distro as a replacement for the stock version of the SimpleHttpServer. No patching or rebuilding of Axis2 will be required

          Oleg

          Show
          Oleg Kalnichevski added a comment - > Oleg, did you get all of the axis2 tests to pass? Sadly, I can't even compile Axis2 trunk using Maven, let alone running integration tests. (Apparently a maven repository hosted at the openejb.org is not available or some such). By looking at the source code of the failed test cases they do not seem dependent on SimpleHttpServer in any way. If that helps, I can package the code as an add-on to Axis2 1.0 release, so it could be compiled against Axis2 1.0 binary and dropped into the standard Axis2 distro as a replacement for the stock version of the SimpleHttpServer. No patching or rebuilding of Axis2 will be required Oleg
          Hide
          Chuck Williams added a comment -

          > Sadly, I can't even compile Axis2 trunk using Maven, let alone running integration tests. (Apparently a maven repository hosted at the openejb.org is not available or some such).

          Welcome to the maven abyss. It usually helps to download everything first and only once, e.g. from the trunk:

          maven create-lib
          maven -o
          cp target/lib/* lib/

          If there are jars you just can't get, you need to find them somewhere. One possibility is to download http://ws.zones.apache.org/~chinthaka/repository.zip and unzip it into the .maven repository.

          If you get the jars into lib/ somehow but can't figure out where everything goes in the maven repository, you can

          cp lib/* target/lib/ # or vice-versa – just make sure everything is both places
          maven -o -Dmaven.jar.override=on # causes build from lib instead of maven repository

          > By looking at the source code of the failed test cases they do not seem dependent on SimpleHttpServer in any way.

          Alas, they must be, because that is the only thing that changes between the test cases succeeding and failing. If I reverse the patch, they all succeed.

          I was pulled onto something else for most of the day and it is late here now. Will take a look again tomorrow. Thanks to Dennis's info about target/test-reports, I do at least have the stack traces now. Most of the errors seem to be failures in expected strings in response messages. I'm wondering if there is some minor difference in formatting or some such. It would be easy to find if mevenide would cooperate so that mevenide:test-single-debug would work right. Codehaus appears to have had major site problems, so mevenide documentation for maven 1 does not seem to be available. When trying a debug-file in netbeans on the test cases, I'm getting connection refused on when mevenide tries to attach the debugger, for mevenide's default debug port (8888) and same for any port I change it to.

          Here are the test-reports for the 5 failing tests:

          Testsuite: org.apache.axis2.rpc.MultirefTest
          Tests run: 9, Failures: 0, Errors: 1, Time elapsed: 10.8 sec

          ------------- Standard Output ---------------
          Server started on port 5555.....[SimpleHTTPServer] Stop called
          Server stopped .....[SimpleHTTPServer] Stop called
          ------------- ---------------- ---------------
          ------------- Standard Error -----------------
          log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder).
          log4j:WARN Please initialize the log4j system properly.
          ------------- ---------------- ---------------
          Testcase: testaddError(org.apache.axis2.rpc.MultirefTest): Caused an ERROR
          null
          java.lang.NullPointerException
          at org.apache.axis2.rpc.MultirefTest.testaddError(MultirefTest.java:300)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Testsuite: org.apache.axis2.engine.HandlerFailureTest
          Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.706 sec

          ------------- Standard Output ---------------
          Server started on port 5555.....[SimpleHTTPServer] Stop called
          Server stopped .....[SimpleHTTPServer] Stop called
          ------------- ---------------- ---------------
          ------------- Standard Error -----------------
          log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder).
          log4j:WARN Please initialize the log4j system properly.
          ------------- ---------------- ---------------
          Testcase: testFailureAtServerRequestFlow(org.apache.axis2.engine.HandlerFailureTest): FAILED
          null
          junit.framework.AssertionFailedError
          at org.apache.axis2.engine.HandlerFailureTest.callTheService(HandlerFailureTest.java:119)
          at org.apache.axis2.engine.HandlerFailureTest.testFailureAtServerRequestFlow(HandlerFailureTest.java:86)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Testsuite: org.apache.axis2.engine.CallUnregisteredServiceTest
          Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.895 sec

          ------------- Standard Output ---------------
          Server started on port 5555.....[SimpleHTTPServer] Stop called
          Server stopped .....[SimpleHTTPServer] Stop called
          ------------- ---------------- ---------------
          ------------- Standard Error -----------------
          log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder).
          log4j:WARN Please initialize the log4j system properly.
          ------------- ---------------- ---------------
          Testcase: testEchoXMLSync(org.apache.axis2.engine.CallUnregisteredServiceTest): FAILED
          null
          junit.framework.AssertionFailedError
          at org.apache.axis2.engine.CallUnregisteredServiceTest.testEchoXMLSync(CallUnregisteredServiceTest.java:83)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Testsuite: org.apache.axis2.engine.ServiceGroupContextTest
          Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 9.767 sec

          ------------- Standard Output ---------------
          Server started on port 5555.....[SimpleHTTPServer] Stop called
          Server stopped .....[SimpleHTTPServer] Stop called
          ------------- ---------------- ---------------
          ------------- Standard Error -----------------
          log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder).
          log4j:WARN Please initialize the log4j system properly.
          ------------- ---------------- ---------------
          Testcase: testEchoXMLSync(org.apache.axis2.engine.ServiceGroupContextTest): FAILED
          Number of requests should be 2 expected:<2> but was:<1>
          junit.framework.AssertionFailedError: Number of requests should be 2 expected:<2> but was:<1>
          at org.apache.axis2.engine.ServiceGroupContextTest.testEchoXMLSync(ServiceGroupContextTest.java:108)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Testsuite: org.apache.axis2.engine.FaultHandlingTest
          Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 6.973 sec

          ------------- Standard Output ---------------
          Server started on port 5555.....[SimpleHTTPServer] Stop called
          Server stopped .....[SimpleHTTPServer] Stop called
          ------------- ---------------- ---------------
          ------------- Standard Error -----------------
          log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder).
          log4j:WARN Please initialize the log4j system properly.
          ------------- ---------------- ---------------
          Testcase: testFaultHandlingWithParamsSetToMsgCtxt(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR
          Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:223)
          at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:590)
          at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:328)
          at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:279)
          at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:457)
          at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:399)
          at org.apache.axis2.engine.FaultHandlingTest.testFaultHandling(FaultHandlingTest.java:87)
          at org.apache.axis2.engine.FaultHandlingTest.testFaultHandlingWithParamsSetToMsgCtxt(FaultHandlingTest.java:66)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305)
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:207)
          ... 25 more
          Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:120)
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:299)
          ... 26 more

          Testcase: testFaultHandlingWithParamsSetToAxisFault(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR
          Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:223)
          at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:590)
          at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:328)
          at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:279)
          at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:457)
          at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:399)
          at org.apache.axis2.engine.FaultHandlingTest.testFaultHandling(FaultHandlingTest.java:87)
          at org.apache.axis2.engine.FaultHandlingTest.testFaultHandlingWithParamsSetToAxisFault(FaultHandlingTest.java:71)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305)
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:207)
          ... 25 more
          Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:120)
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:299)
          ... 26 more

          Testcase: testRefParamsWithFaultTo(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR
          Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:223)
          at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:590)
          at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:328)
          at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:279)
          at org.apache.axis2.engine.FaultHandlingTest.getResponse(FaultHandlingTest.java:162)
          at org.apache.axis2.engine.FaultHandlingTest.testRefParamsWithFaultTo(FaultHandlingTest.java:115)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is:
          org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305)
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:207)
          ... 23 more
          Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer
          at org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:120)
          at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:299)
          ... 24 more

          Testcase: testExceptionInformationExtractionFromAxisFault(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR
          null
          java.lang.NullPointerException
          at org.apache.axis2.engine.FaultHandlingTest.testExceptionInformationExtractionFromAxisFault(FaultHandlingTest.java:191)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Show
          Chuck Williams added a comment - > Sadly, I can't even compile Axis2 trunk using Maven, let alone running integration tests. (Apparently a maven repository hosted at the openejb.org is not available or some such). Welcome to the maven abyss. It usually helps to download everything first and only once, e.g. from the trunk: maven create-lib maven -o cp target/lib/* lib/ If there are jars you just can't get, you need to find them somewhere. One possibility is to download http://ws.zones.apache.org/~chinthaka/repository.zip and unzip it into the .maven repository. If you get the jars into lib/ somehow but can't figure out where everything goes in the maven repository, you can cp lib/* target/lib/ # or vice-versa – just make sure everything is both places maven -o -Dmaven.jar.override=on # causes build from lib instead of maven repository > By looking at the source code of the failed test cases they do not seem dependent on SimpleHttpServer in any way. Alas, they must be, because that is the only thing that changes between the test cases succeeding and failing. If I reverse the patch, they all succeed. I was pulled onto something else for most of the day and it is late here now. Will take a look again tomorrow. Thanks to Dennis's info about target/test-reports, I do at least have the stack traces now. Most of the errors seem to be failures in expected strings in response messages. I'm wondering if there is some minor difference in formatting or some such. It would be easy to find if mevenide would cooperate so that mevenide:test-single-debug would work right. Codehaus appears to have had major site problems, so mevenide documentation for maven 1 does not seem to be available. When trying a debug-file in netbeans on the test cases, I'm getting connection refused on when mevenide tries to attach the debugger, for mevenide's default debug port (8888) and same for any port I change it to. Here are the test-reports for the 5 failing tests: Testsuite: org.apache.axis2.rpc.MultirefTest Tests run: 9, Failures: 0, Errors: 1, Time elapsed: 10.8 sec ------------- Standard Output --------------- Server started on port 5555..... [SimpleHTTPServer] Stop called Server stopped ..... [SimpleHTTPServer] Stop called ------------- ---------------- --------------- ------------- Standard Error ----------------- log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder). log4j:WARN Please initialize the log4j system properly. ------------- ---------------- --------------- Testcase: testaddError(org.apache.axis2.rpc.MultirefTest): Caused an ERROR null java.lang.NullPointerException at org.apache.axis2.rpc.MultirefTest.testaddError(MultirefTest.java:300) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Testsuite: org.apache.axis2.engine.HandlerFailureTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.706 sec ------------- Standard Output --------------- Server started on port 5555..... [SimpleHTTPServer] Stop called Server stopped ..... [SimpleHTTPServer] Stop called ------------- ---------------- --------------- ------------- Standard Error ----------------- log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder). log4j:WARN Please initialize the log4j system properly. ------------- ---------------- --------------- Testcase: testFailureAtServerRequestFlow(org.apache.axis2.engine.HandlerFailureTest): FAILED null junit.framework.AssertionFailedError at org.apache.axis2.engine.HandlerFailureTest.callTheService(HandlerFailureTest.java:119) at org.apache.axis2.engine.HandlerFailureTest.testFailureAtServerRequestFlow(HandlerFailureTest.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Testsuite: org.apache.axis2.engine.CallUnregisteredServiceTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.895 sec ------------- Standard Output --------------- Server started on port 5555..... [SimpleHTTPServer] Stop called Server stopped ..... [SimpleHTTPServer] Stop called ------------- ---------------- --------------- ------------- Standard Error ----------------- log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder). log4j:WARN Please initialize the log4j system properly. ------------- ---------------- --------------- Testcase: testEchoXMLSync(org.apache.axis2.engine.CallUnregisteredServiceTest): FAILED null junit.framework.AssertionFailedError at org.apache.axis2.engine.CallUnregisteredServiceTest.testEchoXMLSync(CallUnregisteredServiceTest.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Testsuite: org.apache.axis2.engine.ServiceGroupContextTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 9.767 sec ------------- Standard Output --------------- Server started on port 5555..... [SimpleHTTPServer] Stop called Server stopped ..... [SimpleHTTPServer] Stop called ------------- ---------------- --------------- ------------- Standard Error ----------------- log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder). log4j:WARN Please initialize the log4j system properly. ------------- ---------------- --------------- Testcase: testEchoXMLSync(org.apache.axis2.engine.ServiceGroupContextTest): FAILED Number of requests should be 2 expected:<2> but was:<1> junit.framework.AssertionFailedError: Number of requests should be 2 expected:<2> but was:<1> at org.apache.axis2.engine.ServiceGroupContextTest.testEchoXMLSync(ServiceGroupContextTest.java:108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Testsuite: org.apache.axis2.engine.FaultHandlingTest Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 6.973 sec ------------- Standard Output --------------- Server started on port 5555..... [SimpleHTTPServer] Stop called Server stopped ..... [SimpleHTTPServer] Stop called ------------- ---------------- --------------- ------------- Standard Error ----------------- log4j:WARN No appenders could be found for logger (org.apache.axiom.om.impl.builder.StAXOMBuilder). log4j:WARN Please initialize the log4j system properly. ------------- ---------------- --------------- Testcase: testFaultHandlingWithParamsSetToMsgCtxt(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:223) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:590) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:328) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:279) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:457) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:399) at org.apache.axis2.engine.FaultHandlingTest.testFaultHandling(FaultHandlingTest.java:87) at org.apache.axis2.engine.FaultHandlingTest.testFaultHandlingWithParamsSetToMsgCtxt(FaultHandlingTest.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:207) ... 25 more Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:120) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:299) ... 26 more Testcase: testFaultHandlingWithParamsSetToAxisFault(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:223) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:590) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:328) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:279) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:457) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:399) at org.apache.axis2.engine.FaultHandlingTest.testFaultHandling(FaultHandlingTest.java:87) at org.apache.axis2.engine.FaultHandlingTest.testFaultHandlingWithParamsSetToAxisFault(FaultHandlingTest.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:207) ... 25 more Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:120) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:299) ... 26 more Testcase: testRefParamsWithFaultTo(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:223) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:590) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:328) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:279) at org.apache.axis2.engine.FaultHandlingTest.getResponse(FaultHandlingTest.java:162) at org.apache.axis2.engine.FaultHandlingTest.testRefParamsWithFaultTo(FaultHandlingTest.java:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer; nested exception is: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:207) ... 23 more Caused by: org.apache.axis2.AxisFault: Transport error 500 . Error Message is org.apache.axis2.transport.http.server.OutputBuffer at org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:120) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:299) ... 24 more Testcase: testExceptionInformationExtractionFromAxisFault(org.apache.axis2.engine.FaultHandlingTest): Caused an ERROR null java.lang.NullPointerException at org.apache.axis2.engine.FaultHandlingTest.testExceptionInformationExtractionFromAxisFault(FaultHandlingTest.java:191) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23)
          Hide
          Oleg Kalnichevski added a comment -

          > Alas, they must be, because that is the only thing that changes between the test cases succeeding and failing. If I reverse the patch, they all succeed.

          Fair enough. I know I may have broken a few things by changing the way exceptions are handled, for instance. I'll work on it. Expect a new patch sometime this week

          Oleg

          Show
          Oleg Kalnichevski added a comment - > Alas, they must be, because that is the only thing that changes between the test cases succeeding and failing. If I reverse the patch, they all succeed. Fair enough. I know I may have broken a few things by changing the way exceptions are handled, for instance. I'll work on it. Expect a new patch sometime this week Oleg
          Hide
          Oleg Kalnichevski added a comment -

          Four failures out of five were caused by a one-liner bug in my code and were trivial to fix. I am having a hard time with the fifth one, though - ServiceGroupContextTest. In fact I am not sure I understand how it is supposed to work at all. The comment accompanying the test case does not help making me believe the test case it right.

          ================================================================
          //TODO : ple imporove this , what I have done is a hack

          OMElement result2 = sender.sendReceive(defaultEnvelope.getBody().getFirstElement());

          String text = result2.getText();

          assertEquals("Number of requests should be 2", 2, Integer.parseInt(text));
          ================================================================

          Does anyone know the background of this?

          Oleg

          Show
          Oleg Kalnichevski added a comment - Four failures out of five were caused by a one-liner bug in my code and were trivial to fix. I am having a hard time with the fifth one, though - ServiceGroupContextTest. In fact I am not sure I understand how it is supposed to work at all. The comment accompanying the test case does not help making me believe the test case it right. ================================================================ //TODO : ple imporove this , what I have done is a hack OMElement result2 = sender.sendReceive(defaultEnvelope.getBody().getFirstElement()); String text = result2.getText(); assertEquals("Number of requests should be 2", 2, Integer.parseInt(text)); ================================================================ Does anyone know the background of this? Oleg
          Hide
          Oleg Kalnichevski added a comment -

          My bad. Found the bug. All tests pass now and Axis2 builds cleanly
          ===========================
          create-jar:
          [jar] Building jar: /home/oleg/src/apache.org/webservices/axis2/target/lib/axis2-SNAPSHOT.jar

          [copy] Copying 1 file to /home/oleg/src/apache.org/webservices/axis2/target
          Copying: from '/home/oleg/src/apache.org/webservices/axis2/target/axis2-SNAPSHOT.jar' to: '/home/oleg/.maven/repository/axis2/jars/axis2-SNAPSHOT.jar'
          Copying: from '/home/oleg/src/apache.org/webservices/axis2/project.xml' to: '/home/oleg/.maven/repository/axis2/poms/axis2-SNAPSHOT.pom'
          BUILD SUCCESSFUL
          Total time: 10 minutes 35 seconds
          Finished at: Mon May 22 17:30:26 CEST 2006
          ===========================

          Show
          Oleg Kalnichevski added a comment - My bad. Found the bug. All tests pass now and Axis2 builds cleanly =========================== create-jar: [jar] Building jar: /home/oleg/src/apache.org/webservices/axis2/target/lib/axis2-SNAPSHOT.jar [copy] Copying 1 file to /home/oleg/src/apache.org/webservices/axis2/target Copying: from '/home/oleg/src/apache.org/webservices/axis2/target/axis2-SNAPSHOT.jar' to: '/home/oleg/.maven/repository/axis2/jars/axis2-SNAPSHOT.jar' Copying: from '/home/oleg/src/apache.org/webservices/axis2/project.xml' to: '/home/oleg/.maven/repository/axis2/poms/axis2-SNAPSHOT.pom' BUILD SUCCESSFUL Total time: 10 minutes 35 seconds Finished at: Mon May 22 17:30:26 CEST 2006 ===========================
          Hide
          Davanum Srinivas added a comment -

          Nice, could u please upload the latest patch / jar ?

          thanks,
          dims

          Show
          Davanum Srinivas added a comment - Nice, could u please upload the latest patch / jar ? thanks, dims
          Hide
          Oleg Kalnichevski added a comment -

          Attaching a new revision of the patch.

          Chuck,
          Could you please take it for a spin?

          Oleg

          Show
          Oleg Kalnichevski added a comment - Attaching a new revision of the patch. Chuck, Could you please take it for a spin? Oleg
          Hide
          Chuck Williams added a comment -

          Thanks Oleg! I've installed the patch, made the necessary build updates to incorporate the new jar, and replicated your report that all axis2 tests pass. I've also tried it out in my application and it works.

          My applications hits the server with a mix of very large and very small messages. When I send the large messages from a single client thread, performance is at least as good as before, probably a little better. When I hit the server with large messages from multiple simultaneous threads, it seems slower however. CPU utilization is low. I'm not sure why this is – it could be an application issue – and will dig into it and report again.

          One application change was required to incorporate the patch because the api to construct a SimpleHTTPServer with a ThreadPool has been removed. This is an upward incompatibility, but the mechanism we had before wasn't useful anyway. I only used it to work around a bug (the old SimpleHTTPServer created all its processing threads as daemons, so the jvm kept stopping!).

          I'm going to proceed and diagnose the possible multi-threading issue and look at extending this with resource-management capabilities. I need segration of operations into varying priority thread pools and ability to dynamically limit thread pool allocation based on size of messages being processed. If anybody else has other resource-management needs or suggestions, please comment. I'd like to produce a general facility that will be useful to many apps.

          To integrate the patch and the new jar, the following additional changes are required to axis2:

          1. Install the new jar into the maven repository at jakarta-httpcore/jars
          2. Add these properties to etc/project.properties:
          a. In "Versions of dependencies": jakarta.httpcore.version=4.0-20060521
          b. In "Jars set explicitly by path": maven.jar.jakarta-httpcore=$

          {dependencies.dir}

          /jakarta-httpcore-$

          {jakarta.httpcore.version}.jar
          3. Add this dependency to the project.xml in modules/ codegen, core, integration, jibx and saaj:
          <dependency>
          <groupId>jakarta-httpcore</groupId>
          <artifactId>jakarta-httpcore</artifactId>
          <version>${jakarta.httpcore.version}

          </version>
          <properties>
          <module>true</module>
          </properties>
          </dependency>

          Show
          Chuck Williams added a comment - Thanks Oleg! I've installed the patch, made the necessary build updates to incorporate the new jar, and replicated your report that all axis2 tests pass. I've also tried it out in my application and it works. My applications hits the server with a mix of very large and very small messages. When I send the large messages from a single client thread, performance is at least as good as before, probably a little better. When I hit the server with large messages from multiple simultaneous threads, it seems slower however. CPU utilization is low. I'm not sure why this is – it could be an application issue – and will dig into it and report again. One application change was required to incorporate the patch because the api to construct a SimpleHTTPServer with a ThreadPool has been removed. This is an upward incompatibility, but the mechanism we had before wasn't useful anyway. I only used it to work around a bug (the old SimpleHTTPServer created all its processing threads as daemons, so the jvm kept stopping!). I'm going to proceed and diagnose the possible multi-threading issue and look at extending this with resource-management capabilities. I need segration of operations into varying priority thread pools and ability to dynamically limit thread pool allocation based on size of messages being processed. If anybody else has other resource-management needs or suggestions, please comment. I'd like to produce a general facility that will be useful to many apps. To integrate the patch and the new jar, the following additional changes are required to axis2: 1. Install the new jar into the maven repository at jakarta-httpcore/jars 2. Add these properties to etc/project.properties: a. In "Versions of dependencies": jakarta.httpcore.version=4.0-20060521 b. In "Jars set explicitly by path": maven.jar.jakarta-httpcore=$ {dependencies.dir} /jakarta-httpcore-$ {jakarta.httpcore.version}.jar 3. Add this dependency to the project.xml in modules/ codegen, core, integration, jibx and saaj: <dependency> <groupId>jakarta-httpcore</groupId> <artifactId>jakarta-httpcore</artifactId> <version>${jakarta.httpcore.version} </version> <properties> <module>true</module> </properties> </dependency>
          Hide
          Chuck Williams added a comment -

          My performance bottleneck when hitting the server hard from the client turned out to be the core pool size in SimpleHttpServer's request ThreadPoolExector (SimpleHttpServer.minThreads == 25). The semantics of ThreadPoolExecutor limit the processing threads to this value until the queue fills up, after which time they could increase up to the max pool size (SimpleHttpServer.maxThreads == 150). But, requests from the client hang if there are no request threads available, so the queue size was not increasing. This left me at only 25 server threads max, which was not enough to provide much cpu utilization.

          The new server seems solid. I think it just needs facilties for dynamically managing threads based on configuration parameters and resource availability (e.g., message size). As mentioned before, I'm looking at adding those things.

          FYI, there are some left-over comments that are now obsolete, including the one about this not being production-quality, I hope.

          Show
          Chuck Williams added a comment - My performance bottleneck when hitting the server hard from the client turned out to be the core pool size in SimpleHttpServer's request ThreadPoolExector (SimpleHttpServer.minThreads == 25). The semantics of ThreadPoolExecutor limit the processing threads to this value until the queue fills up, after which time they could increase up to the max pool size (SimpleHttpServer.maxThreads == 150). But, requests from the client hang if there are no request threads available, so the queue size was not increasing. This left me at only 25 server threads max, which was not enough to provide much cpu utilization. The new server seems solid. I think it just needs facilties for dynamically managing threads based on configuration parameters and resource availability (e.g., message size). As mentioned before, I'm looking at adding those things. FYI, there are some left-over comments that are now obsolete, including the one about this not being production-quality, I hope.
          Hide
          Oleg Kalnichevski added a comment -

          > When I send the large messages from a single client thread, performance is at least as good as before, probably a little better

          Chuck, can you quantify that? Usually HttpCore tends to be 20% to 40% faster compared to HttpClient 3.0 (the old SHS is based on) depending on the content length. I am unable to make a comparative performance analysis of old SHS vs new one because I have never been able to make the old SHS survive under even a moderate workload.

          Anyways, I am glad the new SHS seems to be holding up well. I see a few areas for further improvement and performance optimization in the HTTP layer but would rather prefer to tackle them incrementally.

          Oleg

          Show
          Oleg Kalnichevski added a comment - > When I send the large messages from a single client thread, performance is at least as good as before, probably a little better Chuck, can you quantify that? Usually HttpCore tends to be 20% to 40% faster compared to HttpClient 3.0 (the old SHS is based on) depending on the content length. I am unable to make a comparative performance analysis of old SHS vs new one because I have never been able to make the old SHS survive under even a moderate workload. Anyways, I am glad the new SHS seems to be holding up well. I see a few areas for further improvement and performance optimization in the HTTP layer but would rather prefer to tackle them incrementally. Oleg
          Hide
          Chuck Williams added a comment -

          Oleg,

          I don't have a good quantitative comparison of before and after, plus I'm sure it wouldn't be relevant anyway as performance is dominated by the size of the thread pool. When I doubled SimpleHttpServer.minThreads from 25 to 50, performance more than doubled. There is already a huge benefit from your new http layer because the unnecessary copying/buffering of incoming messages is gone. The large messages are streamed through my application processing, so eliminating this copying in the http layer is a big factor in boith performance and memory utilization (which translates directly to the supportable size of the thread pool and therefore to cpu utilization).

          The http server seems to be solid so far. What's needed now, at least in my app,. is the layer on top to manage threads for performance and priority of messages. This is important because the small messages need to get through even if there is a backlog of large messages. A single large message could consume all available memory, while as the stat above shows, for more normal large messages at least 50 need to be processed simultaneously to achieve good cpu utilization on a dual-processor machine. So the thread pool management needs to be dynamic. I beleive this control mechanism will be the primary performance determinant.

          Show
          Chuck Williams added a comment - Oleg, I don't have a good quantitative comparison of before and after, plus I'm sure it wouldn't be relevant anyway as performance is dominated by the size of the thread pool. When I doubled SimpleHttpServer.minThreads from 25 to 50, performance more than doubled. There is already a huge benefit from your new http layer because the unnecessary copying/buffering of incoming messages is gone. The large messages are streamed through my application processing, so eliminating this copying in the http layer is a big factor in boith performance and memory utilization (which translates directly to the supportable size of the thread pool and therefore to cpu utilization). The http server seems to be solid so far. What's needed now, at least in my app,. is the layer on top to manage threads for performance and priority of messages. This is important because the small messages need to get through even if there is a backlog of large messages. A single large message could consume all available memory, while as the stat above shows, for more normal large messages at least 50 need to be processed simultaneously to achieve good cpu utilization on a dual-processor machine. So the thread pool management needs to be dynamic. I beleive this control mechanism will be the primary performance determinant.
          Hide
          Oleg Kalnichevski added a comment -

          > I'm sure it wouldn't be relevant anyway as performance is dominated by the size of the thread pool

          Agreed. I do have a hidden agenda here, though, as my main motivating factor is to gather some empirical data to be able to optimize the HTTP transport layer.

          > The http server seems to be solid so far. What's needed now, at least in my app,. is the layer on top to manage threads for performance and priority of messages

          This is likely to require you to write a custom version of HttpService from HttpCore which presently built assuming one thread of execution. In your case, however, you may have to parse request headers on a dispatch thread which in its turn can assign messages to different worker threads based on a desired criteria such as length of incoming content, availability of threads in thread pools or what not.

          Essentially it is now up to the Axis folks to decide how to proceed further depending on whether they want to accept the patch at all and, if so, whether they want to keep it as simple as possible or they might want some more advanced features.

          Oleg

          Show
          Oleg Kalnichevski added a comment - > I'm sure it wouldn't be relevant anyway as performance is dominated by the size of the thread pool Agreed. I do have a hidden agenda here, though, as my main motivating factor is to gather some empirical data to be able to optimize the HTTP transport layer. > The http server seems to be solid so far. What's needed now, at least in my app,. is the layer on top to manage threads for performance and priority of messages This is likely to require you to write a custom version of HttpService from HttpCore which presently built assuming one thread of execution. In your case, however, you may have to parse request headers on a dispatch thread which in its turn can assign messages to different worker threads based on a desired criteria such as length of incoming content, availability of threads in thread pools or what not. Essentially it is now up to the Axis folks to decide how to proceed further depending on whether they want to accept the patch at all and, if so, whether they want to keep it as simple as possible or they might want some more advanced features. Oleg
          Hide
          Davanum Srinivas added a comment -

          oleg,

          Can you please make the jar available on people.apache.org/repository? so that we can add the code to our maven build? I usually set up a cron job that builds snapshots every few hours and updates the repository (people.apache.org/repository). So that we can keep up with the changes in HttpCore.

          thanks,
          dims

          Show
          Davanum Srinivas added a comment - oleg, Can you please make the jar available on people.apache.org/repository? so that we can add the code to our maven build? I usually set up a cron job that builds snapshots every few hours and updates the repository (people.apache.org/repository). So that we can keep up with the changes in HttpCore. thanks, dims
          Hide
          Oleg Kalnichevski added a comment -

          I'll do so. I will be pushing out snapshots that are known to be stable on a regular basis

          Oleg

          Show
          Oleg Kalnichevski added a comment - I'll do so. I will be pushing out snapshots that are known to be stable on a regular basis Oleg
          Hide
          Davanum Srinivas added a comment -

          Sounds good! please let us know and one of us will apply the patch and fix the project.xml etc...

          thanks,
          dims

          Show
          Davanum Srinivas added a comment - Sounds good! please let us know and one of us will apply the patch and fix the project.xml etc... thanks, dims
          Hide
          Oleg Kalnichevski added a comment -

          Davanum,

          Please let me know if that's sufficient for the time being:

          http://people.apache.org/repository/org.apache.httpcomponents/jars/

          Oleg

          Show
          Oleg Kalnichevski added a comment - Davanum, Please let me know if that's sufficient for the time being: http://people.apache.org/repository/org.apache.httpcomponents/jars/ Oleg
          Hide
          Chuck Williams added a comment -

          Sorry to be late getting back to this. Been a very busy week – just got some time this afternoon and evening.

          The attached ConfigurableSimpleHTTPServer.patch provides facilities to fully configure a SImpleHTTPServer for production use. A new class HttpFactory is introduced that is
          a) Configurable with the most commonly set parameters, like request core thread pool size, request socket timeout, origin server header, etc., and
          b) Specializable to supply factory methods to override all the default classes instantiated by SimpleHTTPServer. This is important to achieve things like a bounded request queue.

          The parameters are also all settable in axis2.xml as part of the http TransportIn config.

          All axis2 tests pass, plus I've updated my application with a custom specialization of HttpFactory that is heavily configured and it also works properly.

          I'd like to look this over again tomorrow, and test the axis2.xml feature (not tested yet), but wanted to post this first version now to get comments on the approach.

          Deepal, Dims suggested you might be the right person to look this over? Also, Oleg, I'd appreciate any thoughts you have.

          The patch is against my local 1.0 repository, but I expect it will apply against the svn head since simplehttpserver patch applies against 1.0 (with different offset for the hunks in one file). If there are any issues, I'll make sure it applies cleanly against svn head tomorrow.

          Thanks,

          Chuck

          Show
          Chuck Williams added a comment - Sorry to be late getting back to this. Been a very busy week – just got some time this afternoon and evening. The attached ConfigurableSimpleHTTPServer.patch provides facilities to fully configure a SImpleHTTPServer for production use. A new class HttpFactory is introduced that is a) Configurable with the most commonly set parameters, like request core thread pool size, request socket timeout, origin server header, etc., and b) Specializable to supply factory methods to override all the default classes instantiated by SimpleHTTPServer. This is important to achieve things like a bounded request queue. The parameters are also all settable in axis2.xml as part of the http TransportIn config. All axis2 tests pass, plus I've updated my application with a custom specialization of HttpFactory that is heavily configured and it also works properly. I'd like to look this over again tomorrow, and test the axis2.xml feature (not tested yet), but wanted to post this first version now to get comments on the approach. Deepal, Dims suggested you might be the right person to look this over? Also, Oleg, I'd appreciate any thoughts you have. The patch is against my local 1.0 repository, but I expect it will apply against the svn head since simplehttpserver patch applies against 1.0 (with different offset for the hunks in one file). If there are any issues, I'll make sure it applies cleanly against svn head tomorrow. Thanks, Chuck
          Hide
          Chuck Williams added a comment -

          The attached ConfigurableSimpleHTTPServer.consolidated.patch combines both Oleg's new SimpleHTTPServer and my extensions to make it configurable into a single patch file that was created from today's (5/26) svn head. This includes a few simple bug fixes from the earlier separate configuration feature patch plus an update to the modules/core/conf/axis2.xml to include documentation and examples for all the new http configuraiton parameters.

          I've tested against the 1.0 distribution and all seems fine, including configuring the http transport from axis2.xml and specializing an HttpFactory for more detailed configuration (e.g., changing the type of request queue). I wanted to verify everything in the head, but my maven create-lib has been running all day and still isn't done, due to repeated timed out attempts to load more-or-less the same snapshot dependencies. I don't expect any problems against the head and will post again if there are any.

          Show
          Chuck Williams added a comment - The attached ConfigurableSimpleHTTPServer.consolidated.patch combines both Oleg's new SimpleHTTPServer and my extensions to make it configurable into a single patch file that was created from today's (5/26) svn head. This includes a few simple bug fixes from the earlier separate configuration feature patch plus an update to the modules/core/conf/axis2.xml to include documentation and examples for all the new http configuraiton parameters. I've tested against the 1.0 distribution and all seems fine, including configuring the http transport from axis2.xml and specializing an HttpFactory for more detailed configuration (e.g., changing the type of request queue). I wanted to verify everything in the head, but my maven create-lib has been running all day and still isn't done, due to repeated timed out attempts to load more-or-less the same snapshot dependencies. I don't expect any problems against the head and will post again if there are any.
          Hide
          Chuck Williams added a comment -

          Another note: in addition to the consolidated patch, the jar needs to be installed per the instructions in earlier comments.

          Show
          Chuck Williams added a comment - Another note: in addition to the consolidated patch, the jar needs to be installed per the instructions in earlier comments.
          Hide
          Oleg Kalnichevski added a comment -

          Chuck,

          Overall, the patch is okay with me. There is a couple of things I thought I should mention

          (1) HttpFactory: I am not a big fan of complex mega object factories used to create all sorts of objects including other object factories. I would rather prefer a simple configuration map containing only elemental values (Integer, String, etc), where concrete implementation classes can be specified by a class name. One should not have to override the HttpFactory just to drop in a custom implementation of an abstract interface. I do admit this is a matter of taste, though, so take it for what it is worth.

          (2) There is a minor bug in HttpFactory

          /** Setter for RequestCoreThreadPoolSize */
          public void setRequestCoreThreadPoolSize(int RequestCoreThreadPoolSize)

          { this.requestCoreThreadPoolSize = requestCoreThreadPoolSize; }

          I should probably be

          /** Setter for RequestCoreThreadPoolSize */
          public void setRequestCoreThreadPoolSize(int requestCoreThreadPoolSize) { this.requestCoreThreadPoolSize = requestCoreThreadPoolSize; }

          (3) HttpServiceProcessor as a subclass HttpService may not be good enough. As I mentioned before, HttpService has been written assuming a single thread of execution per HTTP connection. If you want to implement a dispatch mechanism intended to assign connections to different thread pools based on some properties of an incoming HTTP request, HttpService simply may not cut it.

          Cheers,

          Oleg

          Show
          Oleg Kalnichevski added a comment - Chuck, Overall, the patch is okay with me. There is a couple of things I thought I should mention (1) HttpFactory: I am not a big fan of complex mega object factories used to create all sorts of objects including other object factories. I would rather prefer a simple configuration map containing only elemental values (Integer, String, etc), where concrete implementation classes can be specified by a class name. One should not have to override the HttpFactory just to drop in a custom implementation of an abstract interface. I do admit this is a matter of taste, though, so take it for what it is worth. (2) There is a minor bug in HttpFactory /** Setter for RequestCoreThreadPoolSize */ public void setRequestCoreThreadPoolSize(int RequestCoreThreadPoolSize) { this.requestCoreThreadPoolSize = requestCoreThreadPoolSize; } I should probably be /** Setter for RequestCoreThreadPoolSize */ public void setRequestCoreThreadPoolSize(int requestCoreThreadPoolSize) { this.requestCoreThreadPoolSize = requestCoreThreadPoolSize; } (3) HttpServiceProcessor as a subclass HttpService may not be good enough. As I mentioned before, HttpService has been written assuming a single thread of execution per HTTP connection. If you want to implement a dispatch mechanism intended to assign connections to different thread pools based on some properties of an incoming HTTP request, HttpService simply may not cut it. Cheers, Oleg
          Hide
          Chuck Williams added a comment -

          Hi Oleg,

          Thanks for reviewing the patch and sharing your thoughts.

          Re. (1) I'm not a great fan of complex factory objects either, but it seems the best approach in this case. I thought about class-valued parameters, but a) wanted an enforced construction protocol to simplify writing specialized classes, and b) did not want to introduce reflection into the core http dispatch (currently reflection is only used at configuration time). I'd like to leave this as is unless others object.

          Re. (2) this was a silly typo – one of the dangers of naming setter and constructor parameters after the member variables they refer to. I had found it also and a couple others, all fixed in the consolidated patch.

          Re. (3) I understand the limitation. Perhaps it should be clarified in the comments, but other than this, do you see a need to change HttpFactory? Does the single-threaded constraint on HttpService also imply that one could not have two different SimpleHTTPServers listening on different ports in the same jvm / class loader?

          Re. my needs for multiple thread pools for different collections of operations, I think this is best done at the message receiver / operation level as it needs to be post-soap-dispatch. I expect this is generally true of all applications with similar needs, so the HttpService limitation is not a problem for this use case. However, I'm using a bounded request queue to protect against the server getting overwhelmed, but would still want administrative requests to get through, whence the idea for a second SimpleHTTPServer listening on an administrative port. Does that sound reasonable to you?

          FYI to all, my create-lib for the latest svn finally finished (took about 5 hours). The consolidated patch builds and passes all tests in the latest svn head.

          How do people feel about the new SimpleHTTPServer being committed?

          Show
          Chuck Williams added a comment - Hi Oleg, Thanks for reviewing the patch and sharing your thoughts. Re. (1) I'm not a great fan of complex factory objects either, but it seems the best approach in this case. I thought about class-valued parameters, but a) wanted an enforced construction protocol to simplify writing specialized classes, and b) did not want to introduce reflection into the core http dispatch (currently reflection is only used at configuration time). I'd like to leave this as is unless others object. Re. (2) this was a silly typo – one of the dangers of naming setter and constructor parameters after the member variables they refer to. I had found it also and a couple others, all fixed in the consolidated patch. Re. (3) I understand the limitation. Perhaps it should be clarified in the comments, but other than this, do you see a need to change HttpFactory? Does the single-threaded constraint on HttpService also imply that one could not have two different SimpleHTTPServers listening on different ports in the same jvm / class loader? Re. my needs for multiple thread pools for different collections of operations, I think this is best done at the message receiver / operation level as it needs to be post-soap-dispatch. I expect this is generally true of all applications with similar needs, so the HttpService limitation is not a problem for this use case. However, I'm using a bounded request queue to protect against the server getting overwhelmed, but would still want administrative requests to get through, whence the idea for a second SimpleHTTPServer listening on an administrative port. Does that sound reasonable to you? FYI to all, my create-lib for the latest svn finally finished (took about 5 hours). The consolidated patch builds and passes all tests in the latest svn head. How do people feel about the new SimpleHTTPServer being committed?
          Hide
          Oleg Kalnichevski added a comment -

          > Re. (3) I understand the limitation. Perhaps it should be clarified in the comments, but other than this,
          > do you see a need to change HttpFactory?

          Given your clarifications, I do not

          > Does the single-threaded constraint on HttpService also imply that one could not have two different SimpleHTTPServers
          > listening on different ports in the same jvm / class loader?

          Not at all. Multiple HttpService instances bound to different HTTP connections should be perfectly fine.

          > However, I'm using a bounded request queue to protect against the server getting overwhelmed, but would still
          > want administrative requests to get through, whence the idea for a second SimpleHTTPServer listening on an
          > administrative port. Does that sound reasonable to you?

          This certainly makes things much easier. I believe this is the way to go.

          Oleg

          Show
          Oleg Kalnichevski added a comment - > Re. (3) I understand the limitation. Perhaps it should be clarified in the comments, but other than this, > do you see a need to change HttpFactory? Given your clarifications, I do not > Does the single-threaded constraint on HttpService also imply that one could not have two different SimpleHTTPServers > listening on different ports in the same jvm / class loader? Not at all. Multiple HttpService instances bound to different HTTP connections should be perfectly fine. > However, I'm using a bounded request queue to protect against the server getting overwhelmed, but would still > want administrative requests to get through, whence the idea for a second SimpleHTTPServer listening on an > administrative port. Does that sound reasonable to you? This certainly makes things much easier. I believe this is the way to go. Oleg
          Hide
          Oleg Kalnichevski added a comment -

          Chuck,
          We are currently in the process of cutting the 4.0 alpha2 release. Just to be on the safe side could you please re-test your latest patch against this version? The release notes and API change summary can be found here:

          https://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/RELEASE_NOTES.txt

          Oleg

          Show
          Oleg Kalnichevski added a comment - Chuck, We are currently in the process of cutting the 4.0 alpha2 release. Just to be on the safe side could you please re-test your latest patch against this version? The release notes and API change summary can be found here: https://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/RELEASE_NOTES.txt Oleg
          Hide
          Chuck Williams added a comment -

          Deepal and Oleg,

          The new jar works great – no issues with it.

          However, I have run into a problem merging this patch with the latest svn head. ServiceGroupContextTest now fails. All other tests succeed.

          The problem is independent of which jar is used, so that is not the issue. The issue may be due to a recent independent change by Deepal that introduced merge conficts. I resolved these but perhaps not correctly. The change is:

          r411162 | deepal | 2006-06-02 04:02:19 -1000 (Fri, 02 Jun 2006) | 6 lines

          • fix security test failures
          • make to change the axis2 configuration path
          • no hard code path checking for services
          • you can change the context path by just adding parameter in axis2.xml
          • if you rename the war it will correctly generate wsdl
            (there were few bugs)

          ServiceGroupContextTest fails to recognize the second request sent as being the same service group as the first, and therefore gets this assertion error:

          Testcase: testEchoXMLSync(org.apache.axis2.engine.ServiceGroupContextTest): FAILED
          Number of requests should be 2 expected:<2> but was:<1>
          junit.framework.AssertionFailedError: Number of requests should be 2 expected:<2> but was:<1>
          at org.apache.axis2.engine.ServiceGroupContextTest.testEchoXMLSync(ServiceGroupContextTest.java:108)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          I'm attaching a new version of the patch called ConfigurableSimpleHTTPServer.complete.patch which applies against today's head with my merges for Deepal's upates. This exhibits the test failure. The patch applies against the top-level of the repository and makes all necessary changes. It assumes the jar is available to maven as jakarta-httpcore with version 4.0-20060602.

          Deepal, I'm hoping you will know what the issue is? If not and I need to debug it, I'll need to set up a special debugging environment. I don't understand how and where the ServiceGroupContext is set for the incoming request and couldn't find this easily with just source analysis tools. A hint about how this works, and how a prior ServiceGroupContext is supposed to get discovered even when there is a unique ServiceGroupContextId, would be helpful.

          The failing test is in the integration module and for this one module I cannot get mevenide to attach the debugger to a test run properly. The issue appears to be that integration has a long start-up time and mevenide tries to attach too soon. The purported fix, maven.netbeans.debug.delay. does not successfully introduce a delay into the attach.

          Show
          Chuck Williams added a comment - Deepal and Oleg, The new jar works great – no issues with it. However, I have run into a problem merging this patch with the latest svn head. ServiceGroupContextTest now fails. All other tests succeed. The problem is independent of which jar is used, so that is not the issue. The issue may be due to a recent independent change by Deepal that introduced merge conficts. I resolved these but perhaps not correctly. The change is: r411162 | deepal | 2006-06-02 04:02:19 -1000 (Fri, 02 Jun 2006) | 6 lines fix security test failures make to change the axis2 configuration path no hard code path checking for services you can change the context path by just adding parameter in axis2.xml if you rename the war it will correctly generate wsdl (there were few bugs) ServiceGroupContextTest fails to recognize the second request sent as being the same service group as the first, and therefore gets this assertion error: Testcase: testEchoXMLSync(org.apache.axis2.engine.ServiceGroupContextTest): FAILED Number of requests should be 2 expected:<2> but was:<1> junit.framework.AssertionFailedError: Number of requests should be 2 expected:<2> but was:<1> at org.apache.axis2.engine.ServiceGroupContextTest.testEchoXMLSync(ServiceGroupContextTest.java:108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) I'm attaching a new version of the patch called ConfigurableSimpleHTTPServer.complete.patch which applies against today's head with my merges for Deepal's upates. This exhibits the test failure. The patch applies against the top-level of the repository and makes all necessary changes. It assumes the jar is available to maven as jakarta-httpcore with version 4.0-20060602. Deepal, I'm hoping you will know what the issue is? If not and I need to debug it, I'll need to set up a special debugging environment. I don't understand how and where the ServiceGroupContext is set for the incoming request and couldn't find this easily with just source analysis tools. A hint about how this works, and how a prior ServiceGroupContext is supposed to get discovered even when there is a unique ServiceGroupContextId, would be helpful. The failing test is in the integration module and for this one module I cannot get mevenide to attach the debugger to a test run properly. The issue appears to be that integration has a long start-up time and mevenide tries to attach too soon. The purported fix, maven.netbeans.debug.delay. does not successfully introduce a delay into the attach.
          Hide
          Chuck Williams added a comment -

          I believe I understand how this is supposed to work now. There appear to be a couple bugs in Deepal's update to make the contextPath configurable, but fixing these did not resolve the failure of ServiceGroupContextTest. I'm flying to California today and so will have to debug this later.

          Here are the issues that appear to me to be bugs in the contextPath update. Both concern the difference between contextPath and contextPath+"/".

          In SimpleHTTPServer.getEPRForService(), I changed:
          return new EndpointReference(hostAddress + contextPath + serviceName);
          to:
          return new EndpointReference(hostAddress + contextPath + "/" + serviceName);

          In HTTPWorker.service(), I changed:
          if (!(uri.endsWith(contextPath))) {
          String serviceName = uri.replaceAll(contextPath, "");
          to:
          if (!(uri.endsWith(contextPath) || uri.endsWith(contextPath+"/"))) {
          String serviceName = uri.replaceAll(contextPath+"/", "");

          Surprisingly these changes had no effect on any test results.

          Show
          Chuck Williams added a comment - I believe I understand how this is supposed to work now. There appear to be a couple bugs in Deepal's update to make the contextPath configurable, but fixing these did not resolve the failure of ServiceGroupContextTest. I'm flying to California today and so will have to debug this later. Here are the issues that appear to me to be bugs in the contextPath update. Both concern the difference between contextPath and contextPath+"/". In SimpleHTTPServer.getEPRForService(), I changed: return new EndpointReference(hostAddress + contextPath + serviceName); to: return new EndpointReference(hostAddress + contextPath + "/" + serviceName); In HTTPWorker.service(), I changed: if (!(uri.endsWith(contextPath))) { String serviceName = uri.replaceAll(contextPath, ""); to: if (!(uri.endsWith(contextPath) || uri.endsWith(contextPath+"/"))) { String serviceName = uri.replaceAll(contextPath+"/", ""); Surprisingly these changes had no effect on any test results.
          Hide
          Chuck Williams added a comment -

          Fixed it on the plane. WIth the new version of ConfigurableSimpleHTTPServer.complete.patch all tests pass.

          The problem was mine. I inadvertantly undid an important change of Oleg's while merging Deepal's recent changes.

          Oleg, is this version of the jar solid, and how far away is the alpha? I'd like to commit these changes soon in order to avoid these kinds of merge problems as development progresses independently on the old code.

          Show
          Chuck Williams added a comment - Fixed it on the plane. WIth the new version of ConfigurableSimpleHTTPServer.complete.patch all tests pass. The problem was mine. I inadvertantly undid an important change of Oleg's while merging Deepal's recent changes. Oleg, is this version of the jar solid, and how far away is the alpha? I'd like to commit these changes soon in order to avoid these kinds of merge problems as development progresses independently on the old code.
          Hide
          Chuck Williams added a comment -

          Another, another merge conflict. Deepal's fixes to sessionContext memory leak conflicted with the new http server. New version of complete.patch resolves the conflict, applies to today's head, and passes all tests.

          Oleg, how about some (solid) jar in ibiblio? I'd sure like to commit this so independent axis2 fixes don't keep stepping on it!

          Chuck

          Show
          Chuck Williams added a comment - Another, another merge conflict. Deepal's fixes to sessionContext memory leak conflicted with the new http server. New version of complete.patch resolves the conflict, applies to today's head, and passes all tests. Oleg, how about some (solid) jar in ibiblio? I'd sure like to commit this so independent axis2 fixes don't keep stepping on it! Chuck
          Hide
          Ajith Harshana Ranabahu added a comment -

          Ahumm..
          Chuck , you are a committer now so just go ahead and commit to the head We'll sort it out if there are any problems

          Show
          Ajith Harshana Ranabahu added a comment - Ahumm.. Chuck , you are a committer now so just go ahead and commit to the head We'll sort it out if there are any problems
          Hide
          Oleg Kalnichevski added a comment -

          Chuck,
          The vote on alpha2 release is still running. I am planning to close the vote on Wednesday and cut the release on Thursday

          Oleg

          Show
          Oleg Kalnichevski added a comment - Chuck, The vote on alpha2 release is still running. I am planning to close the vote on Wednesday and cut the release on Thursday Oleg
          Hide
          Chuck Williams added a comment -

          Thanks Oleg.

          Deepal, any chance of holding off on further changes to the http transport until Thursday? I'll commit this then (after testing the alpha2 jar of course).

          Ajith, I'd love to commit now, but it would break the build unless everybody added the jakarta-httpcore jar to their maven repository manually. I think it is best to wait for Oleg to post a jar to ibiblio.

          Chuck

          Show
          Chuck Williams added a comment - Thanks Oleg. Deepal, any chance of holding off on further changes to the http transport until Thursday? I'll commit this then (after testing the alpha2 jar of course). Ajith, I'd love to commit now, but it would break the build unless everybody added the jakarta-httpcore jar to their maven repository manually. I think it is best to wait for Oleg to post a jar to ibiblio. Chuck
          Hide
          Chuck Williams added a comment -

          Latest version resolves yet more merge conflicts from today's head.

          Show
          Chuck Williams added a comment - Latest version resolves yet more merge conflicts from today's head.
          Hide
          Oleg Kalnichevski added a comment -

          Chuck et al,

          HttpCore 4.0-alpha2 is now available in the official Maven repository
          http://www.apache.org/dist/java-repository/httpcomponents-httpcore/jars/

          It may take a while for the release to get propagated the the ibiblio repository, though

          The Axis2 core SVN trunks compiles against HttpCore 4.0-alpha2 and all tests pass.

          I am attaching a new revision of the patch with the latest changes

          I'll probably hold off an official release announcement for a while to give you some time to test stuff just to make sure everything works as advertised.

          Oleg

          Show
          Oleg Kalnichevski added a comment - Chuck et al, HttpCore 4.0-alpha2 is now available in the official Maven repository http://www.apache.org/dist/java-repository/httpcomponents-httpcore/jars/ It may take a while for the release to get propagated the the ibiblio repository, though The Axis2 core SVN trunks compiles against HttpCore 4.0-alpha2 and all tests pass. I am attaching a new revision of the patch with the latest changes I'll probably hold off an official release announcement for a while to give you some time to test stuff just to make sure everything works as advertised. Oleg
          Hide
          Chuck Williams added a comment -

          Oleg,

          This is great news! I've got a little time to work on this today and hope to get things cleaned up and committed.

          Could you perhaps attach your latest changes as an incremental patch? I.e., as a patch against axis2 after the last version of ConfigurableSimpleHTTPServer.complete.patch that I posted? If that is difficult, I'll work with the new version of the complete patch that you posted.

          My issue is that Deepal has been changing the old implementation every day for about the past week. I'm fighting all the merge conflicts and have some locally at the moment.

          Thanks,

          Chuck

          Show
          Chuck Williams added a comment - Oleg, This is great news! I've got a little time to work on this today and hope to get things cleaned up and committed. Could you perhaps attach your latest changes as an incremental patch? I.e., as a patch against axis2 after the last version of ConfigurableSimpleHTTPServer.complete.patch that I posted? If that is difficult, I'll work with the new version of the complete patch that you posted. My issue is that Deepal has been changing the old implementation every day for about the past week. I'm fighting all the merge conflicts and have some locally at the moment. Thanks, Chuck
          Hide
          Chuck Williams added a comment -

          Oleg,

          I've got your chamges merged with Deepal's changes in the latest svn head, so don't worry about the incremental patch.

          Thanks,

          Chuck

          Show
          Chuck Williams added a comment - Oleg, I've got your chamges merged with Deepal's changes in the latest svn head, so don't worry about the incremental patch. Thanks, Chuck
          Hide
          Chuck Williams added a comment -

          This is now committed in svn. The issue should be marked resolved fixed – I don't have the rights to do that.

          Show
          Chuck Williams added a comment - This is now committed in svn. The issue should be marked resolved fixed – I don't have the rights to do that.
          Hide
          Davanum Srinivas added a comment -

          Please try now. you should have karma now.

          – dims

          Show
          Davanum Srinivas added a comment - Please try now. you should have karma now. – dims
          Hide
          Chuck Williams added a comment -

          Dims,

          I still don't have any additional operations, at least not with this account.

          Chuck

          Show
          Chuck Williams added a comment - Dims, I still don't have any additional operations, at least not with this account. Chuck
          Hide
          Davanum Srinivas added a comment -

          could u please log out and try log back in?

          – dims

          Show
          Davanum Srinivas added a comment - could u please log out and try log back in? – dims
          Hide
          Chuck Williams added a comment -

          I had tried logging out and logging back in before to no avail, but it works now. Thanks Dims!

          HttpCore is now part of axis2 and we have a new SimpleHTTPServer. Thanks Oleg!

          Show
          Chuck Williams added a comment - I had tried logging out and logging back in before to no avail, but it works now. Thanks Dims! HttpCore is now part of axis2 and we have a new SimpleHTTPServer. Thanks Oleg!
          Hide
          Oleg Kalnichevski added a comment -

          Chuck,
          I still would like to clean things up a little here and there (at the very least the old classes from HttpClient testing framework should be removed). I would also like to refactor the session context management code and improve cookie handling. Presently Set-Cookie2 headers generated by the HTTPWorker are not spec compliant.

          Do you want me to open a new bug or re-open this one?

          Oleg

          Show
          Oleg Kalnichevski added a comment - Chuck, I still would like to clean things up a little here and there (at the very least the old classes from HttpClient testing framework should be removed). I would also like to refactor the session context management code and improve cookie handling. Presently Set-Cookie2 headers generated by the HTTPWorker are not spec compliant. Do you want me to open a new bug or re-open this one? Oleg
          Hide
          Chuck Williams added a comment -

          This issue is resolved as the core implementation is committed and working. Axis2-812 continues with additional needed enhancements.

          Show
          Chuck Williams added a comment - This issue is resolved as the core implementation is committed and working. Axis2-812 continues with additional needed enhancements.

            People

            • Assignee:
              Unassigned
              Reporter:
              Oleg Kalnichevski
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development