Hi, Heiko,
Thanks a lot for the response.I saw that in the manual (java
though,
http://doc.akka.io/docs/akka/2.3.2/java/untyped-actors.html#actorselection-java),
but couldn't understand what exactly is happening. The sample code of
class Follower does not have any comment, and does not
Hi guys,
The problem confused me one day. I found that when the client actor has
remotely connected with the server actor, the server actor can not remotely
call the client again. Is that true? Based on my observation, only sender
in server actor can send the message back to the client.
On Thu, Apr 10, 2014 at 2:17 PM, Roland Kuhn goo...@rkuhn.info wrote:
It is slightly inconsistent, though: consider
/a/*/c
- if a does not exist, we reply
- if it has no children, we don't reply
- if one of its children has no `c` then we reply
I think we should send
Liang,
This is not true: Akka is location transparent. Therefore it doesn't matter
where (locally, remotely) your actor lives, all will work the same way.
Heiko
On Fri, Apr 11, 2014 at 6:07 AM, Liang Tang liang.x...@gmail.com wrote:
Hi guys,
The problem confused me one day. I found that
I was specifically talking about wildcards at the end-position.
Perhaps this problem is better solved with some kind of stream-thing rather
than a Future?
On Fri, Apr 11, 2014 at 9:33 AM, Patrik Nordwall
patrik.nordw...@gmail.comwrote:
On Thu, Apr 10, 2014 at 2:17 PM, Roland Kuhn
11 apr 2014 kl. 09:33 skrev Patrik Nordwall patrik.nordw...@gmail.com:
On Thu, Apr 10, 2014 at 2:17 PM, Roland Kuhn goo...@rkuhn.info wrote:
It is slightly inconsistent, though: consider
/a/*/c
if a does not exist, we reply
if it has no children, we don’t reply
if one of its
Yes, we are talking about two different things at the same time here. I’d
prefer to solve the lower level inconsistency first, and then think about the
higher level feature. Using a stream thing sounds interesting …
Regards,
Roland
11 apr 2014 kl. 09:56 skrev √iktor Ҡlang
On Fri, Apr 11, 2014 at 9:57 AM, Roland Kuhn goo...@rkuhn.info wrote:
11 apr 2014 kl. 09:33 skrev Patrik Nordwall patrik.nordw...@gmail.com:
On Thu, Apr 10, 2014 at 2:17 PM, Roland Kuhn goo...@rkuhn.info wrote:
It is slightly inconsistent, though: consider
/a/*/c
- if a does not
Hi,
The akka-sbt-plugin has been removed and you should take a look at the
sbt-native-packager. The old plugin (2.2.x) should also be usable with newer
versions of akka as explained in the akka migration guide.
B/
On 10 April 2014 at 23:25:22, ahjohannessen (ahjohannes...@gmail.com) wrote:
Try googling for some code snippets: http://lmgtfy.com/?q=akka+ActorIdentity
Some results:
http://stackoverflow.com/a/18015626/77102
http://letitcrash.com/post/55504766698/2-2-spotlight-actorselection-watch-and-identify
On Fri, Apr 11, 2014 at 6:52 AM, Atom Cong hotat...@gmail.com wrote:
Hi,
Thanks for your answers, it makes perfect sense now. Although I am a
little disappointed as this means my goal of abstracting a common restart
pattern into into a separate actor is fruitless. However I will look for
another approach.
On Thursday, 10 April 2014 13:25:48 UTC+1, √ wrote:
Hello,
I get strange error while sending message on remote node (see Error.txt in
attach).
Also in attach. is picture of basic architecture I'm using and dependencies.
How is package made: sbt console dist (it will make one jar file which
constains all classes and resource files)
How do I
On Friday, 11 April 2014 10:35:46 UTC+1, Iain Hull wrote:
However I will look for another approach.
I think I have found a clean way to inject the DeathReportActor code into a
parent actor. I have made this actor a trait and renamed it to
ChildMonitor. I would be very grateful if someone
Viktor, of course locally we always code first then measure and optimize.
However in this case, I am trying to figure what is a good architecture
choice. For example, without knowing that EventBus is limited to one jvm, I
could have chosen to use that and then later have to rewrite my code
Hello,
We are trying to evaluate using Akka persistence to use going forward in
our new platform. It seems to us that views could be a very powerful way to
do some of the things we need to do but it can only act on one stream of
events. An interesting feature, I think, would be to have a view
It seems to be infrastructure related. Can you reproduce this on different
machines? If so, can you pack a simple example that does this and share it
with us?
--
Martynas Mickevičius
Typesafe http://typesafe.com/ – Reactivehttp://www.reactivemanifesto.org/
Apps
on the JVM
--
Read the
Chanan,
that's a good strategy. I normally recommend to always have 2-3 different
solutions to the problem so one does not accidentally go with the worst
possible.
On Fri, Apr 11, 2014 at 12:53 PM, Chanan Braunstein
chanan.braunst...@pearson.com wrote:
Viktor, of course locally we always code
Also, were there GC pauses? Did the threads get CPU time? Are the clocks
synced?
On Fri, Apr 11, 2014 at 1:59 PM, Martynas Mickevičius
martynas.mickevic...@typesafe.com wrote:
It seems to be infrastructure related. Can you reproduce this on different
machines? If so, can you pack a simple
I have found the solution. I had to add configuration for serializers.
akka {
actor {
serializers {
java = akka.serialization.JavaSerializer
proto = akka.remote.serialization.ProtobufSerializer
#myown = docs.serialization.MyOwnSerializer
}
serialization-bindings {
This In-Memory journal might be used as inspiration:
https://github.com/michaelpisula/akka-journal-inmemory
Cheers,
Patrik
On Tue, Apr 8, 2014 at 12:25 PM, Carsten Saathoff
cars...@kreuzverweis.comwrote:
Hi,
I am currently trying to figure out a good way to test an eventsourced
processor,
For the record, the issues listed here were fixed in Akka 2.3.2.
Thanks for your help finding and narrowing down the issues.
Cheers,
Patrik
On Thu, Apr 3, 2014 at 8:42 AM, Patrik Nordwall
patrik.nordw...@gmail.comwrote:
On Wed, Apr 2, 2014 at 10:23 PM, Patrik Nordwall
I'm using the latest release of Akka (2.3.2) and I've been playing around
with the Tcp Api a bit, trying to get familiar with how it works. In doing
so, I've been writing a little Memcached binary client. This usage of Tcp
is a little different then the examples in the docs in that the
The problem is still confusing me.
MachineB is able to periodically send messages to MachineA, and it works
well.
However, when Machine A initiated a connection with MachineB, there always
exists something wrong. MachineA seems working very good when observing log.
Machine B received this
Hi, been having great luck with Akka so far but I can't figure this one out.
I have a JVM app with two actor systems, let's call them AS and BS. AS is
created first. I also have a remote actor system called RS in another JVM.
AS sending messages to RS is no problem and RS can reply using the
All your ActorSystems need to use Remoting. I don't see anywhere in your
post where you explain what RS has in terms of config.
On Sat, Apr 12, 2014 at 12:06 AM, Curtis Stanford
cur...@stanfordcomputing.com wrote:
Hi, been having great luck with Akka so far but I can't figure this one
out.
They all use this. Internally, I set the IP and port of RS depending on
command line parms. I assume you mean the akka.actor.provider =
akka.remove.RemoteActorRefProvider part?
akka {
log-dead-letters = on
log-dead-letters-during-shutdown = off
loglevel = INFO
actor {
How do they learn of eachother if all of their interfaces and ports are
random?
On Sat, Apr 12, 2014 at 12:53 AM, Curtis Stanford
cur...@stanfordcomputing.com wrote:
They all use this. Internally, I set the IP and port of RS depending on
command line parms. I assume you mean the
I was trying to simplify it but there is another server MS at a known port
that RS registers at. I guess my main question is, should this work? I
assume at some point the BS actors ActorRef gets converted from local to
remote. Somewhere on the trip, it gets converted to an actor in AS even
I have no idea what Somewhere on the trip, it gets converted to an actor
in AS even though it's own context points to the BS actor system. means,
I'm afraid.
There are a couple of invariants that need to be enforced:
a) the hostname needs to be reachable (127.0.0.1 is a local address, so it
OK, in general when sending a message to a remote actor, the self reference
(which is local) needs to be converted to a remote reference (i.e.
akka.tcp://bs@127.0.0.1:64002/user/b) so the remote actor has something it
can respond to via the sender() call. I think it's doing it wrong when two
On Sat, Apr 12, 2014 at 1:43 AM, Curtis Stanford
cur...@stanfordcomputing.com wrote:
OK, in general when sending a message to a remote actor, the self
reference (which is local) needs to be converted to a remote reference
(i.e. akka.tcp://bs@127.0.0.1:64002/user/b) so the remote actor has
Ahhh, I didn't think of that. Not sure that's the problem but it gives me
something to look into.
Thanks very much!
On Friday, April 11, 2014 5:47:22 PM UTC-6, √ wrote:
On Sat, Apr 12, 2014 at 1:43 AM, Curtis Stanford
cur...@stanfordcomputing.com javascript: wrote:
OK, in general when
If I got a remote ActorRef from RS in one actor system, could I use it in
another actor system?
On Friday, April 11, 2014 5:49:47 PM UTC-6, Curtis Stanford wrote:
Ahhh, I didn't think of that. Not sure that's the problem but it gives me
something to look into.
Thanks very much!
On
Yah, that was the problem. Apparently, I can't share even remote actor refs
between systems. Solved it by sharing the actor path instead and using
context.actorSelection(path)
Thanks for all your help.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
34 matches
Mail list logo
