Basically, thread/layer should not hold any resources while serializing the object or chunk. We should be able to see this flow (ms1-chunk1, msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)
On other pdx note: to de-serialize the pdx we need length of serialized bytes, so that we can read field offset from serialized stream, and then can read field value. Though, I can imagine with the help of pdxType, we can interpret serialized stream. ________________________________ From: Jacob Barrett <jbarr...@pivotal.io> To: dev@geode.apache.org; Hitesh Khamesra <hitesh...@yahoo.com> Cc: Anthony Baker <aba...@pivotal.io> Sent: Thursday, May 4, 2017 2:14 PM Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal > One benefit of messageHeader with chunk is that, it gives us ability to > write different messages(multiplexing) on same socket. And if thread is > ready it can write its message. Though we are not there yet, but that will > require for single socket async architecture. > I wouldn't tackle that at this layer. I would suggest adding a layer between the message and TCP that creates channels that are opaque to the message layer above. The message layer wouldn't know if it was talking to multiple sockets to the client or single socket with multiple channels. -Jake
