[jbossts-issues] [JBoss JIRA] Closed: (JBTM-487) Make WS-AT and WS-BA participants gradually increment the resend period when retrying prepared/completed messages

Andrew Dinn (JIRA) jira-events at lists.jboss.org
Wed Feb 11 11:42:48 EST 2009

     [ https://jira.jboss.org/jira/browse/JBTM-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Dinn closed JBTM-487.

    Resolution: Done

The resend period for retries of participant prepared/completed messages now increases from the initial period by a factor of approx sqrt(2) up to a maximum period. The resend period is reset to the initial period whenever a message is received from the coordinator.

The initial and max periods and the timeout period for comms waits are defined by static fields of class TransportTimer. This class exposes public setter methods allowing them to be reset. The XTSService class defines getters and setters for virtual bean properties which redirect reads and writes to these static fields. This allows reconfiguration of the TransportTimer fields by editing the jboss-beans.xml file in the deployed service archive.

> Make WS-AT and WS-BA participants gradually increment the resend period when retrying prepared/completed messages
> -----------------------------------------------------------------------------------------------------------------
>                 Key: JBTM-487
>                 URL: https://jira.jboss.org/jira/browse/JBTM-487
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.5
>            Reporter: Andrew Dinn
>            Assignee: Andrew Dinn
>             Fix For: 4.6
> The current WS-AT/BA participant implementations resend prepared/completed messages at a fixed frequency until they receive a response. The period is currently defined by a settable property of class TransportTimer (which defaults to 5 seconds). It would be better if the period between resends could be configured to increase gradually up to some maximum period (obviously setting the maximum period equal to the initial period maintains the status quo). The benefit of a higher period is that it avoids resends using up the available network bandwidth when a response from the coordinator is slow. It is particularly beneficial in the case where a web service employs BA ParticipantCompletion participants  since there may be a very long delay between the first completed message being sent and a subsequent close or cancel operation being dispatched by the coordinator. If the service is likely to support many long-running transactions then configuring a high maximum resend period will limit the extent to which resent messages clogg up the network. The downside of increasing the resend period is that a higher value means a higher latency before participant (bottom-up) recovery is initiated following a coordinator crash.
> It would also be useful if the initial and maximum resend period could be configured via bean properties associated with the XTS Service bean.
> Note that it only makes sense to implement this feature for retries dispatched from the participant side. Retries only occur on the coordinator side while the coordinator is waiting for a specific response from the participant and the wait will always timeout and cancel further retries in these cases (using the timeout interval defined by TransportTimer -- default 30 seconds).
> This change is a preliminary to a related change required to successfully recover  BA participants. In order to detect coordinator crashes which occur between complete and close/cancel they need switch from sending Completed messages to sending GetStatus messages until they get a response or an invalid transaction/participant soap fault. The switchover algorithm needs to be defined to kick in compatibly with this incremental resend.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbossts-issues mailing list