On Wed, Apr 29, 2015 at 6:52 AM, Atri Sharma <[email protected]> wrote:
> For 1), can we have any issues of state on different nodes i.e. > communicating effectively to all nodes that a query is canceled with > immediate effect? > Atri, we already do that. The problem is reverse: if the client node got crashed and the autoUnsubscribe property is not set, then it is impossible to cancel the CQ from another node because it is impossible to get a handle on it from another node. > On Wed, Apr 29, 2015 at 1:53 PM, Yakov Zhdanov <[email protected]> > wrote: > > > Andrey, > > > > Your points seem very reasonable to me. > > > > 1. Agree that we should have an ability to cancel query from any node at > > any point. It will help if original node leaves and auto unsubscribe is > > "false". > > 2. It is better to use same listener for initial notification. I will > think > > on how to refactor this. > > 3. As far as distinguishing initial iteration we can add some attribute > to > > entry implementation used in query. > > > > We also had several recent requests to enhance continuous query > > functionality. Give me a couple of days to review code and think > everything > > over and I will file tickets to address CQ issues we have now. > > > > Thanks for pointing that out! > > > > --Yakov > > > > 2015-04-28 23:52 GMT+03:00 Kornev, Andrey <[email protected]>: > > > > > Hello, > > > > > > There are a couple of things wrt Ignite's CQ API and implementation I'd > > > like to bring the community's attention to. > > > > > > First, a CQ instance is a long living resource. Once started it > continues > > > to run until explicitly stopped by closing its cursor. If the query > > master > > > node (the one holding the instance of the QueryCursor) crashes and the > > Auto > > > Unsubscribe is off, then it doesn't seem there is any way to stop the > CQ > > > save for a complete restart of the grid. Making it possible to obtain > the > > > instance of the CQ from any grid node, might improve things. > > > > > > Second, the purpose of the initial query and its usage in the current > API > > > is not clear. It makes one wonder what was the original use case the > API > > > was designed to address? > > > > > > A couple of things: > > > > > > 1) the implementation doesn't provide a consistent point-in-time > snapshot > > > of the cache (no isolation). The cursor may deliver a more recent > version > > > of an entry if it got updated by a concurrent transaction. The same > entry > > > will also be delivered to the listener as an update event. Please > correct > > > me if I'm wrong. > > > 2) the delivery of the initial query results is in no way synchronized > > > with the delivery of the events to the listener. > > > > > > This makes the API prone to race conditions and its correct usage > > > impossible. By "correct usage" I mean the ability to capture point in > > time > > > state of the cache followed by the correctly ordered change data events > > > including the ones that occurred while the initial snapshot was being > > > processed. In database systems it is also known as "materialized view > > > maintenance". > > > > > > It'd be more practical to deliver the initial state to the listener > > > instance rather than to the cursor executing in a different thread. > It'd > > > also be necessary to punctuate the end of the initial state delivery > and > > > the beginning of the change data events, so that the listener could > > switch > > > from building its initial state to applying incremental updates. > > > > > > I'm curious if any of the above makes any sense? > > > > > > Thanks > > > Andrey > > > "Misys" is the trade name of the Misys group of companies. This email > and > > > any attachments have been scanned for known viruses using multiple > > > scanners. This email message is intended for the named recipient only. > It > > > may be privileged and/or confidential. If you are not the named > recipient > > > of this email please notify us immediately and do not copy it or use it > > for > > > any purpose, nor disclose its contents to any other person. This email > > does > > > not constitute the commencement of legal relations between you and > Misys. > > > Please refer to the executed contract between you and the relevant > member > > > of the Misys group for the identity of the contracting party with which > > you > > > are dealing. > > > > > > > > > -- > Regards, > > Atri > *l'apprenant* >
