[akka-user] Re: Akka OSGI renewed
Hello, thanks for your responses. @Roman: There is no problem with the example on github. I haven't tried running it, but I took inspiration from it to set up Akka in my container. My question is in fact a state of the union question. What I was after was whether some work has already been done on some kind of Akka-fied API to OSGi itself. perhaps [1] gives you the best impression of what I was looking for. @Ian: Sounds like you are targeting the same software stack that intend to use. Happy to stay in touch if you are interested. [1] https://github.com/woq/de.woq.osgi.java/blob/master/de.woq.osgi.akka.system/src/test/scala/de/woq/osgi/akka/system/internal/OSGIServiceTrackerSpec.scala Best 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-user] Has anyone tried akka-persistence on Android?
My co-worker is struggling (it's probably proguard) and it would be useful to know if somebody had succeeded. -- 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] Has anyone tried akka-persistence on Android?
Hi Tim, what error message do you see? On 25.04.14 09:38, Tim Pigden wrote: My co-worker is struggling (it's probably proguard) and it would be useful to know if somebody had succeeded. -- 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 mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto: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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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] Has anyone tried akka-persistence on Android?
Hi Martin Unfortunately I don't have his code (he's inn a different Timezone and I only got email last night) but his stack trace http://pastebin.com/uHqwWYbJ so it looks like there's some reason it can't find the akka.persistence.DeliveredByChannelBatching constructor. I'll get him to add further info here as soon as he comes on line. On 25 April 2014 09:06, Martin Krasser krass...@googlemail.com wrote: Hi Tim, what error message do you see? On 25.04.14 09:38, Tim Pigden wrote: My co-worker is struggling (it's probably proguard) and it would be useful to know if somebody had succeeded. -- 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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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/qaBSx6sJH2Y/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. -- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -- 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: Patterns for 'Bootstrapping' and routing/selection of Eventsourced Processors
and the cluster sharding that Michael mentions is documented here: http://doc.akka.io/docs/akka/2.3.2/contrib/cluster-sharding.html On Fri, Apr 25, 2014 at 8:49 AM, delasoul michael.ham...@gmx.at wrote: yes that's how we have done it before using cluster sharding - per processor type e.g.: Account we had a CommandHandler e.g.: AccountCommandHandler which was responsible to create and route: val account = context.child(accountId) getOrElse createAccountProcessor(accountId) account forwardMsg cmd hth, michael On Thursday, 24 April 2014 15:55:52 UTC+2, erich oliphant wrote: Hi, I'm playing around with akka-persistence, and one thing that's not clear to me is the best way to 1) Handle the command that might create an instance of a particular event processor (e.g. CreateOrder(...)) 2) Route commands to the proper instance of the created eventsourced processor (e.g. SubmitOrderForProcessing(id:27,...)) I've not seen anything in the examples, etc that handles this particular case. Any suggestions for a 'command gateway/handler' or something patterns that might be the a way to approach this? -- 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 JOIN US. REGISTER TODAY! http://www.scaladays.org/ Scala http://www.scaladays.org/ Days http://www.scaladays.org/ June 16th-18th, http://www.scaladays.org/ Berlin http://www.scaladays.org/ -- 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] Has anyone tried akka-persistence on Android?
Hi Martin, When I get hold of him I intend to ensure we can run a simple test program in both standard environment before re-testing on Android. I can see the DeliveredByChannelBatching is part of the standard start-up process and there's no obvious reason the constructor should be missing. From what little I know of Android development, the culprit in these cases is usually Proguard being over-enthusiastic about pruning stuff it thinks is not required. If we can get a simple test program working I'll make sure we make it available. Personally I think the eventsource model is an excellent way of overcoming the problems associated with mobile applications being randomly stopped and restarted, either due to the Android OS kicking them out or users powering on and off. On 25 April 2014 12:48, Martin Krasser krass...@googlemail.com wrote: On 25.04.14 10:41, Tim Pigden wrote: Hi Martin Unfortunately I don't have his code (he's inn a different Timezone and I only got email last night) but his stack trace http://pastebin.com/uHqwWYbJ so it looks like there's some reason it can't find the akka.persistence.DeliveredByChannelBatching constructor. Hmm, this constructor actually exists. I'll get him to add further info here as soon as he comes on line. Yes please. I'd also like to know: Have you tried running it on other platforms? What Akka version do you use? On 25 April 2014 09:06, Martin Krasser krass...@googlemail.com wrote: Hi Tim, what error message do you see? On 25.04.14 09:38, Tim Pigden wrote: My co-worker is struggling (it's probably proguard) and it would be useful to know if somebody had succeeded. -- 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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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/qaBSx6sJH2Y/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. -- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -- 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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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
[akka-user] Initialize global variable during actor initialization?
Hi, all
I'm a newbie to akka, I have a question on the initialization process of
akka
My question comes from the following scenario
class A {
val workerActor: ActorRef = _
val supervisorActor: ActorRef = actorOf(Props[B])
def work() {workerActor ! message} //NPE line
}
class B {
val supervisorStrategy = ...
def receive = {...}
workerActor = context.actorOf(...) //buggy line
}
it seems that the buggy line is executed in another thread (I think it's
true, as I found actorOf is non-blocking since akka 2.1), so sometimes I
will meet a NPE when the work() is called before B is fully started
What I want is to block A's constructor thread until workerActor is not null
I can send a message to supervisorActor in a blocking way and returns a
ActorRef from the supervisor in A's constructor, but it seems that I have
to define a timeout Value on that blocking operationwhich may involve
some hard-coding
The other option includes busy loop in A's constructor...but it's obviously
not a first option
I also saw this https://gist.github.com/viktorklang/856818, but I'm not
sure if it is what I want
Any suggestion is highly appreciated!
Best,
Nan
--
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] testing akka cluster on Blue Waters @ NCSA
Boris, you should try the timestamped snapshot 2.3-20140425-151510 that is published to repo http://repo.akka.io/snapshots/ It is supposed to handle bursts of many messages without (much) degraded throughput or false failure detection. More details here: https://groups.google.com/d/msg/akka-dev/mFvz_d737t4/pZSmbFRLAV8J Regards, Patrik On Mon, Mar 24, 2014 at 5:00 PM, √iktor Ҡlang viktor.kl...@gmail.comwrote: Nice! On Mon, Mar 24, 2014 at 4:55 PM, Boris Capitanu bor...@gmail.com wrote: Anyway, one thing to try is to set akka.remote.backoff-interval to a larger value while setting the send-buffer-size to 1024000b. I would try with backoffs 0.5s and 1s. While 1s is not a very good setting, it is a good way to test our hypothesis. I've used the backoff-interval = 0.5s and send-buffer-size=1024000b and I do see the timings becoming more consistent (albeit worse). The standard deviation of the timings observed is much lower. Well - I think we narrowed down the issue. I'll wait for a fix... I'll be glad to test any nightly builds that include a fix if it would be helpful. -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. -- Cheers, √ * ——— **Viktor Klang* *Chief Architect - **Typesafe http://www.typesafe.com/* Twitter: @viktorklang -- 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 JOIN US. REGISTER TODAY! http://www.scaladays.org/ Scala http://www.scaladays.org/ Days http://www.scaladays.org/ June 16th-18th, http://www.scaladays.org/ Berlin http://www.scaladays.org/ -- 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: Akka OSGI renewed
Andreas -- Dinning Hakkers and the related code in Akka was the main result of the effort you referenced in your first post. I don't believe there is much ongoing effort for Akka and OSGi right now. However, I would suggest posting on akka-dev if you'd like to propose enhancements like the Akka API to OSGi that you mentioned, along with a summary of the benefits that you see from that approach. I, for one, would be interested in learning more. Regards, Raman On Friday, April 25, 2014 2:42:49 AM UTC-4, Andreas Gies wrote: Hello, thanks for your responses. @Roman: There is no problem with the example on github. I haven't tried running it, but I took inspiration from it to set up Akka in my container. My question is in fact a state of the union question. What I was after was whether some work has already been done on some kind of Akka-fied API to OSGi itself. perhaps [1] gives you the best impression of what I was looking for. @Ian: Sounds like you are targeting the same software stack that intend to use. Happy to stay in touch if you are interested. [1] https://github.com/woq/de.woq.osgi.java/blob/master/de.woq.osgi.akka.system/src/test/scala/de/woq/osgi/akka/system/internal/OSGIServiceTrackerSpec.scala Best 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-user] Re: Strange behavior with Akka Tcp
Hi Patrick. I will try and boil this down to something much simpler before taking out a ticket. Thanks for looking into it for me. Yes, I'm just starting to familiarize myself with the new Akka reactive streams api. This is just a prototype to get myself familiar with the inner workings of the core IO stuff. I'm really waiting for reactive streams to come out and then I plan on building on top of that as it will be much cleaner and simpler. On Friday, April 11, 2014 2:32:37 PM UTC-4, Chris Baxter wrote: 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 connection is kept alive and never closed (unless the peer closes the connection in which a reconnect will happen). In my little prototype, I'm using the Ack based back-pressure solution. I also recently switched to pullMode for reads because I found that when I didn't, so many reads were coming when I was hammering it with load that it took forever to receive the write ack thus delaying the next write and slowing throughput down. When I switched to pullMode, things sped up, but now I'm running into a strange issue where I eventually do not receive an Ack for one of the writes that I made which pretty much kills the flow as it's the acks that keep data flowing from my memcached node actor into the connection actor. I enabled trace logging and more often then not, when this happens, I see this is the log as the last log message from the selection handler: [DEBUG] [04/11/2014 14:11:02.281] [couch-akka.actor.default-dispatcher-22] [akka://couch/system/IO-TCP/selectors/$a/0] Wrote [0] bytes to channel I can post my code if need be, but I just wanted to first see if anyone else has ever seen this behavior. -- 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] Initialize global variable during actor initialization?
Okay -- the key problem is that you have to remember that *everything*
involving Actors is asynchronous. You're not allowed to make any
assumptions about what happens when.
So take a look at your code. Main creates A. A **begins** to create
supervisorActor -- but that will happen *someday*, not immediately. You
get the ActorRef back immediately, but doesn't say anything about when the
Actor *itself* gets created and initialized. That takes time -- truth to
tell, I'm surprised you only sometimes get a NPE, since I would have
expected it to almost always happen.
More importantly, the line
aInstance.workerActor = context.actorOf(Props(new WorkerActor))
violates one of the cardinal rules of Akka -- Actors should be
self-contained. An Actor should not modify state outside itself. (And
anything outside the Actor *must* not ever modify the Actor's state.) So
while this isn't *quite* strictly illegal, it's highly frowned upon.
Personally, I would probably hide workerActor completely inside B (the
supervisorActor), and would route messages to workerActor through the
supervisor, something like this:
class MainClass {
val aInstance = new A()
def submitJob {aInstance.submitJob()}
}
class A {
val supervisorActor: B = MainClass.env.system.actorOf(Props(new B))
def submitJob() {
supervisorActor! JobSubmitted // Now it won't NPE, because you are using
the Actor you built synchronously
}
}
class B {
val myWorker = context.actorOf(Props(new WorkerActor))
def receive = {
// This won't happen until after myWorker's ActorRef has been
created, and the Supervisor is ready to pass the message on:
case msg:JobSubmitted = myWorker.forward(msg)
}
}
That produces better separation of concerns -- for example, the supervisor
can decide to spawn ten workers instead of one, and route to any of them,
without the controlling code needing to know about it.
If you strongly prefer having the outer shell communicate directly with the
worker, you must *ask* the supervisor for it -- that allows the supervisor
to respond when it's good and ready. That would be something like (again,
totally untested and probably needs tweaking):
case object GetWorker
case class MyWorker(worker:ActorRef)
Class MainClass {
val aInstance = new A()
def submitJob {aInstance.submitJob()}
}
Class A {
val supervisorActor: B = MainClass.env.system.actorOf(Props(new B))
val workerActor: ActorRef = getWorker()
def getWorker():ActorRef = {
val fut = supervisorActor ? GetWorker
// We have to *wait* until the Supervisor says that it's
created the worker:
scala.concurrent.Await.result(fut, 5 seconds) match {
case MyWorker(worker) = worker
case _ = throw new Exception
}
}
def submitJob() {
workerActor ! JobSubmitted// Shouldn't NPE, because now we've waited
until we got the workerActor back properly
}
}
Class B (aInstance: A) {
val myWorker = context.actorOf(Props(new WorkerActor))
def receive = {
case GetWorker = sender ! MyWorker(myWorker)
}
}
You know that's an inferior solution because of that Await sitting there in
the middle -- that's blocking the main thread. But I don't see any other
way for it to work: the main thread has to wait until the supervisor has
actually created the worker and says that it is ready.
The first solution is better, though: the main thread makes no assumptions
except that it has created the supervisor, and it trusts the supervisor to
pass messages to the worker once it is good and ready to do so. No
blocking required.
(Caveat: I am eliding all *kinds* of real-world problems like back-pressure
and stuff. This solution works for easy cases, but you need a totally
different approach for high-volume problems. Look up work pulling and
reactive streams for more sophisticated approaches...)
On Fri, Apr 25, 2014 at 12:57 PM, Nan Zhu zhunanmcg...@gmail.com wrote:
Hi, Justin
Thank you for the reply, here is a revised description of the question
Class A is a non-actor class containing some methods in which some
messages are sent to the workerActor
WorkerActor is to do some real work, e.g. forward messages to other system
components and monitor the task status...
At the beginning, we initialize workerActor directly in the constructor of
A. Then, we added a new Class B which is supposed to be the supervisor of
the WorkerActor. We want this because in our scenario, we want to stop the
system upon the failure of WorkerActor, so we use Class B to achieve this.
We create B in the constructor of A and create workerActor in B's
constructor.
However, the weird thing is we found that some methods in A (sending
messages to worker) are called before A is assigned with any non-null
value, so some NPEs are thrown
I'm not sure about the reason of this, though I highly suspect that it's
because of the
Re: [akka-user] Initialize global variable during actor initialization?
On Fri, Apr 25, 2014 at 8:43 PM, Justin du coeur jduco...@gmail.com wrote:
Okay -- the key problem is that you have to remember that *everything*
involving Actors is asynchronous. You're not allowed to make any
assumptions about what happens when.
So take a look at your code. Main creates A. A **begins** to create
supervisorActor -- but that will happen *someday*, not immediately. You
get the ActorRef back immediately, but doesn't say anything about when the
Actor *itself* gets created and initialized. That takes time -- truth to
tell, I'm surprised you only sometimes get a NPE, since I would have
expected it to almost always happen.
You will never get a NPE, the ActorRef you get back is fully operable, i.e.
you can send messages, even if the respective actor hasn't been created.
Essentially messages are buffered until the actor is up and ready to handle
these.
Heiko
More importantly, the line
aInstance.workerActor = context.actorOf(Props(new WorkerActor))
violates one of the cardinal rules of Akka -- Actors should be
self-contained. An Actor should not modify state outside itself. (And
anything outside the Actor *must* not ever modify the Actor's state.) So
while this isn't *quite* strictly illegal, it's highly frowned upon.
Personally, I would probably hide workerActor completely inside B (the
supervisorActor), and would route messages to workerActor through the
supervisor, something like this:
class MainClass {
val aInstance = new A()
def submitJob {aInstance.submitJob()}
}
class A {
val supervisorActor: B = MainClass.env.system.actorOf(Props(new B))
def submitJob() {
supervisorActor! JobSubmitted // Now it won't NPE, because you are
using the Actor you built synchronously
}
}
class B {
val myWorker = context.actorOf(Props(new WorkerActor))
def receive = {
// This won't happen until after myWorker's ActorRef has been
created, and the Supervisor is ready to pass the message on:
case msg:JobSubmitted = myWorker.forward(msg)
}
}
That produces better separation of concerns -- for example, the supervisor
can decide to spawn ten workers instead of one, and route to any of them,
without the controlling code needing to know about it.
If you strongly prefer having the outer shell communicate directly with
the worker, you must *ask* the supervisor for it -- that allows the
supervisor to respond when it's good and ready. That would be something
like (again, totally untested and probably needs tweaking):
case object GetWorker
case class MyWorker(worker:ActorRef)
Class MainClass {
val aInstance = new A()
def submitJob {aInstance.submitJob()}
}
Class A {
val supervisorActor: B = MainClass.env.system.actorOf(Props(new B))
val workerActor: ActorRef = getWorker()
def getWorker():ActorRef = {
val fut = supervisorActor ? GetWorker
// We have to *wait* until the Supervisor says that it's
created the worker:
scala.concurrent.Await.result(fut, 5 seconds) match {
case MyWorker(worker) = worker
case _ = throw new Exception
}
}
def submitJob() {
workerActor ! JobSubmitted// Shouldn't NPE, because now we've waited
until we got the workerActor back properly
}
}
Class B (aInstance: A) {
val myWorker = context.actorOf(Props(new WorkerActor))
def receive = {
case GetWorker = sender ! MyWorker(myWorker)
}
}
You know that's an inferior solution because of that Await sitting there
in the middle -- that's blocking the main thread. But I don't see any
other way for it to work: the main thread has to wait until the supervisor
has actually created the worker and says that it is ready.
The first solution is better, though: the main thread makes no assumptions
except that it has created the supervisor, and it trusts the supervisor to
pass messages to the worker once it is good and ready to do so. No
blocking required.
(Caveat: I am eliding all *kinds* of real-world problems like
back-pressure and stuff. This solution works for easy cases, but you need
a totally different approach for high-volume problems. Look up work
pulling and reactive streams for more sophisticated approaches...)
On Fri, Apr 25, 2014 at 12:57 PM, Nan Zhu zhunanmcg...@gmail.com wrote:
Hi, Justin
Thank you for the reply, here is a revised description of the question
Class A is a non-actor class containing some methods in which some
messages are sent to the workerActor
WorkerActor is to do some real work, e.g. forward messages to other
system components and monitor the task status...
At the beginning, we initialize workerActor directly in the constructor
of A. Then, we added a new Class B which is supposed to be the supervisor
of the WorkerActor. We want this because in our scenario, we want to stop
the system upon
Re: [akka-user] Has anyone tried akka-persistence on Android?
Hello Martin Krasser! First: Thanks for your contributions to akka-persistence. Can you please take a look at: https://github.com/Optrak/akkaPersistenceNoAndroid https://github.com/Optrak/akkaPersistenceWithAndroid I am available to answer questions and help as much as I can. We want to be able to use akka-persistence on Android! On Friday, April 25, 2014 7:04:31 AM UTC-5, Martin Krasser wrote: On 25.04.14 13:58, Tim Pigden wrote: Hi Martin, When I get hold of him I intend to ensure we can run a simple test program in both standard environment before re-testing on Android. I can see the DeliveredByChannelBatching is part of the standard start-up process and there's no obvious reason the constructor should be missing. From what little I know of Android development, the culprit in these cases is usually Proguard being over-enthusiastic about pruning stuff it thinks is not required. If we can get a simple test program working I'll make sure we make it available. Personally I think the eventsource model is an excellent way of overcoming the problems associated with mobile applications being randomly stopped and restarted, either due to the Android OS kicking them out or users powering on and off. Absolutely, I also plan to run akka-persistence on Android in the near future, so I'm very interested about your findings. On 25 April 2014 12:48, Martin Krasser kras...@googlemail.comjavascript: wrote: On 25.04.14 10:41, Tim Pigden wrote: Hi Martin Unfortunately I don't have his code (he's inn a different Timezone and I only got email last night) but his stack trace http://pastebin.com/uHqwWYbJ so it looks like there's some reason it can't find the akka.persistence.DeliveredByChannelBatching constructor. Hmm, this constructor actually exists. I'll get him to add further info here as soon as he comes on line. Yes please. I'd also like to know: Have you tried running it on other platforms? What Akka version do you use? On 25 April 2014 09:06, Martin Krasser kras...@googlemail.comjavascript: wrote: Hi Tim, what error message do you see? On 25.04.14 09:38, Tim Pigden wrote: My co-worker is struggling (it's probably proguard) and it would be useful to know if somebody had succeeded. -- 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 javascript:. To post to this group, send email to akka...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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/qaBSx6sJH2Y/unsubscribe. To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -- 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
Re: [akka-user] Has anyone tried akka-persistence on Android?
As usually happens, Perry Nguyen has helped me and taught me something. He told me on irc channel #sbt-android that https://github.com/Optrak/akkaPersistenceWithAndroid/blob/master/errorMsg2.txt#L203 shows the guilty guy: pfn: can see what exactly is null there pfn: *public static final int CPU_DATA_MODEL = Integer.getInteger(sun.arch.data.model);* pfn: https://github.com/dain/leveldb/blob/master/leveldb/src/main/java/org/iq80/leveldb/impl/Iq80DBFactory.java#L32 pfn: there you go pfn: *leveldb won't even work on android* pfn: there is no system property sun.arch.data.model pfn: so it returns null, unboxing to int = nullpointer So what are the alternatives? -- 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] Has anyone tried akka-persistence on Android?
I think I'm getting closer, but still see the error at https://github.com/Optrak/akkaPersistenceWithAndroid/blob/master/errorMsg5.txt On Friday, April 25, 2014 5:18:45 PM UTC-5, Oscar Vargas Torres wrote: As usually happens, Perry Nguyen has helped me and taught me something. He told me on irc channel #sbt-android that https://github.com/Optrak/akkaPersistenceWithAndroid/blob/master/errorMsg2.txt#L203shows the guilty guy: pfn: can see what exactly is null there pfn: *public static final int CPU_DATA_MODEL = Integer.getInteger(sun.arch.data.model);* pfn: https://github.com/dain/leveldb/blob/master/leveldb/src/main/java/org/iq80/leveldb/impl/Iq80DBFactory.java#L32 pfn: there you go pfn: *leveldb won't even work on android* pfn: there is no system property sun.arch.data.model pfn: so it returns null, unboxing to int = nullpointer So what are the alternatives? -- 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] How to send a message to a ClusterSingleton actor (JAVA)?
Hi, I'm trying to send a message to an actor that was instantiated by the ClusterSingletonManager but I get the message from Actor[akka://ClusterSystem/deadLetters] to Actor[akka://ClusterSystem/user/master] was not delivered My test code .. ActorSystem system1 = ActorSystem.create(Constants.CLUSTER_ID, ConfigFactory.parseFile( FileSystems.getDefault() .getPath(src, test, resources,Master_1.conf).toFile())); ActorRef master1 = system1.actorOf(ClusterSingletonManager.defaultProps( Props.create(Master.class), master, PoisonPill.getInstance(), test)); ActorSelection selection = system1.actorSelection(akka.tcp://ClusterSystem@127.0.0.1:4/user/master); selection.tell(hello, ActorRef.noSender()); What am I missing? Thanks -- 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] Understanding routers
Let's say I have a router actor whose sole purpose is really to supervise routees but otherwise should be out of the picture. If I want to send a message for processing by a routee, I would first send it to the router actor, correct? If I do that, does it effectively bottleneck all messages to routees since it's being placed in the router's mailbox before it's distributed amongst routees? It almost seems that what I'm actually looking for is a ghost router so to speak -- where all messages sent to it are really placed on a shared mailbox amongst all routees but the router is still responsible for supervision. The router and routees will always be in the same process. Here's a use case (and I'd appreciate any/all suggestions on alternatives): a pool of actors responsible for persisting data into backend storage. So if I want to save something to persistent storage I would send it to my storage router first which is abstracting the ultimate storage destination. It would then select a routee to actually do the work. If a routee dies for whatever reason, the storage router can create a new one and ensure a proper pool size. Here's my concern: if I have lots of other actors trying to send messages to my single router, then the router becomes a bottleneck if it processes messages one-by-one. I like the idea of having my router supervise members of the pool, but I don't want all messages to go through it before fanning out to routees. Hope that makes sense. Can you think of an alternative way of doing it? Thanks so much! -- 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] Initialize global variable during actor initialization?
Read the original code more carefully - it is creating the worker ref
asynchronously, and is inited to null, so it can totally throw an NPE...
On Apr 25, 2014 3:12 PM, Heiko Seeberger heiko.seeber...@gmail.com
wrote:
On Fri, Apr 25, 2014 at 8:43 PM, Justin du coeur jduco...@gmail.comwrote:
Okay -- the key problem is that you have to remember that *everything*
involving Actors is asynchronous. You're not allowed to make any
assumptions about what happens when.
So take a look at your code. Main creates A. A **begins** to create
supervisorActor -- but that will happen *someday*, not immediately. You
get the ActorRef back immediately, but doesn't say anything about when the
Actor *itself* gets created and initialized. That takes time -- truth to
tell, I'm surprised you only sometimes get a NPE, since I would have
expected it to almost always happen.
You will never get a NPE, the ActorRef you get back is fully operable,
i.e. you can send messages, even if the respective actor hasn't been
created. Essentially messages are buffered until the actor is up and ready
to handle these.
Heiko
More importantly, the line
aInstance.workerActor = context.actorOf(Props(new WorkerActor))
violates one of the cardinal rules of Akka -- Actors should be
self-contained. An Actor should not modify state outside itself. (And
anything outside the Actor *must* not ever modify the Actor's state.) So
while this isn't *quite* strictly illegal, it's highly frowned upon.
Personally, I would probably hide workerActor completely inside B (the
supervisorActor), and would route messages to workerActor through the
supervisor, something like this:
class MainClass {
val aInstance = new A()
def submitJob {aInstance.submitJob()}
}
class A {
val supervisorActor: B = MainClass.env.system.actorOf(Props(new B))
def submitJob() {
supervisorActor! JobSubmitted // Now it won't NPE, because you are
using the Actor you built synchronously
}
}
class B {
val myWorker = context.actorOf(Props(new WorkerActor))
def receive = {
// This won't happen until after myWorker's ActorRef has been
created, and the Supervisor is ready to pass the message on:
case msg:JobSubmitted = myWorker.forward(msg)
}
}
That produces better separation of concerns -- for example, the
supervisor can decide to spawn ten workers instead of one, and route to any
of them, without the controlling code needing to know about it.
If you strongly prefer having the outer shell communicate directly with
the worker, you must *ask* the supervisor for it -- that allows the
supervisor to respond when it's good and ready. That would be something
like (again, totally untested and probably needs tweaking):
case object GetWorker
case class MyWorker(worker:ActorRef)
Class MainClass {
val aInstance = new A()
def submitJob {aInstance.submitJob()}
}
Class A {
val supervisorActor: B = MainClass.env.system.actorOf(Props(new B))
val workerActor: ActorRef = getWorker()
def getWorker():ActorRef = {
val fut = supervisorActor ? GetWorker
// We have to *wait* until the Supervisor says that it's
created the worker:
scala.concurrent.Await.result(fut, 5 seconds) match {
case MyWorker(worker) = worker
case _ = throw new Exception
}
}
def submitJob() {
workerActor ! JobSubmitted// Shouldn't NPE, because now we've waited
until we got the workerActor back properly
}
}
Class B (aInstance: A) {
val myWorker = context.actorOf(Props(new WorkerActor))
def receive = {
case GetWorker = sender ! MyWorker(myWorker)
}
}
You know that's an inferior solution because of that Await sitting there
in the middle -- that's blocking the main thread. But I don't see any
other way for it to work: the main thread has to wait until the supervisor
has actually created the worker and says that it is ready.
The first solution is better, though: the main thread makes no
assumptions except that it has created the supervisor, and it trusts the
supervisor to pass messages to the worker once it is good and ready to do
so. No blocking required.
(Caveat: I am eliding all *kinds* of real-world problems like
back-pressure and stuff. This solution works for easy cases, but you need
a totally different approach for high-volume problems. Look up work
pulling and reactive streams for more sophisticated approaches...)
On Fri, Apr 25, 2014 at 12:57 PM, Nan Zhu zhunanmcg...@gmail.com wrote:
Hi, Justin
Thank you for the reply, here is a revised description of the question
Class A is a non-actor class containing some methods in which some
messages are sent to the workerActor
WorkerActor is to do some real work, e.g. forward messages to other
system components and monitor the task status...
At the
