August 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Amos Feng created pull request #1062 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: win > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2743: ---------------------------- Labels: win (was: ) > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: win > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2734) EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2734: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ] Tom Jenkinson edited comment on JBTM-2701 at 8/30/16 6:49 AM: -------------------------------------------------------------- Problem is observed in following scenario: {code} 0. crash 1. Periodic recovery periodicFirstPass (before XAR1 registered with recovery system) - move from IDLE to BETWEEN_PASSES 2. XATerminator::recover() - loads SAA from external to PeriodicRecovery system 3. commit SAA1 4. commit XAResourceRecord1 5. XARecoveryModule::getNewXAResource 6. periodicFirstPass not called as not IDLE so no scan XAR1 so XAR unavailable {code} We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass. was (Author: tomjenkinson): Problem is observed in following scenario: {code} 0. prepare SAA1 1. prepare XAR1 2. getNewXAResource 3. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES 4. commit XAR1 5. prepare XAR2 6. commit XAR2 7. getNewXAResource 8. periodicFirstPass not called as not IDLE so no scan XAR2 {code} We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass. > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.... ] Amos Feng edited comment on JBTM-2743 at 8/29/16 10:32 PM: ----------------------------------------------------------- the apr_pollset_poll uses the WSAPoll as the default implementation since 1.4 And there was a bug in the WSAPoll when using the non-blocking connecting to the non-exist port. It never returns the failure. [1] https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/18769abd-fc... [2] http://stackoverflow.com/questions/21653003/is-this-wsapoll-bug-for-non-b... was (Author: zhfeng): the apr_pollset_poll uses the WSAPoll as the default implementation since 1.4 And there was a bug in the WSAPoll when using the non-blocking connecting to the non-exist port. It never returns the failure. https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/18769abd-fc... > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-2743: --------------------------------- the apr_pollset_poll uses the WSAPoll as the default implementation since 1.4 And there was a bug in the WSAPoll when using the non-blocking connecting to the non-exist port. It never returns the failure. https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/18769abd-fc... > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang

by Amos Feng (JIRA)

Amos Feng created JBTM-2743: ------------------------------- Summary: Blacktie integration-tests TestTPCancel hang Key: JBTM-2743 URL: https://issues.jboss.org/browse/JBTM-2743 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2734) EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2734: -------------------------------- Summary: EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared (was: EIS can't recover transaction when heuristic outcome happens) > EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2713) Investigate why a null FileLock is declared but not used

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2713?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2713: -------------------------------- Description: It is not assigned but later on it is checked for null and if not then released: https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce1... was: It certainly isn't referenced: https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce1... > Investigate why a null FileLock is declared but not used > -------------------------------------------------------- > > Key: JBTM-2713 > URL: https://issues.jboss.org/browse/JBTM-2713 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > It is not assigned but later on it is checked for null and if not then released: > https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce1... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2712) Karaf build failing

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2712: --------------------------------- > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2016