Hello,
I'm working on a project which is running as a cluster and it was
implemented by using akka-scala API. My application has mainly 4 actors.
Those are Client, Dispatcher, WorkDistributor, and Worker.
My application.conf as follows,
cluster {
seed-nodes = [
Hello Jeff,
your question requires some in-depth consideration and is more in the
consultation realm than general help using Akka.
Typesafe is offering consulting services
http://typesafe.com/subscription/consulting which can surely address your
inquiries.
On Fri, Dec 5, 2014 at 3:16 PM, Jeff
Dear hakkers,
it has been a while since the last update
https://typesafe.com/blog/akka-roadmap-update-2014 on the overall direction
and release planning of Akka, so before this year ends I thought it a good time
to lay out the plans for the first half of the next. You have all seen the
first
On Tue, Dec 9, 2014 at 1:50 AM, io loop iol...@gmail.com wrote:
I am looking at akka persistence as a possible platform for a workflow
system. The idea is that events are placed on a bus and stateful workflow
instances (persistent actors) are created in response.
Users need to interact with
Hi,
you have to make sure that there is only one process that is accessing
LevelDB storage files. Is that the case?
On Sat, Dec 13, 2014 at 11:33 AM, 何品 hepin1...@gmail.com wrote:
I am using akka persistent with netty to handle the statistic of game
server.
There are 1 to N statistic client
Hi Rishi,
what is not completely clear is if you are getting rid of HTTP protocol
altogether.
If so, then you can have actors running in two separate actor systems and
you can send messages from one actor system to the other using remoting and
ActorSelection
Hi Jakub,
you have probably already stumbled upon a When to use TypedActors
http://letitcrash.com/post/19074284309/when-to-use-typedactors article on
Let it Crash blog already. It is quite old, but TypedActors did not change
since then.
Also consider integrating systems using HTTP, which is
Hi Krishna,
just calling context.actorSelection(...) with a remote path does not hit
network and is naturally latency and bandwidth independent.
Now if you want to get an ActorRef from ActorSelection you need to either
send an Identify message or call resolveOne on ActorSelection. This has a
On Mon, Dec 15, 2014 at 7:38 PM, David davidlu...@gmail.com wrote:
Hello,
Given a pool router (PR) containing 5 workers(Wn) which connect to the
database and a client actor (C) which uses and watches PR.
I would like to implement a fault tolerance strategy as follows:
1. When the
Hi Tim,
the focus of current sprint which is ending in a couple of days is
documentation. You have probably noticed that the nature of the latest PRs
is very much documentation driven. You can already get some useful insights
by reviewing these still open or already merged PRs.
On Tue, Dec 16,
Hi all,
there was one issue on akka-remoting fixed in the just released 2.3.8. I
was wondering if that would fix your issue. Could you try it?
On Tue, Dec 16, 2014 at 8:08 PM, Jim Washburn washb...@ticketfly.com
wrote:
Hi Björn , thanks for the comments .
In our scenario it seems to be that
Hi Daniel,
I wanted to elaborate that before joining a cluster you can send and
receive messages between nodes to determine what seed nodes or the order of
thereof would suit best. In such way you can determine the start time or
the uptime (reported by methods on ActorSystem
These are all really great questions. I will provide answers as I
understand them and as things currently stand. In another thread Roland
discusses the Akka roadmap for the next half year. It's possible that some
things could change between now and then, so I can't say that this is
long-term
Hi Martynas,
Thanks for the heads-up. We tried 2.3.8 but unfortunately our problem still
remains.
Jim
On Thu, Dec 18, 2014 at 6:33 AM, Martynas Mickevičius
martynas.mickevic...@typesafe.com wrote:
Hi all,
there was one issue on akka-remoting fixed in the just released 2.3.8. I
was
Hi Vaughn
Thanks so much for replying. I have your excellent book and the Blue Book,
but obviously I'm still a bit unclear on some things.
So you are giving unique identity to Domain Events? That sounds less like
Event Sourcing already. While that can be done (and my book discusses it),
it
If you are doing Event Sourcing the Domain Events are both your state and
the means by which others are notified of changes. Because with Event
Sourcing you need to create new events for everything that happens in your
Aggregates you may not want all of those events to be published to
This seems like it should be a no-brainer, but I haven't been able to find
any documentation to back it up.
In the following scenario:
- A watches B
- B terminated
- A receives Termination message for B
Does A need to unwatch B? Is there a list of watched ActorRefs somewhere
that
Hi,
Did anything ever become of this thread
https://groups.google.com/forum/#!searchin/akka-user/strange$20tcp/akka-user/BYFQR68jriI/YHmYQUbE-h8J,
in which an actor eventually did not receive an Ack to a Tcp.Write
command? I'm seeing something which may or may not be similar...
I also have
I think my idea is wrong, so long as the SerializedSuspendableExecutionContext
does indeed do what it says it does and serialize tasks.
The question as to whether anything ever became of the earlier thread
stands.
On Thursday, 18 December 2014 19:25:41 UTC, David Hotham wrote:
Hi,
Did
It's not obvious to me that Alerts are part of the Monitor aggregate, but
perhaps they are, with the in-memory model containing only the last alert,
and a Read Model Projection, to use the term in Appendix A, to allow
querying of alerts.
On Thu, Dec 18, 2014 at 1:38 PM, Vaughn Vernon
20 matches
Mail list logo
