Right now, this information is stored on the client side.The client has a
list of nodes and get/store the data in them using the following algorithm:
public Value Get(string key)
{
return nodes[ key.GetHashCode() % nodes.Length].Get(key)
}
On Sun, Feb 8, 2009 at 12:19 AM, Tapio Kulmala <[email protected]>wrote:
> I don't know anything about Rhino DHT so this might be a really stupid
> question. You said that that each node is each node is totally isolated from
> all the rest. How does the client initially know what nodes exists and where
> the data might be stored?
>
> Tapio
>
>
> On Sat, Feb 7, 2009 at 9:17 PM, Ayende Rahien <[email protected]> wrote:
>
>> My initial design when building Rhino DHT was that it would work in a
>> similar manner to Memcached, with the addition of multi versioned values and
>> persistence. That is, each node is completely isolated from all the rest,
>> and it is the client that is actually creating the illusion of distributed
>> cohesion.
>>
>> The only problem with this approach is reliability. That is, if a node
>> goes down, all the values that are stored in it are gone. This is not a
>> problem for Memcached. If the node is down, all you have to do is to hit the
>> actual data source. Memcached is *not *a data store, it is a cache, and
>> it is allowed to remove values when you want it.
>>
>> For Rhino DHT, that is not the case. I am using it to store the saga
>> details for Rhino Service Bus, as well as storing persistent state.
>>
>> The first plan was to use it as is. If a node is down, it would cause an
>> error during load saga state stage (try to say *that* three times fast!),
>> which would eventually move the message to the error queue, when the node
>> came back up, we could move the messages from the error queue to the main
>> queue and be done with it.
>>
>> My current client had some objections to that, from his perspective, if
>> any node in the DHT was down, the other nodes should take over
>> automatically, without any interruption of service. That is… somewhat more
>> complex to handle.
>>
>> Well, actually, it isn't more complex to handle. I was able to continue
>> with my current path for everything (including full transparent failover for
>> reads and writes).
>>
>> What I was *not *able to solve, however, was how to handle a node coming
>> back *up*. Or, to be rather more exact, I run into a problem there
>> because the only way to solve this cleanly was to use messaging. But, of
>> course, Rhino Service Bus is dependent on Rhino DHT. And creating a circular
>> reference would just make things more complex, even if it was broken with
>> interfaces in the middle.
>> Thoughts?
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
