ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Deadlock during Client Continuous Query deserialization
Date Mon, 01 Aug 2016 09:46:13 GMT

Deserialization may be heavy. When you deserialize object Ignite implicitly
goes to some internal caches to get metadata of the type. This explains why
your example works when you skip deserialization.

I am not sure whether 2000 is a lot or not. For me even 1 cont query
bringing all the updates from 100-nodes partitioned cache is quite a lot :)
and most probably will kill the cluster.


2016-08-01 11:34 GMT+03:00 ross.anderson <ross.anderson@caplin.com>:

> 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.

View raw message