On Fri, Oct 31, 2014 at 10:50 AM, Adam Warski <[email protected]> wrote:
> > So even if sink1 fails, the whole setup will continue? So using sink2 (on > complete sink/drain) won't have any effect? Is there a way to detect errors > in such case then? > Sink2 will detect the failure of source, but not of sink1. Currently there is no way to detect it, because most people expect the broadcast to continue instead of failing. We can make it configurable though. You should be aware though that using the stream TCP you *don't* get an error event from the outputStream anyway, you only get notified that it has cancelled (Reactive Streams specify only cancel as an event propagated from downstream to upstream), but not the reason why. See my other answer a bit below before you panic :) > > >> Btw, in your TCP example you don't use the inputStream of the connection, >> if you use that stream it will give you the termination events of the TCP >> connection (normal/error). Output stream can only say "cancelled" but not >> why. >> > > Well this application only sends data, so I don't need the input stream > for anything. > This is not true, you always need to connect something to the input stream, because it is the thing that carries the termination events of the *TCP stream pair* -- i.e. failures in outputs will be also reported on this channel. You don't need to do anything with the input data though, you can just attach an OnComplete Drain/Sink (whatever it is named in that version ;) ), that will discard all data anyway, but will not clog the inbound TCP buffers even if the remote part happens to send things, and you will get the TCP termination events in the callback you provided to OnComplete > > Even supposing broadcast does work, shouldn't there be some other way to > detect and handle failures/errors/completions? E.g. wouldn't it make sense > to add a callback to run()? Or make run() return some kind of Future? > Creating an artificial broadcast just to detect errors seems not optimal :) > There is a common misconception here. Imagine a setup like this: inputFile -> someProcessing -> outputFile Now imagine that we provided an API that gives a completion future after you call run(). Now if that future completes, would that mean that writing to the file finished? Unfortunately no, since the completion of a Reactive Streams means that no elements in flight anymore and everyone is aware of that, but this does not imply that all the buffers of the outputFile writer has been flushed and the file has been closed. This is exactly why Akka Streams provide Sinks (formerly Drains) that can return a completion Future (or whatever they want to return) of their own that is completely library dependent -- for example a file writer Sink can give a Future that represents the event while the file has been completely closed. -Endre > > Adam > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
