On Wed, Jul 30, 2014 at 12:25 PM, Evgeniy Ostapenko <[email protected]>
wrote:
>
>
> среда, 30 июля 2014 г., 13:46:49 UTC+4 пользователь drewhk написал:
>
>>
>>
>>
>>>
>>> Absolutely yes! But more exactly the behavior of recovery depends on
>>> stream type.
>>>
>>> 1) When you reading from file then you have byte stream which must be
>>> ordered and kill himself after exception.
>>> 2) When you have stream from which you want collect elements to finite
>>> Set then stream can be unordered, but must kill himself after exception.
>>>
>> 3) When you have stream of any linear changing state ( progress bar for
>>> example) - stream must be ordered, but after exception you not must
>>> killing him.
>>>
>>
>> Killing what? If the progressbar is a Producer, and you have a map stage
>> after it which throws an exception, the map will simply cancel its
>> subscription to the Producer, it will not kill it -- it only propagates
>> error downwards.
>>
>
> Yes, you lose your handler anyway. For example if exception will be
> throwed when progressbar will be on 50% then you ever do not knows when it
> achieve 60%.
>
In those cases you need to resubscribe your handler -- that is possible. I
still prefer the Try approach though, it makes it much more clearer, even
if adds boilerplate.
What might makes sense though is to provide additional, optional settings
to the materializer that controls how to deal with errors in
transformations -- similar to a SupervisorStrategy. I am not sure that it
is possible to meaningfully implement it for all operations though. For
transformations implemented in terms of Transformer it is very easy, but
not for others.
Anyway, that would need a careful design round, so it will take some time
to come up with something that works well and sufficiently general.
>> To solve that problem you need to choose applicable FlattenStrategy. But
> eventually set stream type is more natively and reliable.
>
Yes, streams are not globally ordered since it is impossible to reestablish
global ordering without domain knowledge (i.e. Akka cannot figure out what
the user code does and how different streams relate -- for example two TCP
connections carrying video frame data, one carries overlay that should be
appended at certain timepoints, etc.). We will provide more tools to handle
that, but we cannot bake it into the low-level model.
>
> Ok, if is finite stream and it not produce any element at all, what would
> toFuture produce? Of course nothing. Future has no timeout. No any problems
> in that case.
>
The problem is streams that provide exactly one element, one example is
fold.
>
>>
>>> mapConcat is method which meaningless for infinite streams - that
>>> supports my opinion that akka-streams is finite streams oriented.
>>>
>>> Or should we just drop elements silently without any error marker?
>>>>
>>> Yes
>>>
>>
>>
>> But wait, previously you wanted filter to emit a marker when elements are
>> dropped so you do not get out of synch with zip. I am confused now.
>>
>
> Sorry about post with emitting marker, it was fast attempt to solve my
> problem, forgot that please.
>
Ok, that clarifies this. I recommend currently to implement a wrapper on
top of Flow/Duct that wraps all user defined transformation functions in a
Try and so you can call things like:
safeFlow.safeMap(2 / _)
which translates the division to a map on the underlying try and therefore
emits a Failure on division by zeros (for example).
As for more general recovery mechanisms, they have to wait for now.
-Endre
>
>> --
> >>>>>>>>>> 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.
>
--
>>>>>>>>>> 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.
