[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-360) Create new events to inform listeners of rehashing and consistent hash changes

[Manik Surtani (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602627#comment-12602627 ] 

Manik Surtani edited comment on ISPN-360 at 5/18/11 6:42 AM:
-------------------------------------------------------------

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 newViewId;
}

@TopologyChanged // this is a new annotation

class TopologyChangedEvent {
  boolean isPre; // before and after new consistent hash is installed
  ConsistentHash consistentHashAtStart, consistentHashAtEnd;
}

{code}



      was (Author: manik):
    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}


  
> Create new events to inform listeners of rehashing and consistent hash changes
> ------------------------------------------------------------------------------
>
>                 Key: ISPN-360
>                 URL: https://issues.jboss.org/browse/ISPN-360
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Listeners, State transfer
>            Reporter: Mircea Markus
>            Assignee: Manik Surtani
>             Fix For: 5.0.0.CR3, 5.0.0.FINAL
>
>
> In relation to http://community.jboss.org/message/529547#529547 
> It's an well known scenario to start a cluster, and only after the ENTIRE cluster is started to start and do work. Right now, we have CacheStarted and ViewChanged notifications. First only tells us that the local node is started but other nodes might still be in the process of starting. Second one tells us that the view has changed, but not that the cluster has started, i.e. the cache might be in the process of rebalancing state etc. 
> A possible solution would be to have an NodeJoined event, that would be called  whenever a new node finished joining the cluster. Finished joining means state transfer happened and that node is started.
> For a possible workaround to this feature see the forum post. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira