The serialized messages you see are sent between local actors and don't
need efficient serialization. The only reason they are serialized is that
you run with:
akka.actor.serialize-messages = on
That is only intended for testing.
/Patrik
On Tue, Mar 18, 2014 at 4:01 AM, Daniel Wang
My custom serialization object with remoting works without a problem. The
NotSerializableException is thrown when adding ReliableProxy.
val proxy = context.system.actorOf(Props(classOf[ReliableProxy], remoteRef,
100.millis), proxy)
// remoteRef ! customSerializedObject // - this works fine,
Hi,
I am getting the below exception from time to time and have no idea how to
get rid of it. I have only reconfigured the journal plugin, but not
modified anything related to the snapshot store.
Any ideas?
thanks
Carsten
11:23:37.614 [kiarchive-akka.actor.default-dispatcher-19] ERROR
Hi All.
First of all many thanks for so efficient library. Very good job!
We're analyzing Akka to support a cluster of heavy objects (a single actor
could have a couple of gigs in RAM). I'm wondering if I could use some kind
of 'preloaded' in ram slave actor that could be used if the 'master
Here is the output from System A:
This is after a connection is made and the first request is processed
07:12:52.133 [WorkServerSystem-akka.actor.default-dispatcher-218] DEBUG
a.s.Serialization(akka://WorkServerSystem) - Using
serializer[akka.serialization.JavaSerializer] for message
Hi again,
I actually figured out that the journal plugin jar was not in the classpath
on that node. After having added it, the error is gone. So I assume it was
somehow related to that. However, there should probably be a more explicit
exception when the plugin is not available.
best
Carsten
On Tue, Mar 18, 2014 at 12:22 PM, Carsten Saathoff cars...@kreuzverweis.com
wrote:
Hi again,
I actually figured out that the journal plugin jar was not in the
classpath on that node. After having added it, the error is gone. So I
assume it was somehow related to that. However, there should
On Tue, Mar 18, 2014 at 12:20 PM, Rob S rms...@gmail.com wrote:
Here is the output from System A:
This is after a connection is made and the first request is processed
07:12:52.133 [WorkServerSystem-akka.actor.default-dispatcher-218] DEBUG
a.s.Serialization(akka://WorkServerSystem) - Using
Hi,
done: https://www.assembla.com/spaces/akka/tickets/3935#/activity/ticket:
best
Carsten
Am Dienstag, 18. März 2014 12:37:26 UTC+1 schrieb Patrik Nordwall:
On Tue, Mar 18, 2014 at 12:22 PM, Carsten Saathoff
car...@kreuzverweis.com javascript: wrote:
Hi again,
I actually figured out
Greetings,
I've been using Akka in my Java based backend and faced some issue related
to ActorSelection API if it is used from ActorContext (from inside Actor).
For some reason I cannot find existing Actors via Identify message for
specific paths.
Imagine, that I have such Actor hierarchy:
USER
First I just want to thank you for attempting to help me with my issue.
Now I have tried to work with the examples you linked and here are my
results:
Scenario 1:
I ran akka-sample-remote-java]$ ./activator run-main
sample.mote.calculator.CreationApplication CalculatorWorker and
CreationApplication is using remote deployed actors. I got the impression
that you are not using that in your original application.
What you are saying is that you see completely different behavior when you
run on one machine compared to two separate machines? Any firewall
in-between? Are the
The wildcard in /user/*/ChildActor will match 2 actors,
both ChildCreationActor and LookingActor. The second path will not match
and you get ActorIdentity with ref null. The first path will match your
expected ChildActor. You will receive two ActorIdentity but you happen to
use only the first. The
Hi,
On Tue, Mar 18, 2014 at 11:45 AM, Eduardo Fernandes edu...@gmail.comwrote:
Hi All.
First of all many thanks for so efficient library. Very good job!
We're analyzing Akka to support a cluster of heavy objects (a single actor
could have a couple of gigs in RAM). I'm wondering if I could
Patrik -- great suggestions, thank you.
On Tuesday, March 18, 2014 4:18:31 AM UTC-4, Patrik Nordwall wrote:
Looks good. If Play 2 is unreachable you might introduce unwanted latency.
You can consider replicating to more than one, or start the insert
immediately and if that is quicker than
Is the problem because I can't reconnect? When I kill the connection
between two remotes on one side I can't reestablish the same connection (ip
and port). Would I need to restart the apps on both systems to resort
communications?
Rob
On Monday, March 17, 2014 3:42:01 PM UTC-4, Rob S wrote:
Many thanks Patrik for your post. Good shot.
We could consider sending commands simultaneously to two processors (the
main and a standby) and in case of timeout talking to the first we could
talk to the second. After the main recovering we could return to the
original situation. Maybe we could
I noticed that there is a java version of Leveldb included as the default
persistence support for Akka. Is this recommended for production? Anyone
have experience using it in production?
Thanks
Eric Weise
--
Read the docs: http://akka.io/docs/
Check the FAQ:
18 matches
Mail list logo
