Ilya, IgniteDataStreamer#addData method returns future which should be completed with error if one is thrown on server side. Does this happen or not?
-Val On Mon, Mar 5, 2018 at 4:10 AM, Nikolay Izhikov <nizhi...@apache.org> wrote: > Hello, Ilya. > > > I think it's time to end this, if that was the case. DataStreamer should > > not be a special case and it should guarantee data safety. WDYT? > > +1 from me. > > I'm also facing this issue. > > Ticket - https://issues.apache.org/jira/browse/IGNITE-7756 > Discussion - http://apache-ignite-developers.2346864.n4.nabble. > com/IgniteDataStreamer-silently-fails-on-a-server-node-td27239.html > > > > В Пн, 05/03/2018 в 14:46 +0300, Ilya Kasnacheev пишет: > > Dear Igniters, why do I have a hunch that DataStreamer would readily > > swallow exceptions? > > > > DataStreamerImpl:1756 swallows marshalling error, lines 1774 & 1781 eat > > deployment errors. > > > > Some people are worried they can fill a leaking vessel without noticing > > anything off. > > Also in line 2156 fsync() on WAL can throw exceptions, which will be > > swallowed, and IMP this fsync doesn't belong to DataStreamer code. > > > > This question is not purely theoretical, we have also replaced one of > these > > eaters with throw with IGNITE-7519. > > > > There was a fault in PDS implementation, which did not propagate to > client. > > A serious issue IMHO. > > > > As a data streamer user I will expect that flush()/close() will throw any > > pending exceptions and will only be silent if all data landed safely in > the > > cluster. > > > > I also have this feeling that DataStreamer was written using very > internal > > APIs so that it can compromise guarantees that cache and SQL APIs are > bound > > by. I think I've heard something about not recovering properly in case of > > node failures. > > I think it's time to end this, if that was the case. DataStreamer should > > not be a special case and it should guarantee data safety. WDYT? > > >
