ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Garg <pg...@gridgain.com>
Subject Re: Thin Client Protocol documentation
Date Thu, 30 Nov 2017 01:55:24 GMT
Pavel,

If the connection handshake fails, what should be the message length in the
response. When I try to fail the handshake, I get 32 as the message length.
Is this expected?

-Prachi

On Wed, Nov 29, 2017 at 8:20 AM, Pavel Tupitsyn <ptupitsyn@gridgain.com>
wrote:

> Hi Prachi,
>
> Flags parameter in all cache operations is reserved for things like
> withSkipStore, withExpiryPolicy, withKeepBinary, withNoRetries,
> withPartitionRecover.
> See methods in IgniteCache interface.
>
> Thanks,
> Pavel
>
> On Wed, Nov 29, 2017 at 7:10 PM, Prachi Garg <pgarg@gridgain.com> wrote:
>
>> Hi Pavel,
>>
>> In the operation request, what does the 'flags' parameter mean?
>>
>>
>> Thanks,
>> -Prachi
>>
>> On Wed, Nov 29, 2017 at 5:27 AM, Pavel Tupitsyn <ptupitsyn@apache.org>
>> wrote:
>>
>>> Sergey, good point, done.
>>>
>>> On Wed, Nov 29, 2017 at 2:30 PM, Sergey Kozlov <skozlov@gridgain.com>
>>> wrote:
>>>
>>> > Pavel
>>> >
>>> > Could you update the page by following:
>>> >
>>> >  - String, date, UUID arrays allow to put NULL. Due to that every item
>>> in
>>> > the array written as type code byte (default item type or null type
>>> code) +
>>> > type data. It should be detailed explained (looks like that the table
>>> > should have an addtional column called for instance "nullable")
>>> >
>>> > -  UUID type takes 16 bytes length
>>> >
>>> > thanks
>>> >
>>> >
>>> > On Mon, Nov 27, 2017 at 4:37 PM, Sergey Kozlov <skozlov@gridgain.com>
>>> > wrote:
>>> >
>>> > > Pavel
>>> > >
>>> > > Thanks for explanations!
>>> > >
>>> > > On Mon, Nov 27, 2017 at 2:46 PM, Pavel Tupitsyn <
>>> ptupitsyn@apache.org>
>>> > > wrote:
>>> > >
>>> > >> Sergey,
>>> > >>
>>> > >> 1. Code table size does not affect anything, as I understand, so
>>> there
>>> > is
>>> > >> no reason to introduce an extra byte.
>>> > >> 2. We have object arrays (code 23), I forgot to mention them, fixed.
>>> > >> 3. Also forgot, see code 25 in the updated document.
>>> > >>
>>> > >> Also note that operation codes have been updated (grouped by
>>> purpose) as
>>> > >> part of https://issues.apache.org/jira/browse/IGNITE-6989.
>>> > >>
>>> > >> Thanks,
>>> > >> Pavel
>>> > >>
>>> > >> On Sun, Nov 26, 2017 at 9:54 PM, Sergey Kozlov <
>>> skozlov@gridgain.com>
>>> > >> wrote:
>>> > >>
>>> > >> > Pavel
>>> > >> >
>>> > >> > Thanks for the document and your efforts for new protocol.
It was
>>> > really
>>> > >> > helpful for playing around the python thin client design.
>>> > >> >
>>> > >> > Could you explain some things that were still not clear for
binary
>>> > >> object
>>> > >> > format:
>>> > >> >
>>> > >> > 1. What a reason to introduce separated type codes for arrays?
Why
>>> > just
>>> > >> we
>>> > >> > can't use the following?
>>> > >> > *<1 byte universal array code>*
>>> > >> > *<1 byte primitive code>*
>>> > >> > *<4 bytes length>*
>>> > >> > *<N bytes data>*
>>> > >> >
>>> > >> > We get 1 byte overhead but save 10 bytes in the code table.
For
>>> arrays
>>> > >> the
>>> > >> > overhead is really insignificant:10 longs array takes now
>>> 1+4+4*10=45
>>> > >> bytes
>>> > >> > vs 1+1+4+4*10=46 bytes for the approach
>>> > >> > Moreover for that appoach a new primitive code will be available
>>> for
>>> > >> using
>>> > >> > for array immediately.
>>> > >> >
>>> > >> > 2. Why the arrays force to use a selected type? For python
>>> there's no
>>> > >> > limitations to use different types across one array (list).
Would
>>> be
>>> > >> good
>>> > >> > to introduce a new type that will allow that. It could be
look
>>> like
>>> > >> > following
>>> > >> > *<1 byte universal array code>*
>>> > >> > *<1 byte no common type code*> <-- this says that
every item must
>>> > >> provide
>>> > >> > its date type code like it does regular primitive data
>>> > >> > *<4 bytes length>*
>>> > >> > *<1 byte item 0 type code>*     <-- item provides
its code
>>> > >> > *<N byte item 0 data>*      <-- item provides its
data
>>> > >> > *<1 byte item 1 type code>*
>>> > >> > *<N byte item 1 data>*
>>> > >> > etc
>>> > >> >
>>> > >> > Also that allow to put nested arrays without changes in type
code
>>> > table!
>>> > >> > For instance if we want to store 9 longs and 1 boolean it
will
>>> take
>>> > >> > now 1+1+4+(1+9)*4+(1+1)=48
>>> > >> > bytes (vs 45 bytes to store as 10 longs as usual).
>>> > >> >
>>> > >> > 3. Ther's only one way to store a dictionary (key-value)
>>> structure as
>>> > >> value
>>> > >> > in the cache via Complex Object. But it looks like
>>> overcomplicated. I
>>> > >> > suppose to introduce a code for that
>>> > >> > *<1 byte key-value dictionary code>*
>>> > >> >
>>> > >> > *<4 bytes length>*
>>> > >> > *<1 byte key 1 **name **type code>*
>>> > >> > *<N byte key 1 name data>*
>>> > >> > *<1 byte value 1 type code>*
>>> > >> > *<N byte value 1 value>*
>>> > >> > *<1 byte key 2 **name **type code>*
>>> > >> > *<N byte key 2 name data>*
>>> > >> > *<1 byte value 2 type code>*
>>> > >> > *<N byte value 2 value>*
>>> > >> > etc
>>> > >> >
>>> > >> > Also that allow to put nested dictionaries without changes
in type
>>> > code
>>> > >> > table!
>>> > >> > Of  course for the appoach above we get significat overhead
for
>>> key
>>> > >> > storing. But I think it is acceptable for some cases and
>>> definitely ok
>>> > >> for
>>> > >> > Python
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> > On Wed, Nov 22, 2017 at 9:14 PM, Prachi Garg <pgarg@gridgain.com>
>>> > >> wrote:
>>> > >> >
>>> > >> > > Thanks Pavel! The document has good information. I'll
create
>>> one on
>>> > >> > > readme.io; will also add some examples there.
>>> > >> > >
>>> > >> > > On Wed, Nov 22, 2017 at 5:03 AM, Pavel Tupitsyn <
>>> > ptupitsyn@apache.org
>>> > >> >
>>> > >> > > wrote:
>>> > >> > >
>>> > >> > > > Igniters,
>>> > >> > > >
>>> > >> > > > I've put together a detailed description of our
Thin Client
>>> > protocol
>>> > >> > > > in form of IEP on wiki:
>>> > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
>>> > >> > > > 9+Thin+Client+Protocol
>>> > >> > > >
>>> > >> > > >
>>> > >> > > > To clarify:
>>> > >> > > > - Protocol implementation is in master (see
>>> ClientMessageParser
>>> > >> class)
>>> > >> > > > - Protocol has not been released yet, so we are
free to change
>>> > >> anything
>>> > >> > > > - Protocol is only used by .NET Thin Client for
now, but is
>>> > >> supposed to
>>> > >> > > be
>>> > >> > > > used from other languages by third party contributors
>>> > >> > > > - More operations will be added in future, this
is a first
>>> set of
>>> > >> them,
>>> > >> > > > cache-related
>>> > >> > > >
>>> > >> > > >
>>> > >> > > > Please review the document and let me know your
thoughts.
>>> > >> > > > Is there anything missing or wrong?
>>> > >> > > >
>>> > >> > > > We should make sure that the foundation is solid
and
>>> extensible.
>>> > >> > > >
>>> > >> > > >
>>> > >> > > > Thanks,
>>> > >> > > > Pavel
>>> > >> > > >
>>> > >> > >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> > --
>>> > >> > Sergey Kozlov
>>> > >> > GridGain Systems
>>> > >> > www.gridgain.com
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Sergey Kozlov
>>> > > GridGain Systems
>>> > > www.gridgain.com
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Sergey Kozlov
>>> > GridGain Systems
>>> > www.gridgain.com
>>> >
>>>
>>
>>
>

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