[
https://issues.jboss.org/browse/JBCACHE-1619?page=com.atlassian.jira.plug...
]
Dennis Reed resolved JBCACHE-1619.
----------------------------------
Resolution: Done
The test case also fails on a similar issue JBCACHE-1621, which you're seeing.
(JBCACHE-1621 didn't make the 3.2.10 cutoff).
To verify this fix, you can look for the following in output.log showing whether
RollbackCommand is using OOB:
2012-09-17 14:37:01,243 TRACE [org.jboss.cache.RPCManagerImpl] (Thread-2)
callRemoteMethods(): valid members are null methods:
ReplicateCommand{cmds=RollbackCommand{gtx=GlobalTransaction:<127.0.0.1:55200>:1}}
Using OOB? true modeToUse: 6
With JBCACHE-1619, it should show "Using OOB? true"
Rollback messages to be broadcast as out-of-band messages so they are
not blocked on the receiver's end
-------------------------------------------------------------------------------------------------------
Key: JBCACHE-1619
URL:
https://issues.jboss.org/browse/JBCACHE-1619
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Replication
Affects Versions: 3.2.9.GA
Reporter: Dennis Reed
Assignee: Dennis Reed
Attachments: JBCACHE-1619-test.zip
Same issue as JBCACHE-1270 for Commit messages.
Without OOB, rollback messages have to wait in the queue behind all other messages.
Processing those messages may need resources being held by the transaction being rolled
back, and will deadlock.
--
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