10 Replies Latest reply on Jul 2, 2008 4:39 PM by Brice Ruth

    deploy ws-tx components external to .ear?

    Brice Ruth Novice

      We are preparing to deploy our first application with WS-TX. However, this will probably not be our only application to have that capability. Our question is how best to deploy the ws-tx capability into our environment. Up until now, we have been deploying the requisite wars with the application that needed it. Obviously, that works fine for a one-off solution but is not optimal for a shared environment.

      We have attempted to deploy the ws-tx endpoints as a sar. However, for application isolation purposes, we deploy each ear with a scoped classloader repository. This seems to cause problems when interacting with the ws-tx apps. Everything appears to start up fine, but when an incoming service request attempts to register a participant, it waits indefinitely in this block of code

      com.arjuna.wsc.RegistrationCoordinator

      lines 76 & 77

      RegistrationCoordinatorClient.getClient().sendRegister(addressingContext, protocolIdentifier, participantProtocolService) ;
      callback.waitUntilTriggered() ;

      the "waitUntilTriggered" just waits ...

      same setup (from the app side) works fine when ws-tx dependencies are deployed internal to the .ear

      The .sar file we are deploying is here: http://filebin.ca/vmkye/ws-tx.sar.zip

        • 1. Re: deploy ws-tx components external to .ear?
          Jonathan Halliday Master

          Future versions of XTS will support deployment as a .sar only, not bundling with an application. That's because it's the only way we can get crash recovery and bridging to work. So I definitely don't recommend putting XTS into your app's .ear as it's effectively an evolutionary dead-end.

          So that leaves us with the classloading issues between .sar and .ear. It's something we have been looking at a lot recently, as participant crash recovery is rather tricky when the participant .class can potentially be unloaded and reloaded during the transaction lifetime.

          We have a new JBossTS release going out shortly to support AS 5.0.CR1, after which we'll get into testing of these issues in more depth. We don't promise to support isolated classloaders for apps that use XTS, but we'll certainly bear that configuration possibility in mind as we work towards JBossTS 4.4.GA. Meanwhile if isolated classloading does not work I'm afraid your only option is not to use it.

          • 2. Re: deploy ws-tx components external to .ear?
            Brice Ruth Novice

             

            "jhalliday" wrote:
            Meanwhile if isolated classloading does not work I'm afraid your only option is not to use it.


            Yeah, actually, we tried that. And then we got into the issues with wstx-asl.jar again, which introduces that silly XmlStreamReader flush problem, it seems, without scoped classloading (on JBoss 4.3 EAP).

            We were trying to figure out why the scoped classloader would be presenting a problem, since it seems that the above referenced lines, in the RegistrationCoordinator are in ws-c.jar, contained within the .sar, so even with the scoped classloader, the global classloader should be loading the class that the callback is registered with. We looked at the class in question and everything is static, so as long as the same classloader is referenced, it should all be good, right?

            Does the .sar get its own classloader somehow? So the servlet receives its response and accesses a different class?

            • 3. Re: deploy ws-tx components external to .ear?
              Andrew Dinn Master

               


              "jhalliday" wrote:
              Meanwhile if isolated classloading does not work I'm afraid your only option is not to use it.


              Yeah, actually, we tried that. And then we got into the issues with wstx-asl.jar again, which introduces that silly XmlStreamReader flush problem, it seems, without scoped classloading (on JBoss 4.3 EAP).


              There is a patch for the flush problem which is hardly more than a one liner. It was included in JBossTS 4.3.0. Look at method output(Writer) in file

              http://anonsvn.labs.jboss.com/labs/jbosstm/tags/JBOSSTS_4_3_GA/XTS/WS-C/dev/src/com/arjuna/webservices/soap/SoapMessageBase.java

              and compare it with the version in the 4.2.3 releases, If you fix this you can then forget about scoped classloading.


              • 4. Re: deploy ws-tx components external to .ear?
                Brice Ruth Novice

                 

                "adinn" wrote:


                There is a patch for the flush problem which is hardly more than a one liner. It was included in JBossTS 4.3.0. Look at method output(Writer) in file

                http://anonsvn.labs.jboss.com/labs/jbosstm/tags/JBOSSTS_4_3_GA/XTS/WS-C/dev/src/com/arjuna/webservices/soap/SoapMessageBase.java

                and compare it with the version in the 4.2.3 releases, If you fix this you can then forget about scoped classloading.


                Yeah, we tried this, too, and unfortunately, it didn't seem to do the trick. Not sure why, but I'm pretty sure the current code has that fix in it. I'd welcome confirmation of that - it should be in the JARs that are contained in the .SAR zip that I referenced above. Maybe use JAD to verify that we put the fix in the right places?

                Thanks!

                • 5. Re: deploy ws-tx components external to .ear?
                  Andrew Dinn Master

                  Ok, here's the relevant output from 'javap -c'

                  public void output(java.io.Writer) throws java.io.IOException;
                   Code:
                   0: aload_0
                   1: aload_1
                   2: invokestatic #7; //Method com/arjuna/webservices/soap/SoapUtils.getXMLStreamWriter:(Ljava/io/Writer;)Ljavax/xml/stream/XMLStreamWriter;
                   5: invokespecial #8; //Method writeEnvelope:(Ljavax/xml/stream/XMLStreamWriter;)V
                   8: goto 24
                   11: astore_2
                   12: new #10; //class java/io/IOException
                   15: dup
                   16: aload_2
                   17: invokevirtual #11; //Method javax/xml/stream/XMLStreamException.toString:()Ljava/lang/String;
                   20: invokespecial #12; //Method java/io/IOException."<init>":(Ljava/lang/String;)V
                   23: athrow
                   24: return
                   Exception table:
                   from to target type
                   0 8 11 Class javax/xml/stream/XMLStreamException
                  


                  Looks to me like it is the old code. I only see calls to getXMLStreamWriter() and writeEnvelope() inside a try catch. No evidence of a call to flush(). Perhaps you could try again?


                  • 6. Re: deploy ws-tx components external to .ear?
                    Brice Ruth Novice

                     

                    "adinn" wrote:
                    Looks to me like it is the old code. I only see calls to getXMLStreamWriter() and writeEnvelope() inside a try catch. No evidence of a call to flush(). Perhaps you could try again?


                    OK, that's embarrassing. Sorry. I compared my ws-c.jar in my build directory to what was in the .sar and indeed, the one in the .sar is the original, not patched. Not sure how that happened.

                    However, when I put in the updated one (confirmed w/ javap, now has a flush()), I still get this exception:

                    11:59:27,506 ERROR [JaxWSTransactionBridgeHandler] com.arjuna.wst.SystemException: Receiver[com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in attribute value
                    at [row,col {unknown-source}]: [1,1000]]

                    Which I think is caused by the XMLStreamReader still, right?

                    Thanks, Andrew!

                    • 7. Re: deploy ws-tx components external to .ear?
                      Brice Ruth Novice

                      Here's the ws-tx.sar with the updated ws-c.jar, for confirmation.

                      http://filebin.ca/cxqfyw/ws-tx.sar.zip

                      • 8. Re: deploy ws-tx components external to .ear?
                        Brice Ruth Novice

                        OK, I've taken a slightly different tack and am trying the JBossTS 4.3GA .sar, built against JBossAS 4.3EAP.

                        Everything deploys fine and I don't appear to get any XMLStreamReader issues while running w/o the scoped classloader, but it seems like the coordinator isn't figuring out its "wsa:From" address correctly.

                        Here's what I see in the POST to the remote coordinator:

                        http://localhost:8080/jbossxts/soap/RegistrationRequester

                        However, the AS is started with -b 127.0.0.3 (which technically is a localhost, but it is not *the* localhost). I don't imagine this is hard-coded anywhere, so there must be some type of translation that's putting "localhost" in there instead of the actual address?

                        Getting closer, I think ...

                        • 9. Re: deploy ws-tx components external to .ear?
                          Brice Ruth Novice

                          (Thanks, Jeff) - found where localhost is set. Using ${jboss.bind.address} in web.xml for the time being, and that's working better. The remote coordinator is getting the correct wsa:From, and the 'local' coordinator is getting a response.

                          I'll do some more testing now to see how the 4.3.GA .sar stacks up.

                          • 10. Re: deploy ws-tx components external to .ear?
                            Brice Ruth Novice

                            Good news, the 4.3 .sar appears to work with and without the scoped classloader configuration. This is good news, indeed. From what I can tell, the Bridge doesn't appear to have any issues with 4.3, either (limited testing, admittedly).