[ https://jira.jboss.org/jira/browse/ISPN-360?page=com.atlassian.jira.plugi... ] Galder Zamarreno commented on ISPN-360: --------------------------------------- hi mmarkus_ <galderz> wanted to clarify couple of things in http://community.jboss.org/message/528762 <mmarkus_> hi galderz <mmarkus_> sure <galderz> preloading is part of the startup of the cache loader, so when cache is started, the preloaded has finished, correct? <mmarkus_> yes <galderz> indeed: @Start(priority = 56) <galderz> but the state transfer is a diff thing <galderz> the cache is started already and it's having state applied to it? <mmarkus_> hmm, not sure which one comes first, i.e. state transfer or preload <galderz> http://community.jboss.org/wiki/JBossCacheNon-BlockingStateTransfer <galderz> assuming a node joining D, it's only marked as started when the state transfer has completed <galderz> not sure either about the order <mmarkus_> yes, a node is not started until state transfer is finished <galderz> @Start(priority = 55) -> @Start(priority = 56) <galderz> state trasnfer is first, the preload <galderz> then preload <mmarkus_> right, makes sense <galderz> now, what's the point of https://jira.jboss.org/jira/browse/ISPN-360 ? <mmarkus_> because you update the store and then, if you want, load it into memory <galderz> i can see maybe the use of a rehash started/completed notifications in running nodes affected by the start of a new node <mmarkus_> and that brings another thing to the forum post <galderz> and I think my last comment is what you're aiming at in 360? <galderz> the capability of other nodes to find out when a new node has joined, which would mean that any rehashing that might have happened in the running node is completed? <mmarkus_> I would like to be notified AFTER a node is started <mmarkus_> even when a remote node joined the cluster <galderz> i see ur point <mmarkus_> yes, exactly <galderz> but just bear in mind, in nodes that are affected by rehashing caused by the start of this node, that notification needs to happen after rehashing has finished, correct? <mmarkus_> this guy wants to start N nodes, and then tell the application that the cluster is started <galderz> assuming the app is running in each of these N nodes? <mmarkus_> yes. Basically the node that receives state will know that it finished receiving state, and should notify all other nodes that NodeJoined <mmarkus_> yes <mmarkus_> you've just raised another problem I wasn't aware of <mmarkus_> so if we have both preload and fetchInMemory state, then local cache store state before starting will be erased <galderz> yeah, i guess that assuming one of those nodes X, it should receive N-1 NodeJoined, but a NodeJoined from X-1, meaning that X-1 is next to X in the hash loop, X would receive NodeJoined when X-1 has started and X has done any reshahing <galderz> mmarkus_, not sure if it will erase it <galderz> it will override it <galderz> i'd assume that if you receive k=akey,v=1 via in memory and u had preloaded k=akey,v=2, v=1 would prevail <mmarkus_> yes, at the time X receives NodeJoioned from X-1, X(and all other nodes) finished rehashing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/ISPN-360?page=com.atlassian.jira.plugi... ] Mircea Markus commented on ISPN-360: ------------------------------------ Agreed that NodeJoined won't directly solve the issue above. We can create implement ClusterStartedListener on top of NodeJoined, and the implementing it should be very easy once we have NodeJoined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-360?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-360: ---------------------------------- Fix Version/s: 5.0.0.BETA2 (was: 5.0.0.BETA1) -- 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-360?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-360: ---------------------------------- Fix Version/s: 5.0.0.CR2 (was: 5.0.0.CR1) -- 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-360?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-360: ------------------------------- Summary: Create new events to inform listeners of rehashing and consistent hash changes (was: create NodeJoined event) The current approach is to have 2 new listener events: {code} @DataRehashed // this is the new annotation class DataRehashedEvent { boolean isPre; // this will be fired before and after rehashing takes place List<Address> membersAtStart, membersAtEnd; long startingViewId, endingViewId; } @TopologyChanged // this is a new annotation class TopologyChangedEvent { boolean isPre; // before and after new consistent hash is installed ConsistentHash consistentHashAtStart, consistentHashAtEnd; } {code} -- 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-360?page=com.atlassian.jira.plugin.s... ] Manik Surtani resolved ISPN-360. -------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira