Pavel, I do not see how it can effect something existing, as nothing exists yet :-) Let's put current SQL aside, we will merge them into protocol later. The main point of length is to move request parsing and deserialization to separate thread. Without it we will have to pre-process all requests in a single thread, what can become a bottleneck. What Yakov suggests, is similar to our communication architecture: we take request length, copy request bytes and then push them to another thread for processing. Makes sense to me.
As far as request ID, yes, this is just and unique ID to correlate request(s) and response(s). On Wed, Aug 2, 2017 at 11:49 AM, Pavel Tupitsyn <ptupit...@apache.org> wrote: > Yakov, > > > 2. put op_code to the first place. This will make possible to eliminate > length field for many messages > This will require extensive refactoring of existing socket pipeline for > very little benefit: almost all messages are of variable length. > > > 3. build date and revision hash to handshake > Please clarify, build version of what? Client or Ignite? Does it come in or > out? > > > Vladimir, Alexey, > Yes, we should definitely add multiplexing in future, but for now let's > make it work in a simple way. > > As for requestId, do I understand correctly that client includes some ID in > the request, > and Ignite just copies it to the corresponding response message? > > Pavel > > On Wed, Aug 2, 2017 at 11:37 AM, Yakov Zhdanov <yzhda...@apache.org> > wrote: > > > Agree with Alex. I think our implementations should share single > connection > > over threads in the process. > > > > --Yakov > > >
