AFAIK there is currently no way of dynamically changing the size of the
pool. What you can do is assign a fixed number of 'slots' which get
dynamically turned off/on
You could look
at
Sounds to me like you want a pooled set of streams for processing your
events, with the restriction that events with the same ID must go into the
same stream?
If that's the case, a FlexiRoute with a fixed set of downstreams should do
the job. Then all you need is a way of consistently
juli 2015 kl. 00:27:32 UTC+2 skrev Joe Edwards:
Inlets are naturally Contravariant (an inlet that reads A can be viewed
as an inlet that reads B : A), but that breaks down slightly when you're
viewing it 'from the other side' - as the Outlet of something else. Perhaps
there should be a view
Inlets are naturally Contravariant (an inlet that reads A can be viewed as
an inlet that reads B : A), but that breaks down slightly when you're
viewing it 'from the other side' - as the Outlet of something else. Perhaps
there should be a view of the Inlet which can be used in a merge which is
You've got your demand condition as 'DemandFromAny', when I think it should
be 'DemandFromAll'. I'm not exactly sure why that would explain your exact
behaviour, but it should help.
If you consciously don't want to wait for demand from both, you could e.g.
have 2 states which are randomly
the connection. You could cheat though: use chunked encoding for
the request entity, and send an empty chunk ending the request entity as
soon as you read the server's rejection headers.
On Wednesday, January 28, 2015 at 6:33:47 PM UTC+2, Joe Edwards wrote:
I have an application in which
Have a look at https://github.com/akka/akka/issues/16510 - it's very likely
the same bug.
On Monday, 15 December 2014 18:07:53 UTC, Łukasz Sowa wrote:
Same here. At first sight it looks like a bug. Any clues?
Best,
Łukasz
W dniu niedziela, 14 grudnia 2014 05:06:20 UTC+1 użytkownik Jan
I'm seeing similar behaviour in 1.0-M1, my client looks like this:
class SingleUseConnectionHttpClient()(implicit actorSystem: ActorSystem) {
val http = Http()
implicit val materializer = FlowMaterializer(namePrefix =
Some(SingleUseConnectionHttpClient))
def sendRequest(request:
Thanks, sounds like I must be doing something wrong. This isn't a huge
priority right now, so I'll probably worry about it later.
The situation is that I have an app streaming a (potentially large) request
in from a client and forwards it on to another downstream application.
I made a test
From the original announcement
(http://typesafe.com/blog/typesafe-announces-akka-streams) it sounds as
though the HTTP entity stream should [have the ability to] apply TCP
back-pressure to clients streaming into the server.
After some rudimentary experimentation it doesn't appear to be doing
Spray 1.3.1 provided an 'Unbind' feature, which allowed you to unbind from
the port and (crucially) wait for existing requests to complete. See
https://groups.google.com/forum/#!searchin/spray-user/bradley/spray-user/Sfh8x5yWibU/JAqWyOKnaj0J
Is there an equivalent feature in akka-http? (I am
11 matches
Mail list logo
