Re: [akka-user] Re: Akka HTTP performance for short lived connections
Small update - disabling auto fuse, or pre-fusing (with & without auto
fusing) has an effect (BTW I could not find a way to do this with the java).
Performance is improved by up to 50%.
However, it's still not in the same order of magnitude as other libraries.
It's still at least 1 second for the fastest requests.
On Tuesday, April 19, 2016 at 12:25:24 AM UTC+3, Adam wrote:
>
> Yeah, no code is rather silly really...
>
> I've created this repository:
>
> https://github.com/adamhonen/Akka-Http-performance-test
>
> I didn't get a chance to try the suggestions above yet, though.
>
>
> On Monday, April 18, 2016 at 10:25:00 PM UTC+3, Konrad Malawski wrote:
>>
>> I see some results, but no code that is being benchmarked – please always
>> post benchmarked code together with benchmark, otherwise it's hard to tell
>> what's actually going on.
>>
>> On Mon, Apr 18, 2016 at 9:19 PM, Johan Andrén
>> wrote:
>>
>>> Yet another thing to test could be to pre-fuse your Request => Response
>>> flow, first, and then run that with autoFusing turned on or off. Locally I
>>> get the best improvement with pre-fusing and no autoFusing. Looks like this:
>>>
>>> implicit val materializer =
>>> ActorMaterializer(ActorMaterializerSettings(system))
>>>
>>> val routes =
>>> path("benchmark") {
>>> get {
>>> complete("ok")
>>> }
>>> }
>>>
>>> val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes
>>>
>>> val prefused = Fusing.aggressive(flow)
>>>
>>> Http().bindAndHandle(
>>> handler = Flow.fromGraph(prefused),
>>> interface = "localhost",
>>> port = 9000)
>>>
>>> --
>>> John Andrén
>>> Akka Team, Lightbend Inc.
>>>
>>>
>>> On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
One thing that could be interesting to try out if you want to achieve
as high throughput as possible where each new request is a new connection
with the current akka-http version is to disable autoFusing (which is
pretty costly). That can be done when you create the materializer like
this:
ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
This will of course come at the cost where persistent connections get a
performance hit instead.
--
John Andrén
Akka Team, Lightbend Inc.
On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>
> Adam, thanks!
>
> Very informative. I also have found handy to use almost empty response
> to estimate the whole request-response chain itself (starting from now
> abandoned tiscaf [1] and rising rps up to almost 90K on humble
> workstation
> :) ).
>
> [1] http://gaydenko.com/scala/tiscaf/httpd/
>
--
>>> >> 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 akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka
Re: [akka-user] Re: Akka HTTP performance for short lived connections
Great, thanks for the update. We have other ideas for how to improve this
and will get to it, eventually. There was a quick attempt previously, but
it had to be abandoned because of more urgent things. If someone would like
to take a stab at it this might be a good starting point:
https://github.com/akka/akka/pull/19762
Cheers,
Patrik
On Tue, Apr 19, 2016 at 10:42 AM, Adam wrote:
> Small update - disabling auto fuse, or pre-fusing (with & without auto
> fusing) has an effect (BTW I could not find a way to do this with the java).
> Performance is improved by up to 50%.
>
> However, it's still not in the same order of magnitude as other libraries.
> It's still at least 1 second for the fastest requests.
>
>
> On Tuesday, April 19, 2016 at 12:25:24 AM UTC+3, Adam wrote:
>>
>> Yeah, no code is rather silly really...
>>
>> I've created this repository:
>>
>> https://github.com/adamhonen/Akka-Http-performance-test
>>
>> I didn't get a chance to try the suggestions above yet, though.
>>
>>
>> On Monday, April 18, 2016 at 10:25:00 PM UTC+3, Konrad Malawski wrote:
>>>
>>> I see some results, but no code that is being benchmarked – please
>>> always post benchmarked code together with benchmark, otherwise it's hard
>>> to tell what's actually going on.
>>>
>>> On Mon, Apr 18, 2016 at 9:19 PM, Johan Andrén
>>> wrote:
>>>
Yet another thing to test could be to pre-fuse your Request => Response
flow, first, and then run that with autoFusing turned on or off. Locally I
get the best improvement with pre-fusing and no autoFusing. Looks like
this:
implicit val materializer =
ActorMaterializer(ActorMaterializerSettings(system))
val routes =
path("benchmark") {
get {
complete("ok")
}
}
val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes
val prefused = Fusing.aggressive(flow)
Http().bindAndHandle(
handler = Flow.fromGraph(prefused),
interface = "localhost",
port = 9000)
--
John Andrén
Akka Team, Lightbend Inc.
On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
>
> One thing that could be interesting to try out if you want to achieve
> as high throughput as possible where each new request is a new connection
> with the current akka-http version is to disable autoFusing (which is
> pretty costly). That can be done when you create the materializer like
> this:
>
>
> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>
> This will of course come at the cost where persistent connections get
> a performance hit instead.
>
> --
> John Andrén
> Akka Team, Lightbend Inc.
>
>
> On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>>
>> Adam, thanks!
>>
>> Very informative. I also have found handy to use almost empty
>> response to estimate the whole request-response chain itself (starting
>> from
>> now abandoned tiscaf [1] and rising rps up to almost 90K on humble
>> workstation :) ).
>>
>> [1] http://gaydenko.com/scala/tiscaf/httpd/
>>
> --
>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso' Malawski
>>> Akka
Re: [akka-user] Re: ActorSystem.terminate() couldn't fully terminate the system
Threads from the pool are released after a timeout. You can make them daemonic if you want via configuration. -Endre On Mon, Apr 18, 2016 at 10:02 PM, Yan Pei wrote: > John, > > After I upgrade AKKA to 2.4.4 and AKKA persistence cassandra to 0.12, > the system.terminate() works well now. > > Thank you very much for your help! > > Emily > > > On Monday, April 18, 2016 at 1:46:52 PM UTC-5, Johan Andrén wrote: >> >> Hi Emily, >> >> That specific stack trace is just the threadpool parking the thread >> waiting for work, the if there is a thread that is occupied with something, >> it would show some of your application classes and methods in it's stack >> trace. >> >> Are you using the latest Cassandra driver? Any special configuration for >> cassandra? It sounds unlikely, but of course not impossible, that there >> would be something in the Cassandra driver blocking and stopping your actor >> system from stopping. >> >> -- >> John Andrén >> Akka Team, Lightbend Inc. >> >> On Monday, April 18, 2016 at 7:55:14 PM UTC+2, Yan Pei wrote: >>> >>> I've simplified the Application to test this scenario by just printing >>> out simple message inside >>> the AbstractPersistentActorWithAtLeastOnceDelivery actor but with cassandra >>> configuration inside application.conf. >>> >>> After changing the persistence from the cassandra to leveldb, the >>> system.terminate() works well. >>> >>> So looks like the cassandra diver is the blocking tread. >>> >>> Should I do anything before calling system.terminate() once I enable the >>> cassandra configuration? >>> >>> Thanks, >>> Emily >>> >>> >>> On Monday, April 18, 2016 at 10:59:08 AM UTC-5, Johan Andrén wrote: Hi Emily, If an actor is blocking a thread and never returns it to the ActorSystem cannot do much about it, and if you try to terminate the ActorSystem it will never complete terminating. Blocking a thread could be actual processing that never stops or just takes a very long time, being stuck reading or writing some blocking resource, etc. You should be able to see what is going on by connecting to the JVM and taking a thread dump - this should show at least one thread having a call stack into one of your actors. -- Johan Andrén Akka Team, Lightbend Inc. On Monday, April 18, 2016 at 5:53:17 PM UTC+2, Yan Pei wrote: > > ActorSystem.terminate() works well with certain number of actors > inside the system. > > Once I increase the actor number, the system().terminate() couldn't > terminate the system, the application just hung on there and I have to > manually kill it. > (running from Eclipse) > > From the log it's trying to: > [DEBUG] [04/18/2016 10:44:58.530] > [ActorSystemmainaroraid1-akka.actor.default-di > spatcher-2] [EventStream] shutting down: StandardOutLogger started > > Anyone knows what's going on? > > Thanks very much! > Emily > -- > >> 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 akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at https://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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Question: Regarding reactive streams and threads / dispatcher
Hey guys,
I have an application where I expect many clients to connect to via TCP. So
my design is the following. I have these two actor-types:
* Server-Actor - Accepts incoming TCP connections (Uses Reactive TCP -
Stream). Per incoming request i spawn a new "ClientSession" - actor
instance.
* ClientSessionActor - This actor handles all the inside like session -
managment (Uses Akka FSM). It also setups a network-Flow (Using reactive
streams) that reads the incoming data.
So far so good. Now the problem I am facing that I have 100% CPU Load after
a short while. I could reproduce the problem by putting a Loadbalancer in
front which constantly makes a new TCP Connection to the application. I
attached JConsole and VisualVM to it and found out that it seems to spawn a
new thread per connection (new akka-default-dispatcher- keep popping
up). Here is how i spawn my "ClientSession" - Actor:
val props =
FromConfig.withDispatcher("network-dispatcher").props(Props[ClientSessionActor])
val actorRef = context.actorOf(clientProps, Server.generateClientPath())
Here is my config:
network-dispatcher {
type = "Dispatcher"
executor = "fork-join-executor"
# configure the thread pool
fork-join-executor {
# Min Threads
parallelism-min = 1
# Max Threads
parallelism-max = 1
# factor =
parallelism-factor = 1.0
}
# Throughput defines the maximum number of messages to be
# processed per actor before the thread jumps to the next actor.
# Set to 1 for as fair as possible.
throughput = 1
}
Is there a way to get around this? I would either prefer to have a fixed amount
of "threads" that do the work. Or it intended that every Flow is doing his work
in it's own thread? If yes is there
a way to fix this? I though about using "one" network-flow. But that seems to
be problematic when using TLS as security layer inbetween that is the reason
why I have one materialzted "flow" per connected client.
Regards,
Thomas
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: What config affects the number of threads for an ActorSystem?
Thanks, Johan. I did see that page, but if I understand the dispatcher config, the actor name you can define can't be a pattern? We define many actors without simple names like "myActor". In order to define a dispatcher for these actors, I presume I'd need to make a code change to use that dispatcher when the actors are created? Long term, that's what I'll want to do. Short term, I was hoping to find a pure config way to fix this. Would be happy to override the default dispatcher's config, if that were possible, for a short-term fix. On Mon, Apr 18, 2016 at 12:08 PM, Johan Andrén wrote: > Hi Steve, > > Did you have a look at the docs about dispatcher configuration? > > http://doc.akka.io/docs/akka/2.4.2/scala/dispatchers.html#default-dispatcher > > -- > Johan Andrén > Akka Team, Lightbend Inc. > > > On Sunday, April 17, 2016 at 3:29:49 PM UTC+2, Steve Rehrauer wrote: >> >> I have an application that doesn't specify a custom dispatcher. >> >> We see the number of threads maxing out at 50, and would like to increase >> it. >> >> This doesn't seem to line up with any of the default config I see in >> Akka? I see >> >> akka.actor.default-dispatcher.fork-join-executor.parallelism-max = 64 >> >> and I've tried raising this particular config, but still don't see more >> than 50 active threads. >> >> How can I affect this? >> > -- > >> 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 a topic in the > Google Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/m1USxQbXIiM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at https://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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: What config affects the number of threads for an ActorSystem?
It was more this specific section of the docs I was hoping you'd notice:
1. # Configuration for the fork join pool
2. fork-join-executor {
3. # Min number of threads to cap factor-based parallelism number to
4. parallelism-min = 2
5. # Parallelism (threads) ... ceil(available processors * factor)
6. parallelism-factor = 2.0
7. # Max number of threads to cap factor-based parallelism number to
8. parallelism-max = 10
9. }
10.
Note how the parallelism-max is a cap, the actual number is calculated by
multiplying the number of cores with the parallelism-factor and then
capping it with the min and max to arrive at the actual number on a given
computer.
The specific number of 50 is hard to say anything concrete about without
more info, but note that you will have a number of threads in the JVM not
being dispatcher threads and even some unrelated to Akka. The dispatcher
threads are easy to recognize as they are named
"[systemname]-actor.default-dispatcher-[n]".
--
Johan Andrén
Akka Team, Lightbend Inc.
On Tuesday, April 19, 2016 at 4:16:05 PM UTC+2, Steve Rehrauer wrote:
>
> Thanks, Johan.
>
> I did see that page, but if I understand the dispatcher config, the actor
> name you can define can't be a pattern? We define many actors without
> simple names like "myActor". In order to define a dispatcher for these
> actors, I presume I'd need to make a code change to use that dispatcher
> when the actors are created?
>
> Long term, that's what I'll want to do. Short term, I was hoping to find
> a pure config way to fix this. Would be happy to override the default
> dispatcher's config, if that were possible, for a short-term fix.
>
>
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] [akka-stream] Stream item error propogation and akka-http
Hi, I am trying to use akka-http's host-level client-side Http().cachedHostConnectionPool flow as part of a larger stream for which items in the stream may have previously failed, and so it wouldn't make sense to send an HTTP request. In other words, I really want a flow with type something like Flow[(Try[HttpRequest], Context)], (Try[HttpResponse], Context), NotUsed], for which the failure would be propagated. In general, this seems hard to do using akka-stream. More generally, I'd like to do something like, given a Flow[A,B,NotUsed], construct a new Flow[Try[A], Try[B], NotUsed] that would perform the operation of the original flow only if the input item was a Success. Otherwise, it would propagate the error. I don't see an easy way to accomplish this. Is this the right way to be approaching single-item failure propagation in a stream? Is there any kind of fan-out stage that routes items downstream based on a predicate? Any guidance would be appreciated. Arron -- >> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Connect two TCP sockets
Hi all,
I'm very new to Akka Streams, trying to get the ideas behind the streams
and how to use them. I'd like to make a very simple thing: to connect two
TCP server sockets, but I get stuck with that.
If I have server and client connections, it more or less clear for me:
val conn = Tcp().bind("localhost", 1234)
val out = Tcp().outgoingConnection("localhost", 2345)
val handler = Sink.foreach[Tcp.IncomingConnection] { c =>
println("Got connection from " + c.remoteAddress)
c.handleWith(out)
}
conn.to(handler).run()
This working for one connection. Could anybody give me a clue how to get
it work with more that one incoming connections (I suppose I need to use
Merge, or Source.combine)?
And the second question. As I understand this works in one direction
(from server socket to client). How can I use BidiFlow in such situation?
Finally, If I have two server connections I have no idea how to achieve
same result. Should I use mutable state to store incoming connections?
--
BR,
Mike.
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: What config affects the number of threads for an ActorSystem?
Ahhh, I see. Thanks for your patience, that helps.
On Tue, Apr 19, 2016 at 10:26 AM, Johan Andrén
wrote:
> It was more this specific section of the docs I was hoping you'd notice:
>
>
>1. # Configuration for the fork join pool
>2. fork-join-executor {
>3. # Min number of threads to cap factor-based parallelism number to
>4. parallelism-min = 2
>5. # Parallelism (threads) ... ceil(available processors * factor)
>6. parallelism-factor = 2.0
>7. # Max number of threads to cap factor-based parallelism number to
>8. parallelism-max = 10
>9. }
>10.
>
>
> Note how the parallelism-max is a cap, the actual number is calculated by
> multiplying the number of cores with the parallelism-factor and then
> capping it with the min and max to arrive at the actual number on a given
> computer.
>
> The specific number of 50 is hard to say anything concrete about without
> more info, but note that you will have a number of threads in the JVM not
> being dispatcher threads and even some unrelated to Akka. The dispatcher
> threads are easy to recognize as they are named
> "[systemname]-actor.default-dispatcher-[n]".
>
> --
> Johan Andrén
> Akka Team, Lightbend Inc.
>
>
> On Tuesday, April 19, 2016 at 4:16:05 PM UTC+2, Steve Rehrauer wrote:
>>
>> Thanks, Johan.
>>
>> I did see that page, but if I understand the dispatcher config, the actor
>> name you can define can't be a pattern? We define many actors without
>> simple names like "myActor". In order to define a dispatcher for these
>> actors, I presume I'd need to make a code change to use that dispatcher
>> when the actors are created?
>>
>> Long term, that's what I'll want to do. Short term, I was hoping to find
>> a pure config way to fix this. Would be happy to override the default
>> dispatcher's config, if that were possible, for a short-term fix.
>>
>> --
> >> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/m1USxQbXIiM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: ActorSystem.terminate() couldn't fully terminate the system
Endre, This is good to know. Could you please let me know how to configure it as daemonic? Thanks, Yan On Tuesday, April 19, 2016 at 8:01:45 AM UTC-5, drewhk wrote: > > Threads from the pool are released after a timeout. You can make them > daemonic if you want via configuration. > > -Endre > > On Mon, Apr 18, 2016 at 10:02 PM, Yan Pei > > wrote: > >> John, >> >> After I upgrade AKKA to 2.4.4 and AKKA persistence cassandra to 0.12, >> the system.terminate() works well now. >> >> Thank you very much for your help! >> >> Emily >> >> >> On Monday, April 18, 2016 at 1:46:52 PM UTC-5, Johan Andrén wrote: >>> >>> Hi Emily, >>> >>> That specific stack trace is just the threadpool parking the thread >>> waiting for work, the if there is a thread that is occupied with something, >>> it would show some of your application classes and methods in it's stack >>> trace. >>> >>> Are you using the latest Cassandra driver? Any special configuration for >>> cassandra? It sounds unlikely, but of course not impossible, that there >>> would be something in the Cassandra driver blocking and stopping your actor >>> system from stopping. >>> >>> -- >>> John Andrén >>> Akka Team, Lightbend Inc. >>> >>> On Monday, April 18, 2016 at 7:55:14 PM UTC+2, Yan Pei wrote: I've simplified the Application to test this scenario by just printing out simple message inside the AbstractPersistentActorWithAtLeastOnceDelivery actor but with cassandra configuration inside application.conf. After changing the persistence from the cassandra to leveldb, the system.terminate() works well. So looks like the cassandra diver is the blocking tread. Should I do anything before calling system.terminate() once I enable the cassandra configuration? Thanks, Emily On Monday, April 18, 2016 at 10:59:08 AM UTC-5, Johan Andrén wrote: > > Hi Emily, > > If an actor is blocking a thread and never returns it to the > ActorSystem cannot do much about it, and if you try to terminate the > ActorSystem it will never complete terminating. > > Blocking a thread could be actual processing that never stops or just > takes a very long time, being stuck reading or writing some blocking > resource, etc. You should be able to see what is going on by connecting > to > the JVM and taking a thread dump - this should show at least one thread > having a call stack into one of your actors. > > -- > Johan Andrén > Akka Team, Lightbend Inc. > > > On Monday, April 18, 2016 at 5:53:17 PM UTC+2, Yan Pei wrote: >> >> ActorSystem.terminate() works well with certain number of actors >> inside the system. >> >> Once I increase the actor number, the system().terminate() couldn't >> terminate the system, the application just hung on there and I have to >> manually kill it. >> (running from Eclipse) >> >> From the log it's trying to: >> [DEBUG] [04/18/2016 10:44:58.530] >> [ActorSystemmainaroraid1-akka.actor.default-di >> spatcher-2] [EventStream] shutting down: StandardOutLogger started >> >> Anyone knows what's going on? >> >> Thanks very much! >> Emily >> > -- >> >> 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 akka-user+...@googlegroups.com . >> To post to this group, send email to akka...@googlegroups.com >> . >> Visit this group at https://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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] How to remotely start a Akka actor: akka-in-action\chapter-remoting
By following Akka documents, I can start two actors(front-end and back-end)
on the same machine, and they can talk to each other. However, when I tried
to deploy back-end actor to another machine(Linux), I hit error of start
remoting:
Multiple main classes detected, select one to run:
[1] com.goticks.BackendMain
[2] com.goticks.BackendRemoteDeployMain
[3] com.goticks.FrontendMain
[4] com.goticks.FrontendRemoteDeployMain
[5] com.goticks.FrontendRemoteDeployWatchMain
[6] com.goticks.SingleNodeMain
Enter number: 2
[info] Running com.goticks.BackendRemoteDeployMain
[DEBUG] [04/18/2016 15:54:11.554] [run-main-0] [EventStream(akka://backend)]
logger log1-Logging$DefaultLogger started
[DEBUG] [04/18/2016 15:54:11.555] [run-main-0] [EventStream(akka://backend)]
Default Loggers started
[INFO] [04/18/2016 15:54:11.591] [run-main-0] [akka.remote.Remoting] Starting
remoting
[ERROR] [04/18/2016 15:54:11.748]
[backend-akka.remote.default-remote-dispatcher-5]
[NettyTransport(akka://backend)] failed to bind to /192.168.1.9:2551, shutting
down Netty transport
[ERROR] [04/18/2016 15:54:11.757] [run-main-0] [akka.remote.Remoting] Remoting
error: [Startup failed] [
akka.remote.RemoteTransportException: Startup failed at
akka.remote.Remoting.akka$remote$Remoting$$notifyError(Remoting.scala:136)
at akka.remote.Remoting.start(Remoting.scala:201)
at
akka.remote.RemoteActorRefProvider.init(RemoteActorRefProvider.scala:184)
at akka.actor.ActorSystemImpl.liftedTree2$1(ActorSystem.scala:663)
at akka.actor.ActorSystemImpl._start$lzycompute(ActorSystem.scala:660)
at akka.actor.ActorSystemImpl._start(ActorSystem.scala:660)
at akka.actor.ActorSystemImpl.start(ActorSystem.scala:676)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:143)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:120)
at
com.goticks.BackendRemoteDeployMain$.delayedEndpoint$com$goticks$BackendRemoteDeployMain$1(BackendRemoteDeployMain.scala:9)
at
com.goticks.BackendRemoteDeployMain$delayedInit$body.apply(BackendRemoteDeployMain.scala:6)
at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
at
scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:381)
at
scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
at scala.App$class.main(App.scala:76)
at
com.goticks.BackendRemoteDeployMain$.main(BackendRemoteDeployMain.scala:6)
at
com.goticks.BackendRemoteDeployMain.main(BackendRemoteDeployMain.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sbt.Run.invokeMain(Run.scala:67)
at sbt.Run.run0(Run.scala:61)
at sbt.Run.sbt$Run$$execute$1(Run.scala:51)
at sbt.Run$$anonfun$run$1.apply$mcV$sp(Run.scala:55)
at sbt.Run$$anonfun$run$1.apply(Run.scala:55)
at sbt.Run$$anonfun$run$1.apply(Run.scala:55)
at sbt.Logger$$anon$4.apply(Logger.scala:85)
at sbt.TrapExit$App.run(TrapExit.scala:248)
at java.lang.Thread.run(Unknown Source)
Caused by: org.jboss.netty.channel.ChannelException: Failed to bind to:
/192.168.1.9:2551
at
org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272)
at
akka.remote.transport.netty.NettyTransport$$anonfun$listen$1.apply(NettyTransport.scala:410)
at
akka.remote.transport.netty.NettyTransport$$anonfun$listen$1.apply(NettyTransport.scala:406)
192.168.1.9 is another machine.
In backend.conf:
remote {
enabled-transports = ["akka.remote.netty.tcp"]
netty.tcp {
#hostname = "0.0.0.0"
hostname = "192.168.1.9"
port = 2551
}
}
I have one basic question, when deploy and start a remote actor on remote
JVM, do we need user login information to remote machine so that we can
remotely start actor/JVM?
Thanks,
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more opti
[akka-user] Re: Connect two TCP sockets
Hi Mike,
The problem is that you create one outgoing connection, but you cannot use
that more than once. If you move that logic to create a new outgoing
connection on every new incoming it will work better, so that would be
inside of your foreach.
Please take a look at the docs for doing IO with Streams
here:
http://doc.akka.io/docs/akka/2.4.4/scala/stream/stream-io.html#Streaming_TCP
(I think that will answer most of your questions)
--
Johan Andrén
Akka Team, Lightbend Inc.
On Tuesday, April 19, 2016 at 5:44:27 PM UTC+2, Mike Limansky wrote:
>
> Hi all,
>
> I'm very new to Akka Streams, trying to get the ideas behind the streams
> and how to use them. I'd like to make a very simple thing: to connect two
> TCP server sockets, but I get stuck with that.
>
> If I have server and client connections, it more or less clear for me:
>
> val conn = Tcp().bind("localhost", 1234)
> val out = Tcp().outgoingConnection("localhost", 2345)
>
>
> val handler = Sink.foreach[Tcp.IncomingConnection] { c =>
>
> println("Got connection from " + c.remoteAddress)
>
> c.handleWith(out)
>
> }
>
> conn.to(handler).run()
>
>
> This working for one connection. Could anybody give me a clue how to get
> it work with more that one incoming connections (I suppose I need to use
> Merge, or Source.combine)?
>
> And the second question. As I understand this works in one direction
> (from server socket to client). How can I use BidiFlow in such situation?
>
> Finally, If I have two server connections I have no idea how to achieve
> same result. Should I use mutable state to store incoming connections?
>
> --
> BR,
> Mike.
>
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: [akka-stream] Stream item error propogation and akka-http
One pretty easy answer to this seems to be to use Http().singleRequest(...) to construct my own flow (using mapAsyncUnordered) with the behaviour I desire. I was concerned that singleRequest might have worse performance than the flow-based interface, but after a look at the source code, they both seem to be fairly thin wrappers around the same implementation. This does mean, for better or worse, that all requests would have to have absolute paths. On Tuesday, April 19, 2016 at 11:36:46 AM UTC-4, Arron Norwell wrote: > > Hi, > > I am trying to use akka-http's host-level client-side > Http().cachedHostConnectionPool flow as part of a larger stream for which > items in the stream may have previously failed, and so it wouldn't make > sense to send an HTTP request. In other words, I really want a flow with > type something like Flow[(Try[HttpRequest], Context)], (Try[HttpResponse], > Context), NotUsed], for which the failure would be propagated. > > In general, this seems hard to do using akka-stream. More generally, I'd > like to do something like, given a Flow[A,B,NotUsed], construct a new > Flow[Try[A], Try[B], NotUsed] that would perform the operation of the > original flow only if the input item was a Success. Otherwise, it would > propagate the error. > > I don't see an easy way to accomplish this. Is this the right way to be > approaching single-item failure propagation in a stream? Is there any kind > of fan-out stage that routes items downstream based on a predicate? Any > guidance would be appreciated. > > Arron > -- >> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] [akka-http] Customizing exception messages for async tasks in routes
Hello,
I have a route like the following
post{
complete {
(actor ? msg).mapTo[AResult]
}
}
When my future fails, a generic exception is returned to the client and I
would like to have more control on that. Recovering the future with a error
message doesn't seem a good idea because it will then be marshalled as a
correct result (200?). How can customize the exception handling, maybe to
tailor-made my behaviour depending on the exception type?
Thank you
Edmondo
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] [akka-http] Customizing exception messages for async tasks in routes
That's what ExceptionHandler is for in Akka HTTP:
more docs here:
http://doc.akka.io/docs/akka/2.4.4/scala/http/routing-dsl/directives/execution-directives/handleExceptions.html#description
Happy hakking!
--
Konrad `ktoso` Malawski
Akka @ Lightbend
On 20 April 2016 at 00:49:49, Edmondo Porcu (edmondo.po...@gottexbrokers.com)
wrote:
Hello,
I have a route like the following
post{
complete {
(actor ? msg).mapTo[AResult]
}
}
When my future fails, a generic exception is returned to the client and I would
like to have more control on that. Recovering the future with a error message
doesn't seem a good idea because it will then be marshalled as a correct result
(200?). How can customize the exception handling, maybe to tailor-made my
behaviour depending on the exception type?
Thank you
Edmondo
--
>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
