[ https://issues.jboss.org/browse/ISPN-977?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-977: ------------------------------- Summary: KeyAffinityService has stale keys when topology changes (was: KeyAffinityService issue on topology change) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-977?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-977: ------------------------------------ A nice solution for this problem would be for KAS to register as a ConsistenHashChangeListener and not as a ViewChangeListener. This way the key buffer would be cleaned at a proper moment in time. There's no such thing as an ConsistenHashChangeListener. This can be implemented either a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. Suggestions? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-977?page=com.atlassian.jira.plugin.s... ] Mircea Markus edited comment on ISPN-977 at 5/11/11 8:03 AM: ------------------------------------------------------------- A nice solution for this problem would be for KAS to register as a ConsistenHashChangeListener and not as a ViewChangeListener. This way the key buffer would be cleaned at a proper moment in time. There's no support for ConsistenHashChangeListener at the moment. This can be implemented either a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. Suggestions? was (Author: mircea.markus): A nice solution for this problem would be for KAS to register as a ConsistenHashChangeListener and not as a ViewChangeListener. This way the key buffer would be cleaned at a proper moment in time. There's no such thing as an ConsistenHashChangeListener. This can be implemented either a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. Suggestions? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-977?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-977: ------------------------------------ Dan suggested another approach: transactions also get blocked during topology changes. That code might be used as well to determine when the new CH has been installed. AT that point just flush existing key and allow for new keys to be generated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-977?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-977: ------------------------------------ The nicest approach is to implement it based on ISPN-360. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-977?page=com.atlassian.jira.plugin.s... ] Manik Surtani resolved ISPN-977. -------------------------------- Fix Version/s: (was: 4.2.2.FINAL) Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira