>
> 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.
> 4) And also you can have stream of state ( ping latency for example) -
> unordered and exception do not kills him.
>
> Only two (stream property/flow modifiers):
> 1) ordered / unordered
> 2) drop after exceptions / not
>
> Without this properties you need to write MergeStrategy, FlattenStrategy
> etc. Strategy depends on stream type, you not need to apply them each time
> when you write .merge or .zip or .flatten.
>
> Today akka-streams has native support only (unordered + drop after
> exception)
>
What do you mean by unordered? They are definitely ordered.
>
>
>> What would a filter emit in case of a failure? Will it drop an element?
>> Will it emit an error marker? Also, what would filter do, if it encounters
>> an error marker? Will it drop that? Will it emit it downstream?
>>
>
> Drop an element of course - emit an marker it is same as wrap message in
> Try - after that you got a lot of boilerplate code.
>
>
>>
>> And above is just one of the simpler scenarios. What would groupBy do?
>> Which group does an error marker belong to? If it encounters an error,
>> where should it emit that? On the master stream (the stream of groups)?
>> All of the groups? One of the groups, then which one? Or should it open an
>> error group?
>>
> What would splitWhen do? Or toFuture, especially if the stream emits only
>> one element which fails? What would mapConcat do if it gets an error
>> marker? What would buffer do if it is full? Drop error markers?
>>
>> Stream can not emit only one element if it infinite.
>
Streams can be finite or infinite.
> 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.
>
>
>
>
>
>
>> All of the questions above have more than one possible answer, and all of
>> them belong to a valid use-case. Yours is one, but not the only one.
>>
>>
>>>
>>> 2) In case of finite stream you can get result value and operate with
>>>>> it. In case of infinite you cant doing anything with data without custom
>>>>> decorator.
>>>>>
>>>>
>>>> Could you elaborate?
>>>>
>>> Without decorator you can not take last element of infinite stream for
>>> example. With decorator it would be like:
>>>
>>> class FlowDecorator[T](flow: Flow[T], initial: Option[T] =
>>> None)(implicit materializer: FlowMaterializer) extends Flow[T] with
>>> Builder[T] {
>>> private val last = new AtomicReference(initial)
>>> private val producer = flow.map { e => last.set(e); e
>>> }.toProducer(materializer)
>>>
>>> def apply() = last.get()
>>>
>>> override def toFuture(..) = last.get().map(Future.
>>> successful).getOrElse(Flow(producer).toFuture(materializer))
>>>
>>> override def map[U](f: T => U) = FlowDecorator(Flow(producer).map(f),
>>> last.get().map(f))
>>> ... a lot of boilerplate for all transformers
>>> }
>>>
>>
>> Why would you extend Flow? You can just build an implicit wrapper that
>> calls into the appropriate Flow methods. The above code touches internals
>> and it might break if we change things.
>>
>
> I write that "on fly" and not in idea - for example only.
>
> --
> >>>>>>>>>> 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.
