[infinispan-dev] Hot Rod - pt2

[Galder Zamarreno]

On 12/17/2009 02:45 PM, Bela Ban wrote:
> Correct, but that ID by itself is NOT unique over space&  time. I don't
> know though whether you ned this uniqueness...

Hmmmm, I don't think the consequences of it not being unique are huge.

Let's say a client has vClient=10 that consists of nodeA and nodeB and 
then the server generates a vServer=10 with nodeA, nodeC and nodeD. The 
server won't send back the topology but the client will be working 
sub-optimally until a new view is generated since it will be sending 
everything to the sole remaining node in his view, nodeA. If the new 
view had included only nodeE and nodeF (assumming nodeA and nodeB have 
been brought down), the client would need to reconnect to a known server 
somehow and would start at -1, so it'd get a new topology in first response.

>
> Manik Surtani wrote:
>> On 17 Dec 2009, at 11:58, Bela Ban wrote:
>>
>>
>>> Do you guys need something from me, e.g. a unique ID (over time and
>>> space) for ViewId ?
>>>
>>> Note that ViewId consists of an Address (UUID) and an ID, so this could
>>> be returned as 3 longs...
>>>
>>
>> Isn't a ViewID just a long?  ViewID.getId() ?
>>
>>
>>
>>
>>> Manik Surtani wrote:
>>>
>>>> On 16 Dec 2009, at 14:04, Galder Zamarreno wrote:
>>>>
>>>>
>>>>
>>>>>> I expect this to be declarative (in XML).  Then you just filter the JGroups view against the nodes you have in the list of HR servers to determine what to send back.
>>>>>>
>>>>>>
>>>>> I was expecting to this in similar to way to how clustered EJBs do. When
>>>>> you you deploy a clustered EJB, it sends a sync message around the
>>>>> cluster indicating to the other servers that there's a new endpoint for
>>>>> that clustered EJB and hence, they update a server side list of HATarget
>>>>> which is what is send back to the clients in piggyback.
>>>>>
>>>>> I was thinking that when a HR server deploys, I could do a similar
>>>>> thing. You could then use the existing JGroups view id and associate it
>>>>> with the current HR server target list.
>>>>>
>>>>> This however assumes that the server side HR servers are actually joined
>>>>> in a single cluster, which might not necessarily suit all situations.
>>>>>
>>>>>
>>>> Maybe Mircea's suggestion makes sense - a separate, internal Cache instance that uses REPL_ASYNC or something, to propagate a HR server list.
>>>>
>>>>
>>>> --
>>>> Manik Surtani
>>>> manik at jboss.org
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>> --
>>> Bela Ban
>>> Lead JGroups / Clustering Team
>>> JBoss
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache