geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <>
Subject Re: [gemfire-dev] New Client-Server Protocol Proposal
Date Thu, 04 May 2017 00:31:10 GMT
Okay .... but how do I has an implementer of a driver know what messages
need an event id and which don't? It seems like maybe this belongs with
those message types, rather than in a generic header. Or maybe you need to
start organizing messages into classes - eg messages that change state and
messages that don't and abstracting out commonality.

It's also not clear exactly what the event id should be set to. When do a
change the sequence id? Does it have to be monotonically increasing? What
should the uniqueId be?


On Wed, May 3, 2017 at 5:07 PM, Udo Kohlmeyer <> wrote:

> Correct,
> I did miss that. @Dan, if you look at
> uence/display/GEODE/Message+Structure+and+Definition#Messa
> geStructureandDefinition-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 <
>>>> luence/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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message