[jbossts-issues] [JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable

[RH Bugzilla Integration (JIRA)]

    [ https://issues.jboss.org/browse/JBTM-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825447#comment-12825447 ] 

RH Bugzilla Integration commented on JBTM-1943:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 1009981|https://bugzilla.redhat.com/show_bug.cgi?id=1009981]

Hi Tom,

I help to Mirek with verification of this issue.
The correct name of attribute that is needed to be set is
com.arjuna.ats.jta.orphanSafetyInterval (default is 10000)

Mirek ran his test with several values of the attribute. When we set the attribute to be 20s (20000) we still get the XAExceptions time to time. When we redefine the time being 40s (40000) the exception disappeared from the log.

I think that I can verify this issue just don't you think that it would be better to set the default interval time a bit bigger?
For not to get the error as default behavior. But I'm not sure how would it influence the whole recovery process. It's true that the problem occurs on faster machines under the load of receiving a bigger amount of messages.

Ondra
                
> Allow the safety interval for RecoveryXids to be configurable
> -------------------------------------------------------------
>
>                 Key: JBTM-1943
>                 URL: https://issues.jboss.org/browse/JBTM-1943
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JTA
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 4.17.11, 5.0.0.M5
>
>
> Currently it is hard coded to 10 seconds. It is possible that under load this could be possible to breach. Allow the setting to be configurable.
> Breaching the threshold does not pose data integrity issues as the scenario where it becomes an issue is when the transaction has completed during a recovery scan. It will result in calling rollback(xid1) on the RM but as that RM is guaranteed to have had commit(xid1) (or rollback) on it already during transaction completion the only impact is an unsightly stack trace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira