override def preStart = {
super.preStart
val persistenceIdsSink = Sink.actorRef(self,
MyViewActor.Protocol.PersistenceIdsComplete)
val source: Source[MyId, NotUsed] =
readJournal.allPersistenceIds().map(MyId.apply)
source.runWith(persistenceIdsSink)
}
Is this a sensible pattern for wi
Newb question: what if I don't have an event for the deferAsync() call? I
just want to execute a block with the guarantee that it runs after
persistAll() completes.
On Sunday, February 28, 2016 at 7:20:47 AM UTC-8, Łukasz Gąsior wrote:
>
> Thanks!
> I think that's exactly what I need, and now t
I debugged my application and it seems to be a bug in Akka:
My routers are defined similarly to each other as
/myActor/ {
dispatcher = my-pinned-dispatcher
router = round-robin
nr-of-instances = 10
}
When I debug into my actor creation and messaging method
public sendAkkaMessage(String act
Always thought provoking response. The issue is that I have a number of
entities that are looking for certain events and updating themselved based
on those events. If they change then they post another message to a topic
indicating they were updated. There is another entity that integrates those
Ahhh -- I get it. So you're trying to "pre-inflate" the whole cluster of
shards and entities, and they're expected to be essentially static after
that? Interesting problem.
So basically, I'd recommend the previous advice to start with: try it out
the easy way, and see whether it works acceptably
Greetings,
I apologize if this has been asked but I am having what I assume is a
config problem. When I start a single node I get the following logged
errors and my sharded actors don't start. The errors are like such:
2016-06-10 14:07:01 -0500 - [INFO] - Message
[akka.cluster.InternalCluste
The problem is I need to have the actors running and from what I understand
the sharding system doesn't start an actor until you actually pass a
message to an actor with that id. They cant subscribe to the topic until
they are started. Now I could have some mediator actor to start them but
then
Denis' definition is about right, although I think of it slightly
differently: so that an end user doesn't see any hiccup beyond somewhat
longer latency than normal. I can think of various ways to achieve this,
but all of them look like a fairly major pain in the tuchus in one way or
another, so I
I don't know how your app works or what router config you are using so it
is impossible for me to know what's happening.
Perhaps you have Restarts happening which will create new MyActor instances
but the old instances are still reachable by something else. Spring perhaps?
Use a memory debugger a
Patrik,
In the Aeron-as-a-transport context (UDP) what is the akka-http's transport
(TCP) planned future?
On Friday, June 10, 2016 at 6:46:09 PM UTC+3, Patrik Nordwall wrote:
>
> Dear hakkers,
>
> We’re excited to announce that we have released the second development
> milestone of the new Akka
Isn't the code:
if (child != null && child.isDefined()) {
actor = child.get();
}
supposed to fetch existing actor actor reference instead of creating a new
one?
If I call stop() at the end of onReceive() what happens to other instances
of the same actor which could be processing differ
Dear hakkers,
We’re excited to announce that we have released the second development
milestone of the new Akka Remoting, which has the code named Artery. It’s
an early development preview and we encourage you to try it out and give us
feedback, but it’s not intended for production usage yet.
The
If you create new actors continually and never stop any of them then you
have by design got a leak.
--
Cheers,
√
On Jun 10, 2016 4:35 PM, "Mark Kaberman" wrote:
> Hi Viktor,
>
> I never stop my actors explicitly (except as reaction to failure in
> supervision strategy). All actors process the v
Hi Viktor,
I never stop my actors explicitly (except as reaction to failure in
supervision strategy). All actors process the vertex data in onReceive()
method, determine if a vertex has children, get the children actor by
calling my createActorRef, send the message to a child via tell (never as
Hi Mark,
Where are you stopping your actors?
--
Cheers,
√
On Jun 10, 2016 2:55 PM, "Mark Kaberman" wrote:
> I have Akka application which is essentially traverses a very large tree
> where each vertex processing is done by an individual actor. Different
> kinds of vertices are processed by di
The following code example (which you can copy and run) shows a
MyParentActor that creates a MyChildActor.
The MyChildActor throws an exception for its first message which causes it
to be restarted.
However, what I want to achieve is for "Message 1" to still be processed
before "Message 2"
I have Akka application which is essentially traverses a very large tree
where each vertex processing is done by an individual actor. Different
kinds of vertices are processed by different actors. The actors are
implemented as prototype Spring beans (they are derived from the same
abstract cla
I'll echo the answer Justin provided. I normally taken existing DB access
code and wrapped it in an Actor with Futures without issues. Was there any
specific use case outside of your typical DB interactions (such as trying
to take advantage of Event Sourcing)?
On Friday, May 13, 2016 at 10:13:5
Option 2 is what I normally use since you're taking advantage of what Akka
already has built in. I have a couple apps in prod that use this technique
and it works fine for our needs
On Friday, May 6, 2016 at 6:42:33 AM UTC-4, scala solist wrote:
>
> I'm started to work with akka as scala actors
We use sharding, but with own persistence, but no rembember-entities
feature.
we do rolling-restarts (yes, not advised, lot's of pain when akka cluster
goes crazy during restart)
so we just shut down shard nodes one by one, and start new ones. Ususally
it works.
In theory it should be possible t
20 matches
Mail list logo
