geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <ukohlme...@pivotal.io>
Subject Re: [gemfire-dev] New Client-Server Protocol Proposal
Date Thu, 04 May 2017 00:07:24 GMT
Correct,

I did miss that. @Dan, if you look at 
https://cwiki.apache.org/confluence/display/GEODE/Message+Structure+and+Definition#MessageStructureandDefinition-MetaDataforRequests

specifies how we provide EventId information.


On 5/3/17 09:53, Bruce Schuchardt wrote:
> I believe Hitesh put EventId in the metadata section.
>
> Le 5/2/2017 à 2:22 PM, Udo Kohlmeyer a écrit :
>> We are considering the function service, but again, this should not 
>> detract from the proposed message specification proposal.
>>
>> You are also correct in your observation of list of error codes not 
>> being complete nor exhaustive. Maybe the first page needs to 
>> highlight that this is a proposal and does not contain all the error 
>> codes that we could per api.
>>
>> As for the EventId, we will look into this and update the document 
>> accordingly.
>>
>> --Udo
>>
>>
>> On 5/2/17 13:42, Dan Smith wrote:
>>> I guess the value of building other messages on top of the function 
>>> service mostly comes into play when we start talking about smarter 
>>> clients that can do single hop. At that point it's really nice to 
>>> have have a layer that lets us send a message to a single primary, 
>>> or all of the members that host a region etc. It is also nice that 
>>> right now if I add new function that functionality becomes available 
>>> to gfsh, REST, Java, and C++ developers automatically.
>>>
>>> I do agree that the new protocol could build in these concepts, and 
>>> doesn't necessarily have to use function execution to achieve the 
>>> same results. But do at least consider whether new developers will 
>>> want to add new functionality to the server via functions or via 
>>> your this new protocol. If it's harder to use the new protocol than 
>>> to write a new function and invoke it from the client, then I think 
>>> we've done something wrong.
>>>
>>>
>>> A couple of other comments, now that I've looked a little more:
>>>
>>> 1) The list of error codes 
>>> <https://cwiki.apache.org/confluence/display/GEODE/RegionAPI#RegionAPI-ErrorCodeDefinitions>

>>> seems really incomplete. It looks like we've picked a few of the 
>>> possible exceptions geode could throw and assigned them integer ids? 
>>> What is the rational for the exceptions that are included here vs. 
>>> other exceptions? Also, not all messages would need to return these 
>>> error codes.
>>>
>>> 2) The existing protocol has some functionality even for basic puts 
>>> that is not represented here. Client generate an event id that is 
>>> associated with the put and send that to the server. These event ids 
>>> are used to guarantee that if a client does put (A, 0) followed by 
>>> put (A, 1), the resulting value will always be 1, even if the client 
>>> timed out and retried put (A, 0). The event id prevents the lingered 
>>> put that timed out on the server from affecting the state. I'm not 
>>> saying the new protocol has to support this sort of behavior, but 
>>> you might want to consider whether the current protocol should 
>>> specify anything about how events are retried.
>>>
>>> -Dan
>>
>>
>


Mime
View raw message