I agree with Dan that the spec will need to deal with the effects of
retrying an operation.
Le 5/3/2017 à 10:58 AM, Hitesh Khamesra a écrit :
(Sorry: one more attempt to format this message)
Here are the few things we need to consider..
1. key, value, callbackarg can be required to interpret as JSON-to-pdx.
2. client calls "get/getall" api and want return value as JSON. Value was
serialized as pdx.
3. This behavior should be optional, if possible no overhead for others.
4. "putAll api" can have mixed type values(JSON and numbers). Dan raised about
this. And may be worth to consider it.
Thus my initial thought was client should indicate this feature at message
level(metadata), saying, convert pdx value to json or vice-versa.
Any thoughts?
Thanks.
HItesh
________________________________
From: Hitesh Khamesra <hitesh...@yahoo.com.INVALID>
To: "dev@geode.apache.org" <dev@geode.apache.org>
Sent: Wednesday, May 3, 2017 10:01 AM
Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
Here are the few things we need to consider..
1. key, value, callbackarg can be required to interpret as JSON-to-pdx2. client calls
"get/getall" api and want return value as JSON. Value was serialized as pdx.3. This
behavior should be optional, if possible no overhead for others.4. "putAll api" can have
mixed type values(JSON and numbers). Dan raised about this. And may be worth to consider it.
Thus my initial thought was client should indicate this feature at message
level(metadata), saying, convert pdx value to json or vice-versa.
Any thoughts?
Thanks.HItesh
From: Jacob Barrett <jbarr...@pivotal.io>
To: dev@geode.apache.org
Cc: Udo Kohlmeyer <ukohlme...@pivotal.io>
Sent: Tuesday, May 2, 2017 8:11 PM
Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
I agree completely with Dan. There is no reason to have flags for value encoding type in the message. I would argue that should be part of the value serialization layer. If something was placed in the message layer it should be more generic and allow for an unrestricted set of encodings by some ID.
Object {
variant ID codec;
byte[] payload;
}
-Jake
Sent from my iPhone
On May 2, 2017, at 1:42 PM, Dan Smith <dsm...@pivotal.io> 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
