ODE
  1. ODE
  2. ODE-758

Disable Process2Process communication

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.3, 2.0-beta3
    • Fix Version/s: 1.3.4
    • Component/s: BPEL Runtime
    • Labels:
      None

      Description

      Hello all,

      I have a problem with the Process2Process communication inside the ODE. Basically I need to implement a BPEL process that uses and implements the same WSDL. For example I have a service A with two methods request-response "createEntity" and one way "confirmCreation", I expect my process to call "createEntity" method and then wait untill the "confirmCreation" method will be called on it, however since ODE route all MEXes internaly despite the fact that process actually only implements one single operation "confirmCreation" I'm getting an MEX expire and failed state.

      Would it be possible to fix the P2P communication so that it would only happen when ODE as a recipient side is able to handle the operation, otherwise just proceed with a call though Integration Layer.

      Renat

      1. P2PDemo.zip
        13 kB
        Renat Zubairov

        Issue Links

          Activity

          Hide
          Terry Mueller added a comment -

          WORKAROUND: Comment out the following lines in ODEWSProcess.java to get this to work:

          // if (partnerEndpoint != null)
          // p2pProcesses = _server.route(partnerEndpoint.serviceName, new DbBackedMessageImpl(mexdao.getRequest()));

          Show
          Terry Mueller added a comment - WORKAROUND: Comment out the following lines in ODEWSProcess.java to get this to work: // if (partnerEndpoint != null) // p2pProcesses = _server.route(partnerEndpoint.serviceName, new DbBackedMessageImpl(mexdao.getRequest()));
          Hide
          Renat Zubairov added a comment -

          Hello Terry,

          I was also looking at this place there is actually an if clause in following lines which is checking wherever p2pProcesses is not null, so if you would comment out this part may be you should also delete the whole If statement, however before I would propose to discuss a different options.
          Actually in the ODE documentation P2P communication is described as a feature, not as a bug. It's obviously better from the reliability point of view that one process sending a message to another process reliably and no exceptions could happen there, however sometimes it's better that integration layer would do this "shortcut" instead of delegating it to ODE core.
          Another possible solution would be to determine routing rule not based on the Service QName but on the Port Name (or QName with WSDL TNS) so that if any of the deployed processes implements a given Port (not Service) then do a shorcut.

          Renat

          Show
          Renat Zubairov added a comment - Hello Terry, I was also looking at this place there is actually an if clause in following lines which is checking wherever p2pProcesses is not null, so if you would comment out this part may be you should also delete the whole If statement, however before I would propose to discuss a different options. Actually in the ODE documentation P2P communication is described as a feature, not as a bug. It's obviously better from the reliability point of view that one process sending a message to another process reliably and no exceptions could happen there, however sometimes it's better that integration layer would do this "shortcut" instead of delegating it to ODE core. Another possible solution would be to determine routing rule not based on the Service QName but on the Port Name (or QName with WSDL TNS) so that if any of the deployed processes implements a given Port (not Service) then do a shorcut. Renat
          Hide
          Renat Zubairov added a comment -

          Hello Antonie, Terry, all

          I was digging the sources of ODE and found following method:

          org.apache.ode.bpel.engine.BpelEngineImpl#route(QName, Message)

          Which returns the process that could be used for P2P communication was changed from using Entpoints to using Service QNames by Antonie committed to revision 830367 (I'm talking here about ODE_1X trunk) with following comments:

          -Introduced new property "p2p.mex.timeout" used as default value for process-to-process mex timeout
          -Changed _serviceMap type to Map<QName, List<BpelProcess>> to optimize routing common case
          -MEX timeout no longer multipled by 1.5 for invokeCheck

          My idea was instead of commenting the routing completely was to enable internal P2P shortcut only when ODE is quite sure a recipient process will be able to handle this message. In ideal case that would be checking wherever process implement that particular operation of that particular port-type. However for my use-cases it would be enough just to check wherever port-type or Endpoint is implemented by the ODE.
          Worth case scenario would be a configured on/off switch for P2P interaction.

          What do you think?

          Renat

          Show
          Renat Zubairov added a comment - Hello Antonie, Terry, all I was digging the sources of ODE and found following method: org.apache.ode.bpel.engine.BpelEngineImpl#route(QName, Message) Which returns the process that could be used for P2P communication was changed from using Entpoints to using Service QNames by Antonie committed to revision 830367 (I'm talking here about ODE_1X trunk) with following comments: -Introduced new property "p2p.mex.timeout" used as default value for process-to-process mex timeout -Changed _serviceMap type to Map<QName, List<BpelProcess>> to optimize routing common case -MEX timeout no longer multipled by 1.5 for invokeCheck My idea was instead of commenting the routing completely was to enable internal P2P shortcut only when ODE is quite sure a recipient process will be able to handle this message. In ideal case that would be checking wherever process implement that particular operation of that particular port-type. However for my use-cases it would be enough just to check wherever port-type or Endpoint is implemented by the ODE. Worth case scenario would be a configured on/off switch for P2P interaction. What do you think? Renat
          Hide
          Renat Zubairov added a comment -

          This is a package with ODE process.
          Process implements an operation (from one endpoint) and at the same time invokes another operation (from another endpoint).

          Show
          Renat Zubairov added a comment - This is a package with ODE process. Process implements an operation (from one endpoint) and at the same time invokes another operation (from another endpoint).
          Hide
          Renat Zubairov added a comment -

          BTW the ODE version is something around 1.3.3 not 2.0

          Show
          Renat Zubairov added a comment - BTW the ODE version is something around 1.3.3 not 2.0
          Hide
          Renat Zubairov added a comment -

          I wish I could debug my intalio server that have an ODE inside in order to produce the better solution, however it seems to be extremely hard to do
          So, I would vote for commenting out the P2P communication completely.

          Show
          Renat Zubairov added a comment - I wish I could debug my intalio server that have an ODE inside in order to produce the better solution, however it seems to be extremely hard to do So, I would vote for commenting out the P2P communication completely.
          Hide
          Rafal Rusin added a comment -

          Hello, I added a switch for disabling P2P communication in deploy.xml in ODE-1.X.
          You can use it like this:

          <dd:invoke partnerLink="..." usePeer2Peer="false">
          <dd:service name="..." port="..." />
          </dd:invoke>

          Let me know if that works for you.

          Regards

          Show
          Rafal Rusin added a comment - Hello, I added a switch for disabling P2P communication in deploy.xml in ODE-1 .X. You can use it like this: <dd:invoke partnerLink="..." usePeer2Peer="false"> <dd:service name="..." port="..." /> </dd:invoke> Let me know if that works for you. Regards
          Hide
          Hudson added a comment -

          Integrated in ODE-1.x #82 (See http://hudson.zones.apache.org/hudson/job/ODE-1.x/82/)
          : Added switch for disabling P2P communication

          Show
          Hudson added a comment - Integrated in ODE-1 .x #82 (See http://hudson.zones.apache.org/hudson/job/ODE-1.x/82/ ) : Added switch for disabling P2P communication
          Hide
          Renat Zubairov added a comment -

          Thnx!.. great idea, seems like a workable solution.... It means that one can explicitly disable process 2 process communication per message exchange right?

          Show
          Renat Zubairov added a comment - Thnx!.. great idea, seems like a workable solution.... It means that one can explicitly disable process 2 process communication per message exchange right?
          Hide
          Rafal Rusin added a comment -

          Right, per partnerRole partnerLink actually (invoke direction).

          Regards

          Show
          Rafal Rusin added a comment - Right, per partnerRole partnerLink actually (invoke direction). Regards
          Hide
          Hudson added a comment -

          Integrated in ODE-1.x #83 (See http://hudson.zones.apache.org/hudson/job/ODE-1.x/83/)
          : Test case

          Show
          Hudson added a comment - Integrated in ODE-1 .x #83 (See http://hudson.zones.apache.org/hudson/job/ODE-1.x/83/ ) : Test case
          Hide
          Tammo van Lessen added a comment -

          fixed for a while.

          Show
          Tammo van Lessen added a comment - fixed for a while.

            People

            • Assignee:
              Rafal Rusin
              Reporter:
              Terry Mueller
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development