8 Replies Latest reply on Jun 22, 2006 7:58 AM by xiaoqj

    Trouble when enrolling remote participant

    xiaoqj

      I'm trying to deploy the elementary restaurant service at another jboss instance(192.168.0.49:8080), while the composite service remains at the original jboss instance(192.168.0.56:8080) where the jsp portal stays.

      After RestaurantServiceAT received the SOAP request, it's just stuck at participant enrollment.

      16:41:09,572 INFO [STDOUT] RestaurantServiceAT transaction id =AtomicTransactio
      nIdentifier: -3f57ffc8:403:4497b265:f
      16:41:09,572 INFO [STDOUT] RestaurantServiceAT - enrolling...


      Then the composite service cannot wait forever, so it timed out.

      The following is the soap request to RestaurantServiceAT:

      <?xml version="1.0" encoding="UTF-8"?>
      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <soapenv:Header>
       <wscoor:CoordinationContext xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">
       <wscoor:Identifier xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">-3f57ffc8:403:4497b265:f</wscoor:Identifier>
       <wscoor:CoordinationType xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">http://schemas.xmlsoap.org/ws/2004/10/wsat</wscoor:CoordinationType>
       <wscoor:RegistrationService xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">
       <wsa:Address xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://192.168.0.56:8080/xts/soap/RegistrationCoordinator</wsa:Address>
       <wsa:ReferenceParameters xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
       <wsarj:InstanceIdentifier xmlns:wsarj="http://schemas.arjuna.com/ws/2005/10/wsarj">-3f57ffc8:403:4497b265:f</wsarj:InstanceIdentifier>
       </wsa:ReferenceParameters>
       </wscoor:RegistrationService>
       </wscoor:CoordinationContext>
       </soapenv:Header>
       <soapenv:Body>
       <ns1:bookSeats xmlns:ns1="http://www.jboss.com/jbosstm/xts/demo/Restaurant">
       <in0>1</in0>
       </ns1:bookSeats>
       </soapenv:Body>
      </soapenv:Envelope>

      Then the context identifier matches and RegistrationCoordinator is also correct. And I didn't change the ws-c.war's context-root in application.xml

      The application.xml
      <application>
       <display-name>XML Transaction Service Demo</display-name>
      
       <description>XML Transaction Service Demo</description>
      
       <module>
       <web>
       <web-uri>ws-c.war</web-uri>
       <context-root>/xts</context-root>
       </web>
       </module>
       ...
      </application>


        • 1. Re: Trouble when enrolling remote participant
          kconner

          The problem probably lies with the configuration of the application on 192.168.0.49. Have you rebuilt the application for this configuration?

          The web.xml file in the ws-c.war contains an init-param that specifies the base URI for the SOAP multiplexor, this is updated by the build.xml file. The multiplexor is the endpoint through which the participants will be exposed.

          The easiest way to set this up is to copy the jboss.properties file and configure the hosts separately, e.g. create jboss-host1.properties and jboss-host2.properties files.

          You can use these files, once they are confgured, to build each ear file, by executing

          build.sh jboss-host1 clean build
          and
          build.sh jboss-host2 clean build

          You must copy the ear file from the build directory after each build.

          Kev

          • 2. Re: Trouble when enrolling remote participant
            kconner

            I should add that you can verify if this is the problem by capturing the SOAP traffic from the second host, either at the network level or via a proxy.

            The first WS-TX message from the second host to the first will be a register message targetted at the registration coordinator. This message will contain a WS-A ReplyTo header that must refer to a service exposed via the multiplexor endpoint on the second host.

            Kev

            • 3. Re: Trouble when enrolling remote participant
              xiaoqj

              It works, Thank you. The BaseHttpURI init-param in 192.168.0.49 is configured wrongly.

              Another question about the times out of rpc call in composite service(CS). In the above example the times-out happens when enrolling participant , which has no serious impact over tx's final result.

              What if the times-out happened just after the participantManager.completed() succeeded but before the rpc response arrived, it's very rare although. Then the CS would think the called service failed, while the coordinator assumed it's completed. If at last the CS makes decision tx.close() using WS-BA. Then final result will be CS thinks this tx branch failed, but in fact it's completed.

              How does WS-BA fight against such a transaction execution sequence.

              • 4. Re: Trouble when enrolling remote participant
                xiaoqj

                Is SOAP multiplexor the same concept as a local subordinate coordinator?

                • 5. Re: Trouble when enrolling remote participant
                  marklittle

                  No. A subordinate coordinator has logging and recovery semantics associated with it in the same was as a root transaction coordinator.

                  • 6. Re: Trouble when enrolling remote participant
                    kconner

                     

                    How does WS-BA fight against such a transaction execution sequence.

                    The normal action would be for the application to cancel the business activity. The coordinator would then call each participant and request a compensation.

                    Kev


                    • 7. Re: Trouble when enrolling remote participant
                      kconner

                      The SOAP multiplexor is a servlet which is responsible for handling all SOAP requests involved in the WS-TX protocols, it plays no part in the orchestration of the transaction.

                      • 8. Re: Trouble when enrolling remote participant
                        xiaoqj

                         

                        The normal action would be for the application to cancel the business activity. The coordinator would then call each participant and request a compensation.

                        So in this case, cancellation will inevitablely involve compensation operation. The assertion holds especially for complex composite services. Half-way cancellation means compensation.

                        Compensation operation may fails, which is indicated by Faulting_Compensating state. And the fault in forward flow is remembered by Faulting_Active state.

                        But in current WS-BA spec, when the participant is in Cancelling state from the perspective of coordinator, a Fault notification is received, then the coordinator can not tell whether it's caused by failure in forward flow or backward flow. So it's a question what's the next state, Faulting_Active or Faulting_Compensating?