Hello and thanks again for an excellent framework.
I'm have a minor question about schedulers. As ActorRefs are somewhat
harder to lookup these days it would be really sweet if the Scheduler
interface could have a schedule method that takes an ActorSelection. Also
as I understand the ActorRef
Hi guys,
We're currently on the verge of refactoring a traditional CRUD based
application into a reactive one. We're planning to apply event sourcing
with Akka Persitence in order to put in practice CQRS/ES principles. In
general terms, we know how to apply this principles when it comes to
I like this idea!
Just a side note: Restarting an actor won't lead to a stale ActorRef; the
opposite is the case!
Heiko
On 07 Jul 2014, at 09:19, Måns Schultz gfae...@gmail.com wrote:
Hello and thanks again for an excellent framework.
I'm have a minor question about schedulers. As
Hi Juan,
Glad to hear you've picked persistence :-)
My immediate reaction would be to store each data point as an event - that
will make replaying and analysing the data simpler. It also means no need
to think about oh yeah, we were getting the data in batches, so it's
batches stored in the db.
Thanks for the reply!
Thanks for the correction about stale ActorRefs. But the statement holds
true if I kill the actor and replace it with something else on the same
path right? (like switching a service at runtime).
Best Regards
Måns Schultz
2014-07-07 12:16 GMT+02:00 Heiko Seeberger
Hi Ryadh,
ActorSystem can only join a Cluster once.
Have you seen the documentation on Cluster Usage?
http://doc.akka.io/docs/akka/2.3.4/java/cluster-usage.html
The relevant excerpt from that page:
An actor system can only join a cluster once. Additional attempts will be
ignored.
When it has
Hi Rohit,
how do you reference the back-end actor from the front-end? If you hold an
ActorRef, then after the back-end machine is stopped, the ActorRef still
points to that non existent actor.
To solve this you should use a cluster membership service (which is what
Akka Cluster provides) to
Hi Mint,
whats the amount of messages you send from the worker nodes? Is it very
high?
Can you package this to a small test case and share it?
On Fri, Jul 4, 2014 at 11:06 PM, Mint tangjian1...@gmail.com wrote:
Hi Patrik,
I've just upgraded the version of Akka from 2.3.0 to 2.3.4 for our
Hi Mario,
your use case resonates to me with the Hot Standby Processor feature
request https://github.com/akka/akka/issues/13938, that we have in our
issue tracker. In that case you would have only one Processor which does
the writes. But next to that there would be a number of Hot Views that do
Hi,
what would be your suggestion on how to persist State machines with Akka
Persistence 2.3.4?
The example in the documentation still uses Processor and Persistent which
is not available anymore.
Thanks,
Hannes
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hello Hannes,
Well noticed - we have not yet ported this functionality over to the
PersistentActor (in `2.3.4`).
Progress on this task can be tracked here:
https://github.com/akka/akka/issues/15279
I hope you can wait a bit for it, but we definitely would like to provide this
(I like FSM a lot
Ah, this looks very nice and I agree that it sounds easier to implement, and
would perfectly cover my use case. Hopefully it will be implemented soon :)
Thanks!
-Mario.
On 07 Jul 2014, at 14:05, Martynas Mickevičius
martynas.mickevic...@typesafe.com wrote:
Hi Mario,
your use case
Hi,
I am evaluating the options for a redis client.
I noticed that there is no example using sentinel that has been put up..
I would like to use sentinel and have client pooling as well.
Is it possible?
Any tips would be useful!
Regards,
Shrivallabh
On Thursday, 8 August 2013 16:13:21
Thanks Martynas!
It seems that Clusters are a higher level entity:
Cluster - ActorSystem - Actor
AFAIK Clusters are created by ActorSystems when configured to do so which
is probably the source of confusion (lower entity creating a higher entity)
.
Cheers,
Ryadh
On 7 July 2014 12:21, Martynas
A cluster is just a name for cooperating ActorSystems using a specific
protocol. They are not reified.
On Mon, Jul 7, 2014 at 2:56 PM, Ryadh khsib ryadh.kh...@gmail.com wrote:
Thanks Martynas!
It seems that Clusters are a higher level entity:
Cluster - ActorSystem - Actor
AFAIK Clusters
Hi Martynas,
Thanks for the reply.
Both master and workers use distributed pub-sub to send receive messages.
There is a distributed pub-sub mediator which acts as a mediator and all
the messages are sent to it. Master and workers subscribe to it. So no
direct ActorRef is held by anyone.
Hi Rohit,
this is not akka specific and this is how IP works. If you bind to
localhost IP (127.0.0.1) then you receive packets sent to that IP address,
which are packets sent from the same machine. If you bind to some LAN
address (ex. 192.168.1.1) then you will receive packets sent to that IP
Thanks. Your definition makes perfect sense. Could we say that a Singleton,
a ClusterAwareRouter are some sort of 'applications' running on top of the
cluster? In that case it should allowed to have multiple 'applications'
running on the same cluster.
Ryadh
On 7 July 2014 14:05, √iktor Ҡlang
Martynas,
Thanks for the clarification.
Regards,
-Rohit
--
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
Drop a note in the issue so it is clear that the feature is wanted by one
more user. :)
On Mon, Jul 7, 2014 at 3:10 PM, Mario Camou mca...@tecnoguru.com wrote:
Ah, this looks very nice and I agree that it sounds easier to implement,
and would perfectly cover my use case. Hopefully it will be
Hi,
you should probably direct these questions to the RedisScala project page
https://github.com/etaty/rediscala.
On Mon, Jul 7, 2014 at 3:09 PM, SScala user shrivall...@gmail.com wrote:
Hi,
I am evaluating the options for a redis client.
I noticed that there is no example using sentinel
Hi!
I justed played a little with the new akka-persitence (2.3.4) and I found
some minor mistakes in the documentation
(http://doc.akka.io/docs/akka/2.3.4/scala/persistence.html)...at least I
think this are mistakes ;)
In the sample the RecoverCompleted is handled in the receiveCommand. In my
Hello Wolfgang,
thanks for reporting your findings!
Yes, the 1st thing you mention is indeed a typo and has been fixed in this PR:
https://github.com/akka/akka/pull/15486
The 2nd thing, snapshots, should indeed be updated, I’ve created an issue and
marked it as community-contrib:
Any help would be greatly appreciated.
On sáb 05 jul 2014 19:08:55 AST, Jorge Marizan wrote:
The sender ref is stored in an object (brokerRef) as a property and
passed to a FSM actor as a message. And the message is discarded if
the FSM actor state is timeouted.
case Event(StateTimeout,
I'm considering using become(processing(params)) in some of my short-lived
job actors, so that the params are available when the job completes, yet
the job can be started separately from its creation.
So I'm wondering about the overhead of become, and whether I should be
considering the FSM stuff
What kind of overhead?
On Mon, Jul 7, 2014 at 4:54 PM, Richard Rodseth rrods...@gmail.com wrote:
I'm considering using become(processing(params)) in some of my short-lived
job actors, so that the params are available when the job completes, yet
the job can be started separately from its
Hello Martynas,
I have found the problem. There's a bug in our own code of message
serialization. I have debugged into the code of Akka to detect this. It's
always strange that there's no explicit exception trace in the log...
Now I test a cluster with 10 nodes every thing works fine.
The time-overhead of calling become is very low. (I believe it's only one
allocation aside from the PF).
On Mon, Jul 7, 2014 at 5:32 PM, Richard Rodseth rrods...@gmail.com wrote:
I was thinking time rather than space. I'm guessing the cost of swapping
is not something I should worry about,
Elsewhere you've said that there are performance downsides to
context.become, specifically that this is the reason sender() is a function
rather than doing something like def receive(sender: ActorRef): Receive = {
... }, which would eliminate the problem of closing over sender() in
futures
I've been experimenting with akka-http in akka 2.3.4 with little luck --
evidently I am missing something (+ I'm an Akka newbie - which doesn't help
:( )
I'm coming at this from the Java API (via Groovy -- doubt if that is my
problem though - Akka has worked marvelously with Groovy so far) and
Hi Alan,
Akka-http works together with akka-stream, so it does work differently than
you tried. Since this is an early technical preview the docs are quite a
bit sketchy, but there are some examples already here:
Hello Moiz,
an event detached from it’s lineage does not make much sense for building
up state - which is how persistent actors are designed to be used.
An persistent actor’s state, and your “domain state”, should be built up
from such series of events (and snapshots).
We do support playback
Hi Konrad,
So I want to create a distributed state machine based on RAFT which I know
you're pretty familiar with. I want to use this facility when reconciling
logs. My understanding is that when an AppendEntries fails the Leader tries
to send the Follower a previous entry from the log till we
Hi,
I am trying to understand how to get the sender of the failed message in a
supervisor. In this sample, there is a service that changes a string to
upper case. I would like to return a FailureToUpResponse when the worker
throws an exception. The service itself is being called from an ask
Hi,
I'm currently starting to learn more about akka's cluster feature.
My goal is to have separate frontend and backend which are part
of the same cluster, so I can
- Start jobs on backend akka-nodes from the play frontend-nodes
- Monitor my cluster status (nodes up/down, jobs running)
Hi Rohit,
Just a thought, as you mentioned earlier Each m/c hosts once master and
one worker process running on different ports.
What about running a test, such as running master in one m/c and running
worker in other m/c.
Thanks
Rahat
On Monday, July 7, 2014 11:07:17 PM UTC+10, Rohit
I'm using the working pull pattern and wanted to be able to spawn and reap
workers while the application is running. Spinning up new workers is
trivial but I had some questions about terminating current workers.
Currently I'll send a worker a PoisonPill to get it to shut down but when I
do
You could call context.unwatch(worker) and then context.stop(worker) from
your supervisor actor. Then you won't get the Terminated message, though
you also won't find out about a crash if the actor were the die for
whatever reason before being stopped.
For the reason I might lean towards just
38 matches
Mail list logo
