> > 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. >
Right, I can imagine needing both. Similar to a one-for-one and one-for-all failover strategy when using actor supervisor hierarchies. Btw. the javadoc for Broadcast currently says: " It will not shutdown until the subscriptions for at least two downstream subscribers have been established.". Why two? Shouldn't it be either one or all? :) > 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 :) > Would it make sense to add something to the current API which could detect such failures? > 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 > Ok, that's in fact much nicer, I didn't like the approach of broadcasting just to detect errors :). I'll try that in the evening. > 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. > So each sink should provide a sink-dependent way of letting the user know when things are "done" or "cancelled". Doesn't it mean that there should be a way to provide a callback or sth like that when creating the specific Subscriber, here it's implemented by the TCP extension? E.g. a Future or similar as part of the binding: StreamTcp.OutgoingTcpConnection? 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
