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

[Brian Stansberry]

I opened a forum thread for this at
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92428; let's do
any further discussion there.

Brian Stansberry wrote:
> 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