M G, Could you please, give a link to FIX protocol description? I would like to read about it to be on same page with you.
Thanks! On Wed, Nov 4, 2015 at 4:17 PM, M G <endian...@gmail.com> wrote: > How about a sequence number pattern like in the FIX protocol? So the > restarted node carries on from where it left off. To make that work you > would also need a client id (equivalent to a CompId in FIX) to make each > request unique. > On 4 Nov 2015 09:13, "Alexey Kuznetsov" <akuznet...@gridgain.com> wrote: > > > Igniters, > > > > I found that we have following problems with HTTP-REST sql query API. > > > > After user execute sql query he will receive queryId to be able to fetch > > next page. > > See docs: https://apacheignite.readme.io/docs/rest-api#sql-query-execute > > > > And current implementation of queryId is a long that simply incremented. > > > > First problem: > > 1. client1 execute query and get queryId = 1. > > 2. node where query was executed is restarted (queryId generator > > initialized to zero). > > 3. client2 execute some query and also get queryId=1. > > 4. client1 fetch next page for queryId=1 and GETS results of > client2!!!! > > > > Second problem: > > As queryId is generated sequentially it is very easy to brute force and > > some client could get data of other clients too easy. > > > > What we could do: > > 1) Add nodeId to execute sql query response and fetch next page should > > pass queryId + nodeId to get next page. > > 2) Generate queryId as random long. > > > > OR > > > > Generate queryId as random UUID in this case it will be globally random, > no > > need for nodeId. > > > > But I'm afraid this will break backward compatibility. > > > > Thoughts? > > > > -- > > Alexey Kuznetsov > > GridGain Systems > > www.gridgain.com > > > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
