Axis2
  1. Axis2
  2. AXIS2-4944

Improve Axis2 local transport to work with Apache Synapse's nhttp transport

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: nightly
    • Fix Version/s: 1.7.0
    • Component/s: transports
    • Labels:
      None
    • Environment:
      Ubuntu 10.04
      Sun JDK 1.6

      Description

      Currently we can not use the axis2 local-transport with Apache Synapse's nhttp transport.

      I am looking into improving the existing local-transport of axis2 to work with nhttp transport.

      I will provide a patch to fix this.

      1. synapse.xml
        2 kB
        Heshan Suriyaarachchi
      2. AXIS2-4944-patch-ver5.txt
        12 kB
        Heshan Suriyaarachchi
      3. AXIS2-4944-patch-ver3.txt
        8 kB
        Heshan Suriyaarachchi
      4. AXIS2-4944-patch-ver2.txt
        8 kB
        Heshan Suriyaarachchi
      5. AXIS2-4944-patch.txt
        10 kB
        Heshan Suriyaarachchi

        Issue Links

          Activity

          Hide
          Paul Khodchenkov added a comment -

          I have found four use cases which should be supported when using local transport in ESB:
          1) proxy->proxy (works fine with NonBlockingLocalTransportSender)
          2) proxy->service (works fine with NonBlockingLocalTransportSender)
          3) proxy->mediator blocking call-> service (works fine with LocalTransportSender)
          4) proxy->mediator blocking call->proxy->proxy (LocalTransportSender and NonBlockingLocalTransportSender can't handle this scenario)

          Show
          Paul Khodchenkov added a comment - I have found four use cases which should be supported when using local transport in ESB: 1) proxy->proxy (works fine with NonBlockingLocalTransportSender) 2) proxy->service (works fine with NonBlockingLocalTransportSender) 3) proxy->mediator blocking call-> service (works fine with LocalTransportSender) 4) proxy->mediator blocking call->proxy->proxy (LocalTransportSender and NonBlockingLocalTransportSender can't handle this scenario)
          Hide
          Paul Khodchenkov added a comment -

          The following did the trick with Axis2 Stub in mediator in ESB axis2.xml:
          <transportSender name="local" class="org.apache.axis2.transport.local.NonBlockingLocalTransportSender"/>
          <transportSender name="local2" class="org.apache.axis2.transport.local.LocalTransportSender"/>
          I added "local2" transport. So axis2 stub need to use "local2://localhost/services/MyProxy", but proxy->proxy should use "local".

          Show
          Paul Khodchenkov added a comment - The following did the trick with Axis2 Stub in mediator in ESB axis2.xml: <transportSender name="local" class="org.apache.axis2.transport.local.NonBlockingLocalTransportSender"/> <transportSender name="local2" class="org.apache.axis2.transport.local.LocalTransportSender"/> I added "local2" transport. So axis2 stub need to use "local2://localhost/services/MyProxy", but proxy->proxy should use "local".
          Hide
          Paul Khodchenkov added a comment -

          Having the similar issue with 'Message Receiver not found" in WSO2 ESB when using Axis2 Stub in mediator with local transport which points to a proxy. Is it possible to improve Local Transport so it correctly can handle proxy->proxy,proxy->service and proxy->mediator->proxy scenarios?
          http://wso2.org/forum/thread/12661

          Show
          Paul Khodchenkov added a comment - Having the similar issue with 'Message Receiver not found" in WSO2 ESB when using Axis2 Stub in mediator with local transport which points to a proxy. Is it possible to improve Local Transport so it correctly can handle proxy->proxy,proxy->service and proxy->mediator->proxy scenarios? http://wso2.org/forum/thread/12661
          Hide
          Heshan Suriyaarachchi added a comment -

          Hi Andreas,

          The NonBlockingLocalTransportSender is used to talk to a proxy service from another proxy service. Since the nhttp transport is written in a non blocking manner, NonBlockingLocalTransport will work against nhttp transport. Since, we are using this TransportSender to talk between proxy services, it's difficult to come up with a test case (test client) for this particular usecase.

          Since we are using NonBlockingLocalTransportSender to handle a special case (in which we are working against a non-blocking transport), the LocalTransportTest test will fail for NonBlockingLocalTransportSender. Please refer Axis-dev for the discussion we had on [1] where we discussed this in-detail.

          The main reason for doing this local-transport related change at axis2 level is to remove the code duplication. Otherwise if we move the NonBlockingLocalTransport related logic to Synapse, we might have to duplicate the same local-transport related code there and improve it.

          If we dont include this improvement into Axis2-local transport, then we have to improve the local transport in such a way that a user should be able to extended the local transport implementation and write a custom implementation. That will help us to move the Synapse specific local transport to Synapse itself.

          [1] - http://markmail.org/thread/qigfb5asu22qestz

          Show
          Heshan Suriyaarachchi added a comment - Hi Andreas, The NonBlockingLocalTransportSender is used to talk to a proxy service from another proxy service. Since the nhttp transport is written in a non blocking manner, NonBlockingLocalTransport will work against nhttp transport. Since, we are using this TransportSender to talk between proxy services, it's difficult to come up with a test case (test client) for this particular usecase. Since we are using NonBlockingLocalTransportSender to handle a special case (in which we are working against a non-blocking transport), the LocalTransportTest test will fail for NonBlockingLocalTransportSender. Please refer Axis-dev for the discussion we had on [1] where we discussed this in-detail. The main reason for doing this local-transport related change at axis2 level is to remove the code duplication. Otherwise if we move the NonBlockingLocalTransport related logic to Synapse, we might have to duplicate the same local-transport related code there and improve it. If we dont include this improvement into Axis2-local transport, then we have to improve the local transport in such a way that a user should be able to extended the local transport implementation and write a custom implementation. That will help us to move the Synapse specific local transport to Synapse itself. [1] - http://markmail.org/thread/qigfb5asu22qestz
          Hide
          Andreas Veithen added a comment -

          Any update on this? I'm really -1 to add code to Axis2 that is known not to work...

          Show
          Andreas Veithen added a comment - Any update on this? I'm really -1 to add code to Axis2 that is known not to work...
          Hide
          Andreas Veithen added a comment -

          There is an issue with this change.

          LocalResponder#handleResponse incorrectly sets serverSide=true, so that NonBlockingLocalTransportSender will not work correctly in a normal (non Synapse) Axis2 configuration.

          Steps to reproduce this issue:

          • In transport/local/test-resources/org/apache/axis2/transport/local/axis2.xml replace LocalTransportSender by NonBlockingLocalTransportSender.
          • Run the unit test in LocalTransportTest.

          Result: the test fails with "Message Receiver not found"

          Show
          Andreas Veithen added a comment - There is an issue with this change. LocalResponder#handleResponse incorrectly sets serverSide=true, so that NonBlockingLocalTransportSender will not work correctly in a normal (non Synapse) Axis2 configuration. Steps to reproduce this issue: In transport/local/test-resources/org/apache/axis2/transport/local/axis2.xml replace LocalTransportSender by NonBlockingLocalTransportSender. Run the unit test in LocalTransportTest. Result: the test fails with "Message Receiver not found"
          Hide
          Andreas Veithen added a comment -

          Just a question: if I'm not mistaken, it is a known fact that the Synapse NHTTP transport (at least the sender part) only works in Synapse, but is incompatible with Axis2. Are we sure that the change described in this JIRA is not just a workaround for a problem in Synapse?

          Show
          Andreas Veithen added a comment - Just a question: if I'm not mistaken, it is a known fact that the Synapse NHTTP transport (at least the sender part) only works in Synapse, but is incompatible with Axis2. Are we sure that the change described in this JIRA is not just a workaround for a problem in Synapse?
          Hide
          Amila Chinthaka Suriarachchi added a comment -

          applied the patch with revision 1073331

          Show
          Amila Chinthaka Suriarachchi added a comment - applied the patch with revision 1073331
          Hide
          Heshan Suriyaarachchi added a comment -

          Hi Amila,

          I have incorporated the suggested improvements to the patch. I ran all axis2 tests. Tests pass without any issues.

          Attaching the patch(AXIS2-4944-patch-ver5.txt).

          Show
          Heshan Suriyaarachchi added a comment - Hi Amila, I have incorporated the suggested improvements to the patch. I ran all axis2 tests. Tests pass without any issues. Attaching the patch( AXIS2-4944 -patch-ver5.txt).
          Hide
          Ruwan Linton added a comment -

          Postponing to the next version

          Show
          Ruwan Linton added a comment - Postponing to the next version
          Hide
          Amila Chinthaka Suriarachchi added a comment -

          There are two issues with this patch which causes Axis2 test failures.

          1. you always set the following parameter which changes the axis2 default flow
          msgCtx.setProperty(IN_MESSAGE_CONTEXT, inMessageContext);

          2.
          MessageContext proxyInMessageContext = msgContext.
          getOperationContext().getMessageContext(WSDL2Constants.MESSAGE_LABEL_IN);

          this gives null pointer exception with some test cases.

          you need to put null check for operation context.

          please attach a bug fixed patch.

          Show
          Amila Chinthaka Suriarachchi added a comment - There are two issues with this patch which causes Axis2 test failures. 1. you always set the following parameter which changes the axis2 default flow msgCtx.setProperty(IN_MESSAGE_CONTEXT, inMessageContext); 2. MessageContext proxyInMessageContext = msgContext. getOperationContext().getMessageContext(WSDL2Constants.MESSAGE_LABEL_IN); this gives null pointer exception with some test cases. you need to put null check for operation context. please attach a bug fixed patch.
          Hide
          Heshan Suriyaarachchi added a comment -

          Andreas,

          As Amila has explained, currently if we use the axis2 local transport within Synapse's proxy service, it fails. It is because of the blocking nature of the local transport.

          I am attaching a sample Synapse configuration. It will help you to understand what I am trying to do.

          Furthermore, this is an improvement to the local transport and it does not break the existing functionality of the local transport.

          Show
          Heshan Suriyaarachchi added a comment - Andreas, As Amila has explained, currently if we use the axis2 local transport within Synapse's proxy service, it fails. It is because of the blocking nature of the local transport. I am attaching a sample Synapse configuration. It will help you to understand what I am trying to do. Furthermore, this is an improvement to the local transport and it does not break the existing functionality of the local transport.
          Hide
          Amila Chinthaka Suriarachchi added a comment -

          Axis2 local transport is written to invoke a service within the same AxisConfiguration without going through the http. As all the other transports it also assumes transport invocation is blocking. What I mean blocking is transport sender thread blocks until the response comes.

          But think about a scenario where some service invokes a synapse proxy service which talk to an http end point using nhttp transport. Since nhttp is not blocking the thread returns before getting the response. Therefore LocalTransportResponder has to create an message context and inject the response once it comes.

          Heshan please attach a sample synapse configuration file which explains this situation.

          Show
          Amila Chinthaka Suriarachchi added a comment - Axis2 local transport is written to invoke a service within the same AxisConfiguration without going through the http. As all the other transports it also assumes transport invocation is blocking. What I mean blocking is transport sender thread blocks until the response comes. But think about a scenario where some service invokes a synapse proxy service which talk to an http end point using nhttp transport. Since nhttp is not blocking the thread returns before getting the response. Therefore LocalTransportResponder has to create an message context and inject the response once it comes. Heshan please attach a sample synapse configuration file which explains this situation.
          Hide
          Andreas Veithen added a comment -

          Heshan,

          Can you provide an explanation of what the actual issue is? I don't understand what it means to make transport X work with transport Y where X and Y are different protocols.

          Show
          Andreas Veithen added a comment - Heshan, Can you provide an explanation of what the actual issue is? I don't understand what it means to make transport X work with transport Y where X and Y are different protocols.
          Hide
          Heshan Suriyaarachchi added a comment -

          Attaching the patch with the proposed changes.

          Show
          Heshan Suriyaarachchi added a comment - Attaching the patch with the proposed changes.
          Hide
          Heshan Suriyaarachchi added a comment -

          Hi Ruwan,

          Thanks for the feedback on the patch. I will improve and attach a new patch.

          Show
          Heshan Suriyaarachchi added a comment - Hi Ruwan, Thanks for the feedback on the patch. I will improve and attach a new patch.
          Hide
          Ruwan Linton added a comment -

          Heshan this patch uses a depricated method on the BuilderUtils class, can you look for an alternative to that? Also optimize imports before submitting the next patch.

          Show
          Ruwan Linton added a comment - Heshan this patch uses a depricated method on the BuilderUtils class, can you look for an alternative to that? Also optimize imports before submitting the next patch.
          Hide
          Heshan Suriyaarachchi added a comment -

          Reattaching the patch with minor modifications

          Show
          Heshan Suriyaarachchi added a comment - Reattaching the patch with minor modifications
          Hide
          Heshan Suriyaarachchi added a comment -

          I have tested this patch and this does not break the existing functionality of the local transport.

          Show
          Heshan Suriyaarachchi added a comment - I have tested this patch and this does not break the existing functionality of the local transport.
          Hide
          Heshan Suriyaarachchi added a comment -

          Attaching the patch to fix the issue.

          I have tested it locally and with this fix, we can use the axis2 local-transport with Synapse's nhttp transport.

          Show
          Heshan Suriyaarachchi added a comment - Attaching the patch to fix the issue. I have tested it locally and with this fix, we can use the axis2 local-transport with Synapse's nhttp transport.

            People

            • Assignee:
              Ruwan Linton
              Reporter:
              Heshan Suriyaarachchi
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development