[jbosscache-dev] FW: [JBoss JIRA] Created: (JBAS-3753) HAParititonImpl implements org.jgroups.ChannelListener

[Brian Stansberry]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev