> I set
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl#DFLT_MAX_REMAP_CNT
> to zero and see test fails now.
Anton, thank you very much!
I've prepared PR [1] to fix issue [2]. TC looks OK.
Looks like it was introduced by commit 53802d8b46f8ee09d51ba84267f65dc6f7e73a2f
[
Nikolay,
I checked your reproducer and it looks like retry helps data streamer to
solve this.
I
set
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl#DFLT_MAX_REMAP_CNT
to zero and see test fails now.
Looks like second attempt is successful for such case.
On Wed, Feb 21, 2018
On Wed, Feb 21, 2018 at 12:10 AM, Nikolay Izhikov
wrote:
> Hello, Igniters.
>
> > Does this exception happen because IgniteUuid class is not correctly
> > handled?
>
> Yes. I've fixed it.
> But story doesn't end :)
>
> > As far as propagating exceptions, addData(...) is asynchronous operation
> >
Hello, Igniters.
> Does this exception happen because IgniteUuid class is not correctly
> handled?
Yes. I've fixed it.
But story doesn't end :)
> As far as propagating exceptions, addData(...) is asynchronous operation
> and returns IgniteFuture.
Thank you, my bad.
But, I can't understand wh
Nikolay,
Does this exception happen because IgniteUuid class is not correctly
handled? If that's the case, we should fix it. Would be great if you could
do it.
As far as propagating exceptions, addData(...) is asynchronous operation
and returns IgniteFuture. The exception should be propagated to
Hello, Igniters.
While working on IGNITE-7727 I found strange behavior of IgniteDataStreamer:
If we have IgniteUuid as an indexed type update silently brokes on a server
node.
Client doesn't have any notification about fails.
All calls of `addData`, `close`, etc. succeed on a client side but fai
