The problem is that when your channel disconnects, you don't get a new view. Experiments with HAPartition showed me that. You do get one when it reconnects. Mainly the issue is to think through the implications of that. Some initial thoughts: 1) While you're disconnected you can't properly replicate. What's the proper behavior -- hold calls in ReplicationInterceptor until you reconnect, which will happen automatically? Or throw exceptions when you try to send messages on the channel (which I'd expect is what happens now)? If the latter, it becomes important to have a way to communicate to the application that the cache is disconnected, so the application can decide whether or not to hold calls. 2) When the new view comes in after reconnect, does the node need to reassign it's buddy and transfer state? During the period of broken communication leading up to the shunning, the buddy probably wasn't getting replication traffic. If REPL_ASYNC, the sender would not know this. If we do need to reassign buddies, when the new view comes in will the BR code recognize it needs to do this? 3) The channel is always AUTO_GET_STATE. So, when it reconnects getState() will be called on the coordinator and setState() will be called on the node. This is inappropriate in many configurations; basically most of those that don't do an initial state transfer. See http://jira.jboss.com/jira/browse/JBCACHE-805. If it is appropriate, do we handle it properly? 3) Non-BR case with region-based marshalling. We definitely don't want a single monolithic state transfer; won't be able to deserialize it. But, we do need to re-transfer the state, as we're now out of sync with the cache. Right now we don't do this. A lot of similar issues apply in the merge case. -Brian Manik Surtani wrote: > Within JBC, how does this affect? Perhaps triggering a reorg of budy > groups? But this is done when a new view is issued anyway. > >> Hi, >> >> The below issue pertains to JBC as well. Propagation of awareness >> of shunning to user code may be less of an issue, but internal >> awareness is important. >> >> Brian Stansberry (JIRA) wrote: >>> HAParititonImpl implements org.jgroups.ChannelListener >>> ------------------------------------------------------ >>> >>> Key: JBAS-3753 >>> URL: http://jira.jboss.com/jira/browse/JBAS-3753 >>> Project: JBoss Application Server >>> Issue Type: Feature Request >>> Security Level: Public (Everyone can see) >>> Components: Clustering >>> Affects Versions: JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1 >>> Reporter: Brian Stansberry >>> Assigned To: Brian Stansberry >>> Fix For: JBossAS-5.0.1.CR1 >>> >>> >>> Currently if a JChannel is shunned and disconnects, higher level >>> services are unaware of this and can't take any remedial action. >>> >>> We need to do something like implement ChannelListener so an >>> HAPartition is aware when the events on the underlying channel >>> occur. Then devise a scheme to propagate some of the events to user >>> code. Preferably this will follow as much as possible the existing >>> notification scheme; i.e. pass a new view to HAMembershipListener >>> impls that doesn't include the current node. >> >> >> >> Brian Stansberry >> Lead, AS Clustering >> JBoss, a division of Red Hat >> Ph: 510-396-3864 >> skype: bstansberry >> >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev