Hello Val! No, this does NOT happen. If you collect future, call get() on it later, it will finish normally despite exceptions in server log and entry not being written. I will do some digging to figure out why this happens exactly.
There's also another huge problems with DataStreamer's futures. They never finish unless you call flush() on DS before calling get() on futures. I think this is a colossal usability problem (I'm pretty sure I've seen numerous messages about it on userlist) and I'll fill an issue if nobody is objecting. Ilya. -- Ilya Kasnacheev 2018-03-05 22:50 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > 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? > > > > > >
