Re: [akka-user] Re: Akka 2.3.4 Released - Major updates to Akka Persistence
Thanks for sharing. I have added some information to the ticket https://github.com/akka/akka/issues/15129. /Patrik On Tue, Jul 1, 2014 at 9:24 PM, Olger Warnier ol...@spectare.nl wrote: One small note for people that may run into this issue: Our project uses the leveldb in a shared mode 'native = off' in our multi-jvm test setup. (inmem in our inproc setup) It appears that the leveldb dependency gives issues in this setup. The whole thing is described here https://github.com/akka/akka/issues/15129 by excluding the leveldb 0.5 in your dependency setup (on akka-persistence) and added 0.7 manually, this is solved. like: val akkaPersistence = com.typesafe.akka %% akka-persistence-experimental % V.akka exclude(org.iq80.leveldb,leveldb) val levelDbFixed = org.iq80.leveldb% leveldb % 0.7 (thereafter use these in your build definition) Interesting thing here is that it was updated before: https://github.com/akka/akka/blob/33030ca96930d0a76a8906f4028b43bec747a555/project/AkkaBuild.scala#L1119 (but the releasing branches refer to 0.5 it appears (after a bit of browsing) -- 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] can actor change its inner state regularly in the private method of the actor?
Hi, I'm a newcomer to Akka. I met with a problem. Any help will be grateful. I want to update state within the actor every other minute , can I just change state within the private method of the actor? Or should I send message to self actor, then change state when receive this message ? The Akka guide said Actor change their state only when they receive a stimulus in from of msg , does it mean cannot change state even in the private method of the actor ? Thanks for reply~ -- 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] Akka cluster: node identity crisis
I upgraded to Akka 2.3.4 (scala 2.10), but still seeing the same issue.
When I log Cluster(system).selfUniqueAddress I get something
like UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,630715883),
with the last number changing everytime I restart.
The gossip message error always has the same number -1482656725. For
example,
18:12:27.472 INFO [streaming-akka.actor.default-dispatcher-15]
Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Ignoring received gossip
intended for someone else, from [akka.tcp://streaming@172.17.110.143:7000]
to [UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)]
On Tuesday, July 1, 2014 2:33:52 PM UTC-4, Patrik Nordwall wrote:
Please use latest version, i.e. 2.3.4
There you find Cluster(system).selfUniqueAddress that includes the uid.
I will look into this in more detail tomorrow.
/Patrik
1 jul 2014 kl. 19:57 skrev Benjamin Black benbl...@gmail.com
javascript::
I have a cluster of 15 nodes/boxes. I start the nodes roughly at the same
time. One of the nodes is behaving oddly and continually logging Ignoring
received gossip intended for someone else. However, the node does seem to
work for a while before being being dropped from the cluster. Basically
this one node seems to think it is someone else, whilst also behaviouring
as itself. The code and config is exactly the same on all 15 nodes so I
don't understand why I'm getting this issue on only one node. Maybe this is
a hardware issue?
Some logging:
11:27:45.412 INFO [main] Remoting - Starting remoting
11:27:45.638 INFO [main] Remoting - Remoting started; listening on
addresses :[akka.tcp://streaming@172.17.102.128:7000]
11:27:45.660 INFO [main] Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Starting up...
11:27:45.714 INFO [main] Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Registered cluster JMX MBean
[akka:type=Cluster]
11:27:45.715 INFO [main] Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Started up successfully
11:27:45.830 INFO [streaming-akka.actor.default-dispatcher-3]
a.a.LocalActorRef - Message
[akka.cluster.InternalClusterAction$InitJoinAck] from Actor[akka.tcp://
streaming@172.17.100.98:7000/system/cluster/core/daemon#1997515880] to
Actor[akka://streaming/system/cluster/core/daemon/joinSeedNodeProcess-1#1132911]
was not delivered. [1] dead letters encountered. This logging can be turned
off or adjusted with configuration settings 'akka.log-dead-letters' and
'akka.log-dead-letters-during-shutdown'.
11:27:45.872 INFO [streaming-akka.actor.default-dispatcher-5]
Cluster(akka://streaming) - Cluster Node [akka.tcp://
streaming@172.17.102.128:7000] - Welcome from [akka.tcp://
streaming@172.17.102.125:7000]
11:27:45.911 INFO [streaming-akka.actor.default-dispatcher-2]
Cluster(akka://streaming) - Cluster Node [akka.tcp://
streaming@172.17.102.128:7000] - Ignoring received gossip intended for
someone else, from [akka.tcp://streaming@172.17.102.68:7000] to
[UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)]
11:27:45.943 INFO [streaming-akka.actor.default-dispatcher-16]
Cluster(akka://streaming) - Cluster Node [akka.tcp://
streaming@172.17.102.128:7000] - Ignoring received gossip intended for
someone else, from [akka.tcp://streaming@172.17.102.70:7000] to
[UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)]
11:27:46.122 INFO [streaming-akka.actor.default-dispatcher-16]
Cluster(akka://streaming) - Cluster Node [akka.tcp://
streaming@172.17.102.128:7000] - Ignoring received gossip intended for
someone else, from [akka.tcp://streaming@172.17.102.69:7000] to
[UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)]
Config:
akka {
cluster {
seed-nodes = [
akka.tcp://streaming@172.17.102.125:7000
akka.tcp://streaming@172.17.100.98:7000
]
}
remote.netty.tcp.hostname = 172.17.102.128
}
I thought it was weird that the unique address in the gossip messages
referred to a negative number. I added log.info(smy unique ID:
${AddressUidExtension(actorSystem).addressUid}) to the confused node (I
hope this is the correct code) and it gave me the answer 1549799231,
whilst continuing to give -1482656725 in the gossip messages. I'm
guessing the problem is that the gossip messages have a corrupted address,
which is why the confused node believes these messages are not for itself.
I'm using Akka 2.3.2.
--
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
Re: [akka-user] Akka cluster: node identity crisis
On Wed, Jul 2, 2014 at 12:21 AM, Benjamin Black benblac...@gmail.com
wrote:
I upgraded to Akka 2.3.4 (scala 2.10), but still seeing the same issue.
When I log Cluster(system).selfUniqueAddress I get something
like UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,630715883),
with the last number changing everytime I restart.
Then it would be great if you could describe how to reproduce the problem.
Preferably using a minimal sample, such as the SimpleClusterListener
in the cluster
sample https://typesafe.com/activator/template/akka-sample-cluster-scala.
The gossip message error always has the same number -1482656725. For
example,
18:12:27.472 INFO [streaming-akka.actor.default-dispatcher-15]
Cluster(akka://streaming) - Cluster Node [akka.tcp://
streaming@172.17.102.128:7000] - Ignoring received gossip intended for
someone else, from [akka.tcp://streaming@172.17.110.143:7000] to
[UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)]
It is not an error to see a few of these while joining (especially when
joining several nodes at the same time), but if this logging continues
(never ends) something is wrong.
Negative uid should not be an issue. It is just a random integer that is
generated when the ActorSystem is started. The reason for using the uid is
to be able to differentiate new and old actor system on the same host:port
from each other when it is restarted.
Regards,
Patrik
On Tuesday, July 1, 2014 2:33:52 PM UTC-4, Patrik Nordwall wrote:
Please use latest version, i.e. 2.3.4
There you find Cluster(system).selfUniqueAddress that includes the uid.
I will look into this in more detail tomorrow.
/Patrik
1 jul 2014 kl. 19:57 skrev Benjamin Black benbl...@gmail.com:
I have a cluster of 15 nodes/boxes. I start the nodes roughly at the same
time. One of the nodes is behaving oddly and continually logging Ignoring
received gossip intended for someone else. However, the node does seem to
work for a while before being being dropped from the cluster. Basically
this one node seems to think it is someone else, whilst also behaviouring
as itself. The code and config is exactly the same on all 15 nodes so I
don't understand why I'm getting this issue on only one node. Maybe this is
a hardware issue?
Some logging:
11:27:45.412 INFO [main] Remoting - Starting remoting
11:27:45.638 INFO [main] Remoting - Remoting started; listening on
addresses :[akka.tcp://streaming@172.17.102.128:7000]
11:27:45.660 INFO [main] Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Starting up...
11:27:45.714 INFO [main] Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Registered cluster JMX
MBean [akka:type=Cluster]
11:27:45.715 INFO [main] Cluster(akka://streaming) - Cluster Node
[akka.tcp://streaming@172.17.102.128:7000] - Started up successfully
11:27:45.830 INFO [streaming-akka.actor.default-dispatcher-3]
a.a.LocalActorRef - Message [akka.cluster.InternalClusterAction$InitJoinAck]
from Actor[akka.tcp://streaming@172.17.100.98:7000/system/
cluster/core/daemon#1997515880] to Actor[akka://streaming/system/
cluster/core/daemon/joinSeedNodeProcess-1#1132911] was not delivered.
[1] dead letters encountered. This logging can be turned off or adjusted
with configuration settings 'akka.log-dead-letters' and
'akka.log-dead-letters-during-shutdown'.
11:27:45.872 INFO [streaming-akka.actor.default-dispatcher-5]
Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.
102.128:7000] - Welcome from [akka.tcp://streaming@172.17.102.125:7000]
11:27:45.911 INFO [streaming-akka.actor.default-dispatcher-2]
Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.
102.128:7000] - Ignoring received gossip intended for someone else, from
[akka.tcp://streaming@172.17.102.68:7000] to [UniqueAddress(akka.tcp://
streaming@172.17.102.128:7000,-1482656725)]
11:27:45.943 INFO [streaming-akka.actor.default-dispatcher-16]
Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.
102.128:7000] - Ignoring received gossip intended for someone else, from
[akka.tcp://streaming@172.17.102.70:7000] to [UniqueAddress(akka.tcp://
streaming@172.17.102.128:7000,-1482656725)]
11:27:46.122 INFO [streaming-akka.actor.default-dispatcher-16]
Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.
102.128:7000] - Ignoring received gossip intended for someone else, from
[akka.tcp://streaming@172.17.102.69:7000] to [UniqueAddress(akka.tcp://
streaming@172.17.102.128:7000,-1482656725)]
Config:
akka {
cluster {
seed-nodes = [
akka.tcp://streaming@172.17.102.125:7000
akka.tcp://streaming@172.17.100.98:7000
]
}
remote.netty.tcp.hostname = 172.17.102.128
}
I thought it was weird that the unique address in the gossip messages
referred to a negative number. I added log.info(smy unique ID:
Re: [akka-user] Ensuring Cancellable jobs stop
Hi Greg, On Tue, Jul 1, 2014 at 8:38 PM, tigerfoot gzol...@gmail.com wrote: Hello, I have a job that's scheduled with Scheduler and I save the Cancellable. The job isn't important, but it just sends a message to an Actor. After scheduling, it runs for a while and at some point I call cancel() on the Cancellable and need to ensure the job is actually done and won't fire again before continuing. What I'm finding is that cancel() on the Cancellable returns immediately and even looping/pausing on isCancelled doesn't ensure the job won't fire a few more times before finally stopping. (It runs once a second for my test purposes.) Is there a way I can ensure my cancelled job is completely done, never to fire again, before proceeding? (Nothing special, but code that schedules the job below): scheduledServices.put( svc.serviceId, server.system.scheduler.schedule( 5 seconds, 5 seconds, myActor, ExecuteTest(svc) ) ) If I understand your description correctly you schedule a message to be sent to an actor. What you might see is that a few such messages have already been sent when you call cancel, and they are queued in the mailbox of the actor, and will eventually be received by the actor. Would it be possible that the actor scheduled messages to itself instead? Then you can easier check when receiving the scheduled message if is is supposed to be processed or not. Somewhat related section in the documentation: http://doc.akka.io/docs/akka/2.3.4/scala/howto.html#scheduling-periodic-messages Regards, Patrik Thanks, Greg -- 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] Circuit breaker java documentation
Hello
I'm playing around with circuit breakers at the moment (having so much
fun). However the documentation at:
http://doc.akka.io/docs/akka/snapshot/common/circuitbreaker.html
makes me abit confused. What makes me confused are the following lines:
final FutureString f = future(
new CallableString() {
public String call() {
return dangerousCall();
}
}, getContext().dispatcher());
pipe(breaker.callWithCircuitBreaker(
new CallableFutureString() {
public FutureString call() throws Exception {
return f;
}
}), getContext().dispatcher()).to(getSender());
As I interpret this the future f will be run even if the circuit breaker is
open (which I guess is not what we want) since akka.dispatch.Futures.future
starts the computation regardless of the circuit breaker state. This would
in my mind mean that the returned result (piped to the sender) will still
fail fast but dangerousCall is still called and it's result ignored. If
dangerousCall would load some other service this could potentially be bad.
Would it not be better to move the future f inside callWithCircuitBreaker?
Best Regards
Måns Schultz
--
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] streams: Multiple subscriptions need to delay producer to read from start?
Is it possible to get more info on Duct? Understandably the docs are light (not yet provided); streams are still evolving and developing. I have been looking at the DuctSpec test cases and the source itself, Would like to see a more detailed Scaladoc with a couple more realistic examples and even an updated Activator Template. You know, when you guys have time. :) Thanks very much! Michael -- 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] Re: ANNOUNCE: First akka-http-core preview and updated akka-stream preview
Fixed! Thanks Michael. /Patrik On Wed, Jul 2, 2014 at 11:24 AM, Michael Pisula michael.pis...@googlemail.com wrote: Hey guys, great work =) You might want to link to the docs directly from the akka docs page, right now there is only the link to the APIs and the dependency information under the Akka Streams and HTTP section. Cheers, The Michael ;-) Am Freitag, 27. Juni 2014 11:44:08 UTC+2 schrieb Björn Antonsson: Dear Akka and Spray community, we are very happy and excited to release the first preview of Akka HTTP’s core module based on an updated preview of Akka Streams. It is the fruit of the collaboration between the Spray and Akka teams and aims to bring you fully reactive HTTP streams. - Both HTTP requests and responses can incorporate data that are streamed on demand, be that from disk or computed on the fly. - The HTTP streams as well as all the other streams, are fully back pressure aware, enabling the server to throttle clients when necessary, or vice versa. The Streams module now includes an expanded DSL for both Scala and Java, and the HTTP module has all the core functionality to build HTTP servers and clients, as well as a brand new Java API for the HTTP model. The request handling DSL equivalent to spray-routing will be part of a future release. This preview is intended to allow you to give feedback on the Java and Scala APIs. It is focused solely on functionality, in particular this means that performance is not yet on par with Spray. We will focus on performance enhancements once the functionality is complete. For more information on Reactive Streams, you are welcome to read the official Typesafe announcement https://typesafe.com/blog/typesafe-announces-akka-streams. The aim for both of these projects are to be back-released against Akka 2.3.x and therefore the code lives in the dedicated release-2.3-dev https://github.com/akka/akka/tree/release-2.3-dev branch in the akka repository. It will of course also be part of Akka 2.4, but that is going to be released only towards the end of the year, see the updated roadmap https://docs.google.com/document/d/18W9-fKs55wiFNjXL9q50PYOnR7-nnsImzJqHOPPbM4E/pub for more information. So please give them a spin. We welcome any and all feedback, preferably in pull request form ;). *Artifacts* sbt: com.typesafe.akka %% akka-http-core-experimental % 0.4 com.typesafe.akka %% akka-stream-experimental % 0.4 maven scala 2.10: com.typesafe.akka akka-http-core-experimental_2.10 0.4 com.typesafe.akka akka-stream-experimental_2.10 0.4 maven scala 2.11: com.typesafe.akka akka-http-core-experimental_2.11 0.4 com.typesafe.akka akka-stream-experimental_2.11 0.4 *Documentation* http://doc.akka.io/docs/akka-stream-and-http-experimental/0.4/ http://doc.akka.io/api/akka-stream-and-http-experimental/0.4/ http://doc.akka.io/japi/akka-stream-and-http-experimental/0.4/ Regards, Björn -- *Björn Antonsson* Typesafe http://typesafe.com/ – Reactive Apps on the JVM twitter: @bantonsson http://twitter.com/#!/bantonsson -- 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] Akka cluster: node identity crisis
Problem resolved. I was running two clusters (dev and prod) and somehow (the mystery remains) the dev cluster was interacting with this one box in the prod cluster. My advice to anyone else who sees this issue is to check the IP addresses of the from nodes. On Wednesday, July 2, 2014 4:31:32 AM UTC-4, Patrik Nordwall wrote: On Wed, Jul 2, 2014 at 12:21 AM, Benjamin Black benbl...@gmail.com javascript: wrote: I upgraded to Akka 2.3.4 (scala 2.10), but still seeing the same issue. When I log Cluster(system).selfUniqueAddress I get something like UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,630715883), with the last number changing everytime I restart. Then it would be great if you could describe how to reproduce the problem. Preferably using a minimal sample, such as the SimpleClusterListener in the cluster sample https://typesafe.com/activator/template/akka-sample-cluster-scala . The gossip message error always has the same number -1482656725. For example, 18:12:27.472 INFO [streaming-akka.actor.default-dispatcher-15] Cluster(akka://streaming) - Cluster Node [akka.tcp:// streaming@172.17.102.128:7000] - Ignoring received gossip intended for someone else, from [akka.tcp://streaming@172.17.110.143:7000] to [UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)] It is not an error to see a few of these while joining (especially when joining several nodes at the same time), but if this logging continues (never ends) something is wrong. Negative uid should not be an issue. It is just a random integer that is generated when the ActorSystem is started. The reason for using the uid is to be able to differentiate new and old actor system on the same host:port from each other when it is restarted. Regards, Patrik On Tuesday, July 1, 2014 2:33:52 PM UTC-4, Patrik Nordwall wrote: Please use latest version, i.e. 2.3.4 There you find Cluster(system).selfUniqueAddress that includes the uid. I will look into this in more detail tomorrow. /Patrik 1 jul 2014 kl. 19:57 skrev Benjamin Black benbl...@gmail.com: I have a cluster of 15 nodes/boxes. I start the nodes roughly at the same time. One of the nodes is behaving oddly and continually logging Ignoring received gossip intended for someone else. However, the node does seem to work for a while before being being dropped from the cluster. Basically this one node seems to think it is someone else, whilst also behaviouring as itself. The code and config is exactly the same on all 15 nodes so I don't understand why I'm getting this issue on only one node. Maybe this is a hardware issue? Some logging: 11:27:45.412 INFO [main] Remoting - Starting remoting 11:27:45.638 INFO [main] Remoting - Remoting started; listening on addresses :[akka.tcp://streaming@172.17.102.128:7000] 11:27:45.660 INFO [main] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.102.128:7000] - Starting up... 11:27:45.714 INFO [main] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.102.128:7000] - Registered cluster JMX MBean [akka:type=Cluster] 11:27:45.715 INFO [main] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17.102.128:7000] - Started up successfully 11:27:45.830 INFO [streaming-akka.actor.default-dispatcher-3] a.a.LocalActorRef - Message [akka.cluster.InternalClusterAction$InitJoinAck] from Actor[akka.tcp://streaming@172.17.100.98:7000/system/ cluster/core/daemon#1997515880] to Actor[akka://streaming/system/ cluster/core/daemon/joinSeedNodeProcess-1#1132911] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. 11:27:45.872 INFO [streaming-akka.actor.default-dispatcher-5] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17. 102.128:7000] - Welcome from [akka.tcp://streaming@172.17.102.125:7000] 11:27:45.911 INFO [streaming-akka.actor.default-dispatcher-2] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17. 102.128:7000] - Ignoring received gossip intended for someone else, from [akka.tcp://streaming@172.17.102.68:7000] to [UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)] 11:27:45.943 INFO [streaming-akka.actor.default-dispatcher-16] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17. 102.128:7000] - Ignoring received gossip intended for someone else, from [akka.tcp://streaming@172.17.102.70:7000] to [UniqueAddress(akka.tcp://streaming@172.17.102.128:7000,-1482656725)] 11:27:46.122 INFO [streaming-akka.actor.default-dispatcher-16] Cluster(akka://streaming) - Cluster Node [akka.tcp://streaming@172.17. 102.128:7000] - Ignoring received gossip intended for someone else, from [akka.tcp://streaming@172.17.102.69:7000] to
[akka-user] question about UntypedPersistentActor
Hi All,
I do not very understand the UntypedPersistentActor. I have 2 questions
*question 1*: we have to overide the method persistenceId. It can return
any String value, but must be unique, right?
@Override
public String persistenceId() {
return test-id-1;
}
*question 2*: I have the below test code. When throws exception in the
actor(refer to the red color code), I believe the variable dataList will be
recovered.
But I debugged the code, the dataList wasn't revocered. *Did I miss
anything?*
public class DemoAggregatorActor extends UntypedPersistentActor {
private ListString dataList = new ArrayListString(100);
@Override
public void onReceiveRecover(Object msg) {
if (msg instanceof String) {
dataList.add((String)msg);
} else {
unhandled(msg);
}
}
@Override
public void onReceiveCommand(Object message) throws Exception {
dataList.add(test);
if(dataList.size()10){
*throw new Exception();*
}
}
}
--
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.
