[ https://issues.jboss.org/browse/ISPN-1883?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-1883: -------------------------------------- I don't know whether this is related only to the experimental changes in the branch or may have roots in main stream code, therefore I reported it. -- 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-1883?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1883: ----------------------------------- Fix Version/s: 5.1.2.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-1883?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-1883: -------------------------------------- Well the message is different :) {code} ISPN-1883: java.lang.IllegalStateException: Trying to block write commands but they are already blocked for view 7 ISPN-1882: java.lang.IllegalStateException: Trying to unblock write commands for cache view 1 but they were not blocked {code} -- 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-1883?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-1883 at 3/1/12 3:26 AM: ------------------------------------------------------------ The error appears when the coordinator leaves the cluster, another coordinator starts to install a new cache view, and then it also dies before finishing the view installation. The 3rd coordinator will pick the same view id that the 2nd coordinator was trying to install, resulting in the IllegalStateException. After the exception, the 3rd coordinator will retry to install the cache view and succeed (because it's using a higher view id): {noformat} v1|A = [A, B, C, D] - initial view A dies v2|B = [B, C, D] B dies - causing v2|B to fail v2|C = [C, D] - fails because it has the same view id v3|C = [C, D] - succeeds {noformat} In this particular case the coordinators were shut down 30 seconds apart, but because of JGRP-1428 the first state transfer didn't finish until the 2nd view change (when the 2nd coordinator had already left the cluster). Since the 2nd attempt to install the cache view is successful and this issue only happens in rare circumstances, I'm postponing it to 5.2.0. Relevant log messages: {noformat} 2012-02-22 13:13:34,352 INFO [JGroupsTransport] (Incoming-2,edg-perf03-57571) ISPN000094: Received new cluster view: [edg-perf01-39846|3] [edg-perf01-39846, edg-perf02-36519, edg-perf03-57571, edg-perf04-36539] 2012-02-22 13:14:11,897 DEBUG [CacheViewsManagerImpl] (CacheViewInstaller-3,edg-perf02-36519) Installing new view CacheView{viewId=7, members=[edg-perf04-36539, edg-perf02-36519, edg-perf03-57571]} for cache testCache 2012-02-22 13:14:41,827 INFO [JGroupsTransport] (Incoming-12,edg-perf03-57571) ISPN000094: Received new cluster view: [edg-perf03-57571|5] [edg-perf03-57571, edg-perf04-36539] 2012-02-22 13:14:42,266 WARN [CacheViewControlCommand] (OOB-18,edg-perf04-36539) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=testCache, type=PREPARE_VIEW, sender=edg-perf02-36519, newViewId=7, newMembers=[edg-perf04-36539, edg-perf02-36519, edg-perf03-57571], oldViewId=4, oldMembers=[edg-perf01-39846, edg-perf02-36519, e dg-perf03-57571, edg-perf04-36539]} org.infinispan.statetransfer.StateTransferCancelledException 2012-02-22 13:14:42,273 DEBUG [CacheViewsManagerImpl] (CacheViewInstaller-3,edg-perf03-57571) Installing new view CacheView{viewId=7, members=[edg-perf04-36539, edg-perf03-57571]} for cache testCache 2012-02-22 13:14:42,296 ERROR [CacheViewsManagerImpl] (CacheViewInstaller-3,edg-perf03-57571) ISPN000172: Failed to prepare view CacheView{viewId=7, members=[edg-perf04-36539, edg-perf03-57571]} for cache testCache, rolling back to view CacheView{viewId=6, members=[edg-perf01-39846, edg-perf02-36519, edg-perf03-57571, edg-perf04-36539]} java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Trying to block write commands but they are already blocked for view 7 2012-02-22 13:14:43,274 DEBUG [CacheViewsManagerImpl] (CacheViewInstaller-3,edg-perf03-57571) Installing new view CacheView{viewId=9, members=[edg-perf03-57571, edg-perf04-36539]} for cache testCache 2012-02-22 13:14:46,409 DEBUG [CacheViewsManagerImpl] (CacheViewInstaller-3,edg-perf03-57571) testCache: Committing cache view CacheView{viewId=9, members=[edg-perf03-57571, edg-perf04-36539]} {noformat} was (Author: dan.berindei): The error appears when the coordinator leaves the cluster, another coordinator starts to install a new cache view, and then it also dies before finishing the view installation. The 3rd coordinator will pick the same view id that the 2nd coordinator was trying to install, resulting in the IllegalStateException. After the exception, the 3rd coordinator will retry to install the cache view and succeed (because it's using a higher view id): v1|A = [A, B, C, D] - initial view A dies v2|B = [B, C, D] - fails because B died B dies v2|C = [C, D] - fails because it has the same view id v3|C = [C, D] - succeeds In this particular case the coordinators were shut down 30 seconds apart, but because of JGRP-1428 the first state transfer didn't finish until the 2nd view change (when the 2nd coordinator had already left the cluster). Since the 2nd attempt to install the cache view is successful and this issue only happens in rare circumstances, I'm postponing it to 5.2.0. -- 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