Hi Yakov, You can see in the example I have provided that the only thing we try to do in the listener is to print the event to the console log. In our other code I attempted to pass the event off to another thread in order to get off the notification thread and see if that unblocked it, but this was to no avail as well. In either case we are trying to keep processing to the minimum.
To be honest I am slightly surprised that 2000 queries is considered a lot. The example I provided is slightly contrived in that there is no initial query, and a null remote filter - the simplest case I could provide which demonstrated the issue - in our real case we are using unique initial queries and filters per listener. I can certainly perform my own local propagation of the updates, but this means I need to be performing my own initial queries, and merging the query results with the updates myself and it seems as though I am just re-writing what continuous queries seem like they are supposed to offer? Cheers, Ross -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Deadlock-during-Client-Continuous-Query-deserialization-tp6565p6650.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
