4:52 a.m.
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
the 4th is to be added, which is transactionable client.
Right now 3 depends on 2, so a unique number can clearly identify the level. With 4, there
might be different combinations: e.g. 4 and 2 or 4 and 3. Or even 4 and 1.
We need a way to specify this intelligence combo: perhaps using bit masks?
IMO, this should be done before going Final as it is a change in the protocol itself.
wdyt?
Cheers,
Mircea
5:29 a.m.
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. Pls
don't pollute this field with orthogonal characteristics.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
5:45 a.m.
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?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:48 a.m.
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?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
5:59 a.m.
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.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:07 a.m.
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? 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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:19 a.m.
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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:37 a.m.
On 20 Jul 2010, at 12:19, Mircea Markus wrote:
>
> 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".
Ah yes, what I meant was the field is unset. E.g., contains a 0 or a -1 as a tx id which
assumes either no tx in progress or a client that doesn't support txs.
So I presume this was to optimise away the extra, unset field? How big is this field
anyway?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
8:13 a.m.
On Jul 20, 2010, at 1:37 PM, Manik Surtani wrote:
On 20 Jul 2010, at 12:19, Mircea Markus wrote:
>>
>> 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".
Ah yes, what I meant was the field is unset. E.g., contains a 0 or a -1 as a tx id which
assumes either no tx in progress or a client that doesn't support txs.
As I said in another email. Use tx_id_length to signal this.
If 0, not transactional
If !=0, transactional and tx id follows
Btw, IMO [tx_id length] [tx_id] should be part of the header area.
And finally, I don't see anything wrong with having a version 2 of the Hot Rod
protocol for 5.x where we can add these modifications.
So I presume this was to optimise away the extra, unset field? How big is this field
anyway?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
8:20 a.m.
On 20 Jul 2010, at 14:13, Galder Zamarreño wrote:
On Jul 20, 2010, at 1:37 PM, Manik Surtani wrote:
>
> On 20 Jul 2010, at 12:19, Mircea Markus wrote:
>
>>>
>>> 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".
>
> Ah yes, what I meant was the field is unset. E.g., contains a 0 or a -1 as a tx id
which assumes either no tx in progress or a client that doesn't support txs.
As I said in another email. Use tx_id_length to signal this.
If 0, not transactional
If !=0, transactional and tx id follows
Btw, IMO [tx_id length] [tx_id] should be part of the header area.
yep, we can do
that. Ping would not ever be transactionable, but yeah, that's not a big win.
And finally, I don't see anything wrong with having a version 2 of the Hot Rod
protocol for 5.x where we can add these modifications.
Never thought of HotRod like
not backward compatible - but you're right we can do that.
>
> So I presume this was to optimise away the extra, unset field? How big is this field
anyway?
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:15 a.m.
On 20 Jul 2010, at 12:37, Manik Surtani wrote:
On 20 Jul 2010, at 12:19, Mircea Markus wrote:
>>
>> 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".
Ah yes, what I meant was the field is unset. E.g., contains a 0 or a -1 as a tx id which
assumes either no tx in progress or a client that doesn't support txs.
The
transaction would be sent as follows:
[tx_id_length:vint] [tx_id: byte array].
if tx_id == 0, no tx.
So I presume this was to optimise away the extra, unset field? How
big is this field anyway?
It would be a vint, so for non-tx request 1 byte - not
much.
Important: If we go for this approach we'd have to add the field now, before
"freezing" the spec.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:10 a.m.
On Jul 20, 2010, at 12:29 PM, 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. Pls
don't pollute this field with orthogonal characteristics.
+1 to Manik.
I made a similar comment in response to
http://community.jboss.org/wiki/TransactionsOverHotRod and on top of that, cluster
formation delivery won't work as expected if we add a 4th value meaning that the
operation is transactional.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
5738
days inactive
5738
days old
infinispan-dev@lists.jboss.org
11 comments
3 participants
participants (3)
-
Galder Zamarreño -
Manik Surtani -
Mircea Markus