[ https://issues.jboss.org/browse/ISPN-1581?page=com.atlassian.jira.plugin.... ] Erik Salter commented on ISPN-1581: ----------------------------------- As an update, further testing this morning showed we could break the existing implementation with just 2 nodes leaving. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1581?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1581: -------------------------------- Assignee: Dan Berindei (was: Manik Surtani) Fix Version/s: 5.1.0.CR1 Affects Version/s: 5.1.0.BETA5 (was: 5.1.0.CR1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1581?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-1581: ------------------------------------ Before we released 5.0 I was talking with Manik about skipping the state transfer lock (transaction lock at that time) for commit commands and queuing them instead, to be sent to the new owners after the state transfer is finished. That would have solved the commit resiliency problem, but I felt the cost in complexity was too great. It would have required something similar to the 4.2 non-blocking state transfer, but with only a small part of the benefits (prepare commands would still be blocked). The approach in ISPN-1424 seems much more promising in the long term. For the short term I was thinking of retrying the commit command with a timeout. That way the user could set the timeout to a very high value to avoid stale locks or to something lower to enforce an upper bound on the execution time of a transaction. However, because we don't have any automatic way of recovering after a stale lock like this, the only feasible option is setting a very high timeout, so we might as well retry the commit command forever, without giving the user any choice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1581?page=com.atlassian.jira.plugin.... ] Dan Berindei reopened ISPN-1581: -------------------------------- My fix had an overflow issue and the commit commands didn't actually wait forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1581?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1581: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.1.0.FINAL (was: 5.1.0.CR2) Resolution: Done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira