Hi, it was my fault, I finally understand the concept behind it, I can see
what is running concurrently/sequentially now. Thank you
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>
>
> Yes, of course these sub-streams are running concurrently! If you don’t
> want that, then why convert them to streams in the first place?
>
To be honest I have real troubles to tell when stuff is running
concurrently and when it is synchronized. For instance in this stream, do I
have to wo
> 18 feb 2015 kl. 15:18 skrev Jakub Liska :
>
> I'l try to reproduce later, but I'm quite sure of it because if I do
>
> val iterable = list.toStream.map( this.synchronize(non-thread-safe-operation)
> )
>
> or
>
> source.map ( this.synchronize(...) )
>
> All concurrent access problems are
I'l try to reproduce later, but I'm quite sure of it because if I do
val iterable = list.toStream.map(
this.synchronize(non-thread-safe-operation) )
or
source.map ( this.synchronize(...) )
All concurrent access problems are suddenly gone... Which seems to be an
ultimate prove...
Btw is it
Hi Jakub,
processing of stream elements is completely sequential in Akka Streams, can you
show the complete setup (a.k.a. a “minimal reproduction”)?
Regards,
Roland
> 18 feb 2015 kl. 14:35 skrev Jakub Liska :
>
> Hey,
>
> I'd need to do something like :
>
> val iterable = list.toStream.map(
Hey,
I'd need to do something like :
val iterable = list.toStream.map( non-thread-safe-operation )
val source = Source(iterable) // Source(() => iterable.iterator)
source.map (...)
but the problem is that there is a concurrent access to the iterator next
method and it breaks non-thread-safe thi
