Pavel,
I have absolutely no doubts that support for all those features will be added
eventually. And if so, wouldn't it be the right thing to do to document the
operations and their semantics right now without necessarily implementing them?
It should really help to ensure that the protocol can accommodate all those use
cases before it gets released to the public.
Thanks
Andrey
________________________________
From: Pavel Tupitsyn <ptupit...@gridgain.com>
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 the doc
2) String is simply 4 byte length (n) + n bytes
3) Op codes have changed
writeByteLittleEndian(1051, out); // Type code
writeIntLittleEndian(20, out); // String length
out.writeUTF("myNewCache"); // Cache name
On Tue, Dec 5, 2017 at 4:39 AM, Prachi Garg <pg...@gridgain.com> wrote:
> Hi Pavel,
>
> I am trying to use the OP_CACHE_CREATE_WITH_NAME operation, but can't get
> it to work. Digging deeper into the source code, it seems like I have to
> provide a flag, string length, and position, in addition to the type code
> and the actual string. Is that correct?
>
> Here is the request I am sending to the server-
>
> DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>
> // Message length
> writeIntLittleEndian(24, out);
>
> // Op code = OP_CACHE_CREATE_WITH_NAME
> writeShortLittleEndian(1051, out);
>
> // Request id
> long reqId = 1;
> writeLongLittleEndian(reqId, out);
>
> // String (cache name)
> writeByteLittleEndian(9, out); // Type code
> writeByteLittleEndian(0, out); // Flag
> writeIntLittleEndian(20, out); // String length
> writeIntLittleEndian(0, out); // Position
> out.writeUTF("myNewCache"); // Cache name
>
> // Send request
> out.flush();
>
> But I get the following error on the server side.
>
> [2017-12-04
> 17:27:39,421][ERROR][client-connector-#53][ClientListenerNioListener]
> Failed to parse client request.
> java.lang.StringIndexOutOfBoundsException: String index out of range: 2575
> at java.lang.String.checkBounds(String.java:385)
> at java.lang.String.<init>(String.java:462)
> at org.apache.ignite.internal.binary.BinaryUtils.
> doReadString(BinaryUtils.java:1314)
> at org.apache.ignite.internal.binary.BinaryReaderExImpl.
> readString(BinaryReaderExImpl.java:1055)
> at org.apache.ignite.internal.processors.platform.client.cache.
> ClientCacheCreateWithNameRequest.<init>(ClientCacheCreateWithNameReque
> st.java:43)
> at org.apache.ignite.internal.processors.platform.client.
> ClientMessageParser.decode(ClientMessageParser.java:318)
> at org.apache.ignite.internal.processors.platform.client.
> ClientMessageParser.decode(ClientMessageParser.java:220)
> at org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.
> onMessage(ClientListenerNioListener.java:119)
> at org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.
> onMessage(ClientListenerNioListener.java:40)
> at org.apache.ignite.internal.util.nio.GridNioFilterChain$
> TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.
> proceedMessageReceived(GridNioFilterAdapter.java:109)
> at org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.
> body(GridNioAsyncNotifyFilter.java:97)
> at org.apache.ignite.internal.util.worker.GridWorker.run(
> GridWorker.java:110)
> at org.apache.ignite.internal.util.worker.GridWorkerPool$1.
> run(GridWorkerPool.java:70)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> What am I missing here? Can you provide an example of how to send a
> 'String' type request?
>
> -Prachi
>
> On Mon, Dec 4, 2017 at 1:06 PM, Andrey Kornev <andrewkor...@hotmail.com>
> wrote:
>
>> Pavel,
>>
>> Thanks! While we're at it, are there any plans to add cluster-related
>> operations? For example, I think it'd be nice to allow the thin clients to
>> obtain a current topology snapshot. This would make it possible the clients
>> to send requests directly to the affinity host for colocated computation.
>> To make it even more useful, all server responses could optionally include
>> the topology version the operation has been executed against. This would
>> effectively give us a kind out-of-band topology change 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 <ptupit...@apache.org>
>> 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 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 solid and
>> future-proof.
>>
>> Thanks,
>> Pavel
>>
>
>
