Re: [akka-user] Do I always need to stop an ActorProducer after calling onComplete/onError?

Hi Giovanni, the Actor must indeed stop itself, and that applies also to the Cancel event. Concerning the ActorPublisher/ActorSubscriber we are not yet finished with the API, it is likely that we will make changes here precisely because the lifecycle management is too complex at the moment, see

Re: [akka-user] Error in Eclipse

Thanks for pointing this out, we’ll have to fix this then. I have created a ticket for this, if you want to try your hand on a PR you are very welcome! Regards, Roland > 1 mar 2015 kl. 03:37 skrev Steve Ramage : > > I did some more digging and it se

Re: [akka-user] Error in Eclipse

I did some more digging and it seems like the behaviour that Akka is relying on is a bug, that is fixed in the next version of Java: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8034044 On Saturday, 28 February 2015 17:55:42 UTC-8, Steve Ramage wrote: > > I just ran across this issue toda

[akka-user] Do I always need to stop an ActorProducer after calling onComplete/onError?

Hi, I noticed that the a materialized ActorProducer does not get stopped when the flow is complete, thus leaking memory. Do I always need to call context.stop(self) after onComplete()/onError()? If that's the case, when/why should I not call it? Why should I want to keep an ActorProducer/Subsc

Re: [akka-user] Error in Eclipse

I just ran across this issue today, although I'm not sure if the problem is Eclipse or Akka. I noticed that at least as javap will show, the classes are not marked as static either by javac or Eclipse. As far as my reading of the JLS (say for instance 15.9.5 in JLS 7) goes it suggests that anon

[akka-user] Re: ANNOUNCE: Akka Streams & HTTP 1.0 MILESTONE 4

another bug: onPull is not called after absorbTermination(). I openened an issue. Do you have the same problem? https://github.com/akka/akka/issues/16966 On Friday, 27 February 2015 19:27:41 UTC, Shawn wrote: > > Does it support HTTPS yet? > -- >> Read the docs: http://akka.io/docs

[akka-user] Problem with supervision strategy & akka-stream 1.0-M4

Hello! I'm very inspired of Reactive streams idea and akka implementation. But i found some discourage fact in 1.0-M4: Why is the stream supervisor works only for one exception and other exceptions ignores? Example1 with one bad element in the stream: > val decider: Supervision.Decider = excep

Re: [akka-user] akka-http long-lived connection & backpressure problem

Hi Jim, sorry for the late response, we’ve been a bit busy lately. Your analysis is correct in that boundedness applies to all aspects and cannot be magically “lifted”: the number of requests in flight will always be limited by the amount of buffering along the whole round-trip. In that sense t

Re: [akka-user] Flatmap for Flows

FYI: I filed https://github.com/akka/akka/issues/16965 for this, which should enable you to easily route elements to either of a set of flows that you then merge together afterwards. That can then also be used to implement a new (custom) combinator like def conditional[I, O](p: I => Boolean, wh

Re: [akka-user] akka-http client broken by M4, any suggestions what to do to fix?

Thanks didn't find that test, was looking in the wrong place >> Source.single(req).via(conn).runWith(Sink.head()) Also note change of Sink.head to Sink.head() which makes a difference On Friday, February 27, 2015 at 6:43:50 PM UTC, Martynas Mickevičius wrote: > > Hi Tim, > > according to the