Re: [infinispan-dev] More thoughts on HotRod's ForceReturnPreviousValue

See below: On Mon, 29 Mar 2010 13:47:59 +0200, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 26 Mar 2010, at 17:03, Galder Zamarreno wrote: > >> Hi all, >> >> I've been thinking further about ForceReturnPreviousValue flag in >> http://community.jboss.org/wiki/HotRodProtocol. >> >> Currently, if no ForceReturnPreviousValue is passed, the responses for >> put, putIfAbsent, replace, replaceIfUmodified, remove and >> removeIfUmodified looks like this: >> >> [header] >> >> Now, if ForceReturnPreviousValue is passed, the idea is this: If >> ForceReturnPreviousValue has been passed, responses will contain >> previous >> [value length][value] for that key. If the key does not exist or >> previous >> was null, value length would be 0. Otherwise, if no >> ForceReturnPreviousValue was sent, the response would be empty. >> >> However, as it is, this means that for a put, the response would be >> either, [header] or [header][value lenght][value]. So, in effect, the >> client decoder needs to know about the request itself to be able to >> determine whether it needs to read the value length or not. I wonder >> whether this could be imposing some restrictions on the client decoder. >> So, instead, I was wondering whether this might make more sense and make >> implementation of the client decoder easier. >> >> put, putIfAbsent, replace, replaceIfUmodified, remove and >> removeIfUmodified responses looks like this: >> [header][value length] >> >> *If no ForceReturnPreviousValue is sent, value length will always be 0*. >> If ForceReturnPreviousValue is passed and key was not present, or >> previous >> value was null, value length is 0. Otherwise, value length will be non >> zero and value will follow. >> >> The idea here is that these ops responses always return a value length, >> regardless of whether the flag is present or not. This, I think, would >> make client dcoders easier since they always know what they need to read >> and can pass it back without knowing which flags were passed on the >> request. >> >> Thoughts? > > Don't clients hold on to the message id when a message is sent, and > shouldn't the response contain the same message id? That should allow > clients to decide whether to parse a return value or not. Indeed they can do that. I just thought having it always there would make decoding easier since they can decode without needing to know about the request. After decoding, you do need to match up the response accordingly and send it back to the client. I've ended up implementing this as originally thought though. > > -- > 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