[infinispan-dev] HotRod, ClientIntelligence and client-side key location
Manik Surtani
manik at jboss.org
Tue Apr 20 09:58:22 EDT 2010
On 16 Apr 2010, at 23:45, Mircea Markus wrote:
>
> On 14 Apr 2010, at 10:22, Galder Zamarreno wrote:
>
>> Apologies for the delay getting back to this. I think Mircea does have a point here.
>>
>> I think his suggestion might make the the hash function parameters more future proof at the cost of a vInt for the parameter number and a String with the parameter name in the response.
> +1. This is more generic and the cost is only one additional param (int?), that's only sent once per HR client.
>>
>> I can't however give individual examples on parameters that'd be needed in the future.
> What about virtual node count, for a function that uses virtual nodes?
There is no guarantee that we'd ever implement a virt node mechanism.
>>
>> Mircea, what did you refer to by sending number of owners? We already do that in the current protocol spec.
> I missed that.
>>
>> Cheers,
>>
>> ----- "Mircea Markus" <mircea.markus at jboss.com> wrote:
>>
>>> On 6 Apr 2010, at 19:37, Manik Surtani wrote:
>>>
>>>>
>>>> On 2 Apr 2010, at 00:59, Mircea Markus wrote:
>>>>
>>>>>> I foresee making the hash space size a tuning parameter in the
>>> future. This is independent of hash function used.
>>>>> Are all the hash functions going to have an hash space parameter?
>>> Other functions might need some additional config params. What about
>>> not "hardcoding" params in the protocol itself, but use a generic way
>>> to send them over:
>>>>> ... bytes[ h f version] [param number] [param name 1] [param value
>>> 1] etc.
>>>>> Each function should be able to read its own params.
>>>>
>>>>
>>>> I don't see what other params could exist? Any examples?
>>> nr of virtual nodes for a different implementation. In future we might
>>> also want to send the number of owners. Another impl might come with
>>> its own params.
>>>>
>>>> --
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100420/a785e1cc/attachment-0001.html
More information about the infinispan-dev
mailing list