Magnus, hi!
Thanks for the suggestions!
On Monday, May 18, 2015 at 3:57:00 PM UTC+3, Magnus Andersson wrote:
1. Keep track of running futures in your actor1 in a var. When your
actor enters poststop you can await the completion of all referenced
futures. You probably would have
The Lifecycle of the Actor System does manage futures you spawn within your
Actors. You have to manage that yourself.
Two suggestions:
1. Keep track of running futures in your actor1 in a var. When your
actor enters poststop you can await the completion of all referenced
futures. You
Hallo Endre,
thanks for your quick response. I have filed an issue
here: https://github.com/akka/akka/issues/17507
Best regards,
Jan
Am Montag, 18. Mai 2015 12:42:05 UTC+2 schrieb drewhk:
On Mon, May 18, 2015 at 12:28 PM, Jan Liße jan@gmail.com
javascript: wrote:
Hello,
i'm
Thanks Martynas for pointing me to heartbeat configuration property. I'll
try and get back to you.
@Soumya, I didn't understand your question. Based on my understanding I am
answering, if you have terribly huge (not very huge it is just 1 TB) heap
space then JVM is very tired to clean it up.
I think he meant I have never seen a GC pause that long. I'm in the same
boat, that's an insanely long pause.
So when I say this, keep in mind I am java guy who is pretty new to akka
and scala, so this isn't expert advice. :) But tuning akka doesn't seem
like the appropriate place for this.
On 05/18/15 08:01, Andrew Gaydenko wrote:
Magnus, hi!
Thanks for the suggestions!
On Monday, May 18, 2015 at 3:57:00 PM UTC+3, Magnus Andersson wrote:
1. Keep track of running futures in your actor1 in a var. When
your actor enters poststop you can await the completion of all
Hi Anders,
It looks like this question has fallen between the cracks. I'm so sorry for
that. Have you found a solution?
The node must be removed, not only detected as unreachable.
Failover of the singleton may take some additional time,
see maxHandOverRetries and maxTakeOverRetries in API docs
Thanks, Martynas
I have a client connecting to the server (actor based) using TCP. By per
session, I mean per TCP connection, until the client disconnects. I need to
have a way of creating a persistent actor initially and the same persistent
actor reused for subsequent tcp connections. There
Guys may be I didn't stress the point of distribution stuff well. I agree
with you all but if you see my first post 3rd line. May I am bit afraid
that our discussion side tracking actual question.
Its my fault I didnt explain well.
- AKKA is NOT causing GC problems ( our application is
On Monday, May 18, 2015 at 9:33:28 PM UTC+3, Michael Frank wrote:
i usually solve this by map()ing the future to some request id that i
generate. for example (written on the spot, may not compile)
Michael,
Aha, I see, it's very smart. Will try. Thanks!
--
Read the docs:
@Soumya, I didn't understand your question. Based on my understanding I am
answering, if you have terribly huge (not very huge it is just 1 TB) heap
space then JVM is very tired to clean it up.
My question is - how do you know that the GC is pause is that long. Have
you tried using
So when I say this, keep in mind I am java guy who is pretty new to akka
and scala, so this isn't expert advice. :) But tuning akka doesn't seem
like the appropriate place for this. Either there is something in your
application layer that requires this massive heap that could be
The back pressure is propagated to the client thanks to TCPs built in
mechanisms for this - on the server side we simply do not read from the
socket
until demand is available, which causes the back pressure to be propagated
properly.
Konrad,
So if we are *not* using a congestion
On 05/18/15 10:31, Andrew Gaydenko wrote:
On Monday, May 18, 2015 at 7:51:31 PM UTC+3, Michael Frank wrote:
How about piping the result of the future back to actor1, then
send the result to actor2? you can prune the completed future in
actor1 when it receives the result.
Michael,
Hi everyone,
I often need to have both the materializer and the execution context in
scope in my routes.
Is there a more compact way of doing this?
extractFlowMaterializer { implicit mat =
extractExecutionContext { implicit ec =
or
extractFlowMaterializer { implicit mat =
implicit val ec
Thanks, it looks interesting
понедельник, 18 мая 2015 г., 12:02:09 UTC+3 пользователь Konrad Malawski
написал:
Hello there,
Have a look at Cluster Sharding
http://doc.akka.io/docs/akka/2.3.11/contrib/cluster-sharding.html it's
exactly that :-)
It will become a stable module in 2.4 (which
On 05/18/15 11:48, seetaramayya vadali wrote:
Hi Martynas,
After adding acceptable-heartbeat-pause and removing
auto-down-unreachable-after both nodes formed different clusters. I am
still exploring failure-detector configuration part. If any one have
any other suggestions I can save
- We are using Java 7
- 32 cores I guess ( I am not sure though )
- Considering Azul
I didnt understand how come GC tuning matters with node joining the
cluster. Is there any relation ?
On Mon, May 18, 2015 at 9:12 PM, Michael Frank syntaxjoc...@gmail.com
wrote:
On 05/18/15 11:48,
Michael,
I have implemented the idea in my context. Yes, it does work. Thanks again!
--
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
18 maj 2015 kl. 21:19 skrev seetaramayya vadali srvad...@gmail.com:
We are using Java 7
32 cores I guess ( I am not sure though )
Considering Azul
I didnt understand how come GC tuning matters with node joining the cluster.
Is there any relation ?
You will not have a smooth
I have actorSelection.tell reaching my onReceiveCommand. Looks like it was
some configuration issue.
I also need the persistent actor deleted on the close of the socket from
the client side. Does this approach seem fine or is there a better way to
do this.
Thanks,
TS
On Monday, May 18,
Дмитрий,
In this topic
https://groups.google.com/forum/#!folder/current/akka-user/R1ZxPKlp1fI
*Michael Frank* has suggested an idea, I have implemented it, and it does
work at my use case as expected. Probably, you will get something useful
there also :)
--
Read the docs:
Hi TS,
I developed an application which solves exactly the same problem. And I
found Cluster Sharding very handy for this. It takes care of making sure
that you have one and only one Actor (or PersistentActor) for an id (in our
case it's SessionId), takes care of rebalancing on node add/remove
I feel like it's a more general problem:
Actors are imperative. So all these simple patterns are not composable.
When you perform something like I need to do smth with future and then
change state of actor, you have a plenty of solutions. Piping, actors per
requests, request ids, etc.
But
My not clustered version of actor was:
class User(userId: String) extends PersistentActor {
override val persistenceId = userId
// ...
}
Now I decided to use Cluster Sharding so I could not pass to constructor any
userId at runtime. It looks that I should use idResolver for that purpose,
I asked myself the same question when I faced to the problem of merging
elements from Source[A] and Source[B] where A and B are children of the
same trait C. Had to make both sources a Source[C].
On Saturday, May 16, 2015 at 4:47:51 PM UTC+3, Oliver Winks wrote:
If you look at the
Hi guys, I was hoping you could point me in the right direction. I have an
API server with the Play framework that uses actors. Right now, these are
just local actors but their workload is growing and since I'm beginning to
introduce more more scheduled background jobs, I would like it to be
cool, glad it works!
-Michael
On 05/18/15 15:27, Andrew Gaydenko wrote:
Michael,
I have implemented the idea in my context. Yes, it does work. Thanks
again!
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the
Thanks Martynas, currently I am trying the TestActorRef approach which
works.
On 16/05/15 10:12, Martynas Mickevičius wrote:
Hi Kostas,
I see two ways in approaching this. First, you could use TestActorRef
to test the insides
I have the following requirements:
A bunch of users communicate with my app via http api and sends video watch
status (progress). Any time I should be able to determine how mach users
watching the particular video right now and how many video is watching by
particular users.
So I should
Hello there,
Have a look at Cluster Sharding
http://doc.akka.io/docs/akka/2.3.11/contrib/cluster-sharding.html it's
exactly that :-)
It will become a stable module in 2.4 (which will get its first milestone
*very soon*).
On Mon, May 18, 2015 at 9:11 AM, Artyom Bolshakov tweek...@gmail.com
wrote:
Hello,
i'm currently building a scraper system on top of Akka Streams. I have
written a Flow that is able to follow paginated sites and scrape them in a
loop.
For this i use a feedback merge.
My code: https://gist.github.com/janlisse/f2672bf8bbee009ef009
script
On Mon, May 18, 2015 at 12:28 PM, Jan Liße jan.li...@gmail.com wrote:
Hello,
i'm currently building a scraper system on top of Akka Streams. I have
written a Flow that is able to follow paginated sites and scrape them in a
loop.
For this i use a feedback merge.
My code:
I have been trying to clarify this question online for a while without
success, so I will try to ask it here.
I would like to find some resource or example where it shows how I can
build an end-to-end fully back-pressured REST service + client. What I mean
is that I would like to see that,
Hi there Matteo,
You’ve arrived in the right place to ask Akka questions :-)
There are two talks I’m aware of which show a demo how the backpressure
mechanism really works when working with http.
1) One is Roland Kuhn’s talk on ScalaDays SF 2015:
HI!
Say, we have actor1 calling a function on received message returning
Future[T].
Then this actor1 pipes the future to actor2.
And the last one does some final work on T.
I have not found a way to gracefully shutdown such actor system (say, with
attached shutdown
hook for daemonic actor
36 matches
Mail list logo
