Re: [akka-user][deprecated] Akka Clustering

[Justin du coeur]

This mailing list is pretty much long-dead.  You'd be better off asking on
the Akka Users Forum ...

On Fri, Dec 6, 2019 at 2:04 AM Randy St.fleur 
wrote:

> I am new to using akka.
> I am seeing the wifi ip address instead of localhost when remoting is
> starting up the backend servers are trying to join on the localhost address
> but failing
>
>
> Here is the output from where the error starts to fail:
>
> [INFO] [12/05/2019 16:14:50.105] [main] [akka.remote.Remoting] Starting
> remoting
> [INFO] [12/05/2019 16:14:50.572] [main] [akka.remote.Remoting] Remoting
> started; listening on addresses :[akka.tcp://ClusterSystem@*10.31.53.249:2552
> ]*
> [INFO] [12/05/2019 16:14:50.574] [main] [akka.remote.Remoting] Remoting
> now listens on addresses: [akka.tcp://ClusterSystem@10.31.53.249:2552]
> [INFO] [12/05/2019 16:14:50.643] [main]
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.31.53.249:2552] - Starting up, Akka version [2.6.0-M8]
> ...
> [INFO] [12/05/2019 16:14:50.784] [main]
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.31.53.249:2552] - Registered cluster JMX MBean
> [akka:type=Cluster]
> [INFO] [12/05/2019 16:14:50.784] [main]
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.31.53.249:2552] - Started up successfully
> [WARN] [12/05/2019 16:14:50.835]
> [ClusterSystem-akka.actor.default-dispatcher-18] [akka.tcp://
> ClusterSystem@10.31.53.249:2552/system/cluster/core/daemon/downingProvider]
> Don't use auto-down feature of Akka Cluster in production. See
> 'Auto-downing (DO NOT USE)' section of Akka Cluster documentation.
> [WARN] [12/05/2019 16:14:50.959] [New I/O boss #3]
> [NettyTransport(akka://ClusterSystem)] Remote connection to [null] failed
> with java.net.ConnectException: Connection refused: /127.0.0.1:2552
> [WARN] [12/05/2019 16:14:50.959] [New I/O boss #3]
> [NettyTransport(akka://ClusterSystem)] Remote connection to [null] failed
> with java.net.ConnectException: Connection refused: /127.0.0.1:2551
> [WARN] [12/05/2019 16:14:50.960]
> [ClusterSystem-akka.remote.default-remote-dispatcher-19] [akka.tcp://
> ClusterSystem@10.31.53.249:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40127.0.0.1%3A2552-1]
> Association with remote system [akka.tcp://ClusterSystem@127.0.0.1:2552]
> has failed, address is now gated for [5000] ms. Reason: [Association failed
> with [akka.tcp://ClusterSystem@127.0.0.1:2552]] Caused by:
> [java.net.ConnectException: Connection refused: /127.0.0.1:2552]
> [WARN] [12/05/2019 16:14:50.960]
> [ClusterSystem-akka.remote.default-remote-dispatcher-6] [akka.tcp://
> ClusterSystem@10.31.53.249:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40127.0.0.1%3A2551-0]
> Association with remote system [akka.tcp://ClusterSystem@127.0.0.1:2551]
> has failed, address is now gated for [5000] ms. Reason: [Association failed
> with [akka.tcp://ClusterSystem@127.0.0.1:2551]] Caused by:
> [java.net.ConnectException: Connection refused: /127.0.0.1:2551]
> [INFO] [12/05/2019 16:14:50.966]
> [ClusterSystem-akka.actor.default-dispatcher-5]
> [akka://ClusterSystem/deadLetters] Message
> [akka.cluster.InternalClusterAction$InitJoin] from
> Actor[akka://ClusterSystem/system/cluster/core/daemon/joinSeedNodeProcess-1#1325673130]
> to Actor[akka://ClusterSystem/deadLetters] was not delivered. [1] dead
> letters encountered. If this is not an expected behavior then
> Actor[akka://ClusterSystem/deadLetters] may have terminated unexpectedly.
> This logging can be turned off or adjusted with configuration settings
> 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
> [INFO] [12/05/2019 16:14:50.966]
> [ClusterSystem-akka.actor.default-dispatcher-5]
> [akka://ClusterSystem/deadLetters] Message
> [akka.cluster.InternalClusterAction$InitJoin] from
> Actor[akka://ClusterSystem/system/cluster/core/daemon/joinSeedNodeProcess-1#1325673130]
> to Actor[akka://ClusterSystem/deadLetters] was not delivered. [2] dead
> letters encountered. If this is not an expected behavior then
> Actor[akka://ClusterSystem/deadLetters] may have terminated unexpectedly.
> This logging can be turned off or adjusted with configuration settings
> 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
> [INFO] [12/05/2019 16:14:51.063]
> [ClusterSystem-akka.actor.default-dispatcher-5]
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.31.53.249:2552] - Metrics collection has started
> successfully
> [INFO] [12/05/2019 16:14:51.072] [main] [akka.remote.Remoting] Starting
> remoting
> [ERROR] [12/05/2019 16:14:51.080]
> [ClusterSystem-akka.remote.default-remote-dispatcher-15]
> [NettyTransport(akka://ClusterSystem)] failed to bind to /
> 10.31.53.249:2552, shutting down Netty transport
> [ERROR] 

Re: [akka-user][deprecated] Re: [akka-user] Announcing discuss.akka.io!

[Justin du coeur]

On Fri, Mar 16, 2018 at 7:17 AM, Johan Andrén 
wrote:

> Sorry to hear that you dislike Discuss so much you won't be coming along
> there Alan.
>

I gotta say -- Alan's not alone in these concerns.  I'm pretty active on
both Scala-Contributors and Scala-Users, and while I put up with the
mailing list mode for them, I hate it with a burning passion.  On the one
hand, it's necessary (I've demonstrated experimentally that I don't
actually follow what's going on without it), but it's such an uncritical
firehose as to be borderline disease-worse-than-the-cure.

As a result, I'm on the fence about getting involved with the new Akka and
Play forums.  I may go for it -- if the volume remains at the level of the
mailing lists, it won't be too bad.  But I'd be a lot less reluctant
(possibly eager, even) if Discourse would fix the damned mailing list mode
to respect the other settings.  I'm surprised and disappointed that they
haven't prioritized this...

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] ANNOUNCE: Akka 2.5.10 released

[Justin du coeur]

On Fri, Feb 23, 2018 at 5:40 AM, Patrik Nordwall 
wrote:

> StreamRefs - Reactive Streams over the network
>
> Stream references, or “stream refs” for short, allow running Akka Streams
> across multiple nodes within an Akka Cluster.
>

Oh, *faboo* -- this has probably been my most-desired feature for over a
year now.  I look forward to it evolving to production-ready: I'm likely to
dump a lot of my hacked-together streaming code to use this, and quite
likely rewrite a lot of my application to be more Stream-ish.  Thanks!

(I suspect this brings us much closer to being able to build a proper
marriage of Sharding and Streaming, which I've long regarded as the holy
grail of Akka -- I'm curious whether y'all are thinking about that yet.)

Akka Typed
>
> There are several breaking changes since 2.5.8 and 2.5.9 in the
> under-development “may change” Akka Typed module. Most of the development
> has been completed and from now on only minor adjustments in the APIs are
> expected. Akka Typed 2.5.10 should be stable enough to start using for
> development.
>
> Our goal is to ship a production ready version of Akka Typed soon and
> therefore we have removed the new runtime implementation and initially only
> support running typed actors with the underlying untyped actor system. See
> the Coexistence
> 
> documentation.
>

Yay!  This is all big news indeed.  Kudos to the team!

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Message processed by Actors

[Justin du coeur]

On Mon, Feb 12, 2018 at 11:26 AM, Kilic Ali-Firat 
wrote:

> Hi Akka team,
>

I'm not the Akka team, but...


> case class Worker() extends Actor {
>
>
>   trait Message
>   case class M1(x : Int) extends Message
>   case class M2(x : Int) extends Message
>
>
>   trait Result
>   case  Sucess(m : Message) extends Result
>   case Failed(m : Message) extends Result
>
>
>   def processM1(m : M1) : Future[Result]
>
>
>   def processM2(m : M2) : Future[Result]
>
>
>   override def receive = {
> case m : M1 => this.processM1(m) pipeTo sender()
> case m : M2 => this.processM2(m) pipeTo sender()
>   }
> }
>
>
>
>
> Imagine that mailbox of a worker *has 4 messages : M1, M2, M3, M4.*
>
> It will process the mailbox messages per message starting by M1, then M2,
> then M3 and finally M4.
>
> My question about order processing is : Do an Actor wait the completion of
> current message before passing to the next one in the mailbox ?
>

Depends on your definitions.  Keep in mind that Akka is focused on
*synchronous* processing -- if the message processing is synchronous, then
yes, a given Actor will only process one at a time.

The problem is, you're spawning off separate threads with those Futures.
Akka has no insight or control over those, so it doesn't and can't wait for
them to be finished.  That's why you are seeing the behavior that you are.


> If I'm a wrong, Does Akka have a mechanism to wait for the completion of
> current message processing before passing to the next one ?
>

I don't know of any built-in way to do this.  The pattern I usually see
(and have sometimes used myself) is to:

* Mix the Stash trait in;
* When I start processing, become() a different state that stash()es all
messages except the Result;
* When processing finishes (once you've dealt with the Result),
unstashAll() and unbecome() back to the main state.

So basically, it isn't "waiting", it's storing all of the received messages
off to the side in the interim, and them putting them back into the mailbox
when you're ready to continue.  You get an effect similar to waiting, but
without blocking anything.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Play Controller/Akka Actor Ask Pattern Question

[Justin du coeur]

No, "ask" shouldn't have this problem.  Each ask() operation creates a
little pseudo-Actor under the hood, which is unique for this operation,
which will be the receiver of the response.  So long as the Actor is
responding to sender(), the response should go to the ask() that initiated
this message; cross-talk shouldn't be possible.  (This is actually a very
common situation.)

On Sat, Jan 27, 2018 at 5:56 PM, Joseph Mansigian <
joseph.c.mansig...@gmail.com> wrote:

> Hello All,
>
> I am making a Scala/Akka Actor based application.
>
> It is necessary for me to query an actor from a controller.
> The queried actor is always the same; only one of these exist.
>
> From the controller I am using the "ask' pattern to send a query message
> to the actor.
> The query message contains a unique key that the actor uses to lookup
> information which it
> formats into a response message and sends the message back to the
> controller.
>
> I have coded this and it seems to work fine; used it extensively.
>
> Here is my concern:
>
> Many clients can be making queries at once.  Let's say that there are two
> queries overlapping in time.
> One of the queries contains the key "abc".  The other query contain the
> key "xyz".
> Since this is async. can a race condition occur that responds to the "abc"
> keyed query with
> the "xyz" keyed data because "xyz" arrives first.  Maybe I am worrying
> about nothing.  Is this managed automatically under the hood?
>
> Thanks, Joe
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Single Writer/Multiple Reader and anonymous actors

[Justin du coeur]

I suspect the reason you're not getting much response is that there *is* no
best practice.  This is a very unusual design -- I don't think I've ever
seen it before.  In principle, I don't see any reason why it doesn't work,
but you're intentionally stepping outside of Akka's firmest invariant, that
the Actor's state should be entirely contained by the Actor and its receive
loop.  So you may be somewhat on your own here...

On Wed, Jan 3, 2018 at 4:28 PM, Jeff  wrote:

> Bumping this - what are the best practices about using anonymous actors to
> modify shared state?
>
> Thanks
> Jeff
>
> On Wednesday, December 27, 2017 at 4:51:04 PM UTC-8, Jeff wrote:
>>
>> I have a class that is read heavy with low contention on writes. I'd like
>> to be able to access a piece of shared mutable state outside of Actors. The
>> state itself (AnnouncementRegistry) is immutable. Since it is a single
>> writer, having a shared @volatile var between the actor and the class seems
>> to be a good approach, however it also has a code smell to it since I am
>> closing over external mutable state and using an anonymous actor. Is there
>> a better approach to what I have below?
>>
>> class DiscoveryClient(config: DiscoveryConfig, singleRequest: HttpRequest => 
>> Future[HttpResponse])
>>  (implicit system: ActorSystem, m: Materializer) {
>>
>>   @volatile
>>   private[this] var _registry = AnnouncementRegistry.empty
>>
>>   def registry = _registry
>>
>>   private[this] val client = system.actorOf(Props(new Actor with 
>> ActorLogging {
>> import DiscoveryClient._
>>
>> private[this] var subscribers = HashSet.empty[ActorRef]
>>
>> private[this] val killswitch =
>>   ChangeWatcher(config.seeds, singleRequest).to(Sink.foreach(self ! 
>> RegistryUpdate(_))).run()
>>
>> def receive: Receive = uninitialized
>>
>> private[this] def uninitialized: Receive = {
>>   case Subscribe =>
>> subscribers += sender
>> context.watch(sender)
>>
>>   case Terminated(ref) =>
>> subscribers -= ref
>>
>>   case m @ RegistryUpdate(newRegistry) =>
>> _registry = newRegistry
>> context.become(initialized)
>> subscribers.foreach(_ ! m)
>> }
>>
>> private[this] def initialized: Receive = {
>>   case Subscribe =>
>> subscribers += sender
>> context.watch(sender)
>> sender ! RegistryUpdate(_registry)
>>
>>   case Terminated(ref) =>
>> subscribers -= ref
>>
>>   case m @ RegistryUpdate(newRegistry) =>
>> _registry = newRegistry
>> subscribers.foreach(_ ! m)
>> }
>>
>> override def postStop(): Unit = killswitch.shutdown()
>>   }), "discovery-client")
>> }
>>
>> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to handle zero (almost) downtime deployments of sharded persistent system.

[Justin du coeur]

No change -- for the time being, I'm still coping with a few seconds of
downtime per deployment.  (On the grounds that that is better than risking
shard duplication between old and new clusters)  That's not a major pain
point while the company is small, but will eventually prove to be more of
an issue.

I've been thinking a bit about what might be required for a plausible
zero-downtime deployment, but still don't have a design that I'm fully
happy with.  (Which is part of why I haven't pursued it yet.)  It really is
a pretty tricky problem to address in a theoretically-correct way; I
suspect the application and the deployment system (and maybe the Cluster
Sharding mechanism itself) have to work together to make it at all
plausible.

On Sun, Dec 3, 2017 at 1:59 PM, Gytis G <gy...@fmu1.net> wrote:

> Bumping an old thread, Justin du coeur, can you perhaps share what
> approach did you take and how did you succeed ?
>
> On Friday, June 10, 2016 at 9:30:27 PM UTC+3, Justin du coeur wrote:
>>
>> 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'm curious about whether you have recommendations.
>>
>> We're using ConductR, but I'm curious about approaches both with and
>> without it.  Architecturally, you can think of Querki as a Play
>> application, where 95% of the serious code is under sharded Actors in an
>> Akka cluster, which is started under but separate from Play's built-in
>> ActorSystem.  (That's wildly oversimplified, but a decent thousand-foot
>> block diagram description.)
>>
>> On Thu, Jun 9, 2016 at 4:31 PM, Viktor Klang <viktor...@gmail.com> wrote:
>>
>>> Can we please define "zero" in this context?
>>>
>>> On Thu, Jun 9, 2016 at 9:05 PM, Justin du coeur <jduc...@gmail.com>
>>> wrote:
>>>
>>>> +1 to this question.  For the moment I'm coping with a few seconds of
>>>> downtime for releases, but we're going to have to become
>>>> downtime-intolerant before long.  And zero downtime does look challenging
>>>> in a heavily-sharded application.
>>>>
>>>> Personally, I've been wondering if I should be trying to deal with
>>>> intermixed releases -- bringing the new release up on one node at a time,
>>>> in the *same* cluster as the old one, and gradually shutting the old ones
>>>> down.  That seems to make sense in theory, but also seems bloody dangerous
>>>> -- it requires that the releases be 100% wire-compatible, which is hard to
>>>> test and presents evolutionary challenges -- and I'm not sure if there are
>>>> gotchas to be aware of...
>>>>
>>>> On Thu, Jun 9, 2016 at 3:44 AM, Denis Mikhaylov <notx...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi, hakkers!
>>>>>
>>>>> I have a distributed app that uses `akka-persistence` and
>>>>> `akka-sharding`.
>>>>> For some of my shard coordinators I use `remember entities` feature.
>>>>> I heard (from Bonér or Kuhn, can't say for sure) that in production
>>>>> it's better to use blue/green deployments.
>>>>> As I see, the steps are:
>>>>> 1. Deploy and start fresh application, let it form cluster (don't
>>>>> start any ShardRegions yet)
>>>>> 2. Stop ShardRegions that do not use `remember entities` features
>>>>> (e.g. Aggregate Roots).
>>>>> 3. Start these ShardRegions on freshly deployed system
>>>>> 4. Switch external traffic to new system (so that we already can
>>>>> accept external commands).
>>>>> 5. Stop ShardRegions that use `remember entities` features (e.g. Long
>>>>> Running Processes, that react to events from Aggregate Roots).
>>>>> 6. Start these ShardRegions on freshly deployed system (here I need
>>>>> akka sharding to restart entities that were alive on previous system)
>>>>> 7. Shut down old system
>>>>>
>>>>> So the questions are:
>>>>> 1. Is there any improvements to the deployment process?
>>>>> 2. Wouldn't this scenario corrupt Sharding related or any Akka
>>>>> internal data in journal?
>>>>> 3. How do you handle deployments in production?
>>>>>
>>>>> Thanks a lot,
>>>>> Denis.
>>

Re: [akka-user] Akka FSM, Persistence and multiple instances

[Justin du coeur]

I think you're misunderstanding how this all works.  The state lives *in*
the Actor, and is only available while the Actor is live; shutting the
Actors down and starting them so quickly is enormously inefficient.  The
database is just a backing store, recording the history of the Actor.

Normally, you would build something like this with Cluster Sharding
managing the Actors; the Actors live until they time out due to inactivity,
and when they are needed again they revive themselves from Persistence...

On Sat, Oct 28, 2017 at 11:43 AM, wapgui  wrote:

> It's the state for a shopping application bound to Kafka with values
> coming from a SAP system. So there could be some 100 Request per Minute
> asking to switch the state. In what time period does an FSM actor saves it
> state or makes an lookup on the persist store. Maybe it's not necessary the
> close the actor on the instances, because the state is up to date.
>
> Am Samstag, 28. Oktober 2017 15:25:27 UTC+2 schrieb Konrad Malawski:
>>
>> But if you can have concurrent writes, because requests to multiple nodes
>> and timing etc, you do run st the risk. Also, stopping actors a meter every
>> write is very weird and not what akka persistence was really designed for.
>> It’s not a key value store, it’s event sourcing for medium-long loved
>> entities.
>>
>> --
>> Konrad Malawski
>>
>> On October 28, 2017 at 17:44:08, wapgui (torsten...@wapgui.com) wrote:
>>
>>> I'm closing the actors after each request and recreate with the same
>>> uuid.
>>>
>>> Am Samstag, 28. Oktober 2017 10:41:28 UTC+2 schrieb Konrad Malawski:

 Are you creating many persistent actors with the same persistence I’d?
 That of course breaks things. Please read the persistence docs and use akka
 cluster with cluster sharding instead to handle the cluster creating the
 actors. This not only is easier but also is safe - the uniqueness will be
 guaranteed by sharding then.

 --
 Konrad Malawski

 On October 28, 2017 at 17:34:12, wapgui (torsten...@wapgui.com) wrote:

> Hi,
>
> I've built a FSM using Akka FSM and Persistence to a Percona cluster
> in near cloud.
> Running this environment in a single instance causes no problems at
> all. If I dockerize this single instance and running it at 2 instances
> causes sometimes problems with the state.
> E.g. making the first request with New creates the state object on an
> instance. From the second instance the next request calls to switch to the
> next state, but the FSM answers there is no object and a switch is not
> possible. The second request was 14s after the first one.
> My service creates an actor each time a request comes in with the
> reference to the uuid of the process. After handling the request, the 
> actor
> will be closed, until the next request comes in. Is this really necessary?
> I made this because of the multiple instances to be sure the state of the
> actor is the same on all instances. Maybe I've there a missunderstanding
> and I can leave the FSM actors on system, generating clones on other
> instances and the persistence handles the data exchange on all these
> instances.
>
> Could somebody explain me what is the right decision?
>
> Best regards
> Torsten
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/additional/faq.html
> >> Search the archives: https://groups.google.com/grou
> p/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.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> >> 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 

Re: [akka-user] How to decline a particular SnapshotOffer on recovery?

[Justin du coeur]

A thought:

On Fri, Oct 27, 2017 at 6:27 AM, Stephen Kennedy  wrote:

> Sorry to resurrect an old topic, but I am having the exact same conundrum.
>
> My particular use case is:
> - I have a persistent actor that is similar to a FSM  with a "state" enum
> that represents its current state
> - Some additional business logic has lead to me wanting to inspect the
> previous states the actor has gone through to get to the current state - so
> I now want to keep a list of historical states in that actor
> - This seems perfect for the Event sourcing model, I have all the
> historical events so I can recreate the historical states in recovery
> - But - snapshots get in the way of this! - to recover the historical
> states from a snapshot I need to persist them to my snapshot, but old
> snapshots won't have this which will then break my business logic
>

I do this heavily -- the *history* of my Actor is available at the user
level, so that they can examine previous states, undo previous actions, and
stuff like that.

But it doesn't belong in the same Actor.  I handle this in a sibling Actor,
which uses Persistence Query to read in and process the history, and
exposes it that way.  That has nothing to do with snapshots (indeed,
they're not even available); it's a simple read of the history.

Persistence Query is a useful tool, and the right way to do "history"-ish
features...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is Akka Streams an FRP Solution?

[Justin du coeur]

Precisely what do you think FRP means?  In my observation, it's a buzzword
that is used rather loosely, with a variety of definitions...

On Thu, Oct 26, 2017 at 6:40 PM, Rambabu Posa 
wrote:

> Hi
>
> We know Akka Toolkit is Reactive Solution. Can we also say that Akka
> Streams is an FRP Solution?  Will it support FRP?
> How it support FRP?
>
> Many thanks,
> Ram
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: "Event driven workflow engine" in Akka - any experiences?

[Justin du coeur]

I'm not sure I see the problem.  Each one is persisting its *own* state --
its parent is pretty much irrelevant.  When one goes down, you bring it
back up (theoretically to the same state again) when you need it.

Mind, I use Persistence more or less exclusively in conjunction with
Sharding, so the down/up thing is pretty much transparent -- it is *normal*
(indeed, deliberate) for these Actors to be taken down when they go idle,
and they simply spring back to life again when they are next accessed.
Since each one returns to its most recent state, there isn't much of a
consistency issue.  (Save when messages have gone astray, and that is
something you *always* have to be prepared for in Akka -- you should always
design around the assumption of unreliable delivery.)

On Sat, Oct 21, 2017 at 4:35 AM, Bertil Muth 
wrote:

> I see. That makes sense. Would that mean that actors whose state depends
> on each other need to be children of the same parent, in order to resurrect
> all of them when one of them goes down? Or how is this potential
> inconsistency problem solved? Should their state be independent?
>
> --
> >>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: "Event driven workflow engine" in Akka - any experiences?

[Justin du coeur]

On Fri, Oct 20, 2017 at 8:22 AM, Bertil Muth 
wrote:

> That would mean that developing such an application could be quite
> different from developing a local application,
> where state is spread over many objects. (Or rather, the only way to
> change state in another object would be that
> the other object is an Actor as well and it receives an event that is
> raised. But what if it does not receive the event
> during replay? Wouldn't that corrupt the overall state of the application?)
>

In such a situation, that other Actor would typically *also* be
Persistent.  That's kind of the point of Actor-centric design: each Actor
is responsible for its own bit of state.  I find that it's not at all
unusual to have a lot of different Persistent Actors...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka | Work - Pull pattern running into problem !

[Justin du coeur]

Yeah -- this approach (which is fairly common) tends to mask the underlying
problem until things get a little more pathological, and then you just get
a bigger explosion...

On Thu, Oct 12, 2017 at 4:20 PM, Bwmat  wrote:

> If, on average, your producers Don't outrun your producers, and only do so
> in limited bursts, you could try storing some of the buffered data on disk,
> until the burst is over?
>
> Hard to imagine it would be reliable though
>
> --
> >>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka | Work - Pull pattern running into problem !

[Justin du coeur]

There's basically no solution to the producer outrunning the consumers.
The point of Akka Streams is to signal upstream that things are fully
loaded, so that the producer knows to slow down; that makes the whole
system more robust, and puts the problem where it belongs, at the head end.

But if there is no way to slow down production, you *have* to build in
enough capacity to handle it, or sooner or later you're going to run out of
buffer space -- there's no magical solution to that...

On Thu, Oct 12, 2017 at 10:19 AM, Kunal Ghosh 
wrote:

> yes producer is fast and consumers can not keep up with it that is why i
> used work-pulling pattern.
> Does akka stream has solution for producer out running the consumer??? or
> is there any other option???
>
>
> On Thursday, October 12, 2017 at 7:30:21 PM UTC+5:30, Bwmat wrote:
>>
>> Sounds like your producers are out running your consumers?
>>
>> Have you looked at akka streams?
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Short lived persistent actors and deletion

[Justin du coeur]

On Fri, Oct 6, 2017 at 10:40 AM, Ole Hjalmar Herje 
wrote:

> Ok. Do you know if it is it supported by other journal plugins? And is
> leveldb stil not considered "production ready"?
>

LevelDB wasn't really *designed* to ever be "production ready", as far as I
know.  It doesn't scale (by design), and it's reportedly prone to data
corruption when things go wrong.

Personally, given the existence of ccm , I
don't think it's worth bothering with LevelDB even for development.  There
are better options...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-cluster-sharding] Create shard entity actors based checking some condition.

[Justin du coeur]

Sure, but I think you're thinking about it incorrectly.  Don't worry about
creating the Sharding entity itself, which has no lasting effect --
instead, focus on not *persisting* anything unless the wallet is already
valid.  The preStart idea isn't bad, but probably expensive (assuming the
external DB is a bit expensive, which is typically true), so you don't want
to *always* check it, just when the wallet is new.

Instead, I would send a message to the wallet, which causes the wallet
entity to be created and to "recover".  Recovery finds that there is no
history for the wallet, so post-recovery the actor checks the external DB.
If it finds that the wallet has been created, great -- it persists an event
that says so.  Otherwise it returns a message saying "this wallet doesn't
exist yet", and kills itself.

On Mon, Sep 25, 2017 at 9:47 AM, Evgeny Shepelyuk 
wrote:

> Hello
>
> I'd like to implement cluster sharding enabled service with following
> scenario
>
> # *Wallet *service manages users' wallets
> # Each *wallet* is represented as persistent actors / shard entity
> # Shard clients are sending deposit / withdraw commands to wallets
> # Wallet creation is a dedicated business procedure and can't be just a
> creating new actor by *ShardRegion *actor
>
> What we're trying to achieve is
>
> # before processing deposit / withdraw commands to check if some external
> DB contains record about *wallet *registration
> # create shard entity only if *wallet *is registered before
>
> Is this a valid scenario for akka cluster sharding and if yes - how can
> this be achieved ?
>
> Unfortunately haven't find proper information in Internet., the only
> option I see now - is to check external DB in preStart method of shard
> entity.
>
>
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Removing programmatically and dynamically Node from Cluster

[Justin du coeur]

On Fri, Sep 15, 2017 at 9:48 AM, Sebastian Oliveri 
wrote:

> I wrote your implementation but as a local actor in every node to live in
> memory as long as the instance is up and running.
>
> I thought about possible border cases regarding to model it as a local
> actor but I can not come up with a case that would break the scenario.
>
> I am thinking about starting with 3 instances (always odd numbers) and in
> case of a network partition that leaves the cluster with a size of two a
> second network partition would not be fixed by the split brain resolver and
> in this case one of those nodes should be Down using the HTTP management.
>
> Do you know any border case that would break when using local actors as
> split brain resolvers?
>

No, but keep in mind I'm not a deep expert here -- I understand the problem
well enough, but I'm not remotely as well-versed in the solutions as the
Akka Team themselves.

My system is actually using local actors in much the same way you describe
-- there's a cluster-singleton Coordinator, but a single local Manager per
node, and the Manager does the SBR work.  Indeed, I *think* it's strictly
necessary to have a single local actor per-node for any good solution.
 (Although, again, I'm not an expert.)

In the long run, I have some airy theories about using AWS to make the
architecture more robust (since AWS theoretically has a "god's-eye" view of
which nodes are up), but I haven't spent enough time on that yet to figure
out whether it really works as a solution.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Removing programmatically and dynamically Node from Cluster

[Justin du coeur]

On Wed, Sep 13, 2017 at 5:55 PM, Sebastian Oliveri 
wrote:

> Am I in the right direction? I was thinking more in a server that crashes
> more than a vertical network partition affecting many nodes...
>

The problem is, how do you tell the difference?  Specifically, when you get
a network partition, it *looks* to each node like the other one(s) have
crashed.  So if they then down each other, you have split-brain.

That's the key issue: from the *outside*, it's usually impossible to tell
the difference between a dead node and a network partition.  If the node is
dead, then sure, you want to down it.  But if it's a network partition, you
must *not* down it unless it has matching logic that causes it to
deliberately crash *itself*.  Without that, you're likely to get
split-brain.

I may be misunderstanding you, but keep in mind that all the infamous
auto-down does is detect an Unreachable member, *wait* a few seconds, and
then down it.  It sounds like you're suggesting doing the same thing
without the wait, but the results will be the same...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Removing programmatically and dynamically Node from Cluster

[Justin du coeur]

If I'm understanding you correctly, that's not really any better than the
broken auto-down system built into Scala.  You really need something
smarter for production.

*Conceptually*, there is a very straightforward strategy: when a node sees
nodes become unreachable, it checks whether it can see more than half of
the nodes it expects.  If it can, it assumes that things are otherwise
okay, and marks the unreachable node as down; if not, then it assumes that
it is on the "losing" side of a network partition, and self-destructs.

That's easy to explain, but implementing all the details properly is
non-trivial.  (My own implementation

has been in production for a while, but I suspect still has problems with
some edge cases, and I plan to replace it with something more AWS-aware.)
 You want some delay before doing this, so that brief network hiccups don't
cause your nodes to self-destruct, and figuring out the correct definition
of "half" can be complex if the network isn't fixed-size.  But something
along those lines is pretty necessary if you want a decently stable cluster
for production...

On Wed, Sep 13, 2017 at 2:54 PM, Sebastian Oliveri 
wrote:

> Hi,
>
> I have a cluster with a few nodes running clustered sharding persistent
> actors that I am close to deploy in prod
> I tested that once a node is unreachable all the persistent actors inside
> it are unreachable as well until human intervention takes places to Down
> that unreachable node for the cluster to restore those actors in other
> nodes.
> I am not considering the commercial split brain strategies so I have no
> other option than doing it manual.
> The worst case would be for the human intervention to take long and so for
> clients to be unable to interact with the actors in a considerable time
> window.
> I was thinking about having an actor in each node just like the
> SimpleClusterListener written in the akka cluster docs and somehow to
> mark as Down the unreachable node when handling the command:
> UnreachableMember using the akka management API through HTTP (no matter
> if it was network partition or crash)
> I don´t know if this is possible because I didn't read as a solution so
> far. The worst case would be that if it was actually a network partition
> that will be eventually restore the unreachable node will be Down and
> removed from the cluster and all its persistent actors (maybe thousands,
> millions) would be restored again in other nodes, am I right?
>
>   def receive = {case UnreachableMember(member) =>
>   akkaManagement.markAsDown(member.address) // something like this  }
>
>
> Is this OK as a solution to avoid human intervention?
>
> Thanks,
> Sebastian
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Sending multiple classes as message

[Justin du coeur]

If you're using Scala, just send the three sub-messages as a Tuple3 --
there's no real effort involved.  Or add a case class for it: creating case
classes is near-trivial, and this sort of thing is what they're for.

If you're in Java, then yeah, you probably need to create a wrapper class...

On Tue, Sep 12, 2017 at 10:21 PM,  wrote:

> Hello all,
>
> Is there a way to send multiple classes to Akka actors in a single
> tell/ask call?
>
> Say, actor X wants to send a message to Actor Y with three classes a,b,c,
> and actor Y takes these 3 classes (a,b,c) and invokes a method y1 with
> parameters (a,b,c). Is wrapping classes a,b,c with a new class A i.e.
> create a class A with fields as a,b and c the only way or is there any
> other better way to do so?
>
> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] AtLeastOnceDelivery: access to the original sender and error handling

[Justin du coeur]

On Thu, Aug 31, 2017 at 7:15 PM, Sebastian Oliveri 
wrote:

> Hi! I am sort of new to Akka. I am implementing DDD around clustered
> actors. Since they are clustered I need to make sure they receive the
> messages at least once. Because of that I have an implicit actor in a Play
> controller which calls my target actor the aggregate passing through a
> "proxy" Actor which implements AtLeastOnceDelivery. So this looks like: A
> -> B -> C, and C replies with an ACK confirm to B. In that precise moment I
> need to reply to A the response so it is the other way around: C -> B -> A.
> But given the context when B received the ACK from C, the sender is B and
> not A... so I kind of handled this by keeping the A actor path in the event
> messages so I can get A actorRef at anytime inside B and reply to the
> temporary actor which fulfills the Ask future in Play controller. Is this a
> common practice to keep an Actor path within the context of Messages to be
> able to get a Sender from a path?
>

Actually, it's legal, easier and more common to simply stick A's ActorRef
("self", rather than the path) into the message.  Not only is that a
legitimate pattern, it's going to become the primary way of doing things in
the upcoming Akka Typed.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Auto downing and Akka Cluster

[Justin du coeur]

On Wed, Aug 30, 2017 at 11:24 AM, Igor Baltiyskiy  wrote:

> I'd like to clarify the warning given in the documentation:
>
> > We recommend against using the auto-down feature of Akka Cluster in
> production. This is crucial for correct behavior if you use Cluster
> Singleton 
> or Cluster Sharding
> ,
> especially together with Akka Persistence
> . For Akka
> Persistence with Cluster Sharding it can result in corrupt data in case of
> network partitions.
> (http://doc.akka.io/docs/akka/2.5/scala/cluster-usage.html#
> auto-downing-do-not-use-)
>
> This passage raises several questions:
>
> 1. Does it mean that auto-downing is *always* a bad idea? Or is it only a
> bad idea when using Cluster Singleton and Cluster Sharding, so that if I'm
> not using them, using auto-downing in production is perfectly fine?
>

It's a more or less *guaranteed* disaster in the long run with Cluster
Sharding; it's only a *likely* disaster without, depending on what your app
is doing.  But personally, I think it should never, ever be used.

Look at it this way: the problem with auto-down is that it is likely, in
the long run, that you will eventually wind up in a Split Brain situation,
with two or more disconnected clusters, each of which thinks that it is The
One True Cluster and Source of Truth.  This will usually happen in a
realistic network, due to the vagaries of network traffic and the
fundamental dumbness of the auto-down algorithm.

Now, ask yourself: if this is acceptable -- if it is okay to sometimes
*not* be a Cluster -- why are you using Clustering at all?

Basically, if your nodes need to be able to share information in a
consistent way, you need Clustering, which means that Split-Brain is
deadly, which means that you must not use auto-down.  If the nodes *don't*
need to be sharing information, you probably shouldn't be bothering with
Clustering at all, so auto-down is irrelevant.

That's the heart of the argument, and why I personally think auto-down
should be simply excised from the library entirely: it is *never* safe to
use in anything more than a toy environment, and its existence just
confuses people...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Problem of routing different java objects with same id to same actor

[Justin du coeur]

I'd recommend looking into Akka Cluster Sharding.  Even if you're not on a
cluster, this is usually the most straightforward way to get messages
routed consistently based on a key...

On Wed, Aug 30, 2017 at 5:37 AM, Wei Guo (SH-LTS)  wrote:

> Hi everyone,
>
> I'm a newbie for Akka, for load balance consideration, I created 5 actors
> to handle the incoming requests, but one important requirement is that
> different types of objects with same key(Symbol of Quote/Trade/RefData in
> my code below) should be routed to same actor, after searching Akka doc, 
> ConsistentHashingRoutingLogic
> is a choice
>
> After running code with testing data, same type of objects were routed to
> same actor, but for different types of objects(Quote,Trade, RefData with
> same Symbol),  it doesn't work as i expected, they were routed to different
> actors
> eg:
> Quote quote1,quote2;
> quote1.setSymbol("001");// quote1 & quote2 were routed to same
> actor(h0)-- no issue
> quote2.setSymbol("001");
>
> Trade trade;
> trade.setSymbol("001");  // trade was sent to different actor (h1)
>-- problem
>
> RefData refData;
> refData.setSymbol("001");// refData was sent to different actor (h2)
> -- problem
>
> Can anyone provide any suggestion to route them into same actor ? Thanks a
> lot.
>
> int nOfHisActor = 5;
>
> actorSystem = ActorSystem.create("lunar");
> String[] pathArray = new String[nOfHisActor];
> for (int i = 0; i < nOfHisActor; i++) {
> String path = "h" + i;
> pathArray[i] = "/user/" + path;
> actorSystem.actorOf(Props.create(HisMarketDataActor.class), path);
> }
> List paths = Arrays.asList(pathArray);
> hisInfoActor = actorSystem.actorOf(new 
> ConsistentHashingGroup(paths).withHashMapper(o -> {
> if (o instanceof Quote) {
> return ((Quote) o).getSymbol();
> } else if (o instanceof Trade) {
> return ((Trade) o).getSymbol();
> } else if (o instanceof RefData) {
> return ((RefData) o).getSymbol();
> }
> return null;
> }).props(), "price");
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] org.apache.spark.SparkException: Task not serializable

[Justin du coeur]

I don't know Spark, so I don't know quite what this is trying to do, but
Actors typically are not serializable -- you send the ActorRef for the
Actor, not the Actor itself.  I'm not sure it even makes any sense
semantically to try to serialize and send an Actor...

On Thu, Aug 3, 2017 at 11:49 PM, 周梦想  wrote:

>
> my main file
> /**
>  * Author: zhouhh
>  * Date  : 2017-06-26
>  *
>  * main file，start web server, init akka ，spark streaming
>  */
> object WebServer extends Directives {
>
>   val log = Logger(LoggerFactory.getLogger("WebServer"))
>   log.info("==enter WebServer init")
>
>   //init ActorSystem
>   implicit val system = ActorSystem("recommed_System")
>   implicit val materializer = ActorMaterializer()
>   implicit val executionContext: ExecutionContextExecutor =
> system.dispatcher
>
>   //init spark streaming
>   val sparkConf: SparkConf = new SparkConf().setMaster(Config.
> sparkMaster).setAppName("WebUserActionConsumer")
>   val ssc: StreamingContext = new StreamingContext(sparkConf,
> Seconds(Config.batchDuration))
>
>   //init routes
>   val routes: Route = BaseRoutes.baseRoutes ~
> new RcmdRoutes().rcmdRoutes ~
> SimpleRoutes.simpleRoutes
>
>   def main(args: Array[String]) {
>
> log.debug("==enter WebServer beginning")
>
>
> val userActConsumerActor = system.actorOf(Props(new
> UserActConsumerActor(ssc)), name = "UserActConsumerActor")
>
> userActConsumerActor ! UserActMsgConsumer
>
>
> val bindingFuture = Http().bindAndHandle(routes, Config.host,
> Config.port)
>
> log.info(s"Server online at ${Config.host}:${Config.port}/\nPress
> RETURN to stop...")
>
> ssc.start()
> ssc.awaitTermination()
>
> log.info(s"Server online at ${Config.host}:${Config.port}/\nPress
> RETURN to stop...")
>
> StdIn.readLine() // let it run until user presses return
> bindingFuture
>   .flatMap(_.unbind()) // trigger unbinding from the port
>   .onComplete(_ => system.terminate()) // and shutdown when done
>
>   }
>
>
> my spark streaming kafka consumer file
>
> class UserActConsumerActor(ssc: StreamingContext) extends Actor {
>   val logger = Logger(LoggerFactory.getLogger("UserActConsumerActor"))
>
>   val userActMsgParseActor: ActorRef = 
> context.actorOf(Props[UserActMsgParseActor],
> name = "UserActMsgParseActor")
>
>   def receive = {
>
> case UserActMsgConsumer => parse()
> case e => logger.info(s"error receive of user act msg:  $e")
>   }
>
>   val stream: InputDStream[ConsumerRecord[String, String]] =
> KafkaUtils.createDirectStream(
> ssc,
> PreferConsistent,
> Subscribe[String, String](Config.useracttopics.split(","),
> Config.kafkaParams)
>   )
>
>   def parse(): Unit = {
>
> stream.foreachRDD(rdd => rdd.foreach(x => {
>   logger.info("==user act value:\n")
>   logger.info(x.value()) //value is String
>
>   Try {
> x.value().parseJson.convertTo[UserActMsg]
>   } match {
> case Success(msg) => userActMsgParseActor ! msg
> //case Success(msg) => context.parent ! msg
> case Failure(x) => logger.error(s"$x") //println(s"$x") //
> //case Success(msg) => println(msg)
>
>   }
>
> }))
>   }
>
> }
>
>
> when i run webserver, it will report the error as the Title repeatly.
>
> 17/08/04 11:40:15 ERROR JobScheduler: Error running job streaming job
> 1501818015000 ms.0
> org.apache.spark.SparkException: Task not serializable
> at org.apache.spark.util.ClosureCleaner$.ensureSerializable(
> ClosureCleaner.scala:298)
> at org.apache.spark.util.ClosureCleaner$.org$apache$
> spark$util$ClosureCleaner$$clean(ClosureCleaner.scala:288)
> at org.apache.spark.util.ClosureCleaner$.clean(ClosureCleaner.scala:108)
> at org.apache.spark.SparkContext.clean(SparkContext.scala:2287)
> at org.apache.spark.rdd.RDD$$anonfun$foreach$1.apply(RDD.scala:917)
> at org.apache.spark.rdd.RDD$$anonfun$foreach$1.apply(RDD.scala:916)
> at org.apache.spark.rdd.RDDOperationScope$.withScope(
> RDDOperationScope.scala:151)
> at org.apache.spark.rdd.RDDOperationScope$.withScope(
> RDDOperationScope.scala:112)
> at org.apache.spark.rdd.RDD.withScope(RDD.scala:362)
> at org.apache.spark.rdd.RDD.foreach(RDD.scala:916)
> at com.ronglian.actor.UserActConsumerActor$$anonfun$parse$1.apply(
> UserActConsumerActor.scala:46)
> at com.ronglian.actor.UserActConsumerActor$$anonfun$parse$1.apply(
> UserActConsumerActor.scala:46)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$
> foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:628)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$
> foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:628)
> at org.apache.spark.streaming.dstream.ForEachDStream$$
> anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(ForEachDStream.scala:51)
> at org.apache.spark.streaming.dstream.ForEachDStream$$
> anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:51)
> at 

Re: [akka-user] Akka Persistence and replaying of all events

[Justin du coeur]

You mention that you're looking at Persistence, but you didn't mention
Cluster Sharding.  For problems like these, you more often than not want
both.  If you haven't dug into Sharding yet, I recommend doing so -- it may
help clarify the common patterns.

On Wed, Jul 26, 2017 at 3:56 AM, Leonti Bielski  wrote:

> Hi!
>
> I'm looking at Akka Persistence for Event Sourcing and I have a couple
> questions that I couldn't find an answer to.
>
> Lets say I have an aggregate named User
>
> 1. As far as I understand persistenceId would be an aggregate id, which
> is an id of a user.
> Let's say I have a million users - will Akka start 1 million actors when I
> start the server or it only creates actors on demand?
>
> 2. How do I ask for all of the event for all time?
> For example if I decide to create a new View/projection I would like to
> populate all of the data.
> Or if I have another system which would like to populate it's cache using
> my events.
> Is it possible with Akka Persistence?
>
> In our custom-built Event Store based on SQL db we have global sequence
> id, so if I want to rebuild a view from scratch I would just do a query for
> all events starting form a certain sequence id.
> As far as I understand in Akka Persistence sequence number is only valid
> inside of a single stream/aggregate id.
> I see how I can replay events for a particular aggregate(user in my case),
> but I would need to know the user id in the first place.
> Not sure how would I do that not only with Akka Persistence but in general
> with Event Stores which don't have global sequence id so I can't just query
> for all events for all aggregates.
>
> Cheers,
> Leonti
>
>
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Fold a large websocket stream message

[Justin du coeur]

You're using runFold() to just do string concatenation over and over
again?  That's very inefficient, at best; at worst, depending on the size
of the "big" message, you might be hitting memory pressure that is causing
things to crash.  (Or at least, causing a massive amount of garbage
collection that is slowing everything to a crawl.)  You're building strings
and throwing them away, over and over and over again.

Keep in mind, part of the point of streaming is to *avoid* having to have
the entire message in memory at any given time.  If I'm reading this right,
you're not only building the entire message in memory, you're doing it in a
really inefficient way.  I would *guess* that it's spending so much time in
garbage collection that it's not getting to the point of finishing in those
five seconds...

On Sun, Jul 16, 2017 at 4:13 PM, ivan morozov  wrote:

> Hi. I can't manage to fold a big message that is coming over websockets.
> The future just never complete. Reproduce:
>
>val flow: Flow[Message, Message, NotUsed] =
>   Flow.fromSinkAndSource(
> Sink.foreach {
>   case TextMessage.Streamed(stream) =>
> val f = stream.limit(100)
>   .completionTimeout(5000.millis)
>   .runFold("")(_ + _)
> println(Await.result(f,5.second))
> }
>  ,
> Source.empty)
>
>
> Http().singleWebSocketRequest(
>   WebSocketRequest("wss://api.sandbox.gemini.com/v1/marketdata/ethbtc"
> ),
>   flow)
>
> Any ideas why?
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka cluster sharding performance issue [creating sharding actor very very slow]

[Justin du coeur]

Are you seeing this once, or are you seeing this slowness in steady-state?
>From the log, this looks like it's the first call -- the shard doesn't
exist, and the system is still setting up.  That *can* take a while, yes:
it's not just allocating one Actor, it's probably allocating several in a
hierarchy.  But once the system is in reasonably steady-state, in my
experience, it's much faster than that.

In general, sending one message isn't going to give you an accurate view of
anything -- sending several thousand messages, to several hundred Actors,
is going to give you a much more realistic understanding of how long things
take...

On Fri, Jul 14, 2017 at 12:22 AM, Chaohua Yuan  wrote:

> Hi,
>
> I am trying to build a backend system with akka cluster and cluster
> sharding. Everything goes well except the performance issue when using akka
> cluster sharding.
>
> It seems creating the actor with shard region actor is extremely slow(The
> shard actor is created when call region actor tell.). Have any one met this
> issue before or it is some thing the sharding works.
>
>
>
> My test actor in JAVA ...
>
> public class AuthService extends BaseService {
> public AuthService(ActorRef serviceActor) {
> super(serviceActor);
> }
>
> @Override
> public Receive createReceive() {
> return receiveBuilder()
> .match(AuthRequest.class, authRequest -> {
> getContext().system().log().info("Get auth request from 
> client {}", authRequest.getToken());
> this.getServiceActor().tell(authRequest, getSender());
> }).build();
> }
>
> public static void config(ActorSystem system) {
> ClusterSharding.get(system)
> .start(AuthServiceActor.SHARD,
> Props.create(AuthServiceActor.class, 
> AuthServiceActor::new),
> ClusterShardingSettings.create(system),
> AuthServiceActor.shardExtractor()
> );
>
> ActorRef actorRef = 
> ClusterSharding.get(system).shardRegion(AuthServiceActor.SHARD);
> ActorRef authService = system.actorOf(Props.create(AuthService.class, 
> actorRef), "authService");
> ClusterClientReceptionist.get(system).registerService(authService);
> }
> }
>
>
>
> The sharding actor:
>
>
> public class AuthServiceActor extends AbstractActor {
> public static final String SHARD = "authService";
>
> @Override
> public void preStart() throws Exception {
> super.preStart();
> getContext().system().log().info("Auth service start, {}", 
> getSelf().path());
> }
>
> @Override
> public void postStop() throws Exception {
> super.postStop();
> getContext().system().log().info("Auth service stop {}", 
> getSelf().path());
> }
>
> public Receive createReceive() {
> return receiveBuilder()
> .match(AuthRequest.class, authRequest -> {
> getContext().system().log().info("Receive auth message 
> from user {}", authRequest.getToken());
> // No logic here, return back token as name and id.
> String userId = authRequest.getToken();
> ActorRef sender = getSender();
> sender.tell(new AuthResponse(userId, userId), getSelf());
> getContext().system().log().info("Send back auth response 
> {}", userId);
> })
> .build();
>
> }
>
> public static ShardRegion.MessageExtractor shardExtractor() {
> return new AuthServiceActor.AuthServiceShardMessageExtractor();
> }
>
> private static class AuthServiceShardMessageExtractor extends 
> ShardRegion.HashCodeMessageExtractor {
> private static final int shardNumber = 64;
>
> AuthServiceShardMessageExtractor() {
> super(shardNumber);
> }
>
> @Override
> public String entityId(Object o) {
> if (o instanceof AuthRequest) {
> return ((AuthRequest) o).getToken();
> }
> return null;
> }
> }
> }
>
>
> User Actor
>
>
> public class UserActor extends AbstractActor {
> public final static String SHARD = "User";
> private ActorRef sessionActor;
>
> @Override
> public void preStart() throws Exception {
> super.preStart();
> 
> getContext().setReceiveTimeout(scala.concurrent.duration.Duration.create(300, 
> TimeUnit.SECONDS));
> getContext().system().log().info("User actor start {}", 
> self().path());
> }
>
> @Override
> public void postStop() throws Exception {
> super.postStop();
> getContext().system().log().info("User actor stop", self().path());
> }
>
> @Override
> public Receive createReceive() {
> return receiveBuilder().match(RegisterSession.class, registerSession 
> -> {
> ActorRef 

Re: [akka-user] Re: Akka Cluster Pub/Sub performance for chat-room like applications

[Justin du coeur]

(I should note: I don't use Akka Pub/Sub myself, but I'm wondering whether
Cluster Sharding actually fits your use case well.  Depending on the
details, it might.)

On Thu, Jul 13, 2017 at 8:55 AM, Justin du coeur <jduco...@gmail.com> wrote:

> Question: how many subscribers does a "topic" typically have?  Also, what
> are your reliability requirements?
>
> On Thu, Jul 13, 2017 at 8:54 AM, Alexander Lukyanchikov <
> alexanderlukyanchi...@gmail.com> wrote:
>
>> Sure. It is Java + Play + Akka. AWS environment, c4.xlarge machines (4
>> CPU, 8 Gb RAM, 750 Mbs bandwidth)
>>
>>
>> On Thursday, July 13, 2017 at 2:15:28 PM UTC+3, MJ wrote:
>>>
>>> Can you let us know the tech stack.
>>>
>>> On Thursday, July 13, 2017 at 4:38:19 PM UTC+5:30, Alexander
>>> Lukyanchikov wrote:
>>>>
>>>> Hi, we are building a message processing system, which is basically
>>>> looks like a classic chat room:
>>>>
>>>> ~ 1 million devices are connected via websockets to a dozen of nodes
>>>> - each of them subscribes on a number of topics
>>>> - each of them publishes updates to the topics, and we should deliver
>>>> these updates to subscribed devices
>>>>
>>>> The problem is, a number of topics is huge, like x100 times more than a
>>>> number of devices.
>>>>
>>>> Right now we are using Redis to store device-to-subscription and
>>>> device-to-node relations.
>>>> On each topic update, we are looking in cache to find all devices to
>>>> notify and node addresses, where these devices are connected at the moment.
>>>>
>>>> We are not using Akka Cluster yet, but looks like it's Pub/Sub
>>>> functionality perfectly matches with our case and we can get rid of our
>>>> logic and cache.
>>>>
>>>> *The only question, is it capable to manage tens of millions of topics?
>>>> Would it perform better then our current solution?*
>>>>
>>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Cluster Pub/Sub performance for chat-room like applications

[Justin du coeur]

Question: how many subscribers does a "topic" typically have?  Also, what
are your reliability requirements?

On Thu, Jul 13, 2017 at 8:54 AM, Alexander Lukyanchikov <
alexanderlukyanchi...@gmail.com> wrote:

> Sure. It is Java + Play + Akka. AWS environment, c4.xlarge machines (4
> CPU, 8 Gb RAM, 750 Mbs bandwidth)
>
>
> On Thursday, July 13, 2017 at 2:15:28 PM UTC+3, MJ wrote:
>>
>> Can you let us know the tech stack.
>>
>> On Thursday, July 13, 2017 at 4:38:19 PM UTC+5:30, Alexander Lukyanchikov
>> wrote:
>>>
>>> Hi, we are building a message processing system, which is basically
>>> looks like a classic chat room:
>>>
>>> ~ 1 million devices are connected via websockets to a dozen of nodes
>>> - each of them subscribes on a number of topics
>>> - each of them publishes updates to the topics, and we should deliver
>>> these updates to subscribed devices
>>>
>>> The problem is, a number of topics is huge, like x100 times more than a
>>> number of devices.
>>>
>>> Right now we are using Redis to store device-to-subscription and
>>> device-to-node relations.
>>> On each topic update, we are looking in cache to find all devices to
>>> notify and node addresses, where these devices are connected at the moment.
>>>
>>> We are not using Akka Cluster yet, but looks like it's Pub/Sub
>>> functionality perfectly matches with our case and we can get rid of our
>>> logic and cache.
>>>
>>> *The only question, is it capable to manage tens of millions of topics?
>>> Would it perform better then our current solution?*
>>>
>> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Typed and MDC

[Justin du coeur]

Oh, sweet -- ExtensibleBehavior looks enormously useful...

On Mon, Jul 10, 2017 at 9:29 AM, Konrad 'ktoso' Malawski 
wrote:

> Once I wrote the response I though that for using the library directly
> you'll also want to know about the possibility to implement:
>
>
> /**
>  * Extension point for implementing custom behaviors in addition to the 
> existing
>  * set of behaviors available through the DSLs in 
> [[akka.typed.scaladsl.Actor]] and [[akka.typed.javadsl.Actor]]
>  */
> abstract class ExtensibleBehavior[T] extends Behavior[T] {
>   /**
>* Process an incoming [[Signal]] and return the next behavior. This means
>* that all lifecycle hooks, ReceiveTimeout, Terminated and Failed messages
>* can initiate a behavior change.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveSignal(ctx: ActorContext[T], msg: Signal): Behavior[T]
>
>   /**
>* Process an incoming message and return the next behavior.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveMessage(ctx: ActorContext[T], msg: T): Behavior[T]
>
> }
>
>
> In which way you should be able to "wrap" any other behaviour and to the
> MDC clear in the right place hm...
>
> Anyway, like I said, not a solved problem yet.
>
> -- Konrad
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to download and install newest Akka

[Justin du coeur]

Ahhh -- okay, that's kind of a pain.  I haven't done it myself, but if the
computer is truly isolated, I *think* that means you need to do everything
as unmanaged dependencies, as described in the sbt documentation
<http://www.scala-sbt.org/0.13/docs/Library-Dependencies.html>.  As for
where you find these libraries to download, the magic keyword you are
looking for is Maven -- that's the central system that is used to access
most open-source libraries.  You can download them from mvnrepository.com,
a searchable site for Maven -- for example, here's the page of Akka
libraries <http://mvnrepository.com/search?q=akka>.  If you drill into
that, you can find the actual JAR files to download.

I believe it's also possible to set up a local Maven proxy for a company,
but I honestly know nothing about how that's done.

All of this is kind of a nuisance -- there is a lot more manual maintenance
to do, and it's easy to make mistakes, so it's not recommended unless you
have no choice.  (A typical complex Akka application can involve dozens or
even hundreds of libraries, due to transitive dependencies -- there is a
lot of ecosystem here, and it's broken into many interconnected libraries.)
 But yes, I believe it can be worked around when necessary.

Possibly others here know of ways to make it less of a hassle...

On Sat, Jul 8, 2017 at 12:20 PM, Eras Rasmuson <eras.rasmu...@gmail.com>
wrote:

>
> But if the network access is not available, it is working badly or
> necessary https-addresses used by sbt are blocked ?
> That was real case of one my computer in my work place.
>
> How to get Akka working in that case (because sbt can not download
> automatically) ?
>
> 
> Eras
>
> lauantai 8. heinäkuuta 2017 18.19.25 UTC+3 Justin du coeur kirjoitti:
>>
>> Just to give the critical high point, so you go into the documentation
>> knowing what you're looking at: when you are writing a Scala program, you
>> don't manually download much.  Instead, you write an sbt file, which
>> *describes* what this program depends upon.  When you compile the program
>> using sbt, it *automatically* downloads the relevant bits from the public
>> servers.
>>
>> So all you need to download and install are a current version of the Java
>> Runtime Environment (which Scala runs on), and sbt, as described in the sbt
>> documentation that Konrad pointed to.  After that, sbt will do all the
>> downloading and installing, as needed.
>>
>> And yes, the source code for Akka is found on GitHub.  But you probably
>> don't care about that much -- you only download and build Akka manually if
>> you want to change Akka itself.  For now, you want to let sbt take care of
>> it...
>>
>> On Sat, Jul 8, 2017 at 4:24 AM, Konrad “ktoso” Malawski <
>> konrad@lightbend.com> wrote:
>>
>>> Akka is just a Scala/Java library, you’d use it like any other Scla/Java
>>> library.
>>> So you could add it as dependency in your maven file, or first learn how
>>> to use sbt: http://www.scala-sbt.org/ and to the same there.
>>>
>>> Akka dependencies are listed on http://akka.io/docs/
>>>
>>> Happy hakking
>>>
>>> — Konrad
>>>
>>>
>>> On 8 July 2017 at 16:59:30, Eras Rasmuson (eras.r...@gmail.com) wrote:
>>>
>>>
>>> Ok. I would want to use Akka with Scala and its tools (like sbt), but i
>>> am a novice with Scala.
>>>
>>> Is it possible to get Akka from GitHub ?
>>> https://github.com/akka/akka
>>>
>>> 
>>> Eras
>>>
>>>
>>> lauantai 8. heinäkuuta 2017 0.01.18 UTC+3 Justin du coeur kirjoitti:
>>>>
>>>> I think you're misunderstanding what Akka is -- there's nothing that
>>>> you "download and install", at least not usually.  It's a library, that you
>>>> use in the context of a larger program.  How you link it into that program
>>>> depends on how you're writing that program -- what language and tools you
>>>> are going to be using.  But the download process is generally handled by
>>>> your build tools: it's quite rare to download Akka manually...
>>>>
>>>> On Fri, Jul 7, 2017 at 4:38 PM, Eras Rasmuson <eras.r...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I have not found a clear guidance how to download and install newest
>>>>> (full) version of Akka (to Windows).
>>>>>
>>>>> Could anyone give a hint how to do that ?
>>>>>
>>>>> PS. I have only found:
>>>>

Re: [akka-user] How to download and install newest Akka

[Justin du coeur]

Just to give the critical high point, so you go into the documentation
knowing what you're looking at: when you are writing a Scala program, you
don't manually download much.  Instead, you write an sbt file, which
*describes* what this program depends upon.  When you compile the program
using sbt, it *automatically* downloads the relevant bits from the public
servers.

So all you need to download and install are a current version of the Java
Runtime Environment (which Scala runs on), and sbt, as described in the sbt
documentation that Konrad pointed to.  After that, sbt will do all the
downloading and installing, as needed.

And yes, the source code for Akka is found on GitHub.  But you probably
don't care about that much -- you only download and build Akka manually if
you want to change Akka itself.  For now, you want to let sbt take care of
it...

On Sat, Jul 8, 2017 at 4:24 AM, Konrad “ktoso” Malawski <
konrad.malaw...@lightbend.com> wrote:

> Akka is just a Scala/Java library, you’d use it like any other Scla/Java
> library.
> So you could add it as dependency in your maven file, or first learn how
> to use sbt: http://www.scala-sbt.org/ and to the same there.
>
> Akka dependencies are listed on http://akka.io/docs/
>
> Happy hakking
>
> — Konrad
>
>
> On 8 July 2017 at 16:59:30, Eras Rasmuson (eras.rasmu...@gmail.com) wrote:
>
>
> Ok. I would want to use Akka with Scala and its tools (like sbt), but i am
> a novice with Scala.
>
> Is it possible to get Akka from GitHub ?
> https://github.com/akka/akka
>
> ----
> Eras
>
>
> lauantai 8. heinäkuuta 2017 0.01.18 UTC+3 Justin du coeur kirjoitti:
>>
>> I think you're misunderstanding what Akka is -- there's nothing that you
>> "download and install", at least not usually.  It's a library, that you use
>> in the context of a larger program.  How you link it into that program
>> depends on how you're writing that program -- what language and tools you
>> are going to be using.  But the download process is generally handled by
>> your build tools: it's quite rare to download Akka manually...
>>
>> On Fri, Jul 7, 2017 at 4:38 PM, Eras Rasmuson <eras.r...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> I have not found a clear guidance how to download and install newest
>>> (full) version of Akka (to Windows).
>>>
>>> Could anyone give a hint how to do that ?
>>>
>>> PS. I have only found:
>>> http://dev.lightbend.com/start/?group=akka=akka-quickstart-scala
>>>
>>> 
>>> Eras
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >>>>>>>>>> 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
> 

Re: [akka-user] How to download and install newest Akka

[Justin du coeur]

I think you're misunderstanding what Akka is -- there's nothing that you
"download and install", at least not usually.  It's a library, that you use
in the context of a larger program.  How you link it into that program
depends on how you're writing that program -- what language and tools you
are going to be using.  But the download process is generally handled by
your build tools: it's quite rare to download Akka manually...

On Fri, Jul 7, 2017 at 4:38 PM, Eras Rasmuson 
wrote:

> Hi
>
> I have not found a clear guidance how to download and install newest
> (full) version of Akka (to Windows).
>
> Could anyone give a hint how to do that ?
>
> PS. I have only found:
> http://dev.lightbend.com/start/?group=akka=akka-quickstart-scala
>
> 
> Eras
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Receive value from persistenceActor.tell (msg, send);

[Justin du coeur]

On Fri, Jul 7, 2017 at 3:10 PM, Jan-Terje Sørensen 
wrote:

> I have a API where I want to create a new user, and as a result of this
> API-call i would like to return the User-ID.
> How is it possible to receive a value from a tell? I have looked into
> Futures with no luck. I am trying to avoid Await.result, and solve it with
> a onSuccess. Anyone have a good code example?
>

Well, to begin with, this sort of problem is usually handled with ask(),
not tell() -- you should look into that.  (It's not strictly necessary, but
ask() is usually much less complex than trying to get results back from a
tell().)

And yes, ask() returns a Future, and yes, you should basically never use
Await in real code.  Instead, you need to get comfortable with
Future.map(), which is how you say "When this Future gets a value, do
something".  That and variations of it are the way you deal with messages
from Actors without messing up threading...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Sharded actors sending messages into other shard regions

[Justin du coeur]

On Thu, Jun 29, 2017 at 7:58 PM, Richard Ney  wrote:

> Is there a cleaner way to do this. It seems like overkill to pass the
> shard region proxy into the Props for each Region actor.
>

It's a matter of taste, but I'll note that I handle this through,
essentially, a simple form of dependency injection.  I have a master
"ecosystem" object that provides all the major interfaces, and the various
shard regions (of which I have several) all get accessed through there.

So on the one hand, it's a val that has to be passed into every Actor's
constructor; OTOH, it's *one* parameter that everything hangs off of, so it
scales nicely as the system grows.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-http] Tagless Final and ToResponseMarshallable

[Justin du coeur]

Good luck -- I've been doing a lot with tagless final in my Akka Sharded /
Persistent code, and have the beginnings of a library for that
,
but I've found that *completely* doing away with the Futures is pretty
challenging.  I've gotten it most of the way there, but I still have to
cheat occasionally...

On Tue, Jun 13, 2017 at 12:44 PM, Jeff  wrote:

> I am trying to learn tagless final style to remove concrete monads (ie
> futures) from my code. I have come up with the following strawman
> application (using cats)
>
> class RestaurantRoutes[F[_]: Monad](algebra: RestaurantAlgebra[F]) {
>   import algebra._
>
>   def route: Route =
> path("api" / "v4.0" / "restaurant" / IntNumber) { rid =>
>   get {
> complete(getRestaurantById(rid).map(_.toString).value)
>   }
> }
> }
>
> object RestaurantRoutes {
>   def apply()(implicit ec: ExecutionContext): RestaurantRoutes[FutureOfOption]
> = {
> import cats.instances.future._
>
> new RestaurantRoutes(new RestaurantFutureInterpreter())
>   }
>
> }
>
> the final type of
>
> getRestaurantById(rid).map(_.toString).value
>
> is a
>
> Future[Option[String]]
>
> However, I can't seem to figure out to get that marshalled. A marshaller
> exists for all those types, and had I had concrete types intstead of F[_],
> it would have worked. What is the best way to handle this to prevent
> implementation details from leaking in?
>
> Thanks
> Jeff
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Permanently stopping a persisted single entity in a cluster shard

[Justin du coeur]

Well, yeah -- that's how Sharding works, and how it is *supposed* to work.
If you send a message to a sharded ID, it will start an entity with that
ID.  Passivate and the like are intended, as the name implies, to
*passivate* the Actor -- to turn it off temporarily while it's not doing
anything useful.  Normal use of Cluster Sharding is to use Passivate to
temporarily release resources, but for the Actor to spring back to life
again as soon as it is referenced.  That's basically the point of Sharding.

Seriously, it sounds like you're trying to do something that's deeply
against the normal design of Cluster Sharding.  If you really need to
permanently kill this entity, the only way I see to do that is to record an
"I Am Dead" message in persistence, and when the Actor receives a message,
it hits that message and kills itself again.

Yes, that's a bit inefficient, but I'm not sure how else it could work --
you're presuming magic central knowledge that a particular Entity is
"permanently dead", and that's not a concept that exists in Cluster
Sharding.  If you want to smash an entity flat permanently, such that it
will refuse further communication, you have to implement that yourself...

On Tue, Jun 6, 2017 at 11:04 AM, Yee-Ning Cheng  wrote:

> I currently have an actor that extends PersistentActor and is created
> using cluster sharding as a single entity part of a shard.  After a certain
> amount of time, I want to be able to explicity kill/stop a single entity
> actor permanently.  I have tried using Passivate, explicitly sending a
> PoisonPill and context.stop() on the entity actor as self but none of it
> seems to work.  I am still sending messages to the shard region with the
> same entity id at the time, but they essentially should be ignored but the
> messages seem to restart the actor.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is it valid to shard children of a sharded parent?

[Justin du coeur]

Hmm.  What do you mean by "parent / child" here?  There are two usages that
often get conflated but which are actually *very* different in Akka, and
the difference is relevant here.

On the one hand, there is a *logical* relationship: in the semantics of the
application, one kind of thing is the "parent", and it has a bunch of
"children".  This tends to be reflected in the data, and often in the
interactions.

On the other hand, there is the *physical* relationship in Akka -- one
parent Actor being the supervisor / owner of a bunch of child Actors.

It's very common for folks who have the first situation to represent it as
the second, but it's often a mistake: the data doesn't necessarily dictate
the Actor parent/child relationships, and frequently shouldn't.  But
sometimes it is appropriate for them to be parent/child Actors.

Consider it this way: can you reframe the problem as a "one-to-many"
relationship of independent entities, or are they truly parent/child Actors?

To answer your actual question: no, as far as I know sharding is
incompatible with this kind of Actor-level parent/child relationship.  The
parent of a Sharded Entity is the Sharding Region, so you can't just have
the children of a given Actor be "sharded".  You *can*, quite
straightforwardly, have independent Sharded Entities in one-to-many
relationships, but they're not really "parents" and "children" in that
case.  Hence my focus here: do you actually care about the *Actors* being
parent/child, or is it enough for them to simply have a relationship?

On Mon, Jun 5, 2017 at 6:38 AM, Martijn Lindhout  wrote:

> Hi all,
>
> I have an application with some of the actors having a parent / child
> relationship (mostly the case in Akka :-)), but...
>
> - the parent is a PersistedActor and it is sharded because there may be to
> many for a single machine
> - those parents can have many children also, even those might not fit in a
> single machine.
>
> As I understand sharding: when an actor is sharded, they are distributed
> around the cluster and their children remain with the parents.
>
> In order to prevent OOM, is it sound the shard the children also? I've not
> done this before, so I'm just looking for advice / design patterns, etc
>
> Regards!
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] cluster sharding and auto-down

[Justin du coeur]

Clarifying question: are you doing downing somewhere in this?

The naive auto-down feature shouldn't be used because it is *too* naive,
and leads to split-brain when you get transient network failures.  But you
do still have to down nodes *somehow* when they crash, so that the system
knows to readjust accordingly...

On Fri, May 26, 2017 at 4:52 AM, Dai Yinhua  wrote:

> I am using *akka cluster sharding *to build a long running calculation
> service, and I have set auto-down to false.
> And we have mechanism that *when one jvm get crashed it will be restarted
> immediately* by some external monitoring tools.
>
> I would like to confirm below behaviors when some jvm get crashed:
>
> Two cases:
>
> 1. *If the crashed jvm is seed node*, and the jvm is restarted
> immediately
> Is this the an expected result:
> 1.1) Other nodes see seed node as unreachable
> 1.2) One from other node become the new leader, but it can not perform
> any duty
> 1.3) Seed node restarted, and join it self
> *Seems in this case the cluster was partitioned to two?*
> How should I deal with this situation?
>
> 2. *If the crashed jvm is not seed node but a shard region node*, and the
> jvm is restarted immediately
> Before crash, the jvm contains some shards and have some entity actors
> running.
> Is this the an expected result:
> 2.1) The crashed node marked as unreachable
> 2.2) Leader can not performance any operation from now
> 2.3) A new instance is trying to join the cluster, and succeed
> 2.4) The jvm marked as up
> 2.5) Leader become available again
> Question:
> Will the *entities *that running in the crashed jvm be *moved to
> other available node automatically *after the crash happened?
> What if the *shard coordinator* happened to be running in the crashed
> jvm?
>
> Thank you.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Dispatcher Issue

[Justin du coeur]

No, no -- I mean "node" in the sense that a configuration file is
essentially a tree, and each section is a node in that tree.  As far as I
know, the description of "my-dispatcher" doesn't belong under
ActorSys.akka.actor.  Please re-read the documentation...

On Fri, May 19, 2017 at 2:14 AM, Abhishek G 
wrote:

>
> Hi Justin,
>
> Am ruuning this code on local machine no concept of node
>
>
> On Thursday, May 18, 2017 at 12:42:09 PM UTC+5:30, Abhishek G wrote:
>>
>> Am a newbie to Akka
>>
>> import akka.actor.Props
>> import akka.actor.ActorSystem
>> import akka.actor.Actor
>> import akka.routing.FromConfig
>>
>>
>>   class RootActor extends Actor{
>>def receive = {
>> case msg:String => println(msg+" "+self.path.name);
>>  var childActor =  context.actorOf(Props[Child],"Child");
>>
>>  childActor ! "Hello"
>>}
>>}
>>   class Child extends Actor{
>>def receive = {
>>case msg:String => println(msg+" "+self.path.name);
>> }
>>  }
>>  object AkkaThread{
>>  def main(args:Array[String]){
>>
>>   println("HIII")
>>
>>  var actorSystem = ActorSystem("ActorSys");
>>  var actor = actorSystem.actorOf(Props[RootActor]
>>
>> .withDispatcher("my-dispatcher")   // .withDispatcher("
>> Actorsys.akka.actor.my-dispatcher") tried along with that facing the
>> same exception
>>
>> .withRouter(FromConfig()),"RootActor");
>>  actor ! "Hello"
>> for (n <- 1 until 30) actor !("Hello, Akka #%d!".format(n))
>> }
>>}
>>
>>
>> And My Application.conf file placed at Src/main/resources
>>
>>   ActorSys{
>> akka{
>>  actor{
>>provider =
>> "akka.actor.LocalActorRefProvider"
>>my-dispatcher {
>>type =
>> "Dispatcher"
>>executor =
>> "fork-join-executor"
>>
>> fork-join-executor{
>>
>> parallelism-min = 50
>>
>> parallelism-factor = 3.0
>>
>> parallelism-max = 100
>>  }
>>
>> throughput = 10
>>  }
>>}
>>   }
>> akka.actor.deployment {
>>"/*/RootActor/*" {
>>  dispatcher =
>> my-dispatcher
>>  router =
>> round-robin-group
>>  routees.paths =
>> ["ActorSys/user/RootActor"]
>>  nr-of-instances
>> = 100
>>
>> }
>>   }
>>  }
>>
>> its throwing an error  Dispatcher [Actorsys.akka.actor.my-dispatcher]
>> not configured for path akka://Actorsys/user/RootActor. Struck with this
>> Akka vesion 2.3.16
>>
>>
>>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Dispatcher Issue

[Justin du coeur]

On Thu, May 18, 2017 at 2:58 AM, Abhishek G 
wrote:

> And My Application.conf file placed at Src/main/resources
>
>   ActorSys{
> akka{
>  actor{
>
   provider = "akka.actor.
> LocalActorRefProvider"
>my-dispatcher {
>type =
> "Dispatcher"
>executor =
> "fork-join-executor"
>
> fork-join-executor{
>
> parallelism-min = 50
>
> parallelism-factor = 3.0
>
> parallelism-max = 100
>  }
>
> throughput = 10
>  }
>

I don't think that's where this node belongs in configuration.  Please
review the dispatcher docs

.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Basic akka - locating actors and their state

[Justin du coeur]

While it's not unreasonable to structure the Actor hierarchy like this, I
suspect it's not actually what you want.  It is specifically likely to make
it a hassle to look up Users just by their UserID.

Rather, I would recommend researching Akka Clustering Sharding.  That's
very likely the right way for you to manage your User Actors, because it is
designed precisely for the case where you want to be able to look up (and
create, when necessary) an Actor of a particular type given an ID.  Storing
data in the UserActor makes good sense, especially if you pair this with
Akka Persistence -- that's often the easiest way to set things up.

In all likelihood, you should have a separate Clustering Sharding Region
for Countries as well, if they have their own data.  A Country might well
contain a list of Region IDs, even if those Regions aren't actually Actors.

As for Regions, I'm not sure -- you might want to think about whether
Regions are anything more than an identifier that is used as a handle for
subscribing and broadcasting events.  That is, instead of "look up all the
actors by Region", you might want to instead ask "how do I *broadcast* to
all Users in a Region?", which might be an easier problem to solve.  I
wouldn't bother making Regions an Actor type unto themselves unless there
was some per-Region state you were managing.

On Sat, May 13, 2017 at 6:00 PM, Christian Hessenbruch 
wrote:

> This is a couple of very basic questions concerning akka. I'm totally
> green on akka, so any advice is appreciated.
>
>
> Say that I have an application with thousands of users - not millions.
>
>
> The domain model is a hierarchy where each user is located in a region
> within a country i.e. a country has multiply regions, a region has multiple
> users.
>
>
> I'm thinking of creating the exact same hierarchy in akka. CountryActor
> ->* RegionActor ->* UserActor. The CountryActor could aside from being
> parent, also have functional duties such as collecting newsfeeds,
> calculating statistics, supervising its children etc. Whereas the
> RegionActor is only a parent of UserActors.
>
>
> *Q1: Does it make sense to mimic the domain model this way?*
>
>
> *Q2: Should I store the attributes of each entity in the actor?* This way
> the data would only need to be stored once and the akka system would
> effectively be memory database as well.
>
>
> (pseudo-code)
>
> CountryActor {
>   Name,
>   CountryCode,
>   (children = list of RegionActors handled by akka)
> }
>
> RegionActor {
>   Name,
>   RegionCode,
>   (children = list of UserActors handled by akka)
> }
>
> UserActor {
>   UserId,
>   Firstname,
>   Lastname,
>   Alias,
>   ReceiveRegionalNews,
>   ReceiveCountryNews,
>   ...
> }
>
>
> *Q3: How do I efficiently lookup a user by userId?* I expect the
> child-name of the UserActor will be the userId, but given that I only have
> a userId, I still need to find that correct Country and Region to do a
> getContent().findChild(userId)? Do I need to keep a complete map of all
> userIds and reference to their actor?
>
>
> *Q4: How to locate actors by their state?* Imagine that each user has the
> ability to switch on a RegionalNews attribute, which means that he wants to
> receive news from the RegionalActor. Whenever the RegionalActor want to
> distribute news to all listeners, how does it locate them? Does it keep an
> internal map of the users with the attribute or does it make a broadcast to
> all it's children and then send to all responders?
>
>
> Thanks in advance
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Cluster Failing for Huge Data File

[Justin du coeur]

My rule of thumb is that you should never, *ever *use

*idstrategy = "incremental"*

What that is saying is that, at serialization time, if it encounters a type
that isn't registered yet, it *makes up a registration out of thin air.*
This is essentially guaranteed to fail unless the order of serialization
and deserialization is absolutely deterministic.  (Really, I don't think
that idstrategy should even exist, since it is nothing but a trap for the
unwary.)

That's likely why it's failing: you are trying to serialize some type
(probably in a subfield) that isn't registered, so it's just making up a
serialization ID.  It gets to the other end, which has never heard of that
ID, and crashes.

Choose a different idstrategy.  For Akka Persistence I consider "explicit"
to be the only sane option, but that's a lot of work; for other
circumstances, "automatic" should usually work decently well...

On Fri, May 12, 2017 at 8:46 AM, Kunal Ghosh  wrote:

> Hi,
> How do i set generics for ObjectArraySerializer in kryos ?
>
> public class ICEUniqueSource{
>
> private final *ICEColSource[] _columns*;
>
> }
>
>
> public class ICEColSource{
>
> }
>
> Following error --
> 00:11 TRACE: [kryo] Write field: _columns 
> (org.iceengine.compare.engine.ICEUniqueSource)
> pos=788
> 00:11 TRACE: [kryo] Write class 910779913: org.iceengine.compare.engine.
> ICEColSource[]
> 00:11 TRACE: [kryo] setting generics for ObjectArraySerializer
> 00:11 TRACE: [kryo] Write initial object reference 91:
> org.iceengine.compare.engine.ICEColSource[]
> 00:11 DEBUG: [kryo] Write: org.iceengine.compare.engine.ICEColSource[]
>
> WARN [17:57:38.455]{iCEDQApp-akka.actor.default-dispatcher-11}(
> Slf4jLogger$$anonfun$receive$1$$anonfun$applyOrElse$2.apply$mcV$sp:78)-Failed
> to deserialize message with serializer id [6] and manifest []. Encountered
> unregistered class ID: 910779913
> Serialization trace:
> _columns (org.iceengine.compare.engine.ICEUniqueSource)
> _model (org.iceengine.compare.sources.ICESourceFlatFile)
> _srcInput (org.iceengine.compare.conf.DefaultDataComparison)
> _dataComparison (org.iceengine.compare.engine.ICEEngineContext)
> _context (org.iceengine.compare.akka.RowData)
>
> *application.conf **( Only **# **KryoSerializer Configuration**)*
>
> *akka {*
>
> *actor {*
> *kryo {*
> *  type = "graph"*
> *  idstrategy = "incremental"*
> *  buffer-size = 4096*
> *  max-buffer-size = -1*
> *  use-manifest = false*
> *  implicit-registration-logging = true*
> *  kryo-trace = true*
>
> *  mappings {*
> *"org.iceengine.compare.engine.ICEUniqueSource" = 72*
> *"org.iceengine.compare.engine.ICEColSource" = 63*
> *  }*
> *}*
>
> *serialize-messages = on*
> *serializers {*
> *  #java = "akka.serialization.JavaSerializer"*
> *  kryo = "com.romix.akka.serialization.kryo.KryoSerializer"*
> *}*
> *serialization-bindings {*
>   *"org.iceengine.compare.engine.ICEUniqueSource" = **kryo *
> *  "org.iceengine.compare.engine.ICEColSource" = **kryo *
> *}*
> *  }*
>
> *  # Disable legacy metrics in akka-cluster.*
> *cluster.metrics.enabled=off*
>
>
> *# Enable metrics extension in akka-cluster-metrics.*
> *extensions=[*
> *   "akka.cluster.metrics.ClusterMetricsExtension",*
> *   "com.romix.akka.serialization.kryo.KryoSerializationExtension$"*
> *   ]*
>
>
> *}*
>
> On Monday, May 8, 2017 at 6:37:17 PM UTC+5:30, Patrik Nordwall wrote:
>>
>> the port number for the seed-nodes does not match canonical.port = 25520
>>
>> replacing akka.tcp with akka is correct, and if you have that in the code
>> somewhere it must be changed there also
>>
>> On Mon, May 8, 2017 at 2:36 PM, Kunal Ghosh  wrote:
>>
>>> Thanks @Patrik Your help is much appreciated !!
>>>
>>> Below are my configuration for Kryo Serialization and Artery remote
>>> implementation in application.conf file. Please go through it and tell me
>>> whether is it correct ??
>>> Also I have a question that changing configuration is enough or I will
>>> have to make changes in the code as well?
>>>
>>> *application.conf *
>>>
>>> *akka {*
>>>
>>> *  loggers = ["akka.event.slf4j.Slf4jLogger"]*
>>>  *  loglevel = "DEBUG"*
>>>
>>> *  stdout-loglevel = "DEBUG"*
>>>
>>> *  logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"*
>>>
>>> *  actor.provider = "akka.cluster.ClusterActorRefProvider"*
>>>
>>> *# Artery remoting implementation*
>>>
>>> *remote {*
>>> *log-remote-lifecycle-events = on*
>>> *log-sent-messages = on*
>>> *log-received-messages = on*
>>> *artery {*
>>> *  enabled = on*
>>> *  canonical.hostname = "192.168.100.199"*
>>> *  canonical.port = 25520*
>>> *}*
>>> *  }*
>>>
>>> *# **KryoSerializer Configuration*
>>>
>>> *  actor {*
>>> *kryo {*
>>> *  type = "graph"*
>>> *  idstrategy = "incremental"*
>>> *  buffer-size = 4096*
>>> *  max-buffer-size = -1*
>>> *  use-manifest = false*
>>> *  

Re: [akka-user] experiences with serialization: json vs protobuf vs avro vs kryo...

[Justin du coeur]

I'm using Kryo, and that's working reasonably well so far, but it's not
trivial to set up.  As I have time, I'm gradually writing that up
,
but it's only half-done.  Happy to answer questions if you want to explore
that route.

My general impression is that protobuf is the well-established route, and
the one that most people are using, but that does involve some duplication
of information.  (Or generating the case classes from the protobuf IDL.)  I
don't much care for that, which is why I went for Kryo; the end result is
broadly similar in terms of the amount of effort, I believe, but with the
serialization information encoded directly into the classes themselves.

On Mon, May 1, 2017 at 12:54 AM, Joost de Vries 
wrote:

> I'm trying to find a suitable serialization for akka persistence.
>
> There are a lot of options but not all of them are equally used and are as
> mature. F.i. we picked avro with avro4s but hit some problems that weren't
> easy to fix.
>
> Of course then it's tempting to fall back on json: it's familiar from
> rest, easy to analyse and there's stamina for schema evolution.
>
> But I wonder if there's another option. So my question is: which non json
> serialisation are you using and what are your experiences with schema
> evolution and otherwise?
> A special concern is that we'd rather not have to duplicate our case class
> structure in IDL files.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Best way to handle large response from Actor

[Justin du coeur]

I don't know that there's a perfect solution to that problem.  Personally,
I wound up building a rough but functioning streaming system

for this purpose, which sets up protocol Actors at both ends to deal with
the chunking, then return the reassembled result and resolve the Future on
the receiving end; you might want to consider something along those lines.
 (Note that my code is known to be inefficient in its current form, but
could serve as inspiration...)

On Wed, Apr 26, 2017 at 2:19 PM, Sumanta Dutta  wrote:

> Hi, we generally use ask pattern to handle request-response between client
> and Akka Cluster. The client waits on the Future. We have a need where the
> response size (~150MB) is too large to fit in one message even after
> increasing message-frame-size to -
>
> maximum-payload-bytes = 5000 bytes
> netty.tcp {
>   message-frame-size = 5000b
>   send-buffer-size = 5000b
>   receive-buffer-size = 5000b
>   maximum-frame-size = 5000b
> }
>
> We don't like keep increasing the above limits. So one possibility is to
> break the response in small chunks, but then how to handle on the Future
> side using the ask pattern. The other possibility may be to use GraphStage
> between Actors to stream the response back. Is that a viable solution? Is
> there any example out there?
>
> Thanks,
> Sumanta
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Best Practice

[Justin du coeur]

On Tue, Apr 25, 2017 at 6:21 AM, Vishwa Bhat 
wrote:

> Suppose there is a sequence of dependant operations say:
>
> a. Build X
>
> b. Insert X into Database
>
> c. Find Y in the Database
>
> d. Get Z from some Computation and return it
>
>  Assuming all the above operations are blocking.
>
> [...]
> 3. One final question is, even if followed various approaches of actors I
could not hit concurrency level beyond 1000. What is the optimal value for
real world scenarios, not hello world ones.

You've probably got your own answer here.

The thing is, Actors aren't magic.  They allow you to tame concurrency to
some degree, but blocking is blocking, and blocking is *always* evil.  If
your lower-level operations are all blocking, that's going to impose hard
limits on how much practical concurrency you can get in the system.

If you have some blocking operations and some non-blocking ones, in
different Actors, then you should look into Dispatchers -- the standard
approach is to assign the blocking operations to their own Dispatcher, so
that the non-blocking Actors can progress at their own speed without having
to share the blocked threads.  But if you are doing a lot of blocking
database I/O, odds are that Akka can't help.  (This is why Akka systems use
non-blocking database APIs whenever possible.)

Now my first question is,
>
> 1. How do I approach in building Actor model for the above scenario?
>

I recommend stepping back and rethinking the question in terms of "what is
this Actor *responsible* for?".  An Actor isn't a collection of random
operations -- it is typically managing a high-level business object, or a
workflow, or something like that.  You haven't given us enough information
here to be able to really answer the question, but the general principle is
that you should be building an Actor that manages a reasonably isolated
concept.


> #Another way is to *wrap all the operations inside one actor*. The better
> part with this approach is it does not create that many actors as approach
> one but it certainly ruins the purpose of actors because AFAIK if an actor
> has severe blocking code, it almost mimics a Java thread itself.
>
>
Yep -- blocking is evil.  Indeed, blocking inside of an Actor is always a
bit problematic, and if *all* of your Actors are blocking, then odds are
pretty good that the system is going to have problems.

Mind, from your description I'm not at all sure whether Akka is an
appropriate solution in the first place.  Here's a question: are you
managing any in-memory state?  If not -- if this application is nothing
more than doing series of database operations -- then I almost certainly
wouldn't use plain Akka for it.  (I might use Akka Streams, but that's for
very different use cases.)

2. I use Play framework with Java, Is there any way to use only actors
> until controller level (after which I am forced to send*
> CompletionStage* to avoid blocking API call anyway)? For now I'm
> using *Patterns.ask(..) *to wait for the data.
>
>
Hmm -- what do you mean by "wait"?  Having a Play Action call ask() is
absolutely standard, and often the correct solution, but that's precisely
because it *doesn't* wait -- ask() returns a Future, which you pass to
Play, and Play knows how to resolve that in a non-blocking way.  There's
normally no waiting involved...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] moving from redis cache to... ?

[Justin du coeur]

On Sun, Apr 23, 2017 at 5:32 PM, Curt Siffert <c...@keenworks.com> wrote:

> > On Apr 22, 2017, at 9:12 AM, Justin du coeur <jduco...@gmail.com> wrote:
> > Personally, I'd likely use Akka Cluster Sharding for this -- assuming
> each request can be summarized in a way that fits as an entity identifier,
> it seems like a good fit.  In this model, the sharded entity would serve as
> a read-through cache for the external service: your stream would go to the
> sharded Actor -- if it's the first request, the Actor would make the
> external request, otherwise it would already know about the value and
> return it.  Cluster Sharded Actors are a lot like an in-memory cache, and I
> use them for exactly this in a number of cases.
> >
> > I'd probably only bother with Akka Persistence (I assume you're thinking
> of building this on top of Redis) if the number of distinct request types
> is too large to typically fit in memory (so the Sharded Actors would need
> to sometimes get flushed), and too expensive/slow to want to ever re-run a
> request externally.  Might be worthwhile, might not; it depends on the
> external constraints.
>
> That’s good to hear. I have some experience setting up an Akka Cluster in
> AWS before, but haven’t used cluster sharding.
>

It's my favorite part of the Akka stack, surprisingly easy to use once you
get the idea.


> We might be able to get away without using Akka Persistence - we’re still
> working out those external constraints. Once “cached” (instantiated), the
> value should remain valid for quite a while (source data doesn’t change
> often), and the external lookup would be against another internal/nearby
> low-latency service anyway.
>

In which case I might not bother with Akka Persistence -- it just adds
another external service without a ton of benefit, if re-querying the
external service is adequately fast/cheap.  (That said, if you aggregate
the shards as described below, Akka Persistence provides a relatively easy
way to save snapshots of each aggregate, and quickly restore them if and
when shards get rebalanced.)

If by distinct request types you mean number of values cached, we’re
> probably in the tens of millions, or perhaps hundreds of millions in time.
> It’s only one type of request though, two parameters that will return back
> a small data structure. We haven’t sized the data structure yet but it is
> roughly similar to an Address object - a flat structure with a handful of
> string fields.
>

Yeah -- in that case I suspect that Distributed Data is a non-starter.
 (Although, mind, I haven't done a lot with it myself yet, so I'm speaking
from my rough knowledge of this one.)


> Since it’s a cluster that new instances can join, is memory effectively
> unbounded?


Pretty much, yeah -- my recollection is that they've tested clusters up to
somewhere in the ballpark of a thousand servers, so you can get a *lot* of
memory in there.

That’s an actor instance for each value we’d otherwise cache, so tens or
> hundreds of millions of actor instances. I know akka scales out well but I
> have not seen much comparing it to the performance of something like Redis.


Don't know -- my understanding is that Akka clustering scales well, but I
don't know Redis at all well, so I don't know how the latency compares.


> I wonder at what point (if ever) an actor-per-cached-value doesn’t make
> sense anymore, if ever, compared to an external cache? I wonder if this
> also impacts what to pick for “state-store-mode”.


AFAIK, the only constraint on dynamically growing it is that you need to
pre-declare the *total* number of shards, so if you expect growth I would
build planned growth into the entity-to-shard multiplier.  (The rough rule
of thumb is that 10 shards per node is good, but AFAIK there's nothing
wrong with starting with a larger number of shards/node, and letting those
gradually re-allocate as you add nodes and rebalance the shards.)

I'd actually worry more about the basic latency -- Redis is more tuned for
this sort of thing, so it might be significantly faster.  But I would
expect that, if Cluster Sharding performance is reasonable to start with,
it would scale well.

Given how small the data structure is, I'd likely look for a way to
sensibly aggregate them -- while Actors are pretty cheap, they're a good
order of magnitude or so larger than an Address, so Actor-per-result is
pretty inefficient.  So I'd probably do some sort of "sub-sharding",
looking for an algorithmic way to divide the namespace so that a given
cache Actor contains a map of hundreds-to-thousands of results, so that it
makes more efficient use of memory.  That's how I do my caching: I
basically hash the query, and divide the resulting namespace among a
relatively modest number of sharded Actors.  That's very easy to implement
in Cluster Sharding, and

Re: [akka-user] moving from redis cache to... ?

[Justin du coeur]

On Fri, Apr 21, 2017 at 2:45 PM, Curt Siffert  wrote:

> I've considered using scalacache since it has the familiar model of
> caching method calls by parameter. But I'm not sure it's really idiomatic
> for akka-streams (which I've just started using) or akka. Should I instead
> consider using akka persistent actors (one per service lookup I guess) or
> dumping Redis entirely and using akka distributed data?
>

Personally, I'd likely use Akka Cluster Sharding for this -- assuming each
request can be summarized in a way that fits as an entity identifier, it
seems like a good fit.  In this model, the sharded entity would serve as a
read-through cache for the external service: your stream would go to the
sharded Actor -- if it's the first request, the Actor would make the
external request, otherwise it would already know about the value and
return it.  Cluster Sharded Actors are a lot like an in-memory cache, and I
use them for exactly this in a number of cases.

I'd probably only bother with Akka Persistence (I assume you're thinking of
building this on top of Redis) if the number of distinct request types is
too large to typically fit in memory (so the Sharded Actors would need to
sometimes get flushed), and too expensive/slow to want to ever re-run a
request externally.  Might be worthwhile, might not; it depends on the
external constraints.

If the number of distinct request types is relatively *small*, I might go
for Distributed Data.  But keep in mind that all of those values are being
gossipped around the network, so while this is likely a good solution for
hundreds-to-thousands of distinct requests, I probably wouldn't use it for
millions.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Facing problems while implementing akka clustering in an e-commerce application.

[Justin du coeur]

ot;9","quantity":1,"price":1.0,"title":"ff","
> imageUrl":"xv"}},"total_numberOf_items":1,"cart_total":1.0}
>
> now i send request to port 9001 with different sku_id:
>
> {"operation": "ADDSKUTOCART","cart_id":"18768458-01d5-4f65-b7f8-
> abe49ba67775","user_id":"----
> 0001","sku_id":"10","quantity":3,"price":1.0,"
> title":"ff","imageUrl":"xv"}
>
> and Response is:
>
> {"cart_id":"18768458-01d5-4f65-b7f8-abe49ba67775","user_
> id":"----0001","cart_entries":{
> "9":{"sku_id":"9","quantity":1,"price":1.0,"title":"ff","
> imageUrl":"xv"},"10":{"sku_id":"10","quantity":1,"price":1.
> 0,"title":"ff","imageUrl":"xv"}},"total_numberOf_items":2,"
> cart_total":2.0}
>
> here you can see ,"total_numberOf_items" is 2
>
> Now i send request to port 9002 again by changing sku_id:
> {"operation": "ADDSKUTOCART","cart_id":"18768458-01d5-4f65-b7f8-
> abe49ba67775","user_id":"----
> 0001","sku_id":"11","quantity":3,"price":1.0,"
> title":"ff","imageUrl":"xv"}
>
> and Response comes:
> {"cart_id":"18768458-01d5-4f65-b7f8-abe49ba67775","user_
> id":"----0001","cart_entries":{
> "9":{"sku_id":"9","quantity":1,"price":1.0,"title":"ff","
> imageUrl":"xv"},"10":{"sku_id":"10","quantity":1,"price":1.
> 0,"title":"ff","imageUrl":"xv"},"11":{"sku_id":"11","
> quantity":1,"price":1.0,"title":"ff","imageUrl":"xv"}},
> "total_numberOf_items":3,"cart_total":3.0}
>
> again "total_numberOf_items" is updated to 3.
>
> Now as i hit second request to any node say i am hitting request to node
> with port number 9000 with again changing sku_id:
>
> {"operation": "ADDSKUTOCART","cart_id":"18768458-01d5-4f65-b7f8-
> abe49ba67775","user_id":"----
> 0001","sku_id":"12","quantity":3,"price":1.0,"
> title":"ff","imageUrl":"xv"}
>
> and response comes:
>
> {"cart_id":"18768458-01d5-4f65-b7f8-abe49ba67775","user_
> id":"----0001","cart_entries":{
> "9":{"sku_id":"9","quantity":1,"price":1.0,"title":"ff","
> imageUrl":"xv"},"12":{"sku_id":"12","quantity":1,"price":1.
> 0,"title":"ff","imageUrl":"xv"}},"total_numberOf_items":2,"
> cart_total":2.0}
>
> here "total_numberOf_items" = 2 which was supposed to be 4.
>
> let me know if there is anything i am missing or is there a different way
> to do it.
>
>
>
>
>
>
>
>
>
>
>
> On Monday, April 17, 2017 at 8:22:11 PM UTC+5:30, Justin du coeur wrote:
>>
>> That's *extremely* weird.  I mean, the entire point of Cluster Sharding
>> is that you are always getting the same Actor for a given ID.  Can you show
>> the code that you're using to start your sharding region, and to send the
>> messages?  What do your messages look like, and how are you extracting the
>> ID from the message?  Are you getting exceptions, and if so, what do they
>> look like?
>>
>> On Mon, Apr 17, 2017 at 1:09 AM, <jatinde...@spineor.com> wrote:
>>
>>> Implemented using cluster sharding also. same problem everything seems
>>> to work for first request on any node in cluster as i hit second request on
>>> any node in the cluster it starts fetching data independently. is there a
>>> different way to get existing actorref in clustered enviornment than from
>>> normal actorsystem.
>>>
>>> On Wednesday, Ap

Re: [akka-user] Facing problems while implementing akka clustering in an e-commerce application.

[Justin du coeur]

That's *extremely* weird.  I mean, the entire point of Cluster Sharding is
that you are always getting the same Actor for a given ID.  Can you show
the code that you're using to start your sharding region, and to send the
messages?  What do your messages look like, and how are you extracting the
ID from the message?  Are you getting exceptions, and if so, what do they
look like?

On Mon, Apr 17, 2017 at 1:09 AM, <jatinder.si...@spineor.com> wrote:

> Implemented using cluster sharding also. same problem everything seems to
> work for first request on any node in cluster as i hit second request on
> any node in the cluster it starts fetching data independently. is there a
> different way to get existing actorref in clustered enviornment than from
> normal actorsystem.
>
> On Wednesday, April 12, 2017 at 6:35:30 PM UTC+5:30, Justin du coeur wrote:
>>
>> Hmm -- I'm not quite sure what you're expecting this to do, but it sounds
>> to me like you're using the wrong tool.  Have you looked into Akka Cluster
>> Sharding yet?  From your problem description, I suspect it's what you
>> should be using...
>>
>> On Wed, Apr 12, 2017 at 12:38 AM, <jatinde...@spineor.com> wrote:
>>
>>> It is first time I am implementing akka clustering so I have no prior
>>> experience with that. What We want to acheive with akka clustering is that
>>> when request goes to each node in cluster each node return same instance of
>>> actor (Or actor consist of same data which should just be sum of response
>>> to all requests to all nodes). But what we all getting is all nodes
>>> returning different response containing different data as if they are
>>> working independently.
>>>
>>>
>>> Here I am sharing some code and configuration and exceptions we are
>>> getting
>>>
>>> def getOrCreateCartActor(cart_id: UUID): ActorRef = {
>>>   var cartActor: ActorRef = null
>>>   implicit val timeout = Timeout(50 seconds)
>>>   val name = "/user/" + cart_id.toString
>>>   val roundRobinPool = RoundRobinPool( nrOfInstances =  4)
>>>
>>>   val clusterRouterPoolSettings = ClusterRouterPoolSettings( totalInstances 
>>> = 4, maxInstancesPerNode = 2,
>>>   allowLocalRoutees = true, useRole = None)
>>>
>>>   val clusterRouterPool = ClusterRouterPool(roundRobinPool, 
>>> clusterRouterPoolSettings)
>>>
>>>   val future = actorSystem.actorSelection("/user/" + 
>>> cart_id.toString).resolveOne()
>>>
>>>
>>>   try{
>>>   /*try {
>>> println("Everything Ok.")
>>> cartActor = actorSystem.actorOf(ClusterSingletonProxy.props(
>>>   singletonManagerPath = "/user/" + cart_id.toString,
>>>   settings = ClusterSingletonProxySettings(actorSystem)),
>>>   name = cart_id.toString+"Proxy"
>>> )
>>>   }catch {
>>> case ex: InvalidActorNameException =>
>>>   if(cartActor == null){
>>>   println("Everything Not Ok.")
>>>   cartActor = actorSystem.actorOf(
>>> ClusterSingletonManager.props(
>>>   singletonProps = Props(classOf[CartActor]),
>>>   terminationMessage = PoisonPill,
>>>   settings = ClusterSingletonManagerSettings(actorSystem)),
>>> //Props[CartActor],
>>> cart_id.toString)
>>> }
>>>   }*/
>>> val actorResult = Await.result(future, 50 seconds)
>>> cartActor = 
>>> actorSystem.actorOf(clusterRouterPool.props(Props[CartActor]), 
>>> cart_id.toString)
>>>
>>>   }
>>>   catch {
>>> case ex: ActorNotFound => {
>>>
>>>
>>>
>>>   cartActor = 
>>> actorSystem.actorOf(clusterRouterPool.props(Props[CartActor]), 
>>> cart_id.toString)
>>> }
>>>   }
>>>
>>>   /*future onComplete {
>>> case Success(v) => {
>>>   cartActor = v
>>>
>>>
>>> }
>>> case Failure(e) => {
>>>   //The cart actor no longer exists and must be recreated
>>>   cartActor = system.actorOf(Props[CartActor], cart_id.toString)
>>>
>>>
>>> }
>>>   }*/
>>>   //Sleep for Actor to be created
>>>   cartActor
>>>
>>>
>>> }
>>>
>>>
>>>  As in comments in code you can see I also tried ClusterSingleton and
>>> Cluster Pooling using round 

Re: [akka-user] persistAll()

[Justin du coeur]

Already fixed, actually.  I'm still on 2.4, so that's the API doc I was
looking at, but when I check over at 2.5 this has been clarified...

On Fri, Apr 14, 2017 at 11:58 AM, Patrik Nordwall <patrik.nordw...@gmail.com
> wrote:

> If this is missing or unclear in docs it would be great with an
> improvement PR.
>
> fre 14 apr. 2017 kl. 17:54 skrev ahjohannessen <ahjohannes...@gmail.com>:
>
>> I am correct, try it out. We do something like this:
>>
>> def processEvents(events: Seq[DomainEvent], cm: CommandMessage)
>>(done: ⇒ Unit): Unit = {
>>
>> val durables = events map { e ⇒
>>   DurableEvent(e).causedBy(cm)
>> }
>>
>> if(durables.isEmpty) done else {
>>   persistAll(durables)(applyEvent)
>>   deferAsync()(_ ⇒ done)
>> }
>>
>>   }
>>
>>
>> On Friday, April 14, 2017 at 2:16:09 PM UTC+1, Justin du coeur wrote:
>>
>>> Huh -- from the documentation I wouldn't have expected that to work.
>>>  (The docs for deferAsync only talk about using it with persistAsync(), not
>>> persist().)  But from looking at the code for Eventsourced, it seems like
>>> you're probably correct.  Excellent -- thanks!
>>>
>> On Thu, Apr 13, 2017 at 8:38 PM, ahjohannessen <ahjoha...@gmail.com>
>>> wrote:
>>>
>> Use deferAsync after persistAll
>>>>
>>>
>>>> --
>>>> >>>>>>>>>>  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.
>>>> To post to this group, send email to akka...@googlegroups.com.
>>>
>>>
>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] persistAll()

[Justin du coeur]

Huh -- from the documentation I wouldn't have expected that to work.  (The
docs for deferAsync only talk about using it with persistAsync(), not
persist().)  But from looking at the code for Eventsourced, it seems like
you're probably correct.  Excellent -- thanks!

On Thu, Apr 13, 2017 at 8:38 PM, ahjohannessen 
wrote:

> Use deferAsync after persistAll
>
> --
> >>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] persistAll()

[Justin du coeur]

I just realized that I have been misusing PersistentActor.persistAll() for
quite some time now -- the only reason it hasn't produced horrible bugs is
because I haven't yet used it for more than a single Event at a time.  (And
foolishly didn't check my types properly.)  I had assumed it called its
callback after *all* Events were persisted; I just realized that it is
called for *each* of them.

Assumption check: as far as I can tell, there is no way to tell that *all*
of the Events passed to persistAll() have been persisted, and react *once*
when they're all complete.  (Short of, eg, keeping some kind of mutable
counter in the callback.)  Correct?

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Facing problems while implementing akka clustering in an e-commerce application.

[Justin du coeur]

Hmm -- I'm not quite sure what you're expecting this to do, but it sounds
to me like you're using the wrong tool.  Have you looked into Akka Cluster
Sharding yet?  From your problem description, I suspect it's what you
should be using...

On Wed, Apr 12, 2017 at 12:38 AM,  wrote:

> It is first time I am implementing akka clustering so I have no prior
> experience with that. What We want to acheive with akka clustering is that
> when request goes to each node in cluster each node return same instance of
> actor (Or actor consist of same data which should just be sum of response
> to all requests to all nodes). But what we all getting is all nodes
> returning different response containing different data as if they are
> working independently.
>
>
> Here I am sharing some code and configuration and exceptions we are getting
>
> def getOrCreateCartActor(cart_id: UUID): ActorRef = {
>   var cartActor: ActorRef = null
>   implicit val timeout = Timeout(50 seconds)
>   val name = "/user/" + cart_id.toString
>   val roundRobinPool = RoundRobinPool( nrOfInstances =  4)
>
>   val clusterRouterPoolSettings = ClusterRouterPoolSettings( totalInstances = 
> 4, maxInstancesPerNode = 2,
>   allowLocalRoutees = true, useRole = None)
>
>   val clusterRouterPool = ClusterRouterPool(roundRobinPool, 
> clusterRouterPoolSettings)
>
>   val future = actorSystem.actorSelection("/user/" + 
> cart_id.toString).resolveOne()
>
>
>   try{
>   /*try {
> println("Everything Ok.")
> cartActor = actorSystem.actorOf(ClusterSingletonProxy.props(
>   singletonManagerPath = "/user/" + cart_id.toString,
>   settings = ClusterSingletonProxySettings(actorSystem)),
>   name = cart_id.toString+"Proxy"
> )
>   }catch {
> case ex: InvalidActorNameException =>
>   if(cartActor == null){
>   println("Everything Not Ok.")
>   cartActor = actorSystem.actorOf(
> ClusterSingletonManager.props(
>   singletonProps = Props(classOf[CartActor]),
>   terminationMessage = PoisonPill,
>   settings = ClusterSingletonManagerSettings(actorSystem)),
> //Props[CartActor],
> cart_id.toString)
> }
>   }*/
> val actorResult = Await.result(future, 50 seconds)
> cartActor = 
> actorSystem.actorOf(clusterRouterPool.props(Props[CartActor]), 
> cart_id.toString)
>
>   }
>   catch {
> case ex: ActorNotFound => {
>
>
>
>   cartActor = 
> actorSystem.actorOf(clusterRouterPool.props(Props[CartActor]), 
> cart_id.toString)
> }
>   }
>
>   /*future onComplete {
> case Success(v) => {
>   cartActor = v
>
>
> }
> case Failure(e) => {
>   //The cart actor no longer exists and must be recreated
>   cartActor = system.actorOf(Props[CartActor], cart_id.toString)
>
>
> }
>   }*/
>   //Sleep for Actor to be created
>   cartActor
>
>
> }
>
>
>  As in comments in code you can see I also tried ClusterSingleton and
> Cluster Pooling using round robin.
>
> Here is configuration :
>
> akka {
>   # "akka.log-config-on-start" is extraordinarly useful because it log the 
> complete
>   # configuration at INFO level, including defaults and overrides, so it s 
> worth
>   # putting at the very top.
>   #
>   # Put the following in your conf/logback.xml file:
>   #
>   # 
>   #
>   # And then uncomment this line to debug the configuration.
>   #
>   #log-config-on-start = true
>
>   loglevel = DEBUG
>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
>
>   actor {
> provider = "akka.cluster.ClusterActorRefProvider"
> debug {
>   receive = on
>   lifecycle = on
> }
> serializers {
>   java = "akka.serialization.JavaSerializer"
> }
>
>   }
> //  remote {
> //log-remote-lifecycle-events = off
> //netty.tcp {
> //  hostname = "127.0.0.1"
> //  port = 0
> //}
> //  }
>
>   remote {
> enabled-transports = ["akka.remote.netty.tcp"]
> netty.tcp {
>   hostname = "127.0.0.1"
>   port = 0
> }
>   }
>
>   cluster {
> seed-nodes = [
>   "akka.tcp://application@127.0.0.1:2551",
>   "akka.tcp://application@127.0.0.1:2552"]
>
>
>
>
> #//#snippet
> # excluded from snippet
> //auto-down-unreachable-after = 10s
> #//#snippet
> # auto downing is NOT safe for production deployments.
> # you may want to use it during development, read more about it in the 
> docs.
> #
> //auto-down-unreachable-after = 10s
>
> //distributed-data {
> //  # Actor name of the Replicator actor, /system/ddataReplicator
> //  name = ddataReplicator
> //}
>   }
>
>   //akka.extensions = ["akka.cluster.pubsub.DistributedPubSub"]
>
> }
>
>
> Then i started nodes using:
>
> sbt "run -Dhttp.port=9001 -Dakka.remote.netty.tcp.port=2551"
> sbt "run -Dhttp.port=9002 -Dakka.remote.netty.tcp.port=2552"
> *and main server with*
> sbt run
>
> and then the exception i am getting is:
>
> [error] application 

Re: [akka-user] Cluster Singleton Migration

[Justin du coeur]

Hmm.  Could be.  I suspect they'd welcome a PR to that effect...

On Mon, Apr 3, 2017 at 11:56 AM, Mushtaq Ahmed  wrote:

> Thanks, that makes sense. But maybe the documentation of cluster-singleton
> is a bit misleading and should be reworded.
>
>
> On Monday, April 3, 2017 at 9:04:30 PM UTC+5:30, Arno Haase wrote:
>
>> When you kill a JVM running a cluster node, it becomes 'unreachable'.
>> The other nodes in the cluster have no way of knowing whether this is
>> permanent or temporary (e.g. network congestion).
>>
>> In order for a singleton to be started on another node, the node it was
>> running on must be moved to state "down" (see Akka documentation on
>> cluster). That can be tricky (see "split brain"), and an Akka cluster
>> does (and can) not do that automatically.
>>
>> In order to run an Akka cluster, you need some sort of downing strategy
>> that decides when to move nodes from 'unreachable' to 'down'. Lightbend
>> has a commercial package containing (among other things) code to support
>> this.
>>
>> Hope this helps
>>
>> - Arno
>>
>> Am 03.04.2017 um 17:19 schrieb Mushtaq Ahmed:
>> > Hello!
>> >
>> > Doc on cluster singleton
>> > 
>> > mention that even in case of JVM crash, singletons will be successfully
>> > started on other nodes:
>> >
>> > "The cluster failure detector will notice when oldest node becomes
>> > unreachable due to things like JVM crash, hard shut down, or network
>> > failure. Then a new oldest node will take over and a new singleton
>> actor
>> > is created. For these failure scenarios there will not be a graceful
>> > hand-over, but more than one active singletons is prevented by all
>> > reasonable means. Some corner cases are eventually resolved by
>> > configurable timeouts."
>> >
>> > But when I kill the JVM process hosting singleton, I do not see that
>> > singleton is started in the nodes in the cluster. Am I missing
>> > something? Only messages I see for past 10 mins are:
>> >
>> > [WARN] [04/03/2017 20:47:58.120] [New I/O boss #9]
>> > [NettyTransport(akka://csw-cluster)] Remote connection to null failed
>> > with java.net.ConnectException: Connection refused: /192.168.1.2:3552
>> >
>> > [WARN] [04/03/2017 20:47:58.120]
>> > [csw-cluster-akka.remote.default-remote-dispatcher-6]
>> > [akka.tcp://csw-cluster@192.168.1.2:54527/system/endpointMan
>> ager/reliableEndpointWriter-akka.tcp%3A%2F%2Fcsw-cluster%
>> 40192.168.1.2%3A3552-96]
>> > Association with remote system [akka.tcp://csw-cluster@192.168.1.2:3552]
>>
>> > has failed, address is now gated for [5000] ms. Reason: [Association
>> > failed with [akka.tcp://csw-cluster@192.168.1.2:3552]] Caused by:
>> > [Connection refused: /192.168.1.2:3552]
>> >
>> > We are using 2.5.0-RC2.
>> >
>> > Thanks,
>> > Mushtaq
>> >
>> > --
>> >>> 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/grou
>> p/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
>> > .
>> > To post to this group, send email to akka...@googlegroups.com
>> > .
>> > Visit this group at https://groups.google.com/group/akka-user.
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is Auto-Downing ok in this situation?

[Justin du coeur]

Insufficient information to answer with any confidence, but here's a
thought experiment to help decide: say that your cluster was divided into
separate machines -- each node was running properly, but they were entirely
unable to communicate with each other, and indeed didn't know that each
other *existed*, but whatever front end you have feeding information *into*
the cluster (say, a load balancer) still knew about all of them and was
continuing to send data to each, probably semi-randomly.  Would the
application still work correctly?

The above situation is basically the pathological extreme of what can
happen with auto-downing turned on -- the cluster slowly decomposes into
individual nodes, each of which thinks that it is the entire cluster.

In most cases, the answer is "no", because if it was "yes", you probably
didn't need Akka Clustering in the first place.  But I don't know how your
application works...

On Sun, Apr 2, 2017 at 1:31 AM, Mushtaq Ahmed  wrote:

> Hello!
>
> We are using these 2 services built on top akka-cluster:
>
> - distributed data: keeps service registry
> - singletons: used for death watching and auto unregistering actorRefs
> from registry
>
> Note that, there is no "persistent" state in singletons.
>
> Also, it should be ok even if more than one singletons exist for any
> reason (due to the idempotent nature of unregistration).
>
> Will you still recommend against using Auto-Downing feature? If yes, why?
>
> Thanks,
> Mushtaq
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to get the resonse from a ask to a region ?

[Justin du coeur]

Do you know the forward() function on ActorRef?  I'm not certain whether
it's right for your use case, but it's often the answer to this sort of
design, since it sends a message while preserving the original sender.  If
ActorA doesn't actually need the response, it's probably correct.  (The
reason it might not work is if you need to send to B and C in parallel, and
only respond when *both* are finished.)

If that's not an option, then likely yes, you should include the original
sender() in the messages to B and C, and use that to coordinate the
response.

On Fri, Mar 31, 2017 at 4:53 AM, Jean Demonceau 
wrote:

> Hi guys,
>
> I have a sharding region that creates instances of ActorA
> I want to "ask" (in order to get a synchronous reponse) the region to do
> something
> The problem is ActorA (that will receive the message) will dispatch the
> work to ActorB and ActorC and will expect messages from them.
>
> When ActorA receives response from B and C it can sends a reponse to the
> inital sender() saying that the job is completed.
>
> The problem is, since ActorA received messages from B and C, the initial
> sender() is lost.
> I cannot tell to context().parent() either because the parent of A is the
> Shard.
>
> How can I do this properly ? Should I backup the initial
> sender().path().toString() and response like so
> context().system().actorSelection(initialSenderPath).tell("jobCompleted",
> self()) ?
>
> Is it safe to do that ? In this case the initial sender path
> is akka://MySystem/temp/$a
>
> Or should I put the initial sender ActorRef to messages sent to B and C
> and expect to get it back from them in their response ?
>
> I know I could use ask in ActorA to send messages to B and C in order to
> keep the original sender but I don't want to set timeouts everywhere.
>
> Any idea ?
> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Can we use activator for Spark projects?

[Justin du coeur]

Activator is essentially nothing but a shell around sbt -- at the command
line, they're identical AFAIK.

If you're not using the UI anyway, just switch to sbt, which is the real
underlying tool, and which something like 98% of the Scala ecosystem runs
on.  While folks are working on other tools that might be better in the
long run, there is zero chance of sbt going away in the foreseeable future.

On Mon, Mar 27, 2017 at 9:40 AM, kant kodali  wrote:

> Hi,
>
> I don't mean to say that I want to use activator for the UI part. In fact,
> I barely even use activator ui (although its really cool). I am at very
> least using activator as a production build tool for apps that are written
> using Play framework. is that ok? I like fact that activator makes the
> packaging so easy either it is a zip, rpm debian or whatever and it puts
> the configs at the appropriates places and so on.
>
> I know that you mentioned activator is going to go away. How about SBT? is
> that there to stay?
>
> Thanks!
>
> On Mon, Mar 27, 2017 at 3:48 AM, Konrad Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> Activator is just a sample-app tool to try out Scala and tutorials etc.
>> I guess it could maybe work with Spark for a demo but I would not
>> recommend it...
>>
>> Use a real IDE :)
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 27 March 2017 at 12:46:17, kant kodali (kanth...@gmail.com) wrote:
>>
>> Hi All,
>>
>> Can we use activator for Spark projects along with typesafe config
>> library? Any examples?
>>
>> Thanks!
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka actor wait on future to resolve before taking off mailbox

[Justin du coeur]

I suspect you're looking for stash(), which is the usual answer to "I want
to pause my inbox for a bit"...

On Thu, Mar 23, 2017 at 8:47 PM, Sean Callahan 
wrote:

> Hey all. Ive got an Actor set up that when called, takes a little bit of
> time to run and I want to limit how many "runs" happen at the same time. I
> have a routing pool above this actor to accomplish that. However, in my
> current implementation of the actor I am blocking to get that
> functionality, and I definitely dont want to lose that thread to a blocking
> call.
>
> If I use Future.pipeTo(sender()), the actor than pulls from the mailbox
> almost immediately causing more work to be run that I would like. Im
> guessing I am either missing something simple, or there is a better pattern
> out there to solve this problem?
>
> class ArchiveActor (workerClass: Worker) extends Actor with Logging {
>
>   import context.dispatcher
>
>   private def run(minute: DateTime): Future[ArchiveResult] = {
> // work is done here that returns a future
> workerClass.doWork(minute)
>   }
>
>   override def receive: Receive = {
> case Run(minute) =>
>   sender().tell(Await.result(run(minute), Duration.Inf),
> context.parent)
>   }
>
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to group a list of actors in Akka?

[Justin du coeur]

Not sure I understand the desired use case, but I believe the answer is no
-- the *path* of an Actor has to be unique.  That is, for a given parent,
only one child may have a given name.

Is there a reason not to just have the parent maintain separate lists of
the different groups?  You seem to be trying to find a built-in solution to
a problem that folks usually just solve manually (because it is usually
extremely easy to do so).

On Tue, Mar 21, 2017 at 4:18 PM, kant kodali <kanth...@gmail.com> wrote:

> Can two actors have the  same name? For Example, Can I create same
> instance of Actor class in a For loop so I can access all the actors by
> that name?
>
> On Tue, Mar 21, 2017 at 6:12 AM, Justin du coeur <jduco...@gmail.com>
> wrote:
>
>> Right -- that's probably the way I would tend to construct something like
>> this, but it would depend on the use case, as well as whether the "groups"
>> in question were mutually exclusive...
>>
>> On Tue, Mar 21, 2017 at 9:05 AM, Konrad Malawski <
>> konrad.malaw...@lightbend.com> wrote:
>>
>>>
>>> As such, no -- there's no formal "group" concept like this, although you
>>> could construct it manually yourself.
>>>
>>> There is "all children of given actor" which is accessible by
>>> context.children() inside an Actor.
>>>
>>>
>>>
>>>
>>> --
>>> Konrad `ktoso` Malawski
>>> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>>>
>>>
>>> On 21 March 2017 at 15:02:26, Justin du coeur (jduco...@gmail.com)
>>> wrote:
>>>
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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/to
>> pic/akka-user/UAFqhZYk8uc/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to group a list of actors in Akka?

[Justin du coeur]

Right -- that's probably the way I would tend to construct something like
this, but it would depend on the use case, as well as whether the "groups"
in question were mutually exclusive...

On Tue, Mar 21, 2017 at 9:05 AM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

>
> As such, no -- there's no formal "group" concept like this, although you
> could construct it manually yourself.
>
> There is "all children of given actor" which is accessible by
> context.children() inside an Actor.
>
>
>
>
> --
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
>
> On 21 March 2017 at 15:02:26, Justin du coeur (jduco...@gmail.com) wrote:
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to group a list of actors in Akka?

[Justin du coeur]

As such, no -- there's no formal "group" concept like this, although you
could construct it manually yourself.

I suspect this use case is usually handled with PubSub -- each group
subscribes to an appropriate channel.  (But I don't use this myself, so
can't say for sure.)

On Tue, Mar 21, 2017 at 6:16 AM, kant kodali  wrote:

> Hi All,
>
> How to group a list of actors? I want to send message A to group of Actors
> M and message B to group of Actors N. Is there a way to give them a common
> name and access them through that name so I can send my messages? or Is
> there any better way?
>
> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] transactors and STM are gone. What conception to use instead?

[Justin du coeur]

On Sat, Mar 18, 2017 at 4:23 PM, scala solist  wrote:

> So now I'm still using akka for single-JVM multitasking and has no desire
> to go back to synchronized. So I need to program local transactions
> somehow. It is definitely feasible since it could be done in single-JVM
> with synchronized. But I'd like to find idiomatic actor way.
>

I don't know if you're going to find anything that is meaningfully
idiomatic for the current world, given that distributed is pretty integral
to the current idiom.  But I suspect that the best way to start may be to
look at the old transactors and STM, and see if that code can be revived as
an external library.  I don't know offhand whether that's possible, but it
likely at least would provide good guidance...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why akka choose protobuf internally

[Justin du coeur]

On Sat, Mar 18, 2017 at 10:23 AM, Patrik Nordwall  wrote:

> Isn't the difference that with Kryo you don't have to write the tedious
> mapping code between the domain classes and the protobuf classes?
>

To a large degree, yes -- my real problem with protobuf is that it's
essentially decoupled code duplication, and I'm pretty allergic to that.
 (Unless you deal with code generation, and then the code becomes harder to
scan and understand.)  That was my primary reason for going for Kryo
instead, and I might still use it knowing what I know now -- but the clear
realization in retrospect is that you still have to write what amounts to a
protobuf description *in* your class descriptions, in order to cope with
schema evolution.

For the Akka internal classes we see that mapping as an advantage because
> it gives us full control but I can understand that in a large system that
> code can be seen as a waste.


Yeah -- while Querki isn't "large" in the grand scheme of things, my Akka
Persistence schema is growing pretty much every month, so it's nice having
clean in-code ways of dealing with that.

But getting there took some significant effort -- I had to enhance romix'
library in order to cope with properly serializing the core Scala/Akka
types (I had no idea how insane some of those traits are until I got into
it), and wound up building several utilities to cope with the reality of
evolution.  Hopefully others will be able to use some of this
trailblazing...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why akka choose protobuf internally

[Justin du coeur]

Honestly, it's pretty subjective -- if I had known then what I know now,
I'm not sure I would have bothered.  I like having my classes be relatively
self-describing, not so dependent on external config in order to function,
so I like this approach, but I could easily argue the other side.  I was
mostly just making the point that Kryo is a valid option, not that it's
necessarily a better one...

On Sat, Mar 18, 2017 at 2:02 AM, Dai Yinhua  wrote:

> Hi Justin,
>>
>
>  Thank you for your information and suggestion.
> I have read your blog but I can't see the benefit of using scala to
> describe the schema over using an external description file(like .proto).
> But I look forward your unfinished part.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How akka cluster become network partition

[Justin du coeur]

I think you're being misled by the word "cluster".  Keep in mind, a single
JVM is still a perfectly valid "cluster" if it allows itself to be one.  So
it's very easy to fall into the trap where node A winds up as its own
cluster, and the other nodes are another cluster -- that's exactly what
happens if A experiences a long GC pause, and the other nodes naively down
it while it is still running.  If the load balancer is still talking to all
of these nodes, you wind up with an inconsistent state, and can easily fall
into data corruption...

On Sat, Mar 18, 2017 at 5:05 AM, Dai Yinhua  wrote:

> @Patrik, I have read the akka document about split brain resolver, but
>> could you please explain a little bit more to help me understand why does
>> it happen?
>>
>
> If node A is experiencing long GC, and then node A is firstly marked as
> unreachable and then marked as down and later removed from the cluster.
> How does it become two separate clusters? I can only think all other node
> has realized that node A is unreachable through gossip?
>
> What I come out with a scenario that cause two separate cluster is that
> when there are several JVMs running in node A, and several JVMs running in
> other node, if there is network issue for node A, then the cluster might be
> separated to two clusters, one is formed by all JVMs in node A, and others
> formed the other one.
> But I can't think out how does this happen for a long GC?
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How akka cluster become network partition

[Justin du coeur]

Right, but that's an intentionally duplicative environment.  In most Akka
systems, you want to have at *most* one Actor for any given entity.  In
particular, if you are using Cluster Sharding and Akka Persistence,
duplication is a recipe for database corruption.

One might well be able to build a more redundant system on top of Akka,
which would be partition-tolerant in the way you're describing.  (In
particular, I could imagine something CRDT-based that wouldn't care so
much.)  But that's higher-level than Akka itself generally focuses.

And even there, you want to have a well-defined concept of when a node has
left the cluster permanently.  (Remember that most Akka architectures are
designed to be tolerant of scaling the cluster up and down based on load,
relatively dynamically.)

On Fri, Mar 17, 2017 at 2:24 PM, kant kodali  wrote:

> Why does one needs to take an approach of Split brain resolver when there
> is something better? The problem of network partitions is well understood
> in most distributed nosql databases. For example Cassandra continues to
> operate with the nodes that are available/reachable/up during
> network partitions and when the network partition is resolved (typically by
> fixing the cable or hardware) The most up to date nodes will just stream
> data to the stale ones.
>
>
>
>
> On Thursday, March 16, 2017 at 4:08:07 AM UTC-7, Dai Yinhua wrote:
>>
>> Hi team,
>>
>> I am aware that akka cluster may be partitioned to 2 clusters with
>> auto-downing.
>> But I can't understand how does it happen?
>> If node A is performing a long GC? And then node A become unreachable,
>> after a while, node A is marked as down, why the cluster is partitioned in
>> this case?
>>
>> Can you help to explain more clearly on that?
>>
>> Thank you.
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Cassandra Time Stamp Problem and How Akka can help?

[Justin du coeur]

On Fri, Mar 17, 2017 at 7:29 AM, kant kodali  wrote:

> Do I need to specify how many nodes or shards I want to distribute to ?
>

Not by number, but IIRC you can assign particular roles to nodes, and have
those roles determine what sorts of things get distributed to those nodes.

Note that you *do* implicitly have to pre-decide how many shards to break a
given concept down to.  But a given node typically hosts a number of
shards, and that rebalances dynamically.


> Node can go up and down right.. Can the Akka cluster discover how many
> nodes are available at any given time?
>

That's essentially what clustering does, yes.  There's an underlying gossip
mechanism, so that all nodes have a rough idea of all of the others at any
given time.


> Also, Why should I manually down the node? I know that there is a failure
> detector so if the Akka cluster "thinks" a node is dead then why cant it
> simply distribute that region to other actors?
>

Problem is, there's a lot of judgement call involved in deciding whether a
node is just temporarily unavailable due to a network failure or is
actually down.  Getting this wrong has *serious* consequences, and can lead
to data corruption.  Akka per se doesn't make that decision, although
Lightbend does sell a product named Split Brain Resolver that provides a
fairly sophisticated algorithm to make the decision.

Basically, Akka doesn't say whether it thinks a node is *down*, it just
knows that it is temporarily unavailable.  You have to decide when that
actually means "down".

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why akka choose protobuf internally

[Justin du coeur]

I have to take issue with "really hard" -- I'm using Kryo for my Akka
Persistence, and it's working well.  It's totally possible to handle schema
evolution with it, and it is *not* rocket science.

That said, I'll agree that it isn't trivial by any means: I put a
significant amount of effort into getting it all working.  I have a
whitepaper in-process
 that details all
the considerations and how I addressed them; I'll talk that up a bit once I
have it finished.  (And I might wind up releasing a tiny library for the
annotations and other details I developed around it.)

Overall, the summary is that, yes, Kryo *is* more effort than Protobuf, and
there's a distinct difference of viewpoint: you have to be annotating the
serialization details *somewhere*, and in the case of Kryo it requires
annotating your serialized classes to a significant degree.  Personally, I
prefer that approach, but there is plenty of room for honest disagreement
here.

(And specifically to Dai, note that Akka Persistence absolutely requires
thinking in a "schema"-ish way -- even when using Kryo, you have to be more
explicit about the schema details, although not in external config files.)

On Fri, Mar 17, 2017 at 6:25 AM, Akka Team  wrote:

> If you use a tool that automagically makes protocol out of classes it is
> really hard to deal with wire compatibility, giving guarantees that old
> messages can still be deserialized, for example on rolling upgrades, or
> when stored (akka-persistence) for a longer period of time. Both these
> aspects are important to all Akka specific messages. In addition to that
> the schema allows us to do optimizations we could not do without it,
> default cases by sending no data at all when possible for example.
>
> If you have a use case where none of those things matters, kryo or any
> other schema-less can be perfectly fine.
> Personally I still prefer explicit protocols over implicit ones, but that
> might be a matter of taste.
>
> --
> Johan
> Akka Team
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Can any actor send message to any other actor?

[Justin du coeur]

Hmm.  I suspect I would handle a problem like this architecturally, rather
than at the individual Actor level.  Remember that you don't usually have
Actors connecting to each other by name -- instead, Actors usually provide
ActorRefs to other Actors.

So I would probably have each service provide some sort of "gatekeeper"
Actor, which mediates the provision of ActorRefs to the rest of the
cluster, and only provide access to the systems that are appropriate to
have it.  The external services would have to go through this gatekeeper,
allowing you to manage the process as tightly as you need.

This approach does require that everyone play by the rules and not try to
do an end-run around them.  But if folks work within the system, it seems
like a reasonably principled way to manage access...

On Thu, Mar 16, 2017 at 1:09 PM, Rado Buranský <radoburan...@gmail.com>
wrote:

> Thanks Justin. I also have the same feeling that this is not the right way.
>
> My idea was to implement micro services but instead of having standalone
> HTTP servers for each service I was thinking to have actor system for each
> service and join them together in a single Akka cluster. To be more
> specific, in our organization I would allow other teams to implement their
> own actor system which we would run on our cluster. But I need to make sure
> that their code doesn't mess with the rest of the cluster.
>
>
> On Thursday, March 16, 2017 at 9:50:37 AM UTC-7, Justin du coeur wrote:
>>
>> What's the underlying need here?  I can't recall ever seeing anyone do
>> something like this, and it's fairly counter to the general architecture of
>> Akka.  I suspect it's impossible in the general case.  (Note that custom
>> mailboxes are always a dicey proposition, and usually indicate that you're
>> trying to do something unwise.)
>>
>> That said, "only accepting some well-defined messages" is precisely the
>> way Actors usually work.
>>
>> But generally: what are you trying to accomplish?  It might be easier to
>> help you with a better idea of what you really need...
>>
>> On Wed, Mar 15, 2017 at 7:54 PM, Rado Buranský <radobu...@gmail.com>
>> wrote:
>>
>>> Here is my original unanswered SO question:
>>> http://stackoverflow.com/questions/42773328/how-to-isolate-akka-actor
>>>
>>> Is it possible to protect some actors within a single actor system from
>>> other actors? Is it actually a good idea at all? I can imagine to implement
>>> a custom mailbox which accepts only some well-defined messages.
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Can any actor send message to any other actor?

[Justin du coeur]

What's the underlying need here?  I can't recall ever seeing anyone do
something like this, and it's fairly counter to the general architecture of
Akka.  I suspect it's impossible in the general case.  (Note that custom
mailboxes are always a dicey proposition, and usually indicate that you're
trying to do something unwise.)

That said, "only accepting some well-defined messages" is precisely the way
Actors usually work.

But generally: what are you trying to accomplish?  It might be easier to
help you with a better idea of what you really need...

On Wed, Mar 15, 2017 at 7:54 PM, Rado Buranský 
wrote:

> Here is my original unanswered SO question:
> http://stackoverflow.com/questions/42773328/how-to-isolate-akka-actor
>
> Is it possible to protect some actors within a single actor system from
> other actors? Is it actually a good idea at all? I can imagine to implement
> a custom mailbox which accepts only some well-defined messages.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Routing question

[Justin du coeur]

This is more or less exactly the way that Akka Cluster Sharding works -- I
strongly recommend reading the documentation for that.

On Thu, Mar 16, 2017 at 6:08 AM, kant kodali  wrote:

> Hi All,
>
> I have a stream of JSON encoded messages and I want to distribute them to
> group of actors or actor systems based on the field inside a message so say
> more like hash(key)->Actor but when the Actor dies I want to be able to
> hash the key to a different Actor that are available but at any given the
> hash of the key should always go to same Actor. Please let me know how I
> can achieve this with Akka?
>
> Thanks,
> kant
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Cassandra Time Stamp Problem and How Akka can help?

[Justin du coeur]

Look at it this way -- typically, you're generating events about some
*thing*, which corresponds to the key you're using in Cassandra.  That's
the "entity" I'm talking about, and typically it would have a single Actor
in Akka, to which all events are being sent.  That Actor mediates all the
Cassandra reads and writes about that entity without thread contention, so
you don't have to worry about race conditions.  If the entity isn't being
used continually, you can allow it to passivate (go to sleep and stop using
memory) after a timeout, and have it automatically revive (based on the
event history) when it is next needed.

And yes, Akka Cluster Sharding is smart about dealing with it when the node
dies -- so long as you "down" the node (telling Akka that yes, this node is
considered dead), it will move the shard to another node as necessary.
It's a pretty mature system for dealing with this sort of stuff.

I don't have a straightforward example myself (my system uses all of this,
but is fairly complex) -- anybody else have a good example to point to?

On Wed, Mar 15, 2017 at 7:29 PM, kant kodali  wrote:

> What is each Entity if I may ask? By Entity you mean Actor? If I shard
> messages across group of actors or actor systems through some user
> specified function and say an actor or actor system(a node) dies then Does
> Akka redirect that shard to other actors (more like rebalancing) ? Any
> simple example somewhere I can take a look please?
>
> Thanks!
>
>
>
>
> On Tuesday, March 14, 2017 at 4:52:43 AM UTC-7, kant kodali wrote:
>>
>> Hi All,
>>
>> I have Kafka as my live streaming source of data (This data isn't  really
>> events but rather just messages with a state) and I want to insert this
>> data into Cassandra but I have the following problem.
>>
>> Cassandra uses Last Write Wins Strategy using timestamps to resolve
>> conflicting writes.
>>
>> By default, Cassandra enables server side timestamps and they are
>> monotonic per node. other words two nodes can produce the same timestamp
>> (although not often). So if they are two writes that go to two different
>> coordinator nodes and are trying to update the same Cassandra partition one
>> write will overwrite the other (we cannot deterministically say which one).
>> But from the user perspective it would look like both writes were
>> successful although we lost the state of one write request (Widely known
>> word to describe this anomaly is called "LOST UPDATES").  So if one doesn't
>> want this to happen Cassandra recommends to use client side timestamps but
>> we can run into the same problem in the following scenario.
>>
>> Client side Cassandra timestamps are monotonic by each client (By client
>> I mean think of it as a process that uses Cassandra driver API) so if one
>> has multiple processes which each of them having Cassandra driver api then
>> they can generate a same time stamp (although not often) and are trying to
>> update the same Cassandra partition then we will run into the same problem
>> as above. And multiple processes talking to Cassandra is very common in the
>> industry. In my case these multiple processes will be Kafka Consumers which
>> will consume data from Kafka and insert it into Cassandra.
>>
>> If one of the two writes that are contending fails and other succeeds
>> such that a failed write can automatically retry using some mechanism in
>> Akka (then it will be an acceptable solution) but how do we do that?
>>
>> I somehow think there might be a nice reactive pattern using Akka whether
>> it is sharding or something else can help me solve this problem?
>>
>> Disclaimer: I am new to Akka and trying to put in lot of effort to learn
>> as quickly as possible so I will be open and thankful to any new ideas on
>> how to solve this problem in a scalable way as possible?
>>
>> Thanks,
>> kant
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 

Re: [akka-user] Cassandra Time Stamp Problem and How Akka can help?

[Justin du coeur]

You may want to take a look at the combination of Akka Cluster Sharding,
and Akka Persistence over Cassandra -- that's the most-idiomatic Akka way
to deal with this.  Cluster Sharding says that each Entity is represented
at most once in the cluster (so you don't have multiple nodes contending
for the same key); Akka Persistence provides an Akka-idiomatic way to
represent the Entity as a stream of events in Cassandra.

Whether you actually want to use these packages themselves, I'm not sure --
it depends, for example, on whether you need to get at the raw Cassandra
under the hood, and whether it is crucial to be writing directly from
separate nodes.  But they're the easiest way to deal with this sort of
thing, and if nothing else they should be able to give you ideas about how
best to deal with the problem...

On Tue, Mar 14, 2017 at 7:52 AM, kant kodali  wrote:

> Hi All,
>
> I have Kafka as my live streaming source of data (This data isn't  really
> events but rather just messages with a state) and I want to insert this
> data into Cassandra but I have the following problem.
>
> Cassandra uses Last Write Wins Strategy using timestamps to resolve
> conflicting writes.
>
> By default, Cassandra enables server side timestamps and they are
> monotonic per node. other words two nodes can produce the same timestamp
> (although not often). So if they are two writes that go to two different
> coordinator nodes and are trying to update the same Cassandra partition one
> write will overwrite the other (we cannot deterministically say which one).
> But from the user perspective it would look like both writes were
> successful although we lost the state of one write request (Widely known
> word to describe this anomaly is called "LOST UPDATES").  So if one doesn't
> want this to happen Cassandra recommends to use client side timestamps but
> we can run into the same problem in the following scenario.
>
> Client side Cassandra timestamps are monotonic by each client (By client I
> mean think of it as a process that uses Cassandra driver API) so if one has
> multiple processes which each of them having Cassandra driver api then they
> can generate a same time stamp (although not often) and are trying to
> update the same Cassandra partition then we will run into the same problem
> as above. And multiple processes talking to Cassandra is very common in the
> industry. In my case these multiple processes will be Kafka Consumers which
> will consume data from Kafka and insert it into Cassandra.
>
> If one of the two writes that are contending fails and other succeeds such
> that a failed write can automatically retry using some mechanism in Akka
> (then it will be an acceptable solution) but how do we do that?
>
> I somehow think there might be a nice reactive pattern using Akka whether
> it is sharding or something else can help me solve this problem?
>
> Disclaimer: I am new to Akka and trying to put in lot of effort to learn
> as quickly as possible so I will be open and thankful to any new ideas on
> how to solve this problem in a scalable way as possible?
>
> Thanks,
> kant
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Naive question

[Justin du coeur]

And for a more complex example, here are the events for the "Spaces" in my
app
<https://github.com/jducoeur/Querki/blob/master/querki/scalajvm/app/querki/spaces/SpaceMessagePersistence.scala>
-- basically CRUD-like operations on a roughly object-oriented database.
 (Note that these events are specifically designed to be serialized using
the Kryo library, but that's an unusual choice.)

On Sun, Mar 12, 2017 at 3:27 PM, Guido Medina <oxyg...@gmail.com> wrote:

> A concrete example:
>
> Imagining you are doing some accounting and your events are a Json
> representing any particular operation:
>
>1. {"op":"set", "value":0}
>2. {"op":"add", "value":20}
>3. {"op":"substract", "value":20}
>
> Then when you reply the events your account total should be zero.
>
> That's the simplest example I could come up with, basically you store each
> Json event and your actor "knows" what to do with such information when it
> is activated.
>
> HTH,
>
> Guido.
>
> On Sunday, March 12, 2017 at 6:03:31 PM UTC, Justin du coeur wrote:
>>
>> Generally not -- you define the "event" as a serializable data structure
>> that *describes* the transformation to execute, and that gets stored in the
>> event stream.  When you reload the Actor, you "replay" those events, and
>> your recovery logic interprets the events to actually change the data.  You
>> generally have a function that takes the stream of events and the starting
>> state, and does this interpretation.
>>
>> In principle, I suppose you *could* save the functions themselves as
>> bytecode, but I don't think I've ever heard of anyone doing so, and it
>> seems quite dangerous -- it could fail to load because dependencies had
>> changed, and other such problems.  (And it would likely be very bulky and
>> redundant.)
>>
>> On Sun, Mar 12, 2017 at 9:59 AM, kant kodali <kant...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> What does it mean when someone says we store the event itself rather
>>> than storing the state/data? such that the events can be replayed to store
>>> the state/data. Does it mean storing the functions/transformation itself
>>> (simply put the JVM byte code for the function itself) ?
>>>
>>> Thanks!
>>> kant
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Naive question

[Justin du coeur]

Generally not -- you define the "event" as a serializable data structure
that *describes* the transformation to execute, and that gets stored in the
event stream.  When you reload the Actor, you "replay" those events, and
your recovery logic interprets the events to actually change the data.  You
generally have a function that takes the stream of events and the starting
state, and does this interpretation.

In principle, I suppose you *could* save the functions themselves as
bytecode, but I don't think I've ever heard of anyone doing so, and it
seems quite dangerous -- it could fail to load because dependencies had
changed, and other such problems.  (And it would likely be very bulky and
redundant.)

On Sun, Mar 12, 2017 at 9:59 AM, kant kodali  wrote:

> Hi,
>
> What does it mean when someone says we store the event itself rather than
> storing the state/data? such that the events can be replayed to store the
> state/data. Does it mean storing the functions/transformation itself
> (simply put the JVM byte code for the function itself) ?
>
> Thanks!
> kant
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] newbie question about await inside actors code

[Justin du coeur]

Yeah -- backpressure is coming into the ecosystem gradually (it is
basically the primary point of Akka Streams), but if you're doing raw
Actors you still have to manage that manually for the time being...

On Fri, Mar 10, 2017 at 2:03 PM, scala solist <scalasol...@gmail.com> wrote:

> That is how I've implemented it finally. Just store messages and restore
> them when the result would become clear. The actor performs some data
> management, so it should have confidence in own state before it could
> proceed further messages.
>
> But reducing actor activity to just message shuffling is is a little bit
> discomfortable. Keeping messages in the common mailbox looks more
> consistent but also more hazardous: it brings possibility of buffer overrun
> to the mailbox instead of just an actor. All the worries are from akka
> lacking built-in backpressure control. So you need to reinvent it to some
> extent.
>
> On Tuesday, February 21, 2017 at 3:57:05 PM UTC+3, Justin du coeur wrote:
>>
>> On Tue, Feb 21, 2017 at 7:19 AM, Alan Burlison <alan.b...@gmail.com>
>> wrote:
>>
>>> On 21/02/2017 12:12, Viktor Klang wrote:
>>>
>>> http://doc.akka.io/docs/akka/2.4/scala/actors.html#Stash
>>>>
>>>
>>> Ahah! I'd seen stash in the docs and not really come up with an case
>>> (other than become/become) where it would be useful, and then forgotten
>>> about it. I'm still not clear how it would help in this scenario though?
>>
>>
>> As I understand it, you want your parent to "wait" until it has collected
>> all the info from the children before it moves on to doing something else.
>>  (Forgive me if I'm misunderstanding your use case -- it isn't spelled out
>> in great detail above.)
>>
>> The Akka-idiomatic way to do this is for the parent to do something like:
>>
>> -- Send out the jobs to the children
>> -- become() into a different receive processor
>> -- In this new processor, everything *other* than the responses from the
>> children get stash()ed -- that is, you save them away for later
>> -- Once you have accumulated all of the child responses (or timed out --
>> it is often adviseable to have a timeout scheduled), send out the
>> aggregated response.  Then unstash() everything that's been stored up, and
>> become() back to your original state.
>>
>> Essentially, instead of waiting/blocking, you shunt everything else aside
>> (queueing it, essentially) until you're ready to handle it.  The effect is
>> largely the same, but without tying up threads.
>>
> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] AKKA crashed using kryo serialization sometimes

[Justin du coeur]

On Thu, Mar 2, 2017 at 8:55 PM, Dai Yinhua  wrote:

> I am using AKKA 2.4.12 and kryo 0.5.2 with scala version 2.12
>

Hmm.  Newer version of akka-kryo than I'm using -- I'm still on Scala 2.11,
so I'm using akka-kryo 0.4.2.  It's possible there has been a regression.
I agree with Konrad that reporting the issue at the akka-kryo library is
probably most appropriate, and that narrowing down exactly what message
causes the error would be a huge help...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] AKKA crashed using kryo serialization sometimes

[Justin du coeur]

Actually, to be precise, it looks like the LZ4 decompression library is
crashing.  IIRC, that's not actually part of Kryo, but is a separate module
that Romix' Kryo adapter is pulling in, to compress/decompress the
Kryo-serialized data.

What versions do you have specified in your sbt file?  This error is very
worrying, since I am highly dependent on that LZ4 library myself...

On Thu, Mar 2, 2017 at 5:59 AM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> Hi there,
> Try to find out which message causes this.
> It indeed seems that kryo crashes.
>
> Try to create the issue in a reproducible way so we could figure out
> what's actually failing.
>
> --
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 2 March 2017 at 11:57:41, Dai Yinhua (yhdai.2...@gmail.com) wrote:
>
> Hi team,
>
> I encountered a jvm crash when akka try to process mailbox.
> Here is the stack, it seems that the issue happened on kryo? It doesn't
> always happen, I haven't get a reproduce pattern.
> Is that indicate an issue of kryo?
> Where can I start to investigate the issue?
>
> Thank you.
>
> j  net.jpountz.lz4.LZ4JNI.LZ4_decompress_fast([BLjava/nio/
> ByteBuffer;I[BLjava/nio/ByteBuffer;II)I+0
> j  net.jpountz.lz4.LZ4JNIFastDecompressor.decompress([BI[BII)I+22
> j  com.romix.akka.serialization.kryo.LZ4KryoCompressor.fromBinary([B)[B+61
> j  com.romix.akka.serialization.kryo.KryoTransformer.$anonfun$
> fromPipeLine$2(Lcom/romix/akka/serialization/kryo/Transformation;[B)[B+2
> j  com.romix.akka.serialization.kryo.KryoTransformer$$Lambda$
> 483.apply(Ljava/lang/Object;)Ljava/lang/Object;+8
> j  scala.Function1.$anonfun$andThen$1(Lscala/Function1;
> Lscala/Function1;Ljava/lang/Object;)Ljava/lang/Object;+8
> j  scala.Function1$$Lambda$481.apply(Ljava/lang/Object;)
> Ljava/lang/Object;+9
> j  com.romix.akka.serialization.kryo.KryoTransformer.fromBinary([B)[B+5
> j  com.romix.akka.serialization.kryo.KryoSerializer.
> fromBinary([BLscala/Option;)Ljava/lang/Object;+11
> J 7151 C1 akka.serialization.Serialization.deserializeByteArray([BLakka/
> serialization/Serializer;Ljava/lang/String;)Ljava/lang/Object; (355
> bytes) @ 0x7f2e993b987c [0x7f2e993b76c0+0x21bc]
> J 7860 C1 akka.serialization.Serialization.deserializeByteBuffer(Ljava/
> nio/ByteBuffer;ILjava/lang/String;)Ljava/lang/Object; (171 bytes) @
> 0x7f2e9a4b24ec [0x7f2e9a4b1200+0x12ec]
> J 7856 C1 akka.remote.artery.Deserializer$$anon$3.onPush()V (240 bytes) @
> 0x7f2e9a4ac9a4 [0x7f2e9a4ac320+0x684]
> J 7938 C2 akka.stream.impl.fusing.GraphInterpreter.execute(I)I (389
> bytes) @ 0x7f2e9a4e7c78 [0x7f2e9a4e7900+0x378]
> J 6523 C1 akka.stream.impl.fusing.GraphInterpreterShell.runBatch(I)I (208
> bytes) @ 0x7f2e9a1e3674 [0x7f2e9a1e3200+0x474]
> J 7098 C1 akka.stream.impl.fusing.GraphInterpreterShell.receive(
> Lakka/stream/impl/fusing/ActorGraphInterpreter$BoundaryEvent;I)I (909
> bytes) @ 0x7f2e9a2b1fc4 [0x7f2e9a2ae3c0+0x3c04]
> J 7100 C1 akka.stream.impl.fusing.ActorGraphInterpreter.akka$
> stream$impl$fusing$ActorGraphInterpreter$$processEvent(Lakka/stream/
> impl/fusing/ActorGraphInterpreter$BoundaryEvent;)V (170 bytes) @
> 0x7f2e9916d314 [0x7f2e9916cc40+0x6d4]
> J 6866 C1 akka.stream.impl.fusing.ActorGraphInterpreter$$
> anonfun$receive$1.applyOrElse(Ljava/lang/Object;Lscala/Function1;)Ljava/lang/Object;
> (309 bytes) @ 0x7f2e9a28f8cc [0x7f2e9a28f560+0x36c]
> J 6865 C1 akka.stream.impl.fusing.ActorGraphInterpreter.
> aroundReceive(Lscala/PartialFunction;Ljava/lang/Object;)V (7 bytes) @
> 0x7f2e9a28bcac [0x7f2e9a28b860+0x44c]
> J 6385 C1 akka.actor.ActorCell.invoke_aroundBody0(Lakka/actor/
> ActorCell;Lakka/dispatch/Envelope;Lorg/aspectj/lang/JoinPoint;)V (157
> bytes) @ 0x7f2e99a6ff34 [0x7f2e99a6f400+0xb34]
> J 6384 C1 
> akka.actor.ActorCell$AjcClosure1.run([Ljava/lang/Object;)Ljava/lang/Object;
> (28 bytes) @ 0x7f2e99a71d24 [0x7f2e99a719a0+0x384]
> J 6382 C1 
> akka.kamon.instrumentation.ActorMonitors$$anon$1$$Lambda$151.apply()Ljava/lang/Object;
> (8 bytes) @ 0x7f2e99a72acc [0x7f2e99a72820+0x2ac]
> J 5434 C1 kamon.trace.Tracer$.withContext(Lkamon/trace/
> TraceContext;Lscala/Function0;)Ljava/lang/Object; (50 bytes) @
> 0x7f2e9a00a3c4 [0x7f2e9a009cc0+0x704]
> J 6234 C1 akka.actor.ActorCell.invoke(Lakka/dispatch/Envelope;)V (64
> bytes) @ 0x7f2e99194094 [0x7f2e99192c20+0x1474]
> J 5660 C1 akka.dispatch.Mailbox.processMailbox(IJ)V (100 bytes) @
> 0x7f2e997e003c [0x7f2e997df980+0x6bc]
> J 5768 C1 akka.dispatch.Mailbox.run()V (65 bytes) @ 0x7f2e991d6a64
> [0x7f2e991d5cc0+0xda4]
> J 6273 C2 java.util.concurrent.ForkJoinPool$WorkQueue.
> runTask(Ljava/util/concurrent/ForkJoinTask;)V (86 bytes) @
> 0x7f2e99b20984 [0x7f2e99b1fe40+0xb44]
> j  java.util.concurrent.ForkJoinPool.runWorker(Ljava/
> util/concurrent/ForkJoinPool$WorkQueue;)V+35
> j  java.util.concurrent.ForkJoinWorkerThread.run()V+24
> v  

Re: [akka-user] how to load external configuration file in akka 2.0 ?

[Justin du coeur]

Coming into this *not* as a member of the Akka Team, but as a heavy
customer -- this is out of line.  I won't claim it's perfect, but both Akka
the system and the supporting documentation are good in the grand scheme of
things, and always getting better.

This sort of rudeness is inappropriate (all the moreso if you're getting it
for free)...

On Tue, Feb 28, 2017 at 4:16 AM, Jun Ma  wrote:

> What the hack does this mean " it will use what you specified as a
> parameter"? Which parameter? You meant the parameter assigned by the "-D"?
> Are you Akka guys really programmers? Your doc and product line control
> sucks!
> What do you guys expect users to keep up with various migrations of Akka?!
> You guys think the maintenance comes for free for users?!
>
> JM
>
> On Wednesday, March 21, 2012 at 11:54:47 PM UTC+8, Akka Team wrote:
>>
>> Sorry, just read the subject line and it says Akka 2.0... My bad.
>>
>> Can you try the following:
>>  java -Dconfig.*file*=/custom.conf -jar Application.jar
>>
>> Also *val conf = ConfigFactory.load()* should be enough.
>> If you do not specify a specific config when starting an ActorSystem it
>> will use what you specified as a parameter, i.e. you do not have to
>> explicitly give it a config.
>>
>> HTH
>> //Henrik
>>
>> On Wed, Mar 21, 2012 at 4:46 PM, Henrik Engstrom 
>> wrote:
>>
>>> Hey Sergey,
>>> Can you please enlighten me with the version of Akka you're using + the
>>> config file you're trying to load.
>>> That would help me investigate what your issue is.
>>> Thanks
>>> //Henrik
>>>
>>>
>>> On Wed, Mar 21, 2012 at 3:44 PM, Sergey Malov 
>>> wrote:
>>>
 I have external configuration file I'm trying to load before starting
 my application, it is sourced inside the app as:
val conf = ConfigFactory.load("custom.conf");

 It has some updated akka {} settings (debug-related) and some
 application specific settings.

 I'm starting app as:
java -Dconfig.resource=/custom.conf -jar Application.jar

 I tried relative , absolute  - nothing works, I'm getting
 error:

 Exception in thread "main" com.typesafe.config.ConfigException$Missing:
 No configuration setting found for key 'akka.version'
at com.typesafe.config.impl.SimpleConfig.findKey(SimpleConfig.
 java:115)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.
 java:135)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.
 java:140)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.
 java:108)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.
 java:146)
at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig
 .java:188)
at akka.actor.ActorSystem$Settings.(ActorSystem.scala:116)
at akka.actor.ActorSystemImpl.(ActorSystem.scala:424)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:103)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:89)
at com.mdialog.linear_stream_manager.LinearStreamManager$delaye
 dInit$body.apply(App.scala:9)
at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
at scala.runtime.AbstractFunction0.apply$mcV$sp(
 AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:60)
at scala.App$$anonfun$main$1.apply(App.scala:60)
at scala.collection.LinearSeqOptimized$class.foreach(
 LinearSeqOptimized.scala:59)
at scala.collection.immutable.List.foreach(List.scala:45)
at scala.collection.generic.TraversableForwarder$class.foreach(
 TraversableForwarder.scala:30)
at scala.App$class.main(App.scala:60)
at com.mdialog.linear_stream_manager.LinearStreamManager$.main(
 App.scala:7)
at com.mdialog.linear_stream_manager.LinearStreamManager.main(
 App.scala)


 Anything I'm doing incorrectly ?

 Thanks,

 Sergey


 --
 You received this message because you are subscribed to the Google
 Groups "Akka User List" group.
 To post to this group, send email to akka...@googlegroups.com.
 To unsubscribe from this group, send email to
 akka-user+...@googlegroups.com.
 For more options, visit this group at http://groups.google.com/group
 /akka-user?hl=en.


>>>
>>>
>>> --
>>> Henrik Engstrom
>>> Typesafe  - The software stack for applications
>>> that scale
>>> Twitter: h3nk3
>>>
>>>
>>
>>
>> --
>> Akka Team
>> Typesafe - The software stack for applications that scale
>> Blog: letitcrash.com
>> Twitter: @akkateam
>>
>> --
> >> 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
> ---
> 

Re: [akka-user] Sharding and unreachable node

[Justin du coeur]

Well, scaling down is straightforward: in that case, you *are* taking down
the node (or at least, the ActorSystem), so you should down it.  As soon as
you down it, the shards should migrate properly to other nodes.  That's
normal stuff.  Keep in mind that "unreachable but not down" should be a
*temporary* situation -- your system should be built to properly down the
unreachable node before long.  (With the appropriate precautions against
split-brain.)

Rolling out a new version of your application without stopping *is*
tricky.  At the moment, I'm accepting very brief downtime (a few seconds)
to shut down the old cluster and boot the new one.  Doing a proper rolling
release seems plausible, but you have to think carefully about wire
compatibility between the nodes.  I don't know offhand of a simple way to
do a rolling release if the wire protocols aren't compatible -- at that
point, I think you have to have application complicity in the process, and
it probably has to be handled with a lot of care...

On Mon, Feb 27, 2017 at 2:24 PM, Andrey Ilinykh <ailin...@gmail.com> wrote:

>
>
> On Monday, February 27, 2017 at 10:11:59 AM UTC-8, Justin du coeur wrote:
>>
>> There's no silver-bullet option for "fault tolerance" in situations like
>> this.  You absolutely do *not* want to start up alternate versions of the
>> sharded entities in this situation -- that's classic split-brain, and is
>> the surest route to data corruption.
>>
> yes, this is a dangerous route. But what is the a way to manage cluster? I
> mean roll out of a new version or scaling down. In such situations one has
> to stop akka (or whole node).
>
>
> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Sharding and unreachable node

[Justin du coeur]

There's no silver-bullet option for "fault tolerance" in situations like
this.  You absolutely do *not* want to start up alternate versions of the
sharded entities in this situation -- that's classic split-brain, and is
the surest route to data corruption.  You could create some sort of
reliable-ish messaging to the entities in this situation, so that the
messages will get retried after the entities are back, but as with any
reliable-messaging solution, getting it right is a considerable amount of
effort, and involves somewhere between "some" and "tons" of overhead.
 (Depending on how tolerant you're trying to be.)

This is pretty classic Akka: messaging *is* unreliable, due to situations
like this and others like it.  Success with Akka requires internalizing
that.  Any fault tolerance is typically up to the higher-level code -- if
it needs reliability, it is up to the higher-level protocol (particularly
at the sending end) to implement that.

On Mon, Feb 27, 2017 at 12:53 PM, Andrey Ilinykh  wrote:

> Hello everybody!
> I do some research about akka sharding. One moment is not clear for me
> right now.
> If some node becomes unreachable (crashed but not down, for example) all
> shards which belong to this node become unreachable. Which means all
> messages to these actors are dropped.
> Is it correct?
> If so, is it possible to implement some fault tolerance mechanism here?
>
> Thank you,
>   Andrey
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Clarity on the term "blocking"

[Justin du coeur]

Everything's talking about the same principle -- the question is focus:

On Wed, Feb 22, 2017 at 4:31 AM,  wrote:

> I read in many articles/SO posts, that the term *blocking* generally
> means a caller (and therefore the thread it executes in) will *wait* until
> some data is returned (or times out maybe).
>
This is talking about what blocking *is*.

> In akka.io docs however it talks about *blocking* only in terms of one
> thread possibly causing other threads to have to wait ie. it may block the
> progress of other threads eg. several threads all trying to acquire same
> resource lock.
>
This is talking about why blocking is a *problem*.

(Really, even deadlocks are something of a distraction: if you are blocking
too casually, you can run out of available threads.  That's the thing:
blocking is fine for the thread that is blocking, but it's tying up a
limited resource.)

By and large, a properly-constructed Akka program doesn't need to worry
about threads at all -- the underlying engine takes care of all of the
threading.  But this depends on the threads being available, and that, in
turn, means not chewing them up by blocking inside of Actors.  Which is why
the rule in Akka is to never block inside an Actor until you *absolutely*
must -- and if you must block, generally use a dedicated Dispatcher for the
purpose so that those Actors don't use the same thread pool as everybody
else...

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Dependency issue

[Justin du coeur]

Weird.  Any more call stack in the Exception?  At this point, I'm out of
ideas about what it might be -- there isn't enough information here to
hazard any more guesses...

On Tue, Feb 21, 2017 at 9:04 AM, Steve Winfield <
mail.stevewinfi...@gmail.com> wrote:

> Nope, that's why I'm so confused about it.
>
> --
> >>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] newbie question about await inside actors code

[Justin du coeur]

On Tue, Feb 21, 2017 at 8:03 AM, Alan Burlison 
wrote:

> I really like the "toolbox" approach of Akka but it can be a bit daunting
> to be given a box of spanners and then be expected to go build a car ;-)


Yeah, understood.  It's useful to keep in mind that Akka *is* a moderately
low-level toolkit; most of us who use it heavily are clear on that.  The
great thing about Akka is that it doesn't lie to you about where the hard
problems are (as opposed to many frameworks that basically brush things
under the rug), but it means you do have to wrestle with them.

This is why stuff like Akka-HTTP has started to happen: that's a much
higher-level framework built on *top* of Akka proper.  I expect more such
to appear in the coming years.

(Don't have any book recommendations personally, I'm afraid -- I've been
using Akka since before it was named Akka, so I don't have the right
perspective to know what's good to start out...)

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] newbie question about await inside actors code

[Justin du coeur]

On Tue, Feb 21, 2017 at 7:19 AM, Alan Burlison 
wrote:

> On 21/02/2017 12:12, Viktor Klang wrote:
>
> http://doc.akka.io/docs/akka/2.4/scala/actors.html#Stash
>>
>
> Ahah! I'd seen stash in the docs and not really come up with an case
> (other than become/become) where it would be useful, and then forgotten
> about it. I'm still not clear how it would help in this scenario though?


As I understand it, you want your parent to "wait" until it has collected
all the info from the children before it moves on to doing something else.
 (Forgive me if I'm misunderstanding your use case -- it isn't spelled out
in great detail above.)

The Akka-idiomatic way to do this is for the parent to do something like:

-- Send out the jobs to the children
-- become() into a different receive processor
-- In this new processor, everything *other* than the responses from the
children get stash()ed -- that is, you save them away for later
-- Once you have accumulated all of the child responses (or timed out -- it
is often adviseable to have a timeout scheduled), send out the aggregated
response.  Then unstash() everything that's been stored up, and become()
back to your original state.

Essentially, instead of waiting/blocking, you shunt everything else aside
(queueing it, essentially) until you're ready to handle it.  The effect is
largely the same, but without tying up threads.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Dependency issue

[Justin du coeur]

Is the room service receiving a message that contains a
players.model.Player?  I'd look for some sort of accidental inclusion in a
case like this...

On Mon, Feb 20, 2017 at 5:10 PM, Steve Winfield <
mail.stevewinfi...@gmail.com> wrote:

> The exception is not thrown by the player service but by the room service
> that doesn't load the class (it doesn't use it!)
>
> --
> >>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] newbie question about await inside actors code

[Justin du coeur]

Do you mean literally calling "sleep()"?  You should never, ever call
Thread.sleep() inside an Actor, and you shouldn't need to -- at worst, you
have the Actor use become() and stash() to store up messages until you get
the response you need; once you have all the needed information, you
process that, unstash() and become() back to the normal state.

Basically, blocking is always a bad idea inside Actors (for exactly the
reasons you suggest), and except for when interfacing to external libraries
it is basically never necessary.  Always figure that there is a
non-blocking way to deal with the problem.  stash() and become() are
usually your friend in such situations...

On Sun, Feb 19, 2017 at 1:05 PM, scala solist  wrote:

> I need to perform number of requests to different actors and sum them to
> some response. An actor wrap all requests inside futures and compose them
> to single. After that I suppose actor would be put in sleep until it
> recovers all needed information (or timer runs out). What if I had hundreds
> of such actors simultaneously?
>
> Naive approach is that they all would be put to sleep and would exhaust
> thread pool which leads to deadlock possibility. Does akka uses such naive
> approach or it has some tricky magic to return blocked actor thread back to
> executor? Should I avoid awaiting inside actors?
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Dependency issue

[Justin du coeur]

The exception suggests that players.model.Player isn't loaded into the
playerService -- are you sure it's loaded?

On Sun, Feb 19, 2017 at 3:27 AM, Steve Winfield <
mail.stevewinfi...@gmail.com> wrote:

> Hey,
>
> I have a bit of a problem. I got a service that communicates with 2
> different services (nodes) in an Akka cluster. Even though the services do
> not depend on each other, I get an exception, when I start a cluster
> sharding proxy and a cluster router group and then send a message to the
> router.
>
> // Start cluster sharding proxy (gets sharded on room service)
> val roomRegion = ClusterSharding(system).startProxy(
>   typeName = RoomEngine.shardName,
>   role = Some("rooms"),
>   extractEntityId = RoomEngine.extractEntityId,
>   extractShardId = RoomEngine.extractShardId)
>
> // Start router for player service
> val playerService = system.actorOf(
>   ClusterRouterGroup(
> RoundRobinGroup(Nil), ClusterRouterGroupSettings(
>   totalInstances = 100,
>   routeesPaths = List(s"/user/PlayerService"),
>   allowLocalRoutees = true,
>   useRole = Some("players")
> )
>   ).props(), name = s"PlayerServiceGroup")
>
> playerService ! GetPlayer(1)
> // Now room service throws ClassNotFoundException: ...players.model.Player 
> (class of player service)
>
>
> Do you know what's wrong with it?
>
> Thanks!
>
> Cheers,
> Steve Winfield
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to deal with massive states in Akka persistent actors

[Justin du coeur]

As you say, "it depends".  In particular, it depends on *how* massive
"massive" is.

As an example: my application's central Actors *can* get fairly large --
they're anywhere from a few K to several Megabytes in size.  Akka handles
that level of scale with reasonable aplomb -- I haven't hit any issues to
date.  In general, Akka doesn't care too much about how much data any given
Actor is carrying; that sort of thing mostly shows up as a tuning parameter
for your cluster.

That said, yes, you should spend some attention on potential snapshot
size.  I vaguely recall that Cassandra can get a bit iffy somewhere around
10 Meg/record, so I am careful to compress my snapshots when I serialize
them.  I would certainly be concerned if snapshots were getting into the
100 Meg range, and it's worth thinking about your requirements and maybe
doing some research into the DB and plugin you're planning on using.  (I
don't think Akka Persistence itself has any particular limits, but it has
to operate within the limits of the underlying DB.)

And yes, you *can* do without snapshots, but that comes at a cost when it
comes to recovery speed.  I would personally be cautious about a
no-snapshot approach unless I was confident that the Actor isn't going to
have than, say, 10k events over its lifetime.

On Thu, Feb 16, 2017 at 5:30 AM, Matteo  wrote:

> Hi,
>
> I read the Akka documentation about actors and streams abstraction and I
> found it very enlightening and fascinating. The only aspect that I did not
> completely understood is what is the best approach to deal with massive
> states within actors.
>
>
> Let’s say I have a client application that shows all visible assets of a
> given type (e.g. connected products or sensors of some kind) for the
> currently logged-in user. The list of visible assets could be seen as the
> state of a persistent actor that manages the lifecycle of the assets for
> specific user / tenant. Now, this state is potentially very big and it
> could contains tens of thousands entries (i.e. tens of thousands of
> assets). If I got it right, this actor could be seen as a projection of a
> underlying event store that shows the list of user accessible machines. My
> doubts are:
>
>
> 1. Is this a suitable use case for Akka? Or Akka assumes that the state
> associated with an actor is small in size and lightweight?
>
> 2. The snapshots generated by the actor could be quite big: is this a
> concern in terms of serialisation to and from the underlying snapshot
> storage?
>
> 3. To solve snapshots ser/deser overhead one could avoid them all
> together. But in this case the portion of the journal that is used by the
> actor increases indefinitely. In this case I wonder what is the cost of
> recovering.
>
>
> I understand that there are a lot of "it depends" answers for these
> questions, but I would like to get the right principles to apply when
> dealing with these scenarios in Akka and the potential pitfalls.
>
>
> Thank you!
>
> matteo
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Help: how to persist different actor types in different shard regions?

[Justin du coeur]

Um -- I *am* an application developer, a heavy user of Cluster Sharding and
Persistence.  I'm not part of the implementation team...

On Fri, Feb 10, 2017 at 12:42 PM, Qing Zheng <qzhen...@gmail.com> wrote:

> An akka actor provides location transparency. The logical path of an actor
> hides the detail implementation from an application developer. I know I can
> do it with some prefix, which means every application developer has do
> similar things. If that is the case, would it better to provide a default
> implementation in a base class? Hope you can think from an application user
> perspective instead of purely from implementation perspective.
>
> Thanks
>
> On Friday, February 10, 2017 at 5:35:16 AM UTC-8, Justin du coeur wrote:
>>
>> I don't know that we're going to agree here, but I *do* strongly
>> disagree.  They're independent libraries, and people use each exclusively
>> of the other.  There mustn't be cross-dependencies.
>>
>> And I have to admit, I don't understand what the problem is.  I simply
>> use a different naming convention for each Cluster Region, and that's no
>> more work than choosing a different prefix.  What's the big deal?
>>
>> On Thu, Feb 9, 2017 at 12:47 PM, Qing Zheng <qzhe...@gmail.com> wrote:
>>
>>> I disagree, you have all the pieces of your system, however, they are
>>> not fit well with each other at least that's how I feel from a user point
>>> of view. Just like you have database tableA and tableB, the ID in tableA
>>> has nothing to do with ID in tableB. This may not be a good analogy, but
>>> you get the idea. I agree with you at the lower level of akka persistence
>>> (journal/snapshot) it should have no knowledge of sharding at all.However,
>>> in the akka persistence base actor class it should take care of this.
>>> Otherwise every user has to come up with its own scheme to make persistence
>>> id unique across all actor classes. It would be nice to provide a default
>>> implementation in the base class and a user can customize it. The default
>>> implementation  can simply encode the actor class info together with some
>>> unique instance id within that class.
>>>
>>>   Thanks
>>>   Qing
>>>
>>> On Thursday, February 9, 2017 at 5:42:25 AM UTC-8, Justin du coeur wrote:
>>>>
>>>> Persistence and sharding are separate systems -- while they work well
>>>> together, neither depends upon the other.  So it would be inappropriate for
>>>> persistence to depend on knowledge of which sharding region an Actor is
>>>> in...
>>>>
>>>> On Wed, Feb 8, 2017 at 11:54 AM, Qing Zheng <qzhe...@gmail.com> wrote:
>>>>
>>>>> Hi Patrik,
>>>>>
>>>>>   My fault, I do have one instance of ActorA that has a duplicate
>>>>> persistence id as another instance of ActorB. Sorry about that.
>>>>>
>>>>>   Without persistence, the only requirement is entity id should be
>>>>> unique within each shard region, with persistence the requirement is
>>>>> persistence id should be unique across all the shard regions. My question
>>>>> is would it better to keep the same programming model with/without
>>>>> persistence? What's the reason not just to have persistence id only unique
>>>>> within the context of a shard region?
>>>>>
>>>>>   Thanks
>>>>>   Qing
>>>>>
>>>>> On Tuesday, February 7, 2017 at 9:00:26 AM UTC-8, Patrik Nordwall
>>>>> wrote:
>>>>>>
>>>>>> I don't know without seeing more code.
>>>>>>
>>>>>> On Tue, Feb 7, 2017 at 5:57 PM, Qing Zheng <qzhe...@gmail.com> wrote:
>>>>>>
>>>>>>> Yes, the persistence IDs are unique for each persistence instance.
>>>>>>> Anything else you think I am missing?
>>>>>>>
>>>>>>> Thanks for the quick response.
>>>>>>>
>>>>>>> Qing
>>>>>>>
>>>>>>> On Tuesday, February 7, 2017 at 1:26:45 AM UTC-8, Patrik Nordwall
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> How have you defined the persistenceId in ActorA and ActorB? It
>>>>>>>> must be unique for each persistent actor instance.
>>>>>>>>
>>>>>>>> On Tue, Feb 7, 2017 at 8:39 AM, Qing Zheng <qzhe...@gmail.com>
>&g

Re: [akka-user] Help: how to persist different actor types in different shard regions?

[Justin du coeur]

I don't know that we're going to agree here, but I *do* strongly disagree.
They're independent libraries, and people use each exclusively of the
other.  There mustn't be cross-dependencies.

And I have to admit, I don't understand what the problem is.  I simply use
a different naming convention for each Cluster Region, and that's no more
work than choosing a different prefix.  What's the big deal?

On Thu, Feb 9, 2017 at 12:47 PM, Qing Zheng <qzhen...@gmail.com> wrote:

> I disagree, you have all the pieces of your system, however, they are not
> fit well with each other at least that's how I feel from a user point of
> view. Just like you have database tableA and tableB, the ID in tableA has
> nothing to do with ID in tableB. This may not be a good analogy, but you
> get the idea. I agree with you at the lower level of akka persistence
> (journal/snapshot) it should have no knowledge of sharding at all.However,
> in the akka persistence base actor class it should take care of this.
> Otherwise every user has to come up with its own scheme to make persistence
> id unique across all actor classes. It would be nice to provide a default
> implementation in the base class and a user can customize it. The default
> implementation  can simply encode the actor class info together with some
> unique instance id within that class.
>
>   Thanks
>   Qing
>
> On Thursday, February 9, 2017 at 5:42:25 AM UTC-8, Justin du coeur wrote:
>>
>> Persistence and sharding are separate systems -- while they work well
>> together, neither depends upon the other.  So it would be inappropriate for
>> persistence to depend on knowledge of which sharding region an Actor is
>> in...
>>
>> On Wed, Feb 8, 2017 at 11:54 AM, Qing Zheng <qzhe...@gmail.com> wrote:
>>
>>> Hi Patrik,
>>>
>>>   My fault, I do have one instance of ActorA that has a duplicate
>>> persistence id as another instance of ActorB. Sorry about that.
>>>
>>>   Without persistence, the only requirement is entity id should be
>>> unique within each shard region, with persistence the requirement is
>>> persistence id should be unique across all the shard regions. My question
>>> is would it better to keep the same programming model with/without
>>> persistence? What's the reason not just to have persistence id only unique
>>> within the context of a shard region?
>>>
>>>   Thanks
>>>   Qing
>>>
>>> On Tuesday, February 7, 2017 at 9:00:26 AM UTC-8, Patrik Nordwall wrote:
>>>>
>>>> I don't know without seeing more code.
>>>>
>>>> On Tue, Feb 7, 2017 at 5:57 PM, Qing Zheng <qzhe...@gmail.com> wrote:
>>>>
>>>>> Yes, the persistence IDs are unique for each persistence instance.
>>>>> Anything else you think I am missing?
>>>>>
>>>>> Thanks for the quick response.
>>>>>
>>>>> Qing
>>>>>
>>>>> On Tuesday, February 7, 2017 at 1:26:45 AM UTC-8, Patrik Nordwall
>>>>> wrote:
>>>>>>
>>>>>> How have you defined the persistenceId in ActorA and ActorB? It must
>>>>>> be unique for each persistent actor instance.
>>>>>>
>>>>>> On Tue, Feb 7, 2017 at 8:39 AM, Qing Zheng <qzhe...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>I have two actor types
>>>>>>>
>>>>>>>
>>>>>>> class ActorA  extends UntypedPersistentActor {
>>>>>>>   //
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> class ActorB extends  UntypedPersistentActor {
>>>>>>>   //
>>>>>>> }
>>>>>>>
>>>>>>> public static void main(String[] argv) {
>>>>>>>   ActorSystem system = ActorSystem.create("ActorSystem",
>>>>>>> ConfigFactory.load(argv[0]));
>>>>>>>   Persistence.apply(system);
>>>>>>>   ClusterShardingSettings settings = ClusterShardingSettings.create
>>>>>>> (system);
>>>>>>>   ClusterExtractor extractor = new ClusterExtractor();
>>>>>>>
>>>>>>>   ClusterSharding.get(system).start("ShardRegionA",
>>>>>>> Props.create(ActorA.class), settings, extractor);
>>>>>>>   ClusterSharding.get(system).start("ShardRegionB

Re: [akka-user] About Akka persistent redis

[Justin du coeur]

Where did you get those settings from?

On Thu, Feb 9, 2017 at 7:11 PM, Dai Yinhua <yhdai.2...@gmail.com> wrote:

> Well, I'm using below maven settings as the document provided.
>
> 
>   com.hootsuite
>   akka-persistence-redis_2.11
>   0.6.0
> 
>
>
> On Thursday, 9 February 2017 21:38:49 UTC+8, Justin du coeur wrote:
>>
>> Hmm.  I don't know the library, but I notice that it seems to require a
>> custom Bintray resolver.  Have you added that to your sbt file?
>>
>> On Wed, Feb 8, 2017 at 9:54 PM, Dai Yinhua <yhdai...@gmail.com> wrote:
>>
>>> Hi team,
>>>
>>> Do you ever used the akka persistent redis: https://index.scala-lan
>>> g.org/hootsuite/akka-persistence-redis?
>>>
>>> Why I can't get the repository from maven central?
>>>
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Help: how to persist different actor types in different shard regions?

[Justin du coeur]

Persistence and sharding are separate systems -- while they work well
together, neither depends upon the other.  So it would be inappropriate for
persistence to depend on knowledge of which sharding region an Actor is
in...

On Wed, Feb 8, 2017 at 11:54 AM, Qing Zheng  wrote:

> Hi Patrik,
>
>   My fault, I do have one instance of ActorA that has a duplicate
> persistence id as another instance of ActorB. Sorry about that.
>
>   Without persistence, the only requirement is entity id should be unique
> within each shard region, with persistence the requirement is persistence
> id should be unique across all the shard regions. My question is would it
> better to keep the same programming model with/without persistence? What's
> the reason not just to have persistence id only unique within the context
> of a shard region?
>
>   Thanks
>   Qing
>
> On Tuesday, February 7, 2017 at 9:00:26 AM UTC-8, Patrik Nordwall wrote:
>>
>> I don't know without seeing more code.
>>
>> On Tue, Feb 7, 2017 at 5:57 PM, Qing Zheng  wrote:
>>
>>> Yes, the persistence IDs are unique for each persistence instance.
>>> Anything else you think I am missing?
>>>
>>> Thanks for the quick response.
>>>
>>> Qing
>>>
>>> On Tuesday, February 7, 2017 at 1:26:45 AM UTC-8, Patrik Nordwall wrote:

 How have you defined the persistenceId in ActorA and ActorB? It must be
 unique for each persistent actor instance.

 On Tue, Feb 7, 2017 at 8:39 AM, Qing Zheng  wrote:

> Hi,
>
>I have two actor types
>
>
> class ActorA  extends UntypedPersistentActor {
>   //
> }
>
>
> class ActorB extends  UntypedPersistentActor {
>   //
> }
>
> public static void main(String[] argv) {
>   ActorSystem system = ActorSystem.create("ActorSystem",
> ConfigFactory.load(argv[0]));
>   Persistence.apply(system);
>   ClusterShardingSettings settings = ClusterShardingSettings.create
> (system);
>   ClusterExtractor extractor = new ClusterExtractor();
>
>   ClusterSharding.get(system).start("ShardRegionA",
> Props.create(ActorA.class), settings, extractor);
>   ClusterSharding.get(system).start("ShardRegionB",
> Props.create(ActorB.class), settings, extractor);
>
>   ActorRef shardRegionA = ClusterSharding.get(system).sh
> ardRegion("ShardRegionA");
>   ActorRef shardRegionB = ClusterSharding.get(system).sh
> ardRegion("ShardRegionB");
>
>   //.
>
>   Without calling persist.add method everything works as I expected. I
> can send a cluster message to shard region A or B and ActorA or ActorB 
> will
> handle the corresponding message differently.However, after invoking the
> persist.add method. ActorA will receive recovery message for ActorB or
> maybe vice versa. Looks like the cluster messages that have been persisted
> do not have the shard region information. How can I solve this problem?
>
>   Thanks
>   Qing
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/additional/faq.html
> >> Search the archives: https://groups.google.com/grou
> p/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.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



 --

 Patrik Nordwall
 Akka Tech Lead
 Lightbend  -  Reactive apps on the JVM
 Twitter: @patriknw

 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> --
> >> 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
> ---
> 

Re: [akka-user] About Akka persistent redis

[Justin du coeur]

Hmm.  I don't know the library, but I notice that it seems to require a
custom Bintray resolver.  Have you added that to your sbt file?

On Wed, Feb 8, 2017 at 9:54 PM, Dai Yinhua  wrote:

> Hi team,
>
> Do you ever used the akka persistent redis: https://index.scala-
> lang.org/hootsuite/akka-persistence-redis?
>
> Why I can't get the repository from maven central?
>
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Persistent Graph Stage

[Justin du coeur]

Closely related (essentially a more scalable version of the same desire),
something for folks to consider as a possible long-term idea:

I've been idly pondering for a few months what the interaction of Akka
Streaming and Cluster Sharding *should* look like, in an ideal world --
what the end-user design would be.  The specific (but fairly general) use
case here is having an Akka HTTP front end working with Sharded Actors that
are providing the guts of an application.  I know that this can be done
now, but it still feels rather clunky and homebrew, not as elegant as Akka
Streaming itself.

I believe what I *want* is to be able to define a Stage that is actually
materialized as (roughly) a sharded, persistent Actor.  As with normal Akka
Streaming, the actual definition of the Stage wouldn't look much like a
normal Actor definition, but I suspect it *would* look somewhat like a
Typed Akka Actor declaration: strongly-typed, usually taking a Trait as its
input type and actually processing subtypes of that Trait.  It would be
fundamentally stateful and Event-Sourced, although likely with the details
of both the Sharding and the Persistence somewhat abstracted out.
 (Admittedly, there are probably limits to how far the Persistence can be
abstracted, due to serialization considerations.)

Key to all of this is that, when you add this Stage to a graph, what it
actually materializes is a *proxy* that hooks into the normal Cluster
Sharding system, wrapping the inputs in some sort of standard envelope
build on top of the ID of this "stage".  (As always for Sharding and
Persistence, the stage would need to define what the ID is.)  And in
particular, it would be entirely legal (and normal) to have multiple Graphs
talking to the same underlying Sharded Entity through these proxies.  Each
Graph would stick to its own knitting, logically speaking, but they'd all
be talking to the same *data*.

In principle, this seems to make a lot of sense -- after all, a
well-designed Persistent Actor can be thought of as simply the sum of a
stream of events.  I *suspect* it would allow one to build
Sharded/Persistent applications more elegantly, with significantly less
boilerplate.  (I also suspect it would obviate some use cases of Typed
Akka, but I don't think that's a complete tragedy.  If designed with some
foresight, it might make the transition to Typed Akka easier for projects
that adopt this.)

All of this is rather hypothetical, of course -- I'm sure there are many
challenges lurking under the surface, and I don't know the relevant code
yet.  But it's where I'm winding up when I ask, "what would it mean to use
Akka HTTP in Querki?"  I'm coming to strongly suspect that there's a
relatively elegant and general abstraction lurking here, the
Sharding/Persistence equivalent of Akka Streaming, and that it holds
similar promise to drag more of Akka up the abstraction stack...

On Mon, Feb 6, 2017 at 10:59 AM, Viktor Klang 
wrote:

> Would it be more flexible with a `persistentBuffer` stage?
>
> On Mon, Feb 6, 2017 at 4:54 PM, Konrad Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> Would you be up to implementing it? Otherwise I don't think there will be
>> much happening around this.
>> It could start out in github.com/akka/akka-stream-contrib
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 6 February 2017 at 16:51:19, Héctor Veiga (kec...@gmail.com) wrote:
>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> √
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  

Re: [akka-user] Akka persistence: can you use it as the main storage system for you application's data?

[Justin du coeur]

On Mon, Jan 30, 2017 at 1:00 PM, José González Gómez <
jose.gonza...@openinput.com> wrote:

> First of all, Akka persistence stores data using a journal. Data in that
> journal (both events and snapshots) are stored after being serialized. This
> seems to pose several problems:
>
>- You can't have access to data as you may have in a SQL or NoSQL
>database, so it seems to be hard to diagnose corrupt data or relationships
>among that data. Am I missing anything here?
>
> Not much, but keep in mind that the journal is the *high* level view of
things.  Underneath, that journal is usually *implemented* using a SQL or
NoSQL database.  (Most often Cassandra, but there are a bunch of options.)
 So it is *possible* to introspect on the data using ordinary DB tools,
although I wouldn't necessarily recommend it: the schema is peculiar to the
Persistence implementation, and you'd have to deserialize in order to make
sense of it.

>
>- Storing data in a journal seems great for storing immutable data and
>recovering events for event sourced data, but... how do you manage to do
>queries on that data? I mean, if you store orders using Akka persistence,
>how do you get orders for example between two dates? The only thing I can
>think of here is to use PersistenceQueries in order to keep a traditional
>database in sync with the journal, but that kind of defeats the purpose of
>Akka persistence, doesn't it?
>
> That comes down to how you structure your application.  Keep in mind that
a typical Akka program just plain doesn't *think* like a SQL-centric one,
and you're generally working without the usual sorts of ad-hoc queries you
do in SQL.  So you need to think about the sorts of queries you're likely
to want, and structure the Actors to support them.  (This really isn't a
persistence thing, it's an Actors thing.)  In the case you're describing,
the answer might be to, eg, denormalize things a bit, and maintain an Actor
(or even just a Cassandra log) indexing the orders by Date.  There's no
one-size-fits-all answer.

It's also possible to do *some* cross-cutting queries using Tags, but
that's a limited mechanism; personally, I haven't done much with it.

Regarding how to keep actors in memory, you may have several requests that
> access the same entity (persistent actor) so I guess they have a different
> life cycle than request specific actors, that can be destroyed after
> serving the request. The point is that you seem to end up with the whole
> database in memory if you don't provide a mechanism to shut down actors
> that hasn't been used recently. But then you may be shutting down actors
> that may be used in a short amount of time and have a negative impact on
> performance due to the actor reloading its state. I guess this is somehow
> alleviated with the use of snapshots. Again, am I missing anything here?
>

Usually, the situation you're describing is handled with a combination of:

   - Cluster Sharding, so that you can just send messages to Actors, and
   wake them up automatically if they're passivated, and
   - Passivation -- having each Actor on a timeout or some such, so that it
   goes away when you're not actively using it.

This particular combination is *very* common, and in practice works well if
you tune your timeouts to match your circumstances.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] how to stop waiting for association failed remote??

[Justin du coeur]

Basically, you need to implement one of the strategies describes in the
Split Brain Resolver document yourself.  This isn't rocket science, but it
does require a bunch of tricky work.  (Which is why Lightbend can charge
money for it.)

You need to pay attention to the Cluster, and particularly to Unreachable
events; when a node becomes Unreachable for long enough, you declare it to
be Down.  That's the heart of it.

The tricky bit is that you need to think about what this looks like both in
the case of the node *actually* going down, and in the case of a network
partition -- when nodes just can't see each other for a while.  It's
essential that, for example, if you have a Cluster of nodes A, B and C, and
C becomes disconnected for too long, that A and B mark it as Down *and* C
kills itself as well.  Otherwise, you wind up with Split Brain -- two
disconnected clusters.

On Tue, Jan 31, 2017 at 2:51 AM, Seongjong Jeon 
wrote:

> Thank you for answering kindly.
>
> I found  Split Brain Resolver
> 
>  in http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#Downing
> 
>  which is that I am exactly  looking for.
> (http://doc.akka.io/docs/akka/akka-commercial-addons-1.0/
> scala/split-brain-resolver.html)
>
> But it seems like NOT FREE, right?
>
> Without commercial-addons, Is there any suggested way?
>
> There's one thing that I want to try as below.
>
> *  document(URL you gave me) say It can also be performed
> programmatically with Cluster(system).down(address).*
>
> But how can I catch a node which should be down?
> Maybe there's some class that I can use in ClusterLisner. ??
>
>
>
>
>
>
>
> 2017년 1월 26일 목요일 오후 9시 44분 43초 UTC+9, Patrik Nordwall 님의 말:
>>
>> That is because NODE2 is still trying to send messages to NODE1.
>> Heartbeat messages more specifically. You see "Marking node(s) as
>> UNREACHABLE". That is not enough to remove the node from the cluster
>> membership. You also need to down the node to confirm that it should be
>> removed. Read more in http://doc.akka.io/docs/akk
>> a/2.4/scala/cluster-usage.html#Downing
>>
>> On Thu, Jan 26, 2017 at 4:05 AM, Seongjong Jeon 
>> wrote:
>>
>>> I made a sample for asking my problem.
>>>
>>> There's simple Akka cluster with 2 nodes like the below.
>>>
>>> NODE 1 : akka.tcp://system@0.0.0.0:1
>>>
>>> NODE 2 : akka.tcp://system@0.0.0.0:2
>>>
>>>
>>>
>>> object Main extends App{
>>>
>>>
>>>
>>>   val system = ActorSystem("system")
>>>
>>>
>>>
>>>   system.actorOf(Props[ClusterListener])
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>> class ClusterListener extends Actor with ActorLogging {
>>>
>>>   val core = Cluster(context.system)
>>>
>>>   core.subscribe(self, InitialStateAsEvents, classOf[MemberEvent],
>>> classOf[UnreachableMember], classOf[ClusterDomainEvent])
>>>
>>>
>>>
>>>   def receive = {
>>>
>>> case state: CurrentClusterState ⇒
>>>
>>>
>>>
>>> log.debug("Current members: {}", state.members.mkString(", "))
>>>
>>> case MemberUp(member) =>
>>>
>>> log.debug("Member is Up: {}", member.address)
>>>
>>> case UnreachableMember(member) =>
>>>
>>> log.debug("Member detected as unreachable: {}", member)
>>>
>>> case MemberRemoved(member, previousStatus) =>
>>>
>>> log.debug("Member is Removed: {} after {}",
>>>
>>> member.address, previousStatus)
>>>
>>> case LeaderChanged(member) => log.info("Leader changed: " + member)
>>>
>>>
>>>
>>> case any: MemberEvent => log.info("Member Event: " + any.toString)
>>>
>>>   }
>>>
>>> }
>>>
>>> Stpes
>>>
>>> 1. When the cluster starts, node 1 was "Leader" node
>>>
>>> 2. I stopped node 1(leader) @11:17:19.098
>>>
>>> 3. NODE2 log "Association with remote system [akka.tcp://
>>> system@0.0.0.0:1] has failed"
>>>
>>> 4. after 10 sec, Leadeer is changed to NODE2@11:17:30.485
>>>
>>> but, It seems like NODE2 waits for NODE1 coming back for forever.
>>>
>>> Question1 : Is there any way to make NODE2 stop for waiting?
>>>
>>> Question2 :  Waht's the meaning of this part of log : address is now
>>> gated for [5000] ms?
>>>
>>> Thanks in advance
>>>
>>> Node1
>>> log 
>>>
>>> 11:16:39.774 [system-akka.actor.default-dispatcher-4] INFO
>>> akka.event.slf4j.Slf4jLogger - Slf4jLogger started
>>>
>>> 11:16:39.874 [system-akka.actor.default-dispatcher-4] INFO
>>> akka.remote.Remoting - Starting remoting
>>>
>>> 11:16:40.018 [system-akka.actor.default-dispatcher-4] INFO
>>> akka.remote.Remoting - Remoting started; listening on addresses
>>> :[akka.tcp://system@0.0.0.0:1]
>>>
>>> 11:16:40.019 [system-akka.actor.default-dispatcher-4] INFO
>>> 

Re: [akka-user] How to avoid InvalidActorNameException with cluster sharding

[Justin du coeur]

You can, but you have to ensure that that name is unique in this context.
Specifically, each of the child Actors of a given parent must have a unique
name within that parent.  So this error is saying that one of your entities
is trying to create multiple children with the same name.

If you want to set the name, you're going to have to do it algorithmically
in some way to make sure that it's unique per-entity.

On Mon, Jan 30, 2017 at 9:44 AM, Dai Yinhua  wrote:

> Hi team,
>
> I'm using cluster sharding to process request from client.
> My entity actor is actually some factory actor, which means it will create
> different actors based on the request parameters, and I will set a name for
> each actor.
> Example code as below:
>
>if(ricRequestMsg.mAppId ==
> AnalyticsAppId.MKTDIGEST) {
> ActorRef appActor = getContext().actorOf(Props.create(MktDigestActor.class),
> "mktdigestactor");
> appActor.forward(message, getContext());
> }
>
> The problem is that when it receives the same request message twice, it
> will report exception:
> akka.actor.InvalidActorNameException: actor name [mktdigestactor] is not
> unique!
>
> And the actor is stopped.
>
> Does that means I can't set the name for the created actor?
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-persistence] Sending messages to a shard region with AtLeastOnce delivery

[Justin du coeur]

Ah, I see -- sorry, I'd missed that context.

I can't say I've used AtLeastOnceDelivery, but the code certainly *looks*
reasonably straightforward.  It looks like it ought to work unless there is
something wrong with sending to a ShardRegion via ActorSelection.  (Which
is what is going on under the hood.)

What do your MsgWithId and ShardEntity classes look like?  Are you
confident that idExtractor() and shardResolver() work correctly with
MsgWithId?

On Fri, Jan 20, 2017 at 2:57 PM, <dave.hag...@threatstack.com> wrote:

> The deliver() method is part of the AtLeastOnceDelivery trait which is
> part of the persistence module (http://doc.akka.io/docs/akka/
> current/scala/persistence.html#At-Least-Once_Delivery). You use that
> method to provide a monotonically increasing delivery ID which can later be
> confirmed or retried. The deliver() method takes an actor path and you need
> to return a message that will ultimately be sent to the actor (in my case
> it's the actor ref to the shard region).
>
> On Friday, January 20, 2017 at 12:35:40 PM UTC-5, Justin du coeur wrote:
>>
>> Hmm.  Where is the deliver() method coming from?  Normally you send
>> messages to sharded entities with the normal tell() method on the
>> ShardRegion, same as any other Actor...
>>
>> On Fri, Jan 20, 2017 at 9:39 AM, <dave@threatstack.com> wrote:
>>
>>> Hi All,
>>>
>>> Im using cluster sharding and I also have a use case for AtLeastOnce
>>> guaranteed message delivery (which of course requires persistence). The
>>> problem is that the deliver() method is not actually sending my messages to
>>> the shard region. Here's some code for the shard region:
>>>
>>> val shardRegion = ClusterSharding(context.system).start(
>>>   typeName = ShardName,
>>>   entityProps = ShardEntity.props(appConfig),
>>>   settings = ClusterShardingSettings(context.system),
>>>   extractEntityId = ShardEntity.idExtractor,
>>>   extractShardId = ShardEntity.shardResolver)
>>>
>>>
>>> Here's the delivery code:
>>>
>>> persist(Message(data)) { _ =>
>>>   // Is this the correct way to send
>>>   // persistent messages to shard region??
>>>   deliver(shardRegion.path) { deliveryId =>
>>> MsgWithId(deliveryId, data)
>>>   }
>>> }
>>>
>>>
>>> For some reason, the shard region entities never see the messages from
>>> the call to deliver(). Am I doing something wrong?
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.