we are planning to create a scheduler module. There is an external service
which provides all the necessary tasks for scheduler. Scheduler has various
use cases and the scheduling would change drastically and dynamically based
for data from the data store. We do not want to include this
Thanks Konrad,
I am aware of kamon.io and will definitely have a look - just wanted to
explore my options.
Currently the monitoring sits on my todo-list, but will come back to it
soon.
Best regards
Andreas
--
Read the docs: http://akka.io/docs/
Check the FAQ:
I sometimes run into cases where I instantiate a child actor ,then
subsequently ask that child with a message, only to discover that the ask
became dead letter due to the child not been initialized yet. I guess my
mistake is to apply a synchronous mindset instead of realizing that the
child
Why does the Download section of the website specify Akka 2.3.3 (scala
2.10 *and 2.11*) but, if you download the distribution it only has the
2.10 JARs in there?
In fact, getting hold of the 2.11 JARs doesn't seem possible from
akka.io/downloads at all: I'm reduced to pratting around on
My main problem with the ask pattern is that it can break code at a
distance. Consider this:
case object Subscribe; case class Publish(msg: Any); case class
Image(state: Any)
class Manager extends Actor {
private var subscribers = Set.empty[ActorRef]
def receive = {
case Subscribe =
I don't have code samples right now, but my issue is identical to the one
discussed here:https://groups.google.com/forum/#!topic/akka-dev/6JSe4RIMPOU
https://groups.google.com/forum/#!topic/akka-dev/6JSe4RIMPOU
On Wednesday, May 28, 2014 10:23:34 AM UTC+2, √ wrote:
That shouldn't happen
Hi Chris,
Thanks for noticing this! We have not previously supported two Scala
versions we this must have slipped our minds when doing the recent release.
I'll update the downloads page to include the links right away.
On Wed, May 28, 2014 at 10:37 AM, oxbow_lakes oxbowla...@gmail.com wrote:
Using TestActorRef on implementations of Processor (and
EventsourcedProcessor) appears to introduce a deadlock at the point of
calling into the snapshot store actor.
The result is an actor-under-test that never completes recovery.
I have worked-around this issue by providing
Hi Heiko,
So moving forward, is the actor selection a bad practice instead? The
temptation to don't pass the actorRef and instead let the actor search for
the dependencies is high, but I see difficulties to test and and heavy
dependency on the actor system hierarchy.
Any thoughts on that?
Heiko, that makes sense. I appreciate your reply. I was planning on using
an adaptive load balancing router to be smarter about what workers get
work. I'm wondering about other possible advantages to the worker pulls
work approach. One thing that comes to mind is that I'm constantly pushing
Hello Lawrence,
Because of the processor’s inner workings (how it interacts with the
Journal) it does not make sense to test it using the *synchronous* test
utilities (such as TestActorRef).
Please do not use TestActorRef with Akka-Persistence - use the plain
TestKit and it’s probes and other
I have updated the site to link to both published zips -
http://akka.io/downloads/
Thanks again for noticing this! :-)
On Wed, May 28, 2014 at 11:10 AM, Konrad Malawski kt...@typesafe.comwrote:
Hi Chris,
Thanks for noticing this! We have not previously supported two Scala
versions we this
Hi Konrad,
I'm currently using TestActorRef to obtain the underlying ActorContext. I
am using this to assert the actor is passing its own context as an argument
to a mocked-out dependency.
Can you think of another way using existing TestKit probes, or is this the
best way?
Thanks,
Lawrence
Actor selection essentially is look up and we all know that look up should not
be overused. It has it’s purpose though, e.g. when you want to connect to a
remote system (How would you get an actor ref for a remote actor?). Rule of
thumb: If you have an actor ref, use it.
Heiko
On 28 May 2014,
On 28 May 2014, at 16:17, Eric Nelson eric.nelso...@gmail.com wrote:
Heiko, that makes sense. I appreciate your reply. I was planning on using an
adaptive load balancing router to be smarter about what workers get work. I'm
wondering about other possible advantages to the worker pulls work
But can you please explain why using an actorref ensures no dead letter,
while an actorSelection
may cause this. Example pseudocode as follows:
Using actorref:
val ref = context.actorOf(Props(classOf[ChildActor],ChildActor.NAME)
ref ! test // --- this is okay
while using actorSelection
We strongly advertise against exposing your ActorContext - it's scary what
could happen with it being accessed from outside of the respective actor.
What's your use case? Perhaps there is a better way to test / abstract it?
On Wed, May 28, 2014 at 4:56 PM, Lawrence Wagerfield
I had an Actor whose code grew to be quite large, so this is the result of
a refactoring.
The new class performs actions on behalf of the actor, impersonating it, so
to speak. It caries out various send operations, sets up state with
un/become, etc.
The refactor produces clearer and more
Hi,
I'm trying to connect two nodes together using akka-cluster and even if I
thought they were setup correctly, while trying to launch the application I
ran into connection problems.
[info] [WARN] [05/28/2014 16:50:09.017]
[ClusterSystem-akka.remote.default-remote-dispatcher-66] [Remoting]
Hi,
Assuming I want to do some aop advice against some of the actor method like
ask , tell, etc like:
@Around(value = execution (* akka.actor.ScalaActorRef.$bang(..))
args(message,sender), argNames = jp,message,sender)
def handle(jp: ProceedingJoinPoint, message: AnyRef, sender: ActorRef) {
Nothing can ensure that the other actor receives the message, but with actor
refs you can use death watch (also remote death watch), i.e. you are notified
if the other actor dies. You can’t watch actor selections.
Heiko
On 28 May 2014, at 17:42, Ketil Johannessen ketil.johanness...@gmail.com
In 2.3.1 we fixed so that UntypedEventSourcedProcessor can receive
ConfirmablePersistent
messages. Try with latest version: 2.3.3.
Regards,
Patrik
On Tue, May 27, 2014 at 4:54 PM, R1 erwan.gil...@gmail.com wrote:
Hi,
I'm kind of new to Akka, and am using its Java API only.
I have a
Hi Eric and Heiko,
doesn't the activator template for distributed workers also use a resilient
(and persisted (?)) master to handle failure?
cheers, Martin
Am 28.05.2014 17:31 schrieb Heiko Seeberger heiko.seeber...@gmail.com:
On 28 May 2014, at 16:17, Eric Nelson eric.nelso...@gmail.com
On 28 May 2014, at 18:47, Martin Senne martin.se...@googlemail.com wrote:
doesn't the activator template for distributed workers also use a resilient
(and persisted (?)) master to handle failure?
I haven't said that it's not possible to make any component (e.g. the master)
resilient via
Great, Thanks Patrik!
--
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
Hello,
I'm a bit confused with supervisor hierarchies. I've read the akka
documentation and other books but hierarchy design is still not sinking in
:(
A simple, made up, example. I have a web front end with business logic and
a database. converting this to akka I would create a
web front
I followed the tcpEcho example to create a stream to split lines from data
coming from a tcp connection. My code look like this
val serverAddress = new InetSocketAddress(127.0.0.1, 6000)
val serverFuture = (IO(StreamTcp) ? StreamTcp.Bind(settings = settings,
localAddress = serverAddress))
27 matches
Mail list logo
