[ https://issues.jboss.org/browse/ISPN-1748?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1748: ------------------------------------- @Manik yes -- 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-1748?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1748: -------------------------------- Attachment: All_PUT.png results of comparing: ispn50->async commit ispn51->sync commit ispn51c->this jira's implementation -- 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-1748?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1748 at 1/19/12 1:19 PM: -------------------------------------------------------------- after implementing this I've run some benchmarks and figures don't look at all encouraging. The attached graph compares: ispn50->async commit ispn51->sync commit ispn51c->this jira's implementation Without performing an exhaustive analysis, the problem seem to be one of flow control: without the fix in place we have the producer threads doing 2 sync RPCs (prepare and commit) and one async RPC performed by OOB (release locks). with the fix in place, we have the producer doing an 1 sync RPC(prepare) and then it triggers an OOB async thread that does 2 other RPCs. Now the problem seems to be caused by the fact that the consumers create more requests than the OOB thread pool can handle, ending up in prepares waiting for locks to be released -> but locks are not released on time because OOB threads are exhausted. Increasing the OOB thread pool size might help. The problem is more visible for REPL, because in that case the designated lock owner is the coordinator. What happens in the case of REPL is a very high percentage of timeouts on the coordinator and performance is very slow (I've interrupted the tests several times after 3h, normally it only takes about 30 mins). Again, the high number of timeouts indicates that locks are not being released on time, most likely because of the flow control. was (Author: mircea.markus): results of comparing: ispn50->async commit ispn51->sync commit ispn51c->this jira's implementation -- 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-1748?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1748: -------------------------------- Fix Version/s: 5.2.0.FINAL (was: 5.1.0.FINAL) Affects Version/s: 5.1.0.FINAL -- 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-1748?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1748: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.2.0.Final) -- 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