[ https://jira.jboss.org/browse/ISPN-448?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-448: ---------------------------------- JBoss Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2010-May/005594.html Added dev forum link. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-448?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-448: --------------------------------------- As a result of ISPN-1182, I've done some initial investigation of this and it's a bit more complicated than originally thought. The obvious way to implement this is by having a @ViewChanged method and within it update the topology view. However, whereas removing topology addresses is simple, adding new addresses here is difficult because the ViewChangeEvent does not carry server host and port settings. Even if a node adds a [Address:Server Host+Port] k/v mapping to the topology cache on startup, this might happen after the view change has been sent around. So, for the coordinator to deal with this properly, two steps would be needed: - To deal with new nodes joining, have a cache listener that listeners for puts on topology cache with an Address instance. The coordinator would then be able to fetch this address host+port and would be able to construct the TopologyAddress and update the view. - To deal with joins leaving or crashing, have a @ViewChanged method, similar to the one that the code has at the moment to deal with crashed members. One downside of this solution is that each node joining would lead to a topology view update cluster wide, whereas if it had been resolvable in the @ViewChanged method, we could potentially deal with multiple joins in just one go. What would be cool would be if ViewChangeEvent could carry arbitrary information provided by the user. Why that? Because when the JGroups channel is started, the host+port are known, and so it'd be cool if the user could provide information to carry along with this node's JGroups or Infinispan address when this is constructed. This information would be exchanged at GMS time and so any view change event would then carry this extra info. -- 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-448?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-448: ---------------------------------- Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2010-May/005594.html, http://community.jboss.org/message/609475#609475 (was: http://lists.jboss.org/pipermail/infinispan-dev/2010-May/005594.html) Someone having issues with concurrent Hot Rod server startup. -- 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-448?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-448. ----------------------------------- Fix Version/s: (was: 5.1.0.BETA1) (was: 5.1.0.FINAL) Resolution: Won't Fix Instead, ISPN-1408 will be implemented to solve problems with topology cache updates. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira