Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
From: Andrey Kornev <andrewkornev@hotmail.com>
To: Pavel Tupitsyn <ptupitsyn@gridgain.com>, "dev@ignite.apache.org"
	<dev@ignite.apache.org>
Subject: Re: Thin Client Protocol documentation
Thread-Topic: Thin Client Protocol documentation
Thread-Index: AQHTY5JrNWf7hyO5MkGsF/eJfgcwTqMsrGcAgAAClQCAAarUgIAANTEAgAH9x2CAAWLVgIABzMeFgABQNACAAGyPgIAAubv1gADKDQCAAKuB1A==
Date: Wed, 6 Dec 2017 17:53:34 +0000
Message-ID: <CY4PR2201MB1543F1CFA56BC92ABAB21B01CF320@CY4PR2201MB1543.namprd22.prod.outlook.com>
References: <CAK2_iMOi3=RVszTTeS_=-VG1tpvwB7pozD1AGOSrtrqD+-kybg@mail.gmail.com>
 <5a1fc8da.10372e0a.dfa50.4edb@mx.google.com>
 <CAK2_iMOWztTM3=rKoL0RZSGWUBc-ugogFw+weU_8A528_+LJbg@mail.gmail.com>
 <5a213111.94a7190a.ba8a3.75d9@mx.google.com>
 <CAK2_iMMdyCp8o29y4HC7ZNTG0jo6s203tcM1GQOg2nHEZsYipA@mail.gmail.com>
 <MWHPR2201MB155129ED049EE2B0AE062326CF3E0@MWHPR2201MB1551.namprd22.prod.outlook.com>
 <CAK2_iMM+GoOb=iv7+2QoRiioXghiw9JfKK-FEsbV3OFnpWHrTQ@mail.gmail.com>
 <MWHPR2201MB1551C8BF94B46AC1080FB115CF3C0@MWHPR2201MB1551.namprd22.prod.outlook.com>
 <CAABS=BP-i0cCkAz6WFq3eVWdFuTLueMnnZC_XoXnorY-ihR15g@mail.gmail.com>
 <CAK2_iMOM=HSTHjjerLPs9RWsHdGeeu8NPLZeL39NvWC2+GvqJA@mail.gmail.com>
 <MWHPR2201MB1551460E112F2BDEB7DBF2A6CF3D0@MWHPR2201MB1551.namprd22.prod.outlook.com>,<CAK2_iMOXwy9iVhex45hkqG+kD2xyKW2m8RHWxO9LO_7yttc5DA@mail.gmail.com>
In-Reply-To: <CAK2_iMOXwy9iVhex45hkqG+kD2xyKW2m8RHWxO9LO_7yttc5DA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [fTpOEGN/Ito8RvPmjD/lfABwUvNI6lb5]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;SN1NAM01HT140;6:5CljVbC3vaDRh3IiGkYBL3UAas71OlGsp+WK502aeDWFCD5AY4oTcsgD3SMslFihXcyLlSGeUFXVpAXtjr7MQEaFyngti4RdCRWWIR13dx92GUXYXto6pPbsVPBFbtiBh+OU1sYB9tqeOm6XnZFyJkrpqbJsEqGmyrKT4SU2rV0JN5y5d/b8juzLLjHWb5UmM9DOHRIrBeU1B4LRUD2Y994jFlDYerOsvRwV1zKyx8vrK/FQrC8bFOtCyIxEXcxBYCDIalgAD2M/efCbzu1cbL4VMNp1bsotzruluT7pGOAWQeceWM9ynj93olE+a56zO3zBGkJszycEh9Rq5344JENsCVtKvqPpaGpVQtAB2sY=;5:8QjsOV015jXoWkcBCLtS0bhBOeFC4tUIa19xCDnX3XzUu4vIGQd3AlJgxxDEaYpF4sMrprgnu27U0CSyipDmzBAhVkK9sUBB0vrhqpup8rypg4KqNg5RY2yOEOkDfJ9BYxEm1Cry+/trOiDIT1z3FuhEhfaqkgD9UzIQ5G0E5mI=;24:f1rhhxr2iWBkXNsmacQun50/3wXKEOdRX2lcMIcSRyqRKqiNhf5bMz67FbQUDWx5LVVUO9Vskg7ySI/RoX0nmRzxknHWJ1l3ei+kbwtJR6k=;7:GtpesEI2FkamzJRZ7VLvW+VQk3ld8gCAotz4/0/CtlqI9bZ6zWHeaNGhWqUcgT7mmPrRII22E/InN+UrjVpjhOAm5kgumuXFrdxxCtQ0xh03uVfng7uIx9ox5u5gsSorcC4B8atjISjmsrB2Zb1MZCqIvqx6UbEjlU7u1b6xWPe+Je41Ywd17UIdpSqmuZPRIjroMLbZIO6Olu89jPyKgbnXATrGezwItZmoNC4TpT7bWlFy6UM/5ShWELtLeXNa
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);SRVR:SN1NAM01HT140;
x-ms-traffictypediagnostic: SN1NAM01HT140:
x-ms-office365-filtering-correlation-id: 315e6489-b47e-42ea-1122-08d53cd2454e
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:SN1NAM01HT140;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:SN1NAM01HT140;
x-forefront-prvs: 05134F8B4F
x-forefront-antispam-report: SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:SN1NAM01HT140;H:CY4PR2201MB1543.namprd22.prod.outlook.com;FPR:;SPF:None;LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_CY4PR2201MB1543F1CFA56BC92ABAB21B01CF320CY4PR2201MB1543_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 315e6489-b47e-42ea-1122-08d53cd2454e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 17:53:34.4929
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT140
archived-at: Wed, 06 Dec 2017 17:53:49 -0000

--_000_CY4PR2201MB1543F1CFA56BC92ABAB21B01CF320CY4PR2201MB1543_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>>> I don't think it makes sense to do that. Another problem is that it wil=
l take weeks :)

I'm sorry, Pavel. None of what you've said so far makes it obvious why it d=
oesn't make sense to produce the complete spec. Would you care to elaborate=
, please?

Also, what's the problem with the "another problem" of the effort taking we=
eks? If based on your best estimate the effort requires a few weeks of your=
 time, why is this a problem then?

>>> But, of course, you are welcome to take the initiative.

Saying something like that is not very helpful, Pavel. But let me just say,=
 I believe that as the current spec lead and an employee of the company beh=
ind Apache Ignite project you're in a much better position to continue to l=
ead the effort (you've been doing great so far!). From my side, I'd be more=
 than happy to review the spec and provide my feedback. Also, I'm very inte=
rested in becoming a contributor/early adopter of the Java-based implementa=
tion of the protocol.

Regards
Andrey

________________________________
From: Pavel Tupitsyn <ptupitsyn@gridgain.com>
Sent: Tuesday, December 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, events, failover, data structures, metrics.

I don't think it makes sense to do that. Another problem is that it will
take weeks :)
But, of course, you are welcome to take the initiative.

Thanks,
Pavel

On Tue, Dec 5, 2017 at 10:20 PM, Andrey Kornev <andrewkornev@hotmail.com>
wrote:

> 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 t=
he
> public.
>
> Thanks
> Andrey
> ------------------------------
> *From:* Pavel Tupitsyn <ptupitsyn@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 <pgarg@gridgain.com> wrote:
>
> > Hi Pavel,
> >
> > I am trying to use the OP_CACHE_CREATE_WITH_NAME operation, but can't g=
et
> > 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 co=
de
> > and the actual string. Is that correct?
> >
> > Here is the request I am sending to the server-
> >
> > DataOutputStream out =3D new DataOutputStream(socket.getOutputStream())=
;
> >
> > // Message length
> > writeIntLittleEndian(24, out);
> >
> > // Op code =3D OP_CACHE_CREATE_WITH_NAME
> > writeShortLittleEndian(1051, out);
> >
> > // Request id
> > long reqId =3D 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 <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 client=
s
> 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 wou=
ld
> >> effectively give us a kind out-of-band topology change notification
> >> mechanism. This way the clients can detect a topology change and refre=
sh
> >> 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
> >>
> >
> >
>

--_000_CY4PR2201MB1543F1CFA56BC92ABAB21B01CF320CY4PR2201MB1543_--