Mailing-List: contact user-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <1470040454494-6650.post@n6.nabble.com>
References: <1469627610472-6565.post@n6.nabble.com> <1469787347729-6616.post@n6.nabble.com>
 <CAFx+i-YmJRRgew+09yjVS-73D2VkSme8ciU-0sfFS_SnNOjTyQ@mail.gmail.com>
 <1469803894105-6620.post@n6.nabble.com> <CABDss3gJDYOuJr8r1=802k+CMxkQy3erb_L0nOcOVNxwm2QkHw@mail.gmail.com>
 <1469806833990-6622.post@n6.nabble.com> <CAGcMBHjBCfM3iS9ndOXbP-TqV-BP0HnzypPV2LNRLHtEzkom4w@mail.gmail.com>
 <1470040454494-6650.post@n6.nabble.com>
From: Yakov Zhdanov <yzhdanov@apache.org>
Date: Mon, 1 Aug 2016 12:46:13 +0300
Message-ID: <CAGcMBHjuyOWyAseb=dXobq1VNaR6sEkMm3kRPTVR9Hpwn-SPDQ@mail.gmail.com>
Subject: Re: Deadlock during Client Continuous Query deserialization
To: user@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a1140b43a9631490538ff78fe
archived-at: Mon, 01 Aug 2016 09:46:17 -0000

--001a1140b43a9631490538ff78fe
Content-Type: text/plain; charset=UTF-8

Ross,

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.

--Yakov

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

--001a1140b43a9631490538ff78fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ross,<div><br></div><div>Deserialization may be heavy. Whe=
n you deserialize object Ignite implicitly goes to some internal caches to =
get metadata of the type. This explains why your example works when you ski=
p deserialization.</div><div><br></div><div>I am not sure whether 2000 is a=
 lot or not. For me even 1 cont query bringing all the updates from 100-nod=
es partitioned cache is quite a lot :) and most probably will kill the clus=
ter.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">-=
-Yakov</div></div></div>
<br><div class=3D"gmail_quote">2016-08-01 11:34 GMT+03:00 ross.anderson <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:ross.anderson@caplin.com" target=3D"_b=
lank">ross.anderson@caplin.com</a>&gt;</span>:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Hi Yakov,<br>
You can see in the example I have provided that the only thing we try to do=
<br>
in the listener is to print the event to the console log. In our other code=
<br>
I attempted to pass the event off to another thread in order to get off the=
<br>
notification thread and see if that unblocked it, but this was to no avail<=
br>
as well. In either case we are trying to keep processing to the minimum.<br=
>
<br>
To be honest I am slightly surprised that 2000 queries is considered a lot.=
<br>
The example I provided is slightly contrived in that there is no initial<br=
>
query, and a null remote filter - the simplest case I could provide which<b=
r>
demonstrated the issue - in our real case we are using unique initial<br>
queries and filters per listener.<br>
I can certainly perform my own local propagation of the updates, but this<b=
r>
means I need to be performing my own initial queries, and merging the query=
<br>
results with the updates myself and it seems as though I am just re-writing=
<br>
what continuous queries seem like they are supposed to offer?<br>
<br>
Cheers,<br>
Ross<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href=3D"http://apache-ignite-users.70518.x=
6.nabble.com/Deadlock-during-Client-Continuous-Query-deserialization-tp6565=
p6650.html" rel=3D"noreferrer" target=3D"_blank">http://apache-ignite-users=
.70518.x6.nabble.com/Deadlock-during-Client-Continuous-Query-deserializatio=
n-tp6565p6650.html</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">Sent from the Apache Ignite Users m=
ailing list archive at Nabble.com.<br>
</div></div></blockquote></div><br></div>

--001a1140b43a9631490538ff78fe--