Thanks Johannes for your feedback,
For pt. 2 I am handling errors using Supervision.Resume so the stream
should technically continue and not complete with an error, correct?
1. It is unclear what your graph looks like and how you are materializing
the value, also which supervision strategy you are employing (default is
Supervision.Stop) so your stream will complete with an exception which
means a failed Try with exception from event 2 (basically the first
exception that causes the stream to fail).
2. I think you are alluding to recovery strategies here, I would suggest
reading documentation on Supervision strategies to handle errors and
potentially recover from them. Also, you can use recover / recoverWith ops
to handle any errors and gracefully complete the stream (these can be
applied to individual stream stages).
On Sunday, September 25, 2016 at 11:44:40 PM UTC-7, Dagny T wrote:
> Hi Kunal and Johannes,
> THANKS for your posts on this -- as I was also wondering how
> exception-handling mid-Flow is supposed to work!
> Followup questions for you, please:
> - Let's say for simplicity that we have only 3 events flowing through a
> Streaming Flow with 5 Stages.
> - We put a Try block around the myGraph.run() materialization
> - Then, say an exception happens on Stage 3, and Event 2.
> 1) Does this mean that the resulting Try collection will contain:
> - Success w Result from Event 1, all Stages
> - Failure w Exception from Event 2, Stage 3
> - NOTHING for Event 3; as Materialized Graph would have just stopped on an
> 2) Does this then imply that Source has to somehow know Events 2,3 got
> dropped via the UUID of Event- last processed;
> then it has to re-stream those to the Sink?
> Please let me know if I'm understanding those two points correctly!
> On Wednesday, September 14, 2016 at 10:49:18 PM UTC-7, Kunal Deshpande
>> I have been using Akka streams to implement a saved-search refresh system
>> as well as a notification processing system at my current company.
>> Recently we ran into a fast-publisher & slow subscriber problem where the
>> downstream HTTP services were taking a long time to respond resulting in
>> Timeout exceptions in our client. Currently we simply drop the event and
>> resume the stream using Supervision.Resume but I am unsure whether that
>> translates into back pressure.
>> Few questions on back pressure
>> 1. While using Flows in akka-streams using .via will a downstream flow
>> apply back pressure to a flow upstream or is back pressure only signaled to
>> a Source?
>> 2. Will exceptions in a Flow trigger back pressure
>> 3. Is there a mathematical way to represent back pressure and is it
>> consistent across different reactive streams implementations?
>> Thanks, and really appreciate your time!
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> 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 post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.