On Fri, Oct 31, 2014 at 12:12 PM, 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. >> > > 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? :) > That doc is outdated, it is a copy-paste from the old API it seems where you had to have exactly two outputs. > > >> 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? > It can't be reported on the output stream because the RS spec does not give any possiblities to signal the nature of termination from a Subscriber. We report it on the other stream though (the input stream). > > >> 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. > Yes, in this case it is not needed, but in general you shouldn't be afraid to fork off from streams, they are meant to be combined in a graph-like way, avoiding out-of-stream communication (futures, etc) as much as possible. > > > So each sink should provide a sink-dependent way of letting the user know > when things are "done" or "cancelled". > Yes, if it makes sense. They might even provide a Cancellable, other streams, or whatever they feel they need. > 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? > The input stream conveys all the information you need about closing events, I don't see the need currently for a side-channel. We prefer to keep as much as possible in-stream and not out-of-stream. Since TCP is a stream in itself it works quite well, unlike with the file example I had where there is a pure sink. That said, we might add more functionality if needed but the design goal is to keep these external signals minimal. -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.
