I see,
but why ForwardingActor is not matched?
Another question - imagine that I have some different paths and I only
care about finding a leaf, like this:
/user/someActor/someotheActor/*someImportantActor*
I have *someImportantActor* known and don't care about it's parents - is
it possible to
hi, in my test system I have 2 processors, A, and B. In the logs below
reflects this message flow:
*Send persistent message DoDepositCash to A*
*Send persistent message DoSubmitOrder to A,*
*A receives DoSubmitOrder message and yields OrderCashLocked to a channel X
and delivers to B*
*B
On Tue, Mar 18, 2014 at 7:12 PM, Rob S rms...@gmail.com wrote:
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
You're welcome. Anyway, I have created a ticket for the hot standby
processor: https://www.assembla.com/spaces/akka/tickets/3938
That doesn't mean that we will implement it, but we will take it into
consideration.
Thanks for the feedback.
Cheers,
Patrik
On Tue, Mar 18, 2014 at 8:52 PM, Eduardo
On Wed, Mar 19, 2014 at 7:37 AM, Anatoliy Kaverin a.kave...@gmail.comwrote:
I see,
but why ForwardingActor is not matched?
What do you mean?
You will get 2 ActorIdentity replies, one matching and one not matching.
If you are thinking about the deadletter String I guess it is similar if
you
Does the following answer your question?
If a processor emits more than one outbound message per inbound
Persistent message
it *must* use a separate channel for each outbound message to ensure that
confirmations are uniquely identifiable, otherwise, at-least-once message
delivery semantics do not
Hi Rohit,
19 mar 2014 kl. 01:36 skrev Rohit Gupta greatroh...@gmail.com:
Hi Roland,
you mention a “potential leak” and “getting similar stack traces”. How and
why exactly are these stack traces emitted? Due to a crash?
These stack traces were seen in thread dumps when the application
Thanks for the new ticket!
This kind of behavior is extremely useful in some cases. In our case we're
moving huge Redis/HBase structures to multiple java/scala maps and the
result is thousand of times faster and simple and faster to implement. We
think, after reading the docs, that Akka is a
Hi Anatoliy,
in general it is much easier to reason about the system if you explicitly
introduce the actors to each other instead of relying on String-based lookups
(which tie down your hierarchy as you now learnt). You can do that by passing
an ActorRef to the constructor of a new actor or
Thanks for your help.
I found a way to resolve my problem.
On Wednesday, March 19, 2014 11:15:01 AM UTC+2, rkuhn wrote:
Hi Anatoliy,
in general it is much easier to reason about the system if you explicitly
introduce the actors to each other instead of relying on String-based
lookups
I see,
thanks for replies!!!
It looks I didn't really get how wildcard actor selection look up works,
but now I got a clear picture.
I have loosely coupled Actors, some of them are dynamic and later addressed
by already existing ones. So, sending ActorRef is not an option.
Original problem I've
Hi Anatoliy,
19 mar 2014 kl. 12:49 skrev Anatoliy Kaverin a.kave...@gmail.com:
I see,
thanks for replies!!!
It looks I didn't really get how wildcard actor selection look up works, but
now I got a clear picture.
I have loosely coupled Actors, some of them are dynamic and later addressed
Patrik, I'll try to provide a test for you :) Thank you for looking into
this.
On Wednesday, March 19, 2014 9:54:19 PM UTC+8, Patrik Nordwall wrote:
Hi Daniel,
That looks strange. I tried to reproduce it, but couldn't. Please provide
a minimized sample/test that we can run.
Regards,
Patrik, I forgot to mention that the actorPath of my channel destination is
actually the path of a cluster-aware router who knows where exactly the
remote target processor is. Maybe that's the cause?
On Wednesday, March 19, 2014 9:54:19 PM UTC+8, Patrik Nordwall wrote:
Hi Daniel,
That
Hi Martin,
I have a process that is running since last Sunday evening using the above
code base(Given
herehttp://stackoverflow.com/questions/22315418/akka-persistentchannel-does-not-delete-message-from-journal-upon-confirm)
. The journal space has grown to be around 24 GB so far. I am still
Thanks Patrik for the reply. For some reason I thought it used the java
version. Good to know though its only intended for testing.
Eric
On Wednesday, March 19, 2014 1:47:15 AM UTC-7, Patrik Nordwall wrote:
On Wed, Mar 19, 2014 at 5:00 AM, Eric Weise ewe...@gmail.comjavascript:
wrote:
Hey everyone!
I've been reading through the akka docs, looking at some of the example
projects, and am interested in how it might help me run a large scale
wildlife simulation. Without elaborating too much, I'd like to simulate a
massive world that potentially is scalable across machines, with
Hi,
I'm using the settings below for a multi-jvm test. After upgrading to
Akka-2.3.0,
I got an error stating that I needed to define the *multinode.max-nodes *
system property.
I added that below and now it works when I run sbt multi-jvm:test, but I
can't figure out how to add the setting
so
Correction: The *multinode.max-nodes *property does not need to be set if
sbt multi-jvm:test is run, but if I run sbt test, I get:
java.lang.IllegalStateException: need system property
multinode.max-nodes to be set
On Wednesday, March 19, 2014 10:29:13 PM UTC+1, Allan Brighton wrote:
Hi all.
We have a system where we've implemented a pipeline strategy as follows:
1) If the number of messages pending for all actors to a remote host is
more than N we flush the message queue to the net
2) If the total number of blocked threads waiting for reading is more then
N we flush the
I missed the live, is this going to be available on Yotube?
--
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
21 matches
Mail list logo
