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 <ptupit...@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 <pg...@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 <ptupit...@apache.org> >> wrote: >> >>> Sergey, good point, done. >>> >>> On Wed, Nov 29, 2017 at 2:30 PM, Sergey Kozlov <skoz...@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 <skoz...@gridgain.com> >>> > wrote: >>> > >>> > > Pavel >>> > > >>> > > Thanks for explanations! >>> > > >>> > > On Mon, Nov 27, 2017 at 2:46 PM, Pavel Tupitsyn < >>> ptupit...@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 < >>> skoz...@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 <pg...@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 < >>> > ptupit...@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 >>> > >>> >> >> >
