[infinispan-dev] Hot Rod protocol design at CR stage. Feedback welcome

[Galder Zamarreno]

By the way,

Something related to this. Now that I'm implementing this, the server  
cannot currently differente between parameterless and with parameter stats  
command without using a different request opcode or some other signal that  
tells the server that it needs to read a parameter. I'd suggest  
implementing only the parameterless version for the time being and leave  
the one with parameter for later, if we see demand for this.

As a FYI, something I need to document is the stats returned. For the  
moment, I'm only sending back the stats in  
http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/stats/Stats.java  
using the following rule for the stats names: stat name for method  
getTimeSinceStart is timeSinceStart.

WDYT?

On Thu, 25 Mar 2010 17:30:29 +0100, Mircea Markus  
<mircea.markus at jboss.com> wrote:

>
> On 25 Mar 2010, at 13:43, Manik Surtani wrote:
>
>>
>> On 25 Mar 2010, at 11:27, Galder Zamarreno wrote:
>>
>>> Mircea/Manik,
>>>
>>> There's a final thing I'm not too happy about and that's the response  
>>> to
>>> the stats command. In the current form, the reply to a paramaterless  
>>> stats
>>> command that returns all stats available looks like this:
>>>
>>> [header][name1 length][name1][value1 length][value1]
>>> [header][name2 length][name2][value2 length][value2]
>>> ...
>>> [header] -> This would be the end marker
>>>
>>> This looks quite wasteful since we're adding a header per each stat.
>>> Instead I suggest doing:
>>>
>>> [header][number of stats][name1 length][name1][value1
>>> length][value1][name2 length][name2][value2 length][value2]...
>>
>> +1
> +1
>>
>>>
>>> This is less wasteful and having the number of stats at the beginning
>>> signals how much to read.
>>>
>>> WDYT?
>>>
>>> On Mon, 22 Mar 2010 16:48:26 +0100, Galder Zamarreno  
>>> <galder at redhat.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After having yet another round of discussions, we consider the Hot Rod
>>>> protocol design at CR stage. Here's the final results:
>>>> http://community.jboss.org/wiki/HotRodProtocol
>>>>
>>>> While me and Mircea are busy coding both the server and client, please
>>>> take some time to have a read through it and let us know what you  
>>>> think.
>>>>
>>>> By the way, remember that we've deferred certain functionality for the
>>>> moment as indicated in a previous email:
>>>> [ISPN-375] Enable Hot Rod clients to start transactions [Open, Major,
>>>> Galder Zamarreno] http://jira.jboss.org/jira/browse/ISPN-375
>>>> [ISPN-374] Add event handling to Hot Rod [Open, Major, Galder  
>>>> Zamarreno]
>>>> http://jira.jboss.org/jira/browse/ISPN-374
>>>>
>>>> Cheers,
>>>
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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