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,

Manik/Mircea, I've noticed that since we won't be doing events for the moment, quit command does not really make sense. The idea of the command was to indicate to the server that it shouldn't send any more notifications to that connection. WDYT?

Cheers, On Mon, 22 Mar 2010 16:48:26 +0100, Galder Zamarreno <galder(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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]...

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(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)redhat.com&gt; >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 25 Mar 2010, at 18:19, Galder Zamarreno wrote: > 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. > +1 > 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/in... > using the following rule for the stats names: stat name for method > getTimeSinceStart is timeSinceStart. > +1 to documenting these on the wiki.

> WDYT? > > On Thu, 25 Mar 2010 17:30:29 +0100, Mircea Markus > <mircea.markus(a)jboss.com&gt; 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(a)redhat.com&gt; >>>> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> -- >>> 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 >> >> >> _______________________________________________ >> 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 -- 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

Just a heads up. I've added more information wrt ForceReturnPreviousValue flag. More precisely, I've added info on which operations it affects: put, remove, putIfAbsent, replace and removeIfUnmodified On Fri, 26 Mar 2010 13:26:56 +0100, Galder Zamarreno <galder(a)redhat.com&gt; wrote: > On Fri, 26 Mar 2010 09:57:54 +0100, Manik Surtani <manik(a)jboss.org&gt; > wrote: > >> >> On 25 Mar 2010, at 18:19, Galder Zamarreno wrote: >> >>> 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. >>> >> >> +1 >> >>> 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/in... >>> using the following rule for the stats names: stat name for method >>> getTimeSinceStart is timeSinceStart. >>> >> >> +1 to documenting these on the wiki. > > I've just updated the wiki and added a section on the stats currently > supported: > https://community.jboss.org/wiki/HotRodProtocol#stats_request > >> >>> WDYT? >>> >>> On Thu, 25 Mar 2010 17:30:29 +0100, Mircea Markus >>> <mircea.markus(a)jboss.com&gt; 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(a)redhat.com&gt; >>>>>> 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>>>> -- >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> 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