Re: [akka-user] [Java/Groovy/Akka 2.2.4] Trouble getting ClusteredSingletonManager working
On Mon, Mar 24, 2014 at 8:33 PM, Michael Kohout mwkoh...@gmail.com wrote:
Hazzah! I look forward to updating to 2.3.1 :-)
Thanks so much for your handholding through my stupid little problems
Mike
You're welcome. Happy hakking!
/Patrik
On Monday, March 24, 2014 2:00:00 PM UTC-5, Patrik Nordwall wrote:
On Mon, Mar 24, 2014 at 6:54 PM, Michael Kohout mwko...@gmail.comwrote:
Hi Patrik-
Yup, now it worked. I had to get the cluster seed nodes set up
correctly and then it looks like it works.
Glad to hear that.
Next, I've got to create the proxy. Have Typesafe/other committers
considered adding a configurable proxy that could do this out of the box?
It seems like a common pattern.
It will be included in upcoming Akka 2.3.1, which will be released within
a few days. :)
Another thing you mentioned in the stack overflow it that the
SingletonManager picks the location of the singleton based on age and that
it will result in all actors being hosted on one box. Are there any common
ways people are distributing a number of singletons across a cluster?
You can define several cluster node roles and run the singletons on
different roles. If you want something more dynamic that can make use of
all nodes you can use Cluster
Shardinghttp://doc.akka.io/docs/akka/2.3.0/contrib/cluster-sharding.html
(introduced
in v2.3.0).
/Patrik
thanks again
Mike
On Sunday, March 23, 2014 3:39:21 AM UTC-5, Patrik Nordwall wrote:
Hi Mike,
On Fri, Mar 21, 2014 at 8:34 PM, Michael Kohout mwko...@gmail.comwrote:
Hi All-
This issue is a repost from a stack overflow
questionhttp://stackoverflow.com/questions/22547889/akka-actors-and-clustering-im-having-trouble-with-clustersingletonmanager-unhaI
currently have, but Patrik
Nordwall http://stackoverflow.com/users/1835220/patrik-nordwall
suggested
I post it here as well.
Currently the system in prod uses only local actors. The basic
functionality of the app is that we have a bunch of actors that are each
responsible some work based on a range of hashed identifiers(hashed so
there is a fairly even distribution of work). A constraint with our
algorithm is that only one actor can work on that hash range at a time-so
some state in the actor is the starthash and the endhash. The application
is time based and every couple of minutes, we send a WORK message to
each
actor and based on the range they are responsible for they pull some data
out of a sql database and process it. While this may not be an optimal
architecture, this project is the first akka based project at this company
and we want to keep it simple.
A new requirement is that we have to handle failover. I've been
prototyping using the ClusteredSingletonManager. It looks like the
simplest way to accomplish what I want-which is one actor across the
cluster that will be created/called per hash range.
Here's the snippet of code that duplicates what I'm doing:
ActorSystem system = ActorSystem.create(${applicat
ionName}-actor-system, clusterConfig)
Props clusteredProps =
ClusterSingletonManager.defaultProps(worker.toString(),
PoisonPill.getInstance(), workerSystem,
new ClusterSingletonPropsFactory(){
@Override
Props create(Object handOverData) {
log.info(called in
ClusterSingetonManager)
//WorkerActorCreator.create makes
a new Creator that'll wire up our newly created Actor with the spring
services it craves.
Props.create(WorkerActorCreato
r.create(applicationContext, it.start, it.end)).withDispatcher(akka.
actor.worker-dispatcher).withMailbox(akka.actor.single-
message-bound-mailbox)
}
} )
ActorRef manager = system.actorOf(clusteredProps,
worker-${it.start}-${it.end}.toString())
String path = manager.path().child(worker).toString()
//This should call my shiny new singleton worker?
system.actorSelection(path).tell(WORK)
Is there something I'm doing wrong? Anything would be appreciated.
You have updated the names of the manager and the worker according to
my proposal. What problem do you see now?
That path should work on the oldest node, where the singleton worker is
active. If you want to send messages to the singleton worker from other
nodes you must implement a proxy actor that keeps track of where the oldest
member is located.
Note that it can take a while until the singleton becomes active when
you startup a new system.
/Patrik
Mike
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/c
urrent/additional/faq.html
Search the archives: https://groups.google.com/grou
p/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To
Re: [akka-user] Is there an established pattern for child timeout management?
On Mon, Mar 24, 2014 at 8:46 PM, Justin du coeur jduco...@gmail.com wrote: This has been stewing for a few hours, so I'm going to follow up: On Mon, Mar 24, 2014 at 12:27 PM, Patrik Nordwall patrik.nordw...@gmail.com wrote: I think opposite. It is easier to let each Aggregate decide, e.g. by using ReceiveTimeout. Slightly different question: are there other reasons to favor putting the timeout in the Aggregate / child? I'm by no means sure of myself here, and I'm genuinely interested in your viewpoint (since you have a lot more practical experience with this than I), but here's my reasoning. I see two obvious reasons to put the timeout in the child: 1) It makes the code a little simpler, as you mention. 2) It makes a certain amount of intuitive sense that the timeout for Actor Foo should adhere to Foo itself. Yes, then different Foos can have different timeouts, by deciding themselves. Might even depend on the data, e.g. WIP Customer stays in memory longer. The Passivate message in cluster sharding can be sent from anywhere to passivate a specific child. It can be sent from the outside, or from the manager itself, or from the child. The process to passivate is the same in all cases. /Patrik I'm not finding either of those arguments all that persuasive, though. I don't much care about the code complexity -- I'm designing a library here, so any complexity is buried. More importantly, I'm not sure I think it's the right separation of concerns. The thing is, at the semantic level the timeout barely even exists: the child Actor doesn't really care about the fact that it has a timeout. It's really an implementation detail to address the more interesting issue, which is memory pressure. And I think of memory pressure more in terms of the *collection* of Actors, than any individual Actor. Architecturally, I want to be able to say, I am allocating 40% of main memory to this body of Actors in my configuration; the timeouts are one way of keeping that under control. And the thing is, while timeouts per se conceptually adhere to the child, most of the other techniques I can think of to deal with this don't. Indeed, as I think about how I might make this more sophisticated, I find myself wanting the Manager / parent to have more control. A simple (and fairly long) timeout is great and appropriate so long as the system is lightly loaded, but once we start seeing any memory pressure, I might want to ratchet those timeouts down, or even move to a different algorithm (eg, an LRU queue that shoots older children in the head more aggressively to make room for newer ones, or which begins to pro-actively move children to other nodes). All of the really serious approaches I can think of require a more holistic view of the situation than can easily be handled in the child. I may well be over-thinking this: truth is, most of the advanced situations I am thinking of will probably want to be handled through the Cluster Sharding system anyway, at least in the long run. But that's roughly why I had been assuming that this logic would be living in the Manager. Indeed, I had *started*, months ago, by assuming that the Manager would have an LRU built into it -- the timeout idea came later... -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Low performance in cluster + sharding with single actor
Hi Eduardo,
On Tue, Mar 25, 2014 at 2:08 AM, Eduardo Fernandes edu...@gmail.com wrote:
Hi all.
I'm pretty sure this is because I don't have the correct configuration on
my side. Please find in the attached file a simple Eclipse Kepler Maven
project with an echo actor. I'm using Akka 2.3.
The basic configuration is
actor {
provider = akka.cluster.ClusterActorRefProvider
default-dispatcher {
throughput = 1024
fork-join-executor {
parallelism-max = 4
}
}
default-mailbox {
mailbox-type = akka.dispatch.SingleConsumerOnlyUnboundedMailbox
}
}
Based on other thread in this group. After heating the JVM I got around
11.000 msg per second. A small and basic program with NIO give me around
45.000 in the same machine, using the loopback interface.
If you refer to the other localhost remoting benchmark thread, the related
ticket is here:
https://www.assembla.com/spaces/akka/simple_planner#/ticket:3960
You can check with a profiler and see if most of the time spent in
unstash/stash in EndpointWriter to verify that it is the same issue.
If you properly backpressure messages between the two nodes there should be
no performance loss due to unstashing, you only need to increase the tcp
send buffer. The stash/unstash death spiral only pops up because buffers
are blowing up.
I need to use a single actor due to processing requirements. I'm using a
simple sharding and a single frontend / backend topology (configured using
roles).
Is it possible to flush the low level TCP channel based, for example, in
the volume of pending command to all actors belonging to a particular host?
Or is this already done based on some setting?
Messages are pumped out to TCP as soon as possible, there is no flushing
involved.
-Endre
Many thanks for any help.
Best regards,
Eduardo.
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Low performance in cluster + sharding with single actor
Eduardo, does the NIO test also use a persistent processor as destination?
/Patrik
On Tue, Mar 25, 2014 at 9:46 AM, Akka Team akka.offic...@gmail.com wrote:
Hi Eduardo,
On Tue, Mar 25, 2014 at 2:08 AM, Eduardo Fernandes edu...@gmail.comwrote:
Hi all.
I'm pretty sure this is because I don't have the correct configuration on
my side. Please find in the attached file a simple Eclipse Kepler Maven
project with an echo actor. I'm using Akka 2.3.
The basic configuration is
actor {
provider = akka.cluster.ClusterActorRefProvider
default-dispatcher {
throughput = 1024
fork-join-executor {
parallelism-max = 4
}
}
default-mailbox {
mailbox-type = akka.dispatch.SingleConsumerOnlyUnboundedMailbox
}
}
Based on other thread in this group. After heating the JVM I got around
11.000 msg per second. A small and basic program with NIO give me around
45.000 in the same machine, using the loopback interface.
If you refer to the other localhost remoting benchmark thread, the related
ticket is here:
https://www.assembla.com/spaces/akka/simple_planner#/ticket:3960
You can check with a profiler and see if most of the time spent in
unstash/stash in EndpointWriter to verify that it is the same issue.
If you properly backpressure messages between the two nodes there should
be no performance loss due to unstashing, you only need to increase the tcp
send buffer. The stash/unstash death spiral only pops up because buffers
are blowing up.
I need to use a single actor due to processing requirements. I'm using a
simple sharding and a single frontend / backend topology (configured using
roles).
Is it possible to flush the low level TCP channel based, for example, in
the volume of pending command to all actors belonging to a particular host?
Or is this already done based on some setting?
Messages are pumped out to TCP as soon as possible, there is no flushing
involved.
-Endre
Many thanks for any help.
Best regards,
Eduardo.
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Patrik Nordwall
Typesafe http://typesafe.com/ - Reactive apps on the JVM
Twitter: @patriknw
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] BankAccount - good fit for akka persistence?
Oh. I see. It would've been nice if I can choose the persistence plug in per actor type. I've read up on Views but don't exactly understand what they are for. Is it better to have the view to log the messages into sql than to have the processor do it? Sent from my iPad On Mar 24, 2014, at 10:39 PM, Akka Team akka.offic...@gmail.com wrote: Hi Jan, You can have only one persistence plugin per system so if you implement an SQL based storage plugin it will be shared by all persistent components. It might be a working solution to have a plugin that delegates to an ordinary storage for normal messages, and stores a specific subset of messages in the SQL storage. If you are fine with your journal entries getting into SQL after a delay, you might want to use a View for that. Then all your messages are persisted to an ordinary journal first (for quick recovery) and the view puts them into a different storage (for example for querying reasons). The second storage populated by the view will see the data delayed. -Endre On Mon, Mar 24, 2014 at 3:04 PM, Jan Vincent Liwanag jvliwa...@gmail.com wrote: Is it normal to create a custom journal and snapshot mechanism for prespecified messages? Or should journal and snapshot implementations be generic -- that is, they should be able to handle any type of message and state - much like the default leveldb one? -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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/yg3_Hapvli0/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 http://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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Low performance in cluster + sharding with single actor
Hi Eduardo,
The problem is that in your case no matter how large you choose your buffer
sizes, they will blow up because there is no backpressure between the two
actors. This is independent of remoting, you can blow up mailboxes even
locally. The issue with stash/unstash only comes into the picture because
the buffer grows out of bounds. Even if that issue would not exist,
eventually GC kicks in due to continuously increasing memory usage.
-Endre
On Tue, Mar 25, 2014 at 11:00 AM, Vitaliy V. Shopov
shopov.vita...@gmail.com wrote:
And what is your updated benchmark result?)
2014-03-25 13:57 GMT+04:00 Eduardo Fernandes edu...@gmail.com:
Many thanks for your suggestions.
I'll check the profiling and the settings below.
Thanks again for your quick answer!
1.
2. # Sets the send buffer size of the Sockets,
3. # set to 0b for platform default
4. send-buffer-size = 256000b
5.
6. # Sets the receive buffer size of the Sockets,
7. # set to 0b for platform default
8. receive-buffer-size = 256000b
El martes, 25 de marzo de 2014 09:46:28 UTC+1, Akka Team escribió:
Hi Eduardo,
On Tue, Mar 25, 2014 at 2:08 AM, Eduardo Fernandes edu...@gmail.comwrote:
Hi all.
I'm pretty sure this is because I don't have the correct configuration
on my side. Please find in the attached file a simple Eclipse Kepler Maven
project with an echo actor. I'm using Akka 2.3.
The basic configuration is
actor {
provider = akka.cluster.ClusterActorRefProvider
default-dispatcher {
throughput = 1024
fork-join-executor {
parallelism-max = 4
}
}
default-mailbox {
mailbox-type = akka.dispatch.SingleConsumerOnlyUnboundedMailbox
}
}
Based on other thread in this group. After heating the JVM I got around
11.000 msg per second. A small and basic program with NIO give me around
45.000 in the same machine, using the loopback interface.
If you refer to the other localhost remoting benchmark thread, the
related ticket is here: https://www.assembla.com/
spaces/akka/simple_planner#/ticket:3960
You can check with a profiler and see if most of the time spent in
unstash/stash in EndpointWriter to verify that it is the same issue.
If you properly backpressure messages between the two nodes there should
be no performance loss due to unstashing, you only need to increase the tcp
send buffer. The stash/unstash death spiral only pops up because buffers
are blowing up.
I need to use a single actor due to processing requirements. I'm using
a simple sharding and a single frontend / backend topology (configured
using roles).
Is it possible to flush the low level TCP channel based, for example,
in the volume of pending command to all actors belonging to a particular
host? Or is this already done based on some setting?
Messages are pumped out to TCP as soon as possible, there is no flushing
involved.
-Endre
Many thanks for any help.
Best regards,
Eduardo.
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that
Re: [akka-user] Low performance in cluster + sharding with single actor
Our current technology (what we want to replace) is using 3 different
criteria when making automatic backpressure: number of blocked threads,
timeout and queue size. The first one apply to ask patterns. The second one
enable us to validate that the system is not blocking cpu due to pending
tasks and the third one does the job if there is no too many queued
elements. With a correct combination of the three parameters we could
increase the throughput up to 40-45kCmd/s in my laptop, both client and
server are monothread. The packet size through the net is adaptive in
function of the concurrency and pressure.
Many thanks for your answer and for driving me to the right direction. I'll
test the concepts and let you know.
El martes, 25 de marzo de 2014 11:16:28 UTC+1, Akka Team escribió:
Hi Eduardo,
The problem is that in your case no matter how large you choose your
buffer sizes, they will blow up because there is no backpressure between
the two actors. This is independent of remoting, you can blow up mailboxes
even locally. The issue with stash/unstash only comes into the picture
because the buffer grows out of bounds. Even if that issue would not exist,
eventually GC kicks in due to continuously increasing memory usage.
-Endre
On Tue, Mar 25, 2014 at 11:00 AM, Vitaliy V. Shopov
shopov@gmail.comjavascript:
wrote:
And what is your updated benchmark result?)
2014-03-25 13:57 GMT+04:00 Eduardo Fernandes edu...@gmail.comjavascript:
:
Many thanks for your suggestions.
I'll check the profiling and the settings below.
Thanks again for your quick answer!
1.
2. # Sets the send buffer size of the Sockets,
3. # set to 0b for platform default
4. send-buffer-size = 256000b
5.
6. # Sets the receive buffer size of the Sockets,
7. # set to 0b for platform default
8. receive-buffer-size = 256000b
El martes, 25 de marzo de 2014 09:46:28 UTC+1, Akka Team escribió:
Hi Eduardo,
On Tue, Mar 25, 2014 at 2:08 AM, Eduardo Fernandes edu...@gmail.comwrote:
Hi all.
I'm pretty sure this is because I don't have the correct configuration
on my side. Please find in the attached file a simple Eclipse Kepler
Maven
project with an echo actor. I'm using Akka 2.3.
The basic configuration is
actor {
provider = akka.cluster.ClusterActorRefProvider
default-dispatcher {
throughput = 1024
fork-join-executor {
parallelism-max = 4
}
}
default-mailbox {
mailbox-type = akka.dispatch.SingleConsumerOnlyUnboundedMai
lbox
}
}
Based on other thread in this group. After heating the JVM I got
around 11.000 msg per second. A small and basic program with NIO give me
around 45.000 in the same machine, using the loopback interface.
If you refer to the other localhost remoting benchmark thread, the
related ticket is here: https://www.assembla.com/
spaces/akka/simple_planner#/ticket:3960
You can check with a profiler and see if most of the time spent in
unstash/stash in EndpointWriter to verify that it is the same issue.
If you properly backpressure messages between the two nodes there
should be no performance loss due to unstashing, you only need to increase
the tcp send buffer. The stash/unstash death spiral only pops up because
buffers are blowing up.
I need to use a single actor due to processing requirements. I'm using
a simple sharding and a single frontend / backend topology (configured
using roles).
Is it possible to flush the low level TCP channel based, for example,
in the volume of pending command to all actors belonging to a particular
host? Or is this already done based on some setting?
Messages are pumped out to TCP as soon as possible, there is no
flushing involved.
-Endre
Many thanks for any help.
Best regards,
Eduardo.
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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
Re: [akka-user] BankAccount - good fit for akka persistence?
On Tue, Mar 25, 2014 at 2:53 AM, Jan Vincent Liwanag jvliwa...@gmail.comwrote: Oh. I see. It would've been nice if I can choose the persistence plug in per actor type. I've read up on Views but don't exactly understand what they are for. Replaying the persistent messages of a Processor or the events of an EventsourcedProcessor in another actor (the View). In the view actor you can build up another representation of the state, and/or optionally save it in another data store (e.g. optimized for queries). Is it better to have the view to log the messages into sql than to have the processor do it? That is a better solution if the eventual consistency aspect is alright for you. /Patrik Sent from my iPad On Mar 24, 2014, at 10:39 PM, Akka Team akka.offic...@gmail.com wrote: Hi Jan, You can have only one persistence plugin per system so if you implement an SQL based storage plugin it will be shared by all persistent components. It might be a working solution to have a plugin that delegates to an ordinary storage for normal messages, and stores a specific subset of messages in the SQL storage. If you are fine with your journal entries getting into SQL after a delay, you might want to use a View for that. Then all your messages are persisted to an ordinary journal first (for quick recovery) and the view puts them into a different storage (for example for querying reasons). The second storage populated by the view will see the data delayed. -Endre On Mon, Mar 24, 2014 at 3:04 PM, Jan Vincent Liwanag jvliwa...@gmail.comwrote: Is it normal to create a custom journal and snapshot mechanism for prespecified messages? Or should journal and snapshot implementations be generic -- that is, they should be able to handle any type of message and state - much like the default leveldb one? -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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/yg3_Hapvli0/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 http://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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Move/Migrate Actors between Remote Nodes
Hello!
I have been trying to find information on how to move/migrate a running
actor from one node to another
but I have not been able to find anything concrete.
Assume we have three actors, the producer, the processor and the consumer.
The producer
creates/senses/reads data and sends it to the processor, the processor
processes this data
and sends it to the consumer that logs/saves it.
Communication chain:
ProducerActor - ProcessActor - ConsumerActor
For the context:
Assume we had the three nodes 6000,6001,6002 running when we initially
deployed the actors.
After a while, node 6003 enters the cluster. We now realize that node 6003
is a much better
candidate for running the ProcessActor, so we would like to move/migrate it.
I looked at the
SimpleClusterApphttps://github.com/akka/akka/blob/master/akka-samples/akka-sample-cluster-scala/src/main/scala/sample/cluster/simple/SimpleClusterApp.scala
and
I just changed it around a bit in order to try out some stuff:
object SimpleClusterApp {
def main(args: Array[String]): Unit = {
if (args.isEmpty)
startup(Seq(6000, 6001, 6002, 6003))
else
startup(args)
}
def startup(ports: Seq[String]): Unit = {
ports foreach { port =
// Override the configuration of the port
val config = ConfigFactory.parseString(akka.remote.netty.tcp.port=
+ port).
withFallback(ConfigFactory.load())
// Create an Akka system
val system = ActorSystem(ClusterSystem, config)
// Create an actor that handles cluster domain events
system.actorOf(Props[ClusterListener], name = clusterListener)
if(port == 0) {
// Set adresses for the four nodes
val producerAddr =
AddressFromURIString(akka.tcp://ClusterSystem@127.0.0.1:6000)
val processAddr =
AddressFromURIString(akka.tcp://ClusterSystem@127.0.0.1:6001)
val consumerAddr =
AddressFromURIString(akka.tcp://ClusterSystem@127.0.0.1:6002)
val newAddr =
AddressFromURIString(akka.tcp://ClusterSystem@127.0.0.1:6003)
// Deploy the actors
val consumerRef =
system.actorOf(Props[ConsumerActor].withDeploy(Deploy(scope =
RemoteScope(consumerAddr))), name = Consumer)
val processRef =
system.actorOf(Props(classOf[ProcessActor],consumerRef).withDeploy(Deploy(scope
= RemoteScope(processAddr))), name = ProcessingResource)
val producerRef =
system.actorOf(Props(classOf[ProducerActor],processRef).withDeploy(Deploy(scope
= RemoteScope(producerAddr))), name = Producer)
// Tell producer to start producing values
producerRef ! Start
// migrate processRef to newAddr
}
}
}
}
If it is Stateless I could just do something like:
//temporarily halt production
producerRef ! Halt
// shut down processRef
processRef ! Stop
//create new processing resource
val newRef =
system.actorOf(Props(classOf[ProcessActor],consumerRef).withDeploy(Deploy(scope
= RemoteScope(newAddr))), name = ProcessingResource)
//redirect producer output to new processing resource
producerRef ! ChangeOutput(newRef)
//restart production
producerRef ! Start
Basically, how do I move/migrate the actor ProcessingResource to newAddr if
it has a state?
Also, is there a smarter/easier way of doing the stateless migration that
I showed above?
Regards,
Andreas
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Move/Migrate Actors between Remote Nodes
Hi Andreas,
To be able to migrate actors you need to be able to restore their state at
their new place. This is one of the use-cases for the new experimental
akka-persistence module (
http://doc.akka.io/docs/akka/2.3.0/scala/persistence.html).
Migrating entities is not trivial, so before you start implementing your
own migration logic, take a look at cluster sharding to see if it is a fit
for your problem:
http://doc.akka.io/docs/akka/2.3.0/contrib/cluster-sharding.html
Sharding allows custom allocation strategies, (see the doc page I linked
above) it might be just what you need.
-Endre
On Tue, Mar 25, 2014 at 2:35 PM, Andreas Moregard
andreas.moreg...@gmail.com wrote:
Hello!
I have been trying to find information on how to move/migrate a running
actor from one node to another
but I have not been able to find anything concrete.
Assume we have three actors, the producer, the processor and the consumer.
The producer
creates/senses/reads data and sends it to the processor, the processor
processes this data
and sends it to the consumer that logs/saves it.
Communication chain:
ProducerActor - ProcessActor - ConsumerActor
For the context:
Assume we had the three nodes 6000,6001,6002 running when we initially
deployed the actors.
After a while, node 6003 enters the cluster. We now realize that node 6003
is a much better
candidate for running the ProcessActor, so we would like to move/migrate
it.
I looked at the
SimpleClusterApphttps://github.com/akka/akka/blob/master/akka-samples/akka-sample-cluster-scala/src/main/scala/sample/cluster/simple/SimpleClusterApp.scala
and
I just changed it around a bit in order to try out some stuff:
object SimpleClusterApp {
def main(args: Array[String]): Unit = {
if (args.isEmpty)
startup(Seq(6000, 6001, 6002, 6003))
else
startup(args)
}
def startup(ports: Seq[String]): Unit = {
ports foreach { port =
// Override the configuration of the port
val config = ConfigFactory.parseString(akka.remote.netty.tcp.port=
+ port).
withFallback(ConfigFactory.load())
// Create an Akka system
val system = ActorSystem(ClusterSystem, config)
// Create an actor that handles cluster domain events
system.actorOf(Props[ClusterListener], name = clusterListener)
if(port == 0) {
// Set adresses for the four nodes
val producerAddr = AddressFromURIString(akka.tcp://
ClusterSystem@127.0.0.1:6000)
val processAddr = AddressFromURIString(akka.tcp://
ClusterSystem@127.0.0.1:6001)
val consumerAddr = AddressFromURIString(akka.tcp://
ClusterSystem@127.0.0.1:6002)
val newAddr = AddressFromURIString(akka.tcp://
ClusterSystem@127.0.0.1:6003)
// Deploy the actors
val consumerRef =
system.actorOf(Props[ConsumerActor].withDeploy(Deploy(scope =
RemoteScope(consumerAddr))), name = Consumer)
val processRef =
system.actorOf(Props(classOf[ProcessActor],consumerRef).withDeploy(Deploy(scope
= RemoteScope(processAddr))), name = ProcessingResource)
val producerRef =
system.actorOf(Props(classOf[ProducerActor],processRef).withDeploy(Deploy(scope
= RemoteScope(producerAddr))), name = Producer)
// Tell producer to start producing values
producerRef ! Start
// migrate processRef to newAddr
}
}
}
}
If it is Stateless I could just do something like:
//temporarily halt production
producerRef ! Halt
// shut down processRef
processRef ! Stop
//create new processing resource
val newRef =
system.actorOf(Props(classOf[ProcessActor],consumerRef).withDeploy(Deploy(scope
= RemoteScope(newAddr))), name = ProcessingResource)
//redirect producer output to new processing resource
producerRef ! ChangeOutput(newRef)
//restart production
producerRef ! Start
Basically, how do I move/migrate the actor ProcessingResource to newAddr
if it has a state?
Also, is there a smarter/easier way of doing the stateless migration
that I showed above?
Regards,
Andreas
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
Re: [akka-user] Is there an established pattern for child timeout management?
On Tue, Mar 25, 2014 at 2:40 AM, Patrik Nordwall patrik.nordw...@gmail.comwrote: Yes, then different Foos can have different timeouts, by deciding themselves. Might even depend on the data, e.g. WIP Customer stays in memory longer. Yeah, I was just realizing that part of our different viewpoints here is because of the different use cases. The Cluster Sharding manager is typically controlling *heterogeneous* children -- it will routinely have a number of child Actors of different sorts. For that case, I agree that it makes far less sense to bundle the semantics into the Manager. But I'm focused on the fairly common (but less general) situation where the Manager has a bunch of relatively *homogeneous* children, each of which has its own data but is essentially the same type: I have a bunch of Foo Actors, and specifically a FooManager. That is leading me to focus on different priorities, and makes the correct separation of concerns less obvious. I *think* that in that sort of situation it's typically going to be more straightforward to put the timeout handling in the Manager. We'll see. I think I'm going to try it that way, and we can see whether the resulting API turns out to make sense in practice. If nothing else, it should provide an interesting alternative to compare against... -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Problem with configuration for router with remote routee; routee creates actor pool with BalancingDispatcher
In the mean time I found that I was looking at a slightly older version of
the configuration (for 2.3-M1), and found the BalancingPool in the 2.3.0
docs.
However, using the following config:
actor.deployment {
/receiver {
router = round-robin-pool
nr-of-instances = 1
target.nodes = [ akka.tcp://systemA@localhost:2553 ]
}
/receiver/*/workerPool {
router = balancing-pool
nr-of-instances = 4
}
}
and the following actor creation code in the Receiver:
val workerPool = context.actorOf(FromConfig.props(Props[Worker]),
workerPool)
I still get the first exception from my previous post:
path parameter: Invalid path
'BalancingPool-/akka.tcp/systemB@localhost:61671/user/receiver/c1/workerPool':
Token not allowed in path expression: '@' (Reserved character '@' is not
allowed outside quotes) (you can double-quote this token if you really want
it here)
Same error if I try to define it in code, rather than in config (having
removed the configuration entry for /receiver/*/workerPool shown above):
val workerPool = context.actorOf(
BalancingPool(4).props(Props[Worker]),
name = workerPool
)
The error:
path parameter: Invalid path
'BalancingPool-/akka.tcp/systemB@localhost:61705/user/receiver/c1/workerPool':
Token not allowed in path expression: '@' (Reserved character '@' is not
allowed outside quotes) (you can double-quote this token if you really want
it here)
-Boris
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
