Re: [jboss-cluster-dev] MyRpcDispatcher
by galder＠jboss.org
Hi Paul,
I'm not sure what method Bela is talking about. The only thing I suggested is having some kind of scope getter method that allows updating the handlers map.
Paul, let me know when you've committed this stuff and I'll try it out. I'm also investigating Bela's suggestion of having a separate cache.
Cheers,
----- "Paul Ferraro" <paul.ferraro(a)redhat.com> wrote:
> Galder,
>
> To which method is Bela referring?
>
> Otherwise, I'm ready to check in the org.jgroups.blocks.mux package.
> There is a small change required in
> MessageDispatcher.setChannel(...):
>
> channel.setUpHandler(prot_adapter);
>
> needs to be replaced by:
>
> if (channel.getUpHandler() == null)
> channel.setUpHandler(prot_adapter);
>
> This is need to prevent each new RpcDispatcher/MessageDispatcher from
> overwriting the preexisting multiplexing UpHandler.
> I can't envision this breaking any existing use case, but I wanted to
> verify before committing.
>
> So, to review, usage will now look like:
>
> Channel c = new JChannel(...);
>
> // RpcDispatcher d = new RpcDispatcher(c, null, null, target);
> // c.setUpHandler(new MuxUpHandler(d.getProtocolAdapter());
>
> c.setUpHandler(new MuxUpHandler());
>
> RpcDispatcher d1 = new MuxRpcDispatcher((short) 1, c, null, null,
> target);
> RpcDispatcher d1 = new MuxRpcDispatcher((short) 2, c, null, null,
> target);
>
> c.connect(...);
>
> Paul
>
> On Mon, 2010-04-12 at 13:16 +0200, Bela Ban wrote:
> > I understand all of the new code is in the new package
> > org.jgroups.blocks.scope. If that's the case, I suggest add and
> commit
> > your changes so you can experiment with them.
> >
> > I also recall Galder needed to change some method from private to
> > protected, why don't you go ahead and do this too ?
> <snip>
15 years, 6 months
Re: [jboss-cluster-dev] MyRpcDispatcher
by Paul Ferraro
On Thu, 2010-04-15 at 13:11 +0200, Bela Ban wrote:
> thx !
>
> Why didn't you add MuxHeader to jg-magic-map.xml, is it never marshalled ?
Good point. Change committed.
I've also moved the declaration of the header id value used by
MuxRequestCorrelator into jg_protocol_ids.xml.
> Paul Ferraro wrote:
> > OK - I've committed the org.jgroups.blocks.mux package.
> > Relevant tests are:
> > tests/junit/org/jgroups/blocks/MuxMessageDispatcherTest
> > tests/junit/org/jgroups/blocks/MuxRpcDispatcherTest
> >
15 years, 6 months
Re: [jboss-cluster-dev] Consistent Hashing in mod_cluster
by Manik Surtani
On 9 Apr 2010, at 16:00, Brian Stansberry wrote:
> I'm putting this on the cluster-dev list as there's no reason for it to
> continue in private.
>
> Manik, I agree with your comment about avoiding tight coupling between
> the ISPN hash algorithm and something inside mod_cluster. The approach
> we decided to take was to change the jvmRoute -- see
> https://jira.jboss.org/jira/browse/JBAS-7853. The Mobicents folks are
> already familiar with that approach since the AS has long done that on
> failover. They've added a browser redirect technique that would even
> avoid the "1 'inefficient' dispatch" issue you noted.
>
> What's different about what Vladimir's raising here is the need to try
> to group sessions together; i.e. use something other than the cache key
> (i.e. jsessionid) as the factor in the hash algorithm. He mentioned a
> use case for multiple users in a chat where the goal would be to cache
> sessions locally with chat state. AIUI there's also a use case where a
> user has a SIP session and an HTTP session, so the goal would be to have
> both session cached together.
>
> Doing that will clearly require quite a bit of AS work -- some pluggable
> policy for determining what the "affinity key" is based on the call
> context (null == use the cache key for hashing). Then use the
> affinityKey can calling into ISPN (i.e. ISPN-359) and when determining
> where to fail over to (JBAS-7853).
I presume you're following the ISPN-359 thread on infinispan-dev...
> This will also be useful for the HTTPSession + SFSB in same request use
> case, where colocating the SFSB and the web session is optimal.
Right.
> I hadn't opened a JIRA for that yet; just tried to but JIRA seems to not
> be working?
>
> Hmm, an issue is if the caches involved in the overall picture (e.g.
> httpsession cache and "chat state" cache) end up using different
> CacheManagers/JGroups Channels. This would quite likely happen (see
> http://community.jboss.org/thread/149868 for discussion why). If that's
> the case, the views between the channels could end up slightly different
> -- e.g. servers A and B are booting at the same time, so due to slight
> differences in the boot, Channel for HTTPSession cache ends up with view
> {A, B} and Channel for "chat state" cache ends up with {B, A}. In that
> case I wouldn't expect there to be a reliable, performant way to ensure
> affinity, since the view is a major factor in the hashing algorithm.
Yes, it would not be useful at all if the 2 components end up with different views. It would only make sense if the web session cache and the SFSB session cache share the same CacheManager/Channel.
>
> On 04/09/2010 04:53 AM, Manik Surtani wrote:
>> I made a few comments on the JIRA to respond to your comment; Brian, correct me if I have missed something, but this is pretty much what we spoke about in Brno? Do you have a JIRA in JBAS for this as well?
>>
>>
>> On 8 Apr 2010, at 19:39, Vladimir Ralev wrote:
>>
>>> Thanks, this will work great for us. However, this issue seems to be scoped purely in Infinispan https://jira.jboss.org/jira/browse/ISPN-359
>>>
>>> A reciprocal feature is needed in mod_cluster. Would it be possible mod_cluster to use a URI parameter, a cookie as affinity key. AFAIK from mod_jk, it only supports using the jsessionid cookie and uri param (hardcoded). Ultimately we'd like to have it use a customer GET param or cookie for affinity. I couldnt find any doc related to that. Would this be possible?
>>>
>>> ----- Original Message -----
>>> From: "Manik Surtani"<msurtani(a)redhat.com>
>>> To: "Brian Stansberry"<brian.stansberry(a)redhat.com>
>>> Cc: "Vladimir Ralev"<vralev(a)redhat.com>, "Brian Stansberry"<bstansbe(a)redhat.com>, "Jean Deruelle"<jderuell(a)redhat.com>, "Paul Ferraro"<paul.ferraro(a)redhat.com>
>>> Sent: Thursday, April 8, 2010 1:43:00 PM GMT +02:00 Athens, Bucharest, Istanbul
>>> Subject: Re: Consistent Hashing in mod_cluster
>>>
>>>
>>> On 6 Apr 2010, at 20:02, Brian Stansberry wrote:
>>>
>>>> Hi Vladimir,
>>>>
>>>> I've been on vacation. I replied to your question on the wiki page, but what you're talking about here is a bigger picture thing.
>>>>
>>>> Sounds like your situation is a good use case for https://jira.jboss.org/jira/browse/ISPN-359 which is an Infinispan JIRA. (At least I believe that's the JIRA that gets into allowing the caller to provide hints such that separate keys hash to the same storage nodes -- Manik, please correct me if I'm wrong.)
>>>
>>> Yup, this is correct.
>>>
>>>>
>>>> On 03/31/2010 01:58 PM, Vladimir Ralev wrote:
>>>>> Hello Brian,
>>>>>
>>>>> Not sure if you are following http://community.jboss.org/wiki/Consistent-hashingbasedJBCdatapartitionin... so decided to email you.
>>>>>
>>>>> We are very interested in the consistent hashing feature in the load balancer working cooperatively with the cache and would like to follow the development and contribute if needed. Particularly, we in Moicents already have a number of use-cases that concern bothtelecom and pure web applications. For example - a web based chat room will have a number of participants with different HTTP sessions and they share the same state somewhere in another cache at the same node. It would be desireable to failover such groups of users together to avoid having them to lookup the chat state in remote caches over the network. That is why, if possible, we are interested in using not just the HTTP session ID for lookups, but have a configurable affinity key/mask that is taken from the messages, so that you could route all requests with http://redhat.com/?chatroom=1 always to the same node, and "chatroom" as an URL param is the affinity key with value "1".
>>>>>
>>>>> Sailfin/Glassfish have something similar with their CLB.
>>>>>
>>>>> In Mobicents we would be using it to coordinate not only mod_cluster and cache, but the SIP load balancer and other protocol load balancers as well. In fact, our load balancer already supports HTTP consistent hashing, however it doesn't have the high performance of mod_cluster (no AJP either) and is only recommended when SIP+HTTP coordination is a requirement for our telco users.
>>>>>
>>>>> http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm (Slide 17 has a helpful diagram)
>>>>>
>>>>> The other technique we are using to coordinate multiprotocol load balancers with local cache is this
>>>>>
>>>>> http://docs.google.com/present/edit?id=0AdgrvwaZgnJ1ZGM1anA1dnhfOTZnZjYyc...
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Lead, AS Clustering
>>>> JBoss by Red Hat
>>>
>>
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jboss-cluster-dev mailing list
> jboss-cluster-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 6 months
Re: [jboss-cluster-dev] Consistent Hashing in mod_cluster
by Manik Surtani
On 12 Apr 2010, at 02:53, Vladimir Ralev wrote:
> (resend to group)
>
> A couple of notes and questions:
>
> 1. Indeed from our POV the jvmRoute-based load balancing combined with DIST is a bit problematic because it concentrates the LB effort in the HTTP container logic on the serer side. There are many issues with non-HTTP protocols, but we can put this aside for now and just focus on the web-based chatroom case. Other protocols use other load balancers anyway.
Depends if the protocol supports some concept of a session id. This is the critical bit, AIUI, pls correct me if I am wrong...
> 2. The current plan for jvmRoute-based load balancing https://jira.jboss.org/jira/browse/JBAS-7853 seems to simply check if the data is available locally in the node and if not try to determine where is it. But DIST will probably maintain at least two nodes where the data is local at all times. Thus chatroom users will probably end up dispersed between those two or more nodes, because they hit mod_cluster independently and eventually they will be routed randomly. Unless infinispan locality-check AND location-determination APIs somehow have a concept of a "primary node" and all requests with same affinity key end up there?
Yes, this is the plan, after the first request (by each independent user) is routed to a random node by the LB and is 'corrected' so that subsequent interactions by that user is directed to one of the nodes where the state is local.
> 3. At this point, we could implement some jvmRoute hack in the application to redirect one group of users to the other node, but it would be better if either we have a primary node concept in DIST or have a mod_cluster "lesser", but deterministic CH algorithm that takes URL params into account?
The "primary node" concept is implicit. So on the server side, when you check for an ownership list of a key, you get back a list of servers. This list is deterministic anywhere in the cluster - including the *order* of the list, so the first entry could be considered "primary".
> 4. Even if mod_cluster was aware of the CH in Infinispan it would have to deal with this issue. And as mentioned earlier our load balancer (MLB) will probably work this way a least for non-HTTP protocols.
Then really no point in trying to solve this on the mod_cluster level. :)
> 5. Is there any plan in either AS or Infinispan for fault-tolerant timers? This is another example where you want to have the timers replicated on N nodes, but need only one primary node to actually execute the logic.
Nope (Infinispan).
>
> Another off-topic question: How does mod_cluster detect dead nodes?
>
>
> ----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
> To: "Manik Surtani" <msurtani(a)redhat.com>
> Cc: "Vladimir Ralev" <vralev(a)redhat.com>, "Brian Stansberry" <bstansbe(a)redhat.com>, "Jean Deruelle" <jderuell(a)redhat.com>, "Paul Ferraro" <paul.ferraro(a)redhat.com>, "cluster-dev" <jboss-cluster-dev(a)lists.jboss.org>
> Sent: Friday, April 9, 2010 6:00:07 PM GMT +02:00 Athens, Bucharest, Istanbul
> Subject: Re: Consistent Hashing in mod_cluster
>
> I'm putting this on the cluster-dev list as there's no reason for it to
> continue in private.
>
> Manik, I agree with your comment about avoiding tight coupling between
> the ISPN hash algorithm and something inside mod_cluster. The approach
> we decided to take was to change the jvmRoute -- see
> https://jira.jboss.org/jira/browse/JBAS-7853. The Mobicents folks are
> already familiar with that approach since the AS has long done that on
> failover. They've added a browser redirect technique that would even
> avoid the "1 'inefficient' dispatch" issue you noted.
>
> What's different about what Vladimir's raising here is the need to try
> to group sessions together; i.e. use something other than the cache key
> (i.e. jsessionid) as the factor in the hash algorithm. He mentioned a
> use case for multiple users in a chat where the goal would be to cache
> sessions locally with chat state. AIUI there's also a use case where a
> user has a SIP session and an HTTP session, so the goal would be to have
> both session cached together.
>
> Doing that will clearly require quite a bit of AS work -- some pluggable
> policy for determining what the "affinity key" is based on the call
> context (null == use the cache key for hashing). Then use the
> affinityKey can calling into ISPN (i.e. ISPN-359) and when determining
> where to fail over to (JBAS-7853).
>
> This will also be useful for the HTTPSession + SFSB in same request use
> case, where colocating the SFSB and the web session is optimal.
>
> I hadn't opened a JIRA for that yet; just tried to but JIRA seems to not
> be working?
>
> Hmm, an issue is if the caches involved in the overall picture (e.g.
> httpsession cache and "chat state" cache) end up using different
> CacheManagers/JGroups Channels. This would quite likely happen (see
> http://community.jboss.org/thread/149868 for discussion why). If that's
> the case, the views between the channels could end up slightly different
> -- e.g. servers A and B are booting at the same time, so due to slight
> differences in the boot, Channel for HTTPSession cache ends up with view
> {A, B} and Channel for "chat state" cache ends up with {B, A}. In that
> case I wouldn't expect there to be a reliable, performant way to ensure
> affinity, since the view is a major factor in the hashing algorithm.
>
> On 04/09/2010 04:53 AM, Manik Surtani wrote:
>> I made a few comments on the JIRA to respond to your comment; Brian, correct me if I have missed something, but this is pretty much what we spoke about in Brno? Do you have a JIRA in JBAS for this as well?
>>
>>
>> On 8 Apr 2010, at 19:39, Vladimir Ralev wrote:
>>
>>> Thanks, this will work great for us. However, this issue seems to be scoped purely in Infinispan https://jira.jboss.org/jira/browse/ISPN-359
>>>
>>> A reciprocal feature is needed in mod_cluster. Would it be possible mod_cluster to use a URI parameter, a cookie as affinity key. AFAIK from mod_jk, it only supports using the jsessionid cookie and uri param (hardcoded). Ultimately we'd like to have it use a customer GET param or cookie for affinity. I couldnt find any doc related to that. Would this be possible?
>>>
>>> ----- Original Message -----
>>> From: "Manik Surtani"<msurtani(a)redhat.com>
>>> To: "Brian Stansberry"<brian.stansberry(a)redhat.com>
>>> Cc: "Vladimir Ralev"<vralev(a)redhat.com>, "Brian Stansberry"<bstansbe(a)redhat.com>, "Jean Deruelle"<jderuell(a)redhat.com>, "Paul Ferraro"<paul.ferraro(a)redhat.com>
>>> Sent: Thursday, April 8, 2010 1:43:00 PM GMT +02:00 Athens, Bucharest, Istanbul
>>> Subject: Re: Consistent Hashing in mod_cluster
>>>
>>>
>>> On 6 Apr 2010, at 20:02, Brian Stansberry wrote:
>>>
>>>> Hi Vladimir,
>>>>
>>>> I've been on vacation. I replied to your question on the wiki page, but what you're talking about here is a bigger picture thing.
>>>>
>>>> Sounds like your situation is a good use case for https://jira.jboss.org/jira/browse/ISPN-359 which is an Infinispan JIRA. (At least I believe that's the JIRA that gets into allowing the caller to provide hints such that separate keys hash to the same storage nodes -- Manik, please correct me if I'm wrong.)
>>>
>>> Yup, this is correct.
>>>
>>>>
>>>> On 03/31/2010 01:58 PM, Vladimir Ralev wrote:
>>>>> Hello Brian,
>>>>>
>>>>> Not sure if you are following http://community.jboss.org/wiki/Consistent-hashingbasedJBCdatapartitionin... so decided to email you.
>>>>>
>>>>> We are very interested in the consistent hashing feature in the load balancer working cooperatively with the cache and would like to follow the development and contribute if needed. Particularly, we in Moicents already have a number of use-cases that concern bothtelecom and pure web applications. For example - a web based chat room will have a number of participants with different HTTP sessions and they share the same state somewhere in another cache at the same node. It would be desireable to failover such groups of users together to avoid having them to lookup the chat state in remote caches over the network. That is why, if possible, we are interested in using not just the HTTP session ID for lookups, but have a configurable affinity key/mask that is taken from the messages, so that you could route all requests with http://redhat.com/?chatroom=1 always to the same node, and "chatroom" as an URL param is the affinity key with value "1".
>>>>>
>>>>> Sailfin/Glassfish have something similar with their CLB.
>>>>>
>>>>> In Mobicents we would be using it to coordinate not only mod_cluster and cache, but the SIP load balancer and other protocol load balancers as well. In fact, our load balancer already supports HTTP consistent hashing, however it doesn't have the high performance of mod_cluster (no AJP either) and is only recommended when SIP+HTTP coordination is a requirement for our telco users.
>>>>>
>>>>> http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm (Slide 17 has a helpful diagram)
>>>>>
>>>>> The other technique we are using to coordinate multiprotocol load balancers with local cache is this
>>>>>
>>>>> http://docs.google.com/present/edit?id=0AdgrvwaZgnJ1ZGM1anA1dnhfOTZnZjYyc...
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Lead, AS Clustering
>>>> JBoss by Red Hat
>>>
>>
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jboss-cluster-dev mailing list
> jboss-cluster-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 6 months
Re: [jboss-cluster-dev] MyRpcDispatcher
by Paul Ferraro
Galder,
To which method is Bela referring?
Otherwise, I'm ready to check in the org.jgroups.blocks.mux package.
There is a small change required in MessageDispatcher.setChannel(...):
channel.setUpHandler(prot_adapter);
needs to be replaced by:
if (channel.getUpHandler() == null)
channel.setUpHandler(prot_adapter);
This is need to prevent each new RpcDispatcher/MessageDispatcher from
overwriting the preexisting multiplexing UpHandler.
I can't envision this breaking any existing use case, but I wanted to
verify before committing.
So, to review, usage will now look like:
Channel c = new JChannel(...);
// RpcDispatcher d = new RpcDispatcher(c, null, null, target);
// c.setUpHandler(new MuxUpHandler(d.getProtocolAdapter());
c.setUpHandler(new MuxUpHandler());
RpcDispatcher d1 = new MuxRpcDispatcher((short) 1, c, null, null, target);
RpcDispatcher d1 = new MuxRpcDispatcher((short) 2, c, null, null, target);
c.connect(...);
Paul
On Mon, 2010-04-12 at 13:16 +0200, Bela Ban wrote:
> I understand all of the new code is in the new package
> org.jgroups.blocks.scope. If that's the case, I suggest add and commit
> your changes so you can experiment with them.
>
> I also recall Galder needed to change some method from private to
> protected, why don't you go ahead and do this too ?
<snip>
15 years, 6 months
Re: [jboss-cluster-dev] MyRpcDispatcher
by Brian Stansberry
Good point on "shared".
I laughed off "multiplexer" in my last post 'cause I thought it would
give you a stroke!
Resurrecting it with a new meaning is ok by me (multiplexing is a
pretty general concept) except I'm a bit concerned the legacy usage is
not quite dead yet. Specifically in the
ChannelFactory.createMultiplexerChannel methods and the JBC (hopefully
not Infinispan) Configuration where there are properties like
getMuxStackName.
OK, checked Infinispan and as expected there's no mention of "mux"
anywhere. And the AS ChannelFactory for years has been documented as not
returning a MuxChannel from createMultiplexerChannel. So, I don't have a
concern about reusing the Multiplexer term.
On 04/12/2010 08:08 AM, Bela Ban wrote:
> Shared also has a connotation in JGroups, maybe MultiplexedUpHandler ?
> MuxUpHandler ? The latter 2 would give a bad word a new (hopefully
> better !) meaning...
>
> Brian Stansberry wrote:
>> We need to think of another word besides "scope" for this, since it
>> has a completely separate meaning elsewhere in JGroups.
>>
>> Multiplexer? Just kidding ;-)
>>
>> Shared/shareable? That seems reasonable in package/class names, but
>> not so good for the short "scope" param/field. Maybe "scope" is ok for
>> the param/field if we can come up with something else for the
>> package/class names; by the time you are thinking about variables the
>> package/class names have given you a clue what you're looking at.
>>
>> On 04/12/2010 06:16 AM, Bela Ban wrote:
>>> I understand all of the new code is in the new package
>>> org.jgroups.blocks.scope. If that's the case, I suggest add and commit
>>> your changes so you can experiment with them.
>>>
>>> I also recall Galder needed to change some method from private to
>>> protected, why don't you go ahead and do this too ?
>>>
>>> Paul Ferraro wrote:
>>>> I've modified Bela's existing sample code to address the issues Brian
>>>> and I discussed below. Here's a summary of the changes:
>>>>
>>>> * Refactored pieces into separate classes with nicer names
>>>> * ScopedRpcDispatcher registers its scope with a ScopedUpHandler
>>>> * Added ScopeUpHandler deregistration on ScopedRpcDispatcher.stop().
>>>> * ScopedUpHandler accepts an optional default handler, which will be
>>>> triggered for non-message events or messages with no scope header
>>>> * ScopedUpHandler returns NoHandlerForScope object if message is
>>>> received for an unknown scope (e.g. its handler was not yet registered
>>>> or was already deregistered)
>>>> * Automatically adds RspFilter to RequestOptions that rejects
>>>> NoHandlerForScope responses, decorating any existing filter, if
>>>> necessary.
>>>> * Added ScopedMessageDispatcher analogue
>>>>
>>>> So, usage would look like:
>>>>
>>>> Channel c = new JChannel(...);
>>>>
>>>> ScopedUpHandler h = new ScopedUpHandlerImpl();
>>>>
>>>> ScopedRpcDispatcher d1 = new ScopedRpcDispatcher((short)1, h, c, null,
>>>> null, target1);
>>>> ScopedRpcDispatcher d2 = new ScopedRpcDispatcher((short)2, h, c, null,
>>>> null, target2);
>>>>
>>>> // This must be set after all rpc dispatchers are created
>>>> c.setUpHandler(h);
>>>> c.connect(...);
>>>>
>>>>
>>>> This will also work in conjunction with a standard rpc dispatcher:
>>>>
>>>> Channel c = new JChannel(...);
>>>>
>>>> RpcDispatcher d = new RpcDispatcher(c, null, null, target);
>>>> ScopedUpHandler h = new ScopedUpHandlerImpl(d.getProtocolAdapter());
>>>>
>>>> ScopedRpcDispatcher d1 = new ScopedRpcDispatcher((short)1, h, c, null,
>>>> null, target1);
>>>> ScopedRpcDispatcher d2 = new ScopedRpcDispatcher((short)2, h, c, null,
>>>> null, target2);
>>>>
>>>> c.setUpHandler(h);
>>>> c.connect(...);
>>>>
>>>>
>>>> I've attached the changes in the form of a patch to JGRP-1177.
>>>> Comments are welcome.
>>>>
>>>> Paul
>>>>
>>>>
>>>
>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 6 months
Re: [jboss-cluster-dev] MyRpcDispatcher
by Brian Stansberry
We need to think of another word besides "scope" for this, since it has
a completely separate meaning elsewhere in JGroups.
Multiplexer? Just kidding ;-)
Shared/shareable? That seems reasonable in package/class names, but not
so good for the short "scope" param/field. Maybe "scope" is ok for the
param/field if we can come up with something else for the package/class
names; by the time you are thinking about variables the package/class
names have given you a clue what you're looking at.
On 04/12/2010 06:16 AM, Bela Ban wrote:
> I understand all of the new code is in the new package
> org.jgroups.blocks.scope. If that's the case, I suggest add and commit
> your changes so you can experiment with them.
>
> I also recall Galder needed to change some method from private to
> protected, why don't you go ahead and do this too ?
>
> Paul Ferraro wrote:
>> I've modified Bela's existing sample code to address the issues Brian
>> and I discussed below. Here's a summary of the changes:
>>
>> * Refactored pieces into separate classes with nicer names
>> * ScopedRpcDispatcher registers its scope with a ScopedUpHandler
>> * Added ScopeUpHandler deregistration on ScopedRpcDispatcher.stop().
>> * ScopedUpHandler accepts an optional default handler, which will be
>> triggered for non-message events or messages with no scope header
>> * ScopedUpHandler returns NoHandlerForScope object if message is
>> received for an unknown scope (e.g. its handler was not yet registered
>> or was already deregistered)
>> * Automatically adds RspFilter to RequestOptions that rejects
>> NoHandlerForScope responses, decorating any existing filter, if
>> necessary.
>> * Added ScopedMessageDispatcher analogue
>>
>> So, usage would look like:
>>
>> Channel c = new JChannel(...);
>>
>> ScopedUpHandler h = new ScopedUpHandlerImpl();
>>
>> ScopedRpcDispatcher d1 = new ScopedRpcDispatcher((short)1, h, c, null,
>> null, target1);
>> ScopedRpcDispatcher d2 = new ScopedRpcDispatcher((short)2, h, c, null,
>> null, target2);
>>
>> // This must be set after all rpc dispatchers are created
>> c.setUpHandler(h);
>> c.connect(...);
>>
>>
>> This will also work in conjunction with a standard rpc dispatcher:
>>
>> Channel c = new JChannel(...);
>>
>> RpcDispatcher d = new RpcDispatcher(c, null, null, target);
>> ScopedUpHandler h = new ScopedUpHandlerImpl(d.getProtocolAdapter());
>>
>> ScopedRpcDispatcher d1 = new ScopedRpcDispatcher((short)1, h, c, null,
>> null, target1);
>> ScopedRpcDispatcher d2 = new ScopedRpcDispatcher((short)2, h, c, null,
>> null, target2);
>>
>> c.setUpHandler(h);
>> c.connect(...);
>>
>>
>> I've attached the changes in the form of a patch to JGRP-1177.
>> Comments are welcome.
>>
>> Paul
>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 6 months
JGroups preference for IPv6
by Brian Stansberry
This is somewhat related to previous discussion at [1] and related
JGRP-1152 [2].
Since we've upgraded JBoss AS trunk to JGroups 2.10.0.Alpha3, it will no
longer start on a machine that supports both IPv4 and IPv6. This is
because we don't specify java.net.preferIPv4Stack in our startup
scripts, so Util.getIpStackType() returns StackType.IPv6. But we
configure IPv4 multicast addresses by default so the JGRP-1152 check
fails the startup.
Since we're specifying IPv4 addresses by default, perhaps our startup
scripts could set -Djava.net.preferIPv4Stack=true. Jason can comment if
he likes; it may be necessary although I don't really like it (yet
another config in an obscure location).
I'm wondering if JGroups can handle this situation more flexibly. I've
attached an *untested* patch that shows what I was thinking:
1) Add a new StackType.Either which Util.getIpStackType() returns if the
OS supports both stack types and no java.net.preferXXX property is set.
2) Configurator.setupProtocolStack() recognizes StackType.Either and
when it's analyzing the InetAddresses it's seeing, it uses the first one
it sees to switch to either StackType.IPv4 or StackType.IPv6. So in this
case the users choice of addresses controls the behavior.
3) Thereafter, the normal JGRP-1152 checks apply, so illegal
inconsistencies are caught and rejected.
I checked for other uses of Util.getIpStackType() and tweaked the one
that needed it to deal with a return value of StackType.Either. I
haven't checked *all* uses of StackType though; wanted to get some
feedback first.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
[1]
http://old.nabble.com/Protocol-stack-issue-on-dual-stack-%28IPv4-and-v6%2...
[2] https://jira.jboss.org/jira/browse/JGRP-1152
15 years, 6 months
Re: [jboss-cluster-dev] Consistent Hashing in mod_cluster
by Brian Stansberry
I'm putting this on the cluster-dev list as there's no reason for it to
continue in private.
Manik, I agree with your comment about avoiding tight coupling between
the ISPN hash algorithm and something inside mod_cluster. The approach
we decided to take was to change the jvmRoute -- see
https://jira.jboss.org/jira/browse/JBAS-7853. The Mobicents folks are
already familiar with that approach since the AS has long done that on
failover. They've added a browser redirect technique that would even
avoid the "1 'inefficient' dispatch" issue you noted.
What's different about what Vladimir's raising here is the need to try
to group sessions together; i.e. use something other than the cache key
(i.e. jsessionid) as the factor in the hash algorithm. He mentioned a
use case for multiple users in a chat where the goal would be to cache
sessions locally with chat state. AIUI there's also a use case where a
user has a SIP session and an HTTP session, so the goal would be to have
both session cached together.
Doing that will clearly require quite a bit of AS work -- some pluggable
policy for determining what the "affinity key" is based on the call
context (null == use the cache key for hashing). Then use the
affinityKey can calling into ISPN (i.e. ISPN-359) and when determining
where to fail over to (JBAS-7853).
This will also be useful for the HTTPSession + SFSB in same request use
case, where colocating the SFSB and the web session is optimal.
I hadn't opened a JIRA for that yet; just tried to but JIRA seems to not
be working?
Hmm, an issue is if the caches involved in the overall picture (e.g.
httpsession cache and "chat state" cache) end up using different
CacheManagers/JGroups Channels. This would quite likely happen (see
http://community.jboss.org/thread/149868 for discussion why). If that's
the case, the views between the channels could end up slightly different
-- e.g. servers A and B are booting at the same time, so due to slight
differences in the boot, Channel for HTTPSession cache ends up with view
{A, B} and Channel for "chat state" cache ends up with {B, A}. In that
case I wouldn't expect there to be a reliable, performant way to ensure
affinity, since the view is a major factor in the hashing algorithm.
On 04/09/2010 04:53 AM, Manik Surtani wrote:
> I made a few comments on the JIRA to respond to your comment; Brian, correct me if I have missed something, but this is pretty much what we spoke about in Brno? Do you have a JIRA in JBAS for this as well?
>
>
> On 8 Apr 2010, at 19:39, Vladimir Ralev wrote:
>
>> Thanks, this will work great for us. However, this issue seems to be scoped purely in Infinispan https://jira.jboss.org/jira/browse/ISPN-359
>>
>> A reciprocal feature is needed in mod_cluster. Would it be possible mod_cluster to use a URI parameter, a cookie as affinity key. AFAIK from mod_jk, it only supports using the jsessionid cookie and uri param (hardcoded). Ultimately we'd like to have it use a customer GET param or cookie for affinity. I couldnt find any doc related to that. Would this be possible?
>>
>> ----- Original Message -----
>> From: "Manik Surtani"<msurtani(a)redhat.com>
>> To: "Brian Stansberry"<brian.stansberry(a)redhat.com>
>> Cc: "Vladimir Ralev"<vralev(a)redhat.com>, "Brian Stansberry"<bstansbe(a)redhat.com>, "Jean Deruelle"<jderuell(a)redhat.com>, "Paul Ferraro"<paul.ferraro(a)redhat.com>
>> Sent: Thursday, April 8, 2010 1:43:00 PM GMT +02:00 Athens, Bucharest, Istanbul
>> Subject: Re: Consistent Hashing in mod_cluster
>>
>>
>> On 6 Apr 2010, at 20:02, Brian Stansberry wrote:
>>
>>> Hi Vladimir,
>>>
>>> I've been on vacation. I replied to your question on the wiki page, but what you're talking about here is a bigger picture thing.
>>>
>>> Sounds like your situation is a good use case for https://jira.jboss.org/jira/browse/ISPN-359 which is an Infinispan JIRA. (At least I believe that's the JIRA that gets into allowing the caller to provide hints such that separate keys hash to the same storage nodes -- Manik, please correct me if I'm wrong.)
>>
>> Yup, this is correct.
>>
>>>
>>> On 03/31/2010 01:58 PM, Vladimir Ralev wrote:
>>>> Hello Brian,
>>>>
>>>> Not sure if you are following http://community.jboss.org/wiki/Consistent-hashingbasedJBCdatapartitionin... so decided to email you.
>>>>
>>>> We are very interested in the consistent hashing feature in the load balancer working cooperatively with the cache and would like to follow the development and contribute if needed. Particularly, we in Moicents already have a number of use-cases that concern bothtelecom and pure web applications. For example - a web based chat room will have a number of participants with different HTTP sessions and they share the same state somewhere in another cache at the same node. It would be desireable to failover such groups of users together to avoid having them to lookup the chat state in remote caches over the network. That is why, if possible, we are interested in using not just the HTTP session ID for lookups, but have a configurable affinity key/mask that is taken from the messages, so that you could route all requests with http://redhat.com/?chatroom=1 always to the same node, and "chatroom" as an URL param is the affinity key with value "1".
>>>>
>>>> Sailfin/Glassfish have something similar with their CLB.
>>>>
>>>> In Mobicents we would be using it to coordinate not only mod_cluster and cache, but the SIP load balancer and other protocol load balancers as well. In fact, our load balancer already supports HTTP consistent hashing, however it doesn't have the high performance of mod_cluster (no AJP either) and is only recommended when SIP+HTTP coordination is a requirement for our telco users.
>>>>
>>>> http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm (Slide 17 has a helpful diagram)
>>>>
>>>> The other technique we are using to coordinate multiprotocol load balancers with local cache is this
>>>>
>>>> http://docs.google.com/present/edit?id=0AdgrvwaZgnJ1ZGM1anA1dnhfOTZnZjYyc...
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss by Red Hat
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 6 months
Re: [jboss-cluster-dev] MyRpcDispatcher
by Galder Zamarreno
Adding Infinispan dev list.
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
----- galder(a)redhat.com wrote:
> As a FYI:
>
> I'm currently testing this and it's interesting to see that the order
> of 1) and 2) as below matters:
>
> 1) disp1=new MyRpcDispatcher((short)100, c1, null, null, new
> Server("foo1()"));
> disp2=new MyRpcDispatcher((short)0, c1, null, null, new
> Server("foo2()"));
> disp3=new MyRpcDispatcher((short)150, c1, null, null, new
> Server("foo3()"));
>
> 2) MyUpHandler handler=new MyUpHandler();
> c1.setUpHandler(handler);
>
> The MyRpcDispatcher constructor relies on MessageDispatcher ctror that
> does:
>
> prot_adapter=new ProtocolAdapter();
> ...
> channel.setUpHandler(prot_adapter);
>
> And after all those ctros have executed, we override the handler in
> 2). If you execute 2) then 1), all messages end up in the last
> uphandler set, which means that all calls go to foo3(). The reason I'm
> looking into this is because from a consumer perspective, I'm trying
> to understand what Hot Rod server would need to give to Infinispan or
> whoever managers the channel.
>
> Note that after 2) comes:
>
> 3) handler.put((short)100, disp1.getProtocolAdapter());
> handler.put((short)0, disp2.getProtocolAdapter());
> handler.put((short)150, disp3.getProtocolAdapter());
>
> Bearing all this mind, I see Hot Rod server providing its own
> Rpcdispatcher in 1) and then 3). 3) might not need to rely on Hot Rod
> server entire if out MyRpcDispatcher, whoever executes 3) can figure
> out the scope number. In other words 3) could be make to look like
> this assuming that disp1, disp2 and disp3 are defined as
> MyRpcDispatcher rather than RpcDispatcher
>
> handler.put(disp1.scope, disp1.getProtocolAdapter());
> handler.put(disp2.scope, disp2.getProtocolAdapter());
> handler.put(disp3.scope, disp3.getProtocolAdapter());
>
> My investigation continues...
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
> ----- "Bela Ban" <bban(a)redhat.com> wrote:
>
> > OK, why don't you take a look ? JGRP-1177 has sample code attached
> > showing how to use this.
> >
> > I'll respond in more detail tomorrow
> >
> > galder(a)redhat.com wrote:
> > > Indeed, I think I need this as well for the Hot Rod use case. Hot
> > Rod servers need to know which other Hot Rod servers are running in
> > the cluster so that they can forward the corresponding information
> > back to clients for load balancing, failover...etc.
> > >
> > > I don't want to polute the core cache channel code having to deal
> > with Hot Rod rpcs.
> > >
> > > Also, a separate channel over a shared transport does not make
> sense
> > since the Hot Rod is tightly linked to the core cache channel that
> > provides data replication capabilities amongst other things. IOW,
> if
> > Hot Rod used a separate channel for this, you could have scenarios
> > where a Hot Rod servers thinks that HotRodServer1, HotRodServer2,
> and
> > HotRodServer3 are the hot rod servers available in the cluster, but
> > underneath the core cache channel would only be formed of
> CoreCache1
> > and CoreCache2, with CoreCache3 isolated. This would be bad since a
> > client could send requests to HotRodServer3 expecting it to
> replicate
> > to 1 or 2 but that would not happen. If the same view was used,
> > clients would realise that HotRodServer3 is not part of the cluster
> > any more.
> > >
> > > I'll check the current proposed solution for
> > https://jira.jboss.org/jira/browse/JGRP-1177 tomorrow and comment
> > further.
> > >
> > > Bela, when do u expect to have something that I can test?
> > >
> > > Cheers,
> > >
> > > p.s. I'm adding cluster-dev list to discussion since this is a
> true
> > inter cluster project concern.
> > > --
> > > Galder Zamarreño
> > > Sr. Software Engineer
> > > Infinispan, JBoss Cache
> > >
> > > ----- "Brian Stansberry" <brian.stansberry(a)redhat.com> wrote:
> > >
> > >
> > >> Paul,
> > >>
> > >> Was just chatting with Galder and it seems Infinispan internally
> > could
> > >>
> > >> also have a use for this. (Their HotRodServers would want to
> make
> > RPCs
> > >>
> > >> but he doesn't want to corrupt the core infinispan usage with
> > that.)
> > >>
> > >> Can you pull together your thoughts on this, respond to Bela,
> bring
> > in
> > >>
> > >> Galder and get this pushed through? Galder's also the most
> > >> knowledgable
> > >> guy on the Hibernate/ISPN integration, which is the other big
> use
> > case
> > >>
> > >> for this.
> > >>
> > >> Thanks,
> > >>
> > >> Brian
> > >>
> > >> On 04/06/2010 03:48 PM, Brian Stansberry wrote:
> > >>
> > >>> Below is the transcript from our chat.
> > >>>
> > >>> Only other thoughts I had on this were:
> > >>>
> > >>> 1) If MyUpHandler exposed a setter for defaultHandler instead
> of
> > >>>
> > >> using
> > >>
> > >>> scope 0 that would be good.
> > >>>
> > >>> 2) If JGroups shipped an UpHandler impl that sent a Message
> with
> > a
> > >>> marker object like NoHandlerForRpc, whoever's responsible for
> > >>>
> > >> setting
> > >>
> > >>> MyUpHandler on the channel could also set that default handler.
> > As
> > >>>
> > >> a
> > >>
> > >>> convenience an overloaded constructor on MyUpHandler could do
> > this
> > >>>
> > >> for
> > >>
> > >>> you based on a boolean param.
> > >>>
> > >>> 3) If JGroups shipped a RspFilter impl that returned false to
> > >>> isAcceptable(Object response, Address sender) if response
> > >>>
> > >> instanceof
> > >>
> > >>> NoHandlerForRpc, then code that was concerned about getting
> > >>> NoHandlerForRpc could pass that to RpcDispatcher call remote
> > >>>
> > >> methods.
> > >>
> > >>> 4) The impl of 3) above should also accept an optional delegate
> > >>>
> > >> whose
> > >>
> > >>> methods would be invoked if the response isn't an instance of
> > >>> NoHandlerForRpc. That could be used in case whatever was making
> > the
> > >>>
> > >> RPC
> > >>
> > >>> also wanted to filter responses some other way.
> > >>>
> > >>> The above plus what we discussed below I think pretty nicely
> > >>> encapsulates the guts of this inside JGroups code. The users of
> > >>>
> > >> this
> > >>
> > >>> stuff would then have to:
> > >>>
> > >>> A) instantiate the channel (if not already done)
> > >>>
> > >>> B) instantiate and set the MyUpHandler and set up the default
> > >>>
> > >> handler
> > >>
> > >>> (if not already done)
> > >>>
> > >>> C) Register their RPC dispatcher
> > >>>
> > >>> D) Pass in the channel to Infinispan, which can be clueless
> about
> > >>>
> > >> all of
> > >>
> > >>> this if they so choose.
> > >>>
> > >>> E) When making any RPCs, pass in the RspFilter impl described
> > >>>
> > >> above.
> > >>
> > >>> If the Channel already existed (e.g. a second service sharing a
> > >>> CacheManager), then the user service would need to figure out a
> > way
> > >>>
> > >> to
> > >>
> > >>> get ahold of it (does Infinispan expose it)? and then do C and
> E
> > >>>
> > >> above.
> > >>
> > >>> I think the latter scenario should discouraged though.
> Different
> > >>> services sharing the same channel is always problematic. Bela
> > >>>
> > >> convinced
> > >>
> > >>> me that by default the different AS services should use
> different
> > >>> CacheManager's/Channels, so all of the above would just be
> needed
> > if
> > >>>
> > >> we
> > >>
> > >>> want to support CacheManager sharing between
> > >>>
> > >> HTTP/SFSB/Hib/HAPartition.
> > >>
> > >>> (02:07:31 PM) besYIM: this class extends ReceiverAdapter, but
> > AFAICT
> > >>>
> > >> it
> > >>
> > >>> doesn't need to; it doesn't do anything w/ that API
> > >>> (02:08:21 PM) paul_m_ferraro: I hadn't even noticed that
> > >>> (02:09:11 PM) besYIM: good; so that means I probably didn't
> miss
> > >>> anything :)
> > >>> (02:10:15 PM) besYIM: the part I don't see is where MyUpHandler
> > >>> put/remove get called
> > >>> (02:10:30 PM) besYIM: ah, in start
> > >>> (02:10:37 PM) paul_m_ferraro: yep
> > >>> (02:12:28 PM) besYIM: this would need to be used from 1) AS 2)
> > >>>
> > >> Hibernate
> > >>
> > >>> 2LC provider 3) Infinispan
> > >>> (02:13:14 PM) paul_m_ferraro: why not put in jgroups directly?
> > >>> (02:13:56 PM) besYIM: yeah, i expect so
> > >>> (02:13:58 PM) paul_m_ferraro: in org.jgroups.blocks?
> > >>> (02:14:02 PM) besYIM: yep
> > >>> (02:14:17 PM) besYIM: i was thinking about what clients would
> > need
> > >>>
> > >> to be
> > >>
> > >>> adapted to use it
> > >>> (02:15:33 PM) besYIM: i.e. what ISPN would have to change to
> deal
> > >>>
> > >> with
> > >>
> > >>> the fact this *may* be there, but typically isn't
> > >>> (02:17:15 PM) paul_m_ferraro: oh - I see you point
> > >>> (02:17:19 PM) paul_m_ferraro: your
> > >>> (02:17:22 PM) besYIM: i'm trying to figure where that
> > >>> MyRpcDispatcher.createRequestCorrelator() method gets invoked
> > >>> (02:17:40 PM) besYIM: since that method smells like a nice hook
> > to
> > >>>
> > >> hide
> > >>
> > >>> all this :)
> > >>> (02:18:21 PM) paul_m_ferraro: infinispan uses their own
> > >>>
> > >> RpcDispatcher
> > >>
> > >>> extension, right?
> > >>> (02:18:33 PM) besYIM: yeah, i believe so
> > >>> (02:19:07 PM) paul_m_ferraro: so the overridden UpHandler would
> > >>>
> > >> just
> > >>
> > >>> fall through to the default behavior if no scope header exists
> > >>> (02:20:23 PM) paul_m_ferraro: the question is, how to override
> > >>> infinispan so that it too can be multiplexed by scope
> > >>> (02:20:31 PM) paul_m_ferraro: no?
> > >>> (02:20:43 PM) besYIM: yep
> > >>> (02:21:33 PM) besYIM: the createRequestCorrelatorMethod seems
> to
> > be
> > >>>
> > >> the way
> > >>
> > >>> (02:21:42 PM) besYIM: well, maybe
> > >>> (02:22:20 PM) besYIM: if it had knowledge as whether the
> > UpHandler
> > >>>
> > >> was
> > >>
> > >>> MyUpHandler it could change the type of RequestCorrelator it
> > >>>
> > >> creates
> > >>
> > >>> (02:22:37 PM) besYIM: std UpHandler, just create the std one
> > >>> (02:22:47 PM) besYIM: special one, create MyRequestCorrelator
> > >>> (02:25:49 PM) paul_m_ferraro: so where would Infinispan get
> it's
> > >>>
> > >> scope
> > >>
> > >>> from?
> > >>> (02:26:14 PM) besYIM: "well known scopes" wiki page?
> > >>> (02:26:45 PM) besYIM: i suppose adding it to the ISPN config
> > would
> > >>>
> > >> be
> > >>
> > >>> better
> > >>> (02:28:28 PM) besYIM: ah, i found the call to
> > >>>
> > >> createRequestCorrelator --
> > >>
> > >>> in MessageDispatcher.start()
> > >>> (02:31:16 PM) besYIM: none of the params passed to that method
> > >>>
> > >> provide
> > >>
> > >>> any info on the type of the UpHandler, but
> > MessageDispatcher.channel
> > >>>
> > >> is
> > >>
> > >>> protected, so the method impl could just look at the Channel
> > >>> (02:32:52 PM) paul_m_ferraro: I should think the
> MyRpcDispatcher
> > >>>
> > >> should
> > >>
> > >>> also register itself w/the MyUpHandler, if its channel used it
> > >>> (02:33:02 PM) besYIM: yep
> > >>> (02:33:44 PM) besYIM: this could all be part of the std
> > >>>
> > >> RpcDispatcher
> > >>
> > >>> (02:34:43 PM) paul_m_ferraro: yep - and can use a default
> scope,
> > if
> > >>>
> > >> none
> > >>
> > >>> specified
> > >>> (02:35:40 PM) besYIM: yeah, so infinispan could deal with
> > >>>
> > >> configuring
> > >>
> > >>> scope or not
> > >>> (02:40:38 PM) besYIM: the other concern i had was lifecycle
> > issues
> > >>>
> > >> --
> > >>
> > >>> i.e. transient issues with a channel not disconnected but a
> > handler
> > >>> removed e.g. during service undeployment
> > >>> (02:41:34 PM) besYIM: or deployment
> > >>> (02:42:52 PM) paul_m_ferraro: so, for example, a message
> arrives
> > >>>
> > >> w/scope
> > >>
> > >>> X but scope X is no longer registered w/the UpHandler?
> > >>> (02:43:16 PM) besYIM: or hasn't yet been registered
> > >>> (02:43:52 PM) besYIM: like lets assume to make it hard that
> HTTP
> > >>> session, SFSB, Hib 2LC will all use the same CacheManager and
> > thus
> > >>>
> > >> same
> > >>
> > >>> Channel
> > >>> (02:44:44 PM) besYIM: nodes A and B are fully started; node C
> is
> > >>>
> > >> coming
> > >>
> > >>> on line. It deploys a distributable webapp, so cache is
> started,
> > >>>
> > >> Channel
> > >>
> > >>> connected, etc
> > >>> (02:45:10 PM) besYIM: but there is no handler for the SFSB and
> > Hib
> > >>>
> > >> 2LC
> > >>
> > >>> stuff yet because those aren't deployed yet
> > >>> (02:46:11 PM) besYIM: HAPartition deals with this via
> > >>>
> > >> NoHandlerForRPC
> > >>
> > >>> (02:51:02 PM) paul_m_ferraro: Well, this is the responsibility
> of
> > >>> whomever created the scoped UpHandler
> > >>> (02:51:57 PM) paul_m_ferraro: bela's impl throws a
> > >>> IllegalArgumentException - but it should be something more
> > specific
> > >>> (02:52:01 PM) besYIM: yeah
> > >>> (02:52:31 PM) besYIM: but if it throws an exception I believe
> > that
> > >>>
> > >> will
> > >>
> > >>> propagate back to the MyRequestCorrelator who sent the RPC and
> > then
> > >>>
> > >> get
> > >>
> > >>> thrown
> > >>> (02:52:32 PM) paul_m_ferraro: and perhaps infinispan should
> allow
> > a
> > >>> pluggable handler for this?
> > >>> (02:53:02 PM) paul_m_ferraro: so those cache users that want to
> > >>>
> > >> ignore
> > >>
> > >>> it can, or retry it, etc.
> > >>> (02:53:13 PM) besYIM: I don't think Infinispan will have a
> > problem
> > >>> (02:53:24 PM) paul_m_ferraro: retry the operation, if possible
> > >>> (02:53:49 PM) besYIM: Infinispan is the one who actually calls
> > >>> Channel.connect, so they are always registered first
> > >>> (02:54:24 PM) besYIM: it's the specialized handlers we'd add
> for
> > >>>
> > >> SFSB
> > >>
> > >>> ownership, or the Hibernate eviction thing that would be
> missing
> > >>> (02:59:17 PM) besYIM: i was looking at the org.jgroups.Request
> > >>>
> > >> class
> > >>
> > >>> (02:59:58 PM) besYIM: it's receiveResponse method is a
> > centralized
> > >>>
> > >> place
> > >>
> > >>> that could deal with something like a NoHandlerForRPC
> > >>> (03:00:10 PM) besYIM: i.e. discard it but mark the response
> > >>>
> > >> received
> > >>
> > >>> (03:02:41 PM) besYIM: a simple impl of
> > org.jgroups.blocks.RspFilter
> > >>> could also work -- add such a thing to JGroups and then AS,
> EJB3,
> > >>> Hibernate could use it for the few RPCs they make
> > >>> (03:06:45 PM) paul_m_ferraro: I see
> > >>> (03:06:57 PM) paul_m_ferraro: damn - its 4
> > >>> (03:07:07 PM) paul_m_ferraro: today's my day to pick up marcus
> > from
> > >>> preschool
> > >>> (03:07:19 PM) besYIM: that's always fun :). enjoy!
> > >>>
> > >> --
> > >> Brian Stansberry
> > >> Lead, AS Clustering
> > >> JBoss by Red Hat
> > >>
> >
> > --
> > Bela Ban
> > Lead JGroups / Clustering Team
> > JBoss
15 years, 6 months