[infinispan-dev] Hotrod client intelligence

[Mircea Markus]

On 20 Jul 2010, at 12:07, Manik Surtani wrote:

> 
> On 20 Jul 2010, at 11:59, Mircea Markus wrote:
> 
>> 
>> On 20 Jul 2010, at 11:48, Manik Surtani wrote:
>> 
>>> 
>>> On 20 Jul 2010, at 11:45, Mircea Markus wrote:
>>> 
>>>> 
>>>> On 20 Jul 2010, at 11:29, Manik Surtani wrote:
>>>> 
>>>>> 
>>>>> On 20 Jul 2010, at 10:52, Mircea Markus wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Right now we have the following intelligence levels in HR:
>>>>>> (0x01) basic client, interested in neither cluster nor hash information
>>>>>> (0x02) topology-aware client, interested in cluster information
>>>>>> (0x03) hash-distribution-aware client, that is interested in both cluster and hash information
>>>>> 
>>>>> Transaction aware clients have nothing to do with "intelligence" in that it doesn't affect the way clients discover or route connections to the back-end.
>>>> not in that sense.
>>>>>  Pls don't pollute this field with orthogonal characteristics.
>>>> Then transaction should be supported by all clients implementing the protocol? 
>>> 
>>> No, but if a client doesn't start a tx, then the backend doesn't care if the client can or cannot ever support transactions, right?
>> 
>> Each HotRod operation needs to contain the tx id, if it is part of a transaction. 
>> a) either we add this now, in 4.1, before protocol completes
>> b) or we add it in 5.0 together as per this JIRA. If so, server would need to be aware that client is transactional aware, hence the new intelligence level I was taking about
>> with b clients that don't support tx would't need to send an additional field. We had this discussion on a separate thread with galder, I can live with either one of the two. 
> 
> What if the field was missing?
I don't know how can we read the optional field form the socket: we read it byte by byte, so if a byte is missing we block on read. Something like InputStream.available() would be useful, but even that one returns "an *estimate* of the number of bytes that can be read" - so it's not "good enough". 
>  Doesn't that implicitly mean the client is not (a) in a transaction or, (b) doesn't support transactions anyway, so inherently is in (a) as well?
> 
> Cheers
> Manik
> --
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100720/53c74c6f/attachment-0001.html