deploy ws-tx components external to .ear?

[ruthbd]

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

[jhalliday]

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.

[ruthbd]

"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?

[adinn]

"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.

[ruthbd]

"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!

[adinn]

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?

[ruthbd]

"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!

[ruthbd]

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

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

[ruthbd]

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 ...

[ruthbd]

(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.

[ruthbd]

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).