[jbossts-issues] [JBoss JIRA] Commented: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint
Andrew Dinn (JIRA)
jira-events at lists.jboss.org
Wed Sep 1 11:07:13 EDT 2010
[ https://jira.jboss.org/browse/JBTM-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12548357#action_12548357 ]
Andrew Dinn commented on JBTM-776:
Ok, this is essentially complete but there is one wrinkle left outstanding.
The old client implementation of the Completion protocol would wait forever after sending a Commit message for a Committed or Aborted message to be returned. So, there was effectively no client timeout once the initial one way request was delivered. By contrast, the RPC based exchange is at the mercy of the JaxWS code as far as timeouts are concerned. If the JaxWS client decides to stop waitign for a response from the server it can drop the connection and return early.
With JBossWS-CXF the default appears to be for the RPC-based commit request to time out after somewhere between 80 and 100 seconds. So, if a commit operation takes a very very long time because, say, one of the web servers is slow to respond or because, maybe, there are a lot of web service participants to contact, the client may give up and claim that the commit request timed out. Note that this is not because the HTTP connection has been lost -- it's just that when the service request takes too long the client will return early.
At present there is no simple way to configure this timeout in a stack independent way. A JIRA has been raised to provide a generic way to do this and we also intend to submit a proposal for this to be included as standard in JaxWS.
This will be dealt with in a later JIRA as will documentation of the new config options raised by this change.
> Enable XTS client deployments without the need for a JaxWS endpoint
> Key: JBTM-776
> URL: https://jira.jboss.org/browse/JBTM-776
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.12.0
> Reporter: Andrew Dinn
> Assignee: Andrew Dinn
> It would be very useful if the XTS client code could be deployed embedded with JBossTS without the need to deploy any JaxWS endpoints i.e. so that it only required httpclient capability. This would allow development of, say, CXF-based clients running on a simple desktop system which use embedded TS/XTS to provide transactional access to web services. Removal of the JaxWS endpoints avoids the need to expose the desktop machine with a public IP address, open up fire walls etc which are serious barriers to such deployments.
> At present implementing this change is stopped by two factors:
> - the XTS code cannot be built and configured as a client only deployment
> - the Completion protocols used by WS-AT and WS-BA to terminate transactions employ one way messages
> the latter requirement forces the client to expose an endpoint for delivery of the message confirming and identifying the outcome of a termination request.
> The first problem will be addressed by a related issue.
> Solving the second problem requires implementing an alternative version of the Completion services employing protocol messages with an RPC message exchange pattern. For WS-BA this raises no serious issues since the BA standard does not specify the details of the Completion protocol -- we can do what we like in this regard.
> In the case of WS-AT the spec does define the protocol. So, any alternative we provide will be non-standard i.e. it willl only work if the client is talking to a JBoss coordinator (this is already the situation for our or anyone else's BA client implementation, mind you). While this does not invalidate adding this feature it does qualify its utility since clients developed using this extension will not be portable. If this feature works and is useful it woudl be worth lobbying to get it adopted as part of the standard.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues