ber 5, 2017 11:15 PM
> To: dev@ignite.apache.org
> Subject: Re: Thin Client Protocol documentation
>
> Andrey,
>
> As I understand, you suggest to document every prospective feature right
> now.
> That would be (at least) compute, clustering, transactions, services,
> messages,
-
> *From:* Pavel Tupitsyn
> *Sent:* Tuesday, December 5, 2017 12:07 AM
> *Cc:* dev@ignite.apache.org
> *Subject:* Re: Thin Client Protocol documentation
>
> Andrey,
>
> All of this is to come :)
>
>
> Prachi,
>
> 1) There are no flags, see
ppy
to review the spec and provide my feedback. Also, I'm very interested in
becoming a contributor/early adopter of the Java-based implementation of the
protocol.
Regards
Andrey
From: Pavel Tupitsyn
Sent: Tuesday, December 5, 2017 11:15 PM
To: de
> *From:* Pavel Tupitsyn
> *Sent:* Tuesday, December 5, 2017 12:07 AM
> *Cc:* dev@ignite.apache.org
> *Subject:* Re: Thin Client Protocol documentation
>
> Andrey,
>
> All of this is to come :)
>
>
> Prachi,
>
> 1) There are no flags, see
l can accommodate all those use
cases before it gets released to the public.
Thanks
Andrey
From: Pavel Tupitsyn
Sent: Tuesday, December 5, 2017 12:07 AM
Cc: dev@ignite.apache.org
Subject: Re: Thin Client Protocol documentation
Andrey,
All of this is to
e notification
>> mechanism. This way the clients can detect a topology change and refresh
>> the topology snapshot next time they need to compute affinity.
>>
>> Regards
>> Andrey
>>
>> From: Pavel Tupitsyn
>> Sent: S
> Andrey
>
> From: Pavel Tupitsyn
> Sent: Sunday, December 3, 2017 9:23 AM
> To: dev@ignite.apache.org
> Subject: Re: Thin Client Protocol documentation
>
> Hi Andrey,
>
> Compute and other APIs are certainly planned, cache is just a s
nd refresh the topology snapshot next time they
need to compute affinity.
Regards
Andrey
From: Pavel Tupitsyn
Sent: Sunday, December 3, 2017 9:23 AM
To: dev@ignite.apache.org
Subject: Re: Thin Client Protocol documentation
Hi Andrey,
Compute and other APIs are
Prachi,
Added "Cache flags" note to the doc.
Thanks,
Pavel
On Mon, Dec 4, 2017 at 7:46 PM, Prachi Garg wrote:
> Pavel,
>
> How do you specify the flags (withSkipStore, withExpiryPolicy, etc..) in
> bytes? Do you have a code for each of them?
>
> On Sun, Dec 3, 2017 at 9:23 AM, Pavel Tupitsyn
Pavel,
How do you specify the flags (withSkipStore, withExpiryPolicy, etc..) in
bytes? Do you have a code for each of them?
On Sun, Dec 3, 2017 at 9:23 AM, Pavel Tupitsyn wrote:
> Hi Andrey,
>
> Compute and other APIs are certainly planned, cache is just a start.
> We intentionally limit the sc
Hi Andrey,
Compute and other APIs are certainly planned, cache is just a start.
We intentionally limit the scope to actually release something in 2.4 and
not delay it further.
Adding operations to existing protocol is relatively easy.
Current focus is to make sure that the protocol itself is soli
to invoke already
deployed tasks/services, or send a closure (if the client happens to be written
in Java) for execution.
Thanks
Andrey
From: Pavel Tupitsyn
Sent: Friday, December 1, 2017 5:48 AM
To: dev@ignite.apache.org
Subject: Re: Thin Client Protocol doc
should have no
> exceptions for message formats.
>
> Thank you,
> Alexey
>
> From: Pavel Tupitsyn
> Sent: Thursday, November 30, 2017 12:11 PM
> To: dev@ignite.apache.org
> Subject: Re: Thin Client Protocol documentation
>
> Hi Alexey,
>
> 1,2,3 are related
-id while others don't? Let's
> simplify parser work )
>
> 4. The same comments for success flag (1 byte) and status code (4 bytes)
> in responses. Let's leave only status code.
>
> Thank you,
> Alexey
>
> From: Pavel Tupitsyn
> Sent: Wednesday, November
hers don't? Let's
> simplify parser work )
>
> 4. The same comments for success flag (1 byte) and status code (4 bytes)
> in responses. Let's leave only status code.
>
> Thank you,
> Alexey
>
> From: Pavel Tupitsyn
> Sent: Wednesday, November 22, 2017 4:04
ay, November 22, 2017 4:04 PM
To: dev@ignite.apache.org
Subject: Thin Client Protocol documentation
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:
-
Prachi, see "Response (failure)" table.
Failed response includes server protocol version and an error message.
On Thu, Nov 30, 2017 at 4:55 AM, Prachi Garg wrote:
> Pavel,
>
> If the connection handshake fails, what should be the message length in
> the response. When I try to fail the handshake
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
wrote:
> Hi Prachi,
>
> Flags parameter in all cache operatio
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 wrote:
> Hi Pavel,
>
> In the op
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
wrote:
> Sergey, good point, done.
>
> On Wed, Nov 29, 2017 at 2:30 PM, Sergey Kozlov
> wrote:
>
> > Pavel
> >
> > Could you update the page by following:
Sergey, good point, done.
On Wed, Nov 29, 2017 at 2:30 PM, Sergey Kozlov 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 d
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
Pavel
Thanks for explanations!
On Mon, Nov 27, 2017 at 2:46 PM, Pavel Tupitsyn
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
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 (group
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
ca
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
wrote:
> Igniters,
>
> I've put together a detailed description of our Thin Client protocol
> in form of IEP on wiki:
> https://cwiki.
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
Pavel Tupitsyn created IGNITE-6607:
--
Summary: Thin client: protocol documentation
Key: IGNITE-6607
URL: https://issues.apache.org/jira/browse/IGNITE-6607
Project: Ignite
Issue Type: Task
28 matches
Mail list logo
