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 Tue, 05 Dec 2017 01:39:20 GMT
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>(ClientCacheCreateWithNameRequest.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 <andrewkornev@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 <ptupitsyn@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
>

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