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

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 >

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

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

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

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

Re: [akka-user] Message processed by Actors

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

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

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

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

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,

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

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

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

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,

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

(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

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

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,

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

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: > > > /** > *

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

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

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

ce 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

Re: [akka-user] Akka Dispatcher Issue

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 =

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

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

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

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

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

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

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

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

Re: [akka-user] Akka Best Practice

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

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

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

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

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

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

d":"11","quantity":3,"price":1.0," > title":"ff","imageUrl":"xv"} > > and Response comes: > {"cart_id":"18768458-01d5-4f65-b7f8-abe49ba67775","user_ > id":"---

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

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

Re: [akka-user] persistAll()

: ⇒ Unit): Unit = { >> >> val durables = events map { e ⇒ >> DurableEvent(e).causedBy(cm) >> } >> >> if(durables.isEmpty) done else { >> persistAll(durables)(applyEvent) >> deferAsync()(_ ⇒ done) >> } &g

Re: [akka-user] persistAll()

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

[akka-user] persistAll()

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

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

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,

Re: [akka-user] Cluster Singleton Migration

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

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

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

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

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

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

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

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

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

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

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

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

toso` 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/ >>>&

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [akka-user] Akka Routing question

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 >

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

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

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

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

Re: [akka-user] Naive question

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

Re: [akka-user] Naive question

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

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

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

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

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

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

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

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

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

Re: [akka-user] Sharding and unreachable node

t 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

Re: [akka-user] Sharding and unreachable node

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

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

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

Re: [akka-user] Dependency issue

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

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

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

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

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

Re: [akka-user] Dependency issue

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

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

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

Re: [akka-user] Dependency issue

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

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

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

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

m 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

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

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

Re: [akka-user] About Akka persistent redis

sday, 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..

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

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:

Re: [akka-user] About Akka persistent redis

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

Re: [akka-user] Persistent Graph Stage

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

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

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

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

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

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

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

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

tor 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? Norm

  1   2   3   >