geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hitesh Khamesra <hitesh...@yahoo.com.INVALID>
Subject Re: [gemfire-dev] New Client-Server Protocol Proposal
Date Tue, 02 May 2017 01:14:04 GMT
>>>The message header currently is specified to have things like correlation
id, isPartial message, and also metdatadata about whether the key or the
value is JSON.
IsPartialMessage: This flag gives us ability to send partial message without serializing the
whole key-value(request). lets say I execute function at server and function just returns
"arraylist of object". And the serialized size of ""arraylist of object"" is quite big( >
2gb).
metadata: Most of the metadata will be optional. JSON: this is a feature we want to introduce,
where client can send JSON string and we want to save that JSON string into pdx.


      From: Dan Smith <dsmith@pivotal.io>
 To: Udo Kohlmeyer <ukohlmeyer@pivotal.io> 
Cc: dev@geode.apache.org
 Sent: Monday, May 1, 2017 5:53 PM
 Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
   
I think the current proposal seems to be gloming some things together that
probably belong in different layers.

The message header currently is specified to have things like correlation
id, isPartial message, and also metdatadata about whether the key or the
value is JSON. Fragmenting messages (isPartialMessage) seems like it
belongs at a lower level, and depending on what transport your are using is
probably already handled (TCP, HTTP). Potentially similar issue for
request/response (correlationId)  - if you were going over http that would
already be handled. Whether a value is JSON seems like it belongs at a
higher level that specifies the value serialization format. Not to mention
not all messages have keys and values, and some have more than one.

If wonder if it would make more sense to organize the message structure
into layers that each have their own responsibility - a fragmentation layer
(maybe not necessary), a request/response layer (maybe not necessary, not
needed for all message types), function execution layer, individual
operations layer (put, get), value serialization layer.

Without having nailed down what underlying serialization framework you are
using, talking about field byte sizes, etc. seems a bit premature.

-Dan

On Fri, Apr 28, 2017 at 2:49 PM, Udo Kohlmeyer <ukohlmeyer@pivotal.io>
wrote:

> Hi there Geode community,
>
> The new Client-Server protocol proposal is available for review.
>
> It can be viewed and commented on https://cwiki.apache.org/confl
> uence/display/GEODE/New+Client+Server+Protocol
>
> --Udo
>
>


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