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
