Re: [akka-user] Can Akka actors deadlock?

You could also look at Requester (I haven't) https://github.com/jducoeur/Requester On Wed, Aug 26, 2015 at 10:21 AM, Richard Rodseth wrote: > Robert, in my case the REST endoint is using Spray. The per-request actor > has a reference to the RequestContext, and calls complete() on

Re: [akka-user] Can Akka actors deadlock?

Robert, in my case the REST endoint is using Spray. The per-request actor has a reference to the RequestContext, and calls complete() on it, before stopping itself. I don't have time to check, but it might be modelled on this Activator Template (which I think is referenced in the net-a-porter blog

Re: [akka-user] Can Akka actors deadlock?

ask() returns a future. You can do things like use Future.sequence, or for-comprehensions. That said, in my project we worked pretty hard to avoid using the ask() pattern. http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ On Wed, Aug 26, 2015 at 9:11 AM, kraythe wrote:

Re: [akka-user] ShardRegion vs EventBus

an we have an arbitrary number of topics, eg. one per channel? On Fri, Aug 7, 2015 at 2:01 AM, Patrik Nordwall wrote: > > > On Tue, Jul 21, 2015 at 10:56 PM, Richard Rodseth > wrote: > >> I'd love a little more input on this, being a complete neophyte when it >>

Re: [akka-user] Actors without side effects (var-decl)

I sometimes use a single var containing an immutable model. Remember that you don't have to worry about synchronization and locks, so multiple vars may not be the end of the world. I also use the become(state) technique. Also look into the FSM trait. http://doc.akka.io/docs/akka/snapshot/scala/fsm.

Re: [akka-user] Re: Dealing with exceptions with pipeTo

I sometimes call recover on the returned Future to generate a message of my own, before doing the pipeTo. On Wed, Aug 5, 2015 at 6:30 AM, Johan Andrén wrote: > pipeTo will wrap failures in an akka.actor.Status.Failure and send that > to the actor that you direct the result to (self in this case)

Re: [akka-user] ShardRegion vs EventBus

utedPubSub with sendOneMessageToEachGroup and a custom routing logic? Thanks for any thoughts on this use case. On Fri, Jul 10, 2015 at 9:11 AM, Richard Rodseth wrote: > But I'll take a look, thanks. Not sure if one topic per channel is > feasible. > > On Fri, Jul 10, 2015 at 9

Re: [akka-user] ANNOUNCE: Akka Streams & HTTP 1.0

Great news. Once the new modules are merged into 2.4, will the only changes to the 2.3 artifacts be bug fixes? On Wed, Jul 15, 2015 at 5:40 AM, Konrad Malawski wrote: > Dear hakkers, > > we—the Akka committers—are very pleased to announce the final release of > Akka Streams & HTTP 1.0. After cou

Re: [akka-user] ShardRegion vs EventBus

But I'll take a look, thanks. Not sure if one topic per channel is feasible. On Fri, Jul 10, 2015 at 9:04 AM, Richard Rodseth wrote: > Nope. I imagined it to be for broadcasting, rather than having something > analagous to LookupClassification. > > On Fri, Jul 10, 2015 at 12

Re: [akka-user] ShardRegion vs EventBus

Nope. I imagined it to be for broadcasting, rather than having something analagous to LookupClassification. On Fri, Jul 10, 2015 at 12:16 AM, Jim Hazen wrote: > Tried looking at the DistributedPubSub module? > > -- > >> Read the docs: http://akka.io/docs/ > >> Check the

[akka-user] ShardRegion vs EventBus

We're not using Akka Cluster yet, but I have an entity actor type that is ripe for sharding. But there's a complication. The numerous entities are receiving event data for various "channels", and rather than receiving messages directly from the supervisor, the supervisor publishes them to an Event

Re: [akka-user] Re: Integrating different Bounded Contexts

Oh, I misunderstood. Thanks for clarifying. I'll be interested in other reactions. My impression (perhaps incorrect) is that a small subset of Akka users are using Akka Cluster. On Fri, Jun 5, 2015 at 3:24 PM, Guido Medina wrote: > No, I have a single cluster, each micro-service is an Akka syste

Re: [akka-user] Re: Integrating different Bounded Contexts

So each BC is an Akka Cluster, and you are relying on remote Akka (remote) messages to propagate changes from one BC to another? That sounds risky. Implementing DDD has a section (p303) called "Spreading the news to Remote Bounded Contexts" On Fri, Jun 5, 2015 at 11:18 AM, Guido Medina wrote: >

Re: [akka-user] Integrating different Bounded Contexts

You don't want more than one ActorSystem per process. If each BC is a separate process (a la microservices) then having something like Kafka to durably message between them would be great. Within an ActorSystem, you can use the Akka EventBus to (non-durably) message between root-level actors that d

Re: [akka-user] [2.3.11] Is akka.persistence production ready?

nd docs about it. > > The query side will follow once we have Akka Streams (which are nearing > 1.0 now) > > Eventuate is a nice project, and as Martin describes in the blog post it > chooses a different trade off (AP) than Persistence (CP). > > > -- Konrad > &

Re: [akka-user] [2.3.11] Is akka.persistence production ready?

Amir, you asked about alternatives. It seems Martin Krasser is no longer involved with Akka Persistence and has his own project Eventuate. I don't have any experience with it (or Akka Persistence for that matter), but here's a recent blog post: http://rbmhtechnology.github.io/akka-persistence-even

[akka-user] Stamina

No, not referring to the effort required to keep up with the Akka team :) I just came across this: https://github.com/scalapenos/stamina and wondered if anyone had any thoughts about it. I'm itching to pitch Akka persistence, but would like the read side and serialization to be well-baked. --

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Have you looked at the pipeTo pattern and the Stash trait? I'm not sure why a combination of pipeTo and become() with Stash wouldn't work. On Thu, May 14, 2015 at 4:33 AM, Andrew Gaydenko wrote: > It's funny just now I have met the same situation! :) > > More strictly, my case is even simpler as

Re: [akka-user] Re: Akka Persistence on the Query Side: The Conclusion

ents available with > akka-persistence > > With the other options, choices enough. Apply them as you require. > > Kind regards, > > Olger > > > > > > > On Fri, May 8, 2015 at 10:58 PM, Richard Rodseth > wrote: > >> Hi Olger >> >> C

Re: [akka-user] Re: Akka Persistence on the Query Side: The Conclusion

Hi Olger Could you please elaborate a bit on your appoach? I'm not sure I follow. Thanks. On Fri, May 8, 2015 at 4:17 AM, Olger Warnier wrote: > Hi Alejandro, > > You have a number of options > > - when you have a single persistence Id, write a view for that > - when you want to aggregate even

[akka-user] Activator: akka-stream-scala template compilation error

You're probably aware of this already: [error] /Users/rrodseth/dev/samples/akka-stream-scala/src/main/scala/sample/stream/GroupLogFile.scala:34: too many arguments for method mapAsync: (parallelism: Int)(f: ((String, akka.stream.scaladsl.Source[String,Unit])) => scala.concurrent.Future[T])akka.str

Re: [akka-user] Akka HTTP TLS support ETA?

Roland tweeted yesterday: >> Yesterday the #jaxcon award, today merged HTTP client (@sirthias ) and WebSockets (@virtualvoid ) and TLS support—can tomorrow be even better? << On Fri, Apr 2

Re: [akka-user] Re: Akka CQRS / Cluster Sharding - Change management of "Events" and other questions

My favourite topic https://groups.google.com/forum/#!topic/akka-user/mNVxRPRUDv0 Jay Kreps recently strongly endorsed Avro for use with Kafka. http://t.co/l9uTFmb6OS On Mon, Apr 13, 2015 at 10:54 AM, Greg Young wrote: > For 1 use weak serialization (say json) > > > On Monday, April 13, 2015 a

Re: [akka-user] NewRelic Integration for Akka Application

Have you looked at Kamon? On Tue, Apr 7, 2015 at 1:49 PM, K.M. Fazle Azim Babu wrote: > Hi, > > I have application written using Akka library, and I want to use New Relic > to monitor it. > > I tried to instrument the akka application using Newrelic's custom java > transaction traces. But data a

Re: [akka-user] Per-request vs Work Pulling vs Dispatcher tuning

explicitly give a different > dispatchers to the Futures)? > > -Endre > > On Fri, Apr 3, 2015 at 9:36 PM, Richard Rodseth > wrote: > >> At startup our application reads a bunch of rows d of type D of a table, >> and for each sets in motion a bunch of Spray clie

[akka-user] Per-request vs Work Pulling vs Dispatcher tuning

At startup our application reads a bunch of rows d of type D of a table, and for each sets in motion a bunch of Spray client calls and other database calls then spins up a bunch of actors of type C which generate more HTTP and DB calls. A fair amount of Future composition and pipeTo happens in the

Re: [akka-user] Again about tell don't ask and use Actor tell instead future

Hi Vladimir I have had good luck with using per-request actors as in the Net-a-porter activator template, and a replyTo:ActorRef in the messages sent to my "DbActor" (which still talks to a DAO) Some more detail in this thread http://qnalist.com/questions/5581605/using-tell-or-ask-with-akka-persi

Re: [akka-user] Re: Event versioning revisited

I see Scala pickling has a stable release http://notes.implicit.ly/post/110275857699/pickling-0-10-0 If anyone has any updates on its viability for event versioning, please post. On Thu, Oct 23, 2014 at 1:16 PM, Christian Douven wrote: > We are using MessagePack as our binary serialization for

Re: [akka-user] Akka Roadmap Update

I'm sure you're right. Sounds like upgrading both JRE and JDK throughout will be a prerequisite for using Akka 2.4. On Fri, Dec 19, 2014 at 1:53 PM, Roland Kuhn wrote: > > > 19 dec 2014 kl. 22:38 skrev Richard Rodseth : > > Sorry, you lost me there. Java 6 is not in

Re: [akka-user] Akka Roadmap Update

t 11:39 AM, Roland Kuhn wrote: > > > 19 dec 2014 kl. 20:35 skrev Roland Kuhn : > > > 19 dec 2014 kl. 20:09 skrev Richard Rodseth : > > Hi Roland > > I'm relaying (not very well) questions from colleagues. > > We don't deploy VM’s or docker containers. O

Re: [akka-user] Akka Roadmap Update

opment machines > are easier and earlier upgraded than deployment machines, in which scenario > does this question come up? > > Regards, > > Roland > > 18 dec 2014 kl. 19:09 skrev Richard Rodseth : > > Hi Roland > > In a mixed Java/Scala project that does not

Re: [akka-user] Re: Domain Events, Aggregate Persistence Events and cross-aggregate consistency

It's not obvious to me that Alerts are part of the Monitor aggregate, but perhaps they are, with the in-memory model containing only the last alert, and a Read Model Projection, to use the term in Appendix A, to allow querying of alerts. On Thu, Dec 18, 2014 at 1:38 PM, Vaughn Vernon wrote: > >

Re: [akka-user] Re: Domain Events, Aggregate Persistence Events and cross-aggregate consistency

Hi Vaughn Thanks so much for replying. I have your excellent book and the Blue Book, but obviously I'm still a bit unclear on some things. > > So you are giving unique identity to Domain Events? That sounds less like > Event Sourcing already. While that can be done (and my book discusses it), >

Re: [akka-user] Akka Roadmap Update

Hi Roland In a mixed Java/Scala project that does not use Java APIs to Akka, Play etc, would the Java code need to be compiled with the Java 8 compiler, or would this just be a runtime dependency? On Thu, Dec 18, 2014 at 5:10 AM, Roland Kuhn wrote: > > Dear hakkers, > > it has been a while since

[akka-user] Domain Events, Aggregate Persistence Events and cross-aggregate consistency

I should probably go back and read some of the threads about Akka persistence and CQRS/ES. The system I'm working on has actors (let's call them Monitors) that monitor event data and generate Alerts. Both Monitors and Alerts are entities with persistent state. In DDD terms, I think of them both as

Re: [akka-user] Drain mailbox on shutdown

? > > On Thu, Dec 11, 2014 at 1:26 AM, Richard Rodseth > wrote: > >> I've read some of the posts on shutdown patterns, reapers, graceful >> shutdown and the like, but am still unclear on the best strategy for my >> situation. >> >> The system is genera

[akka-user] Drain mailbox on shutdown

I've read some of the posts on shutdown patterns, reapers, graceful shutdown and the like, but am still unclear on the best strategy for my situation. The system is generating records to be written to a database. A single actor is doing this writing, in response to messages. When the system is sh

Re: [akka-user] Any limits on using Akka futures to make *ANY* blocking call to be asynchronous?

Have you seen the "Blocking Needs Careful Management" section here? http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html On Fri, Dec 5, 2014 at 12:57 PM, David wrote: > Hi, > > Futures seem magical. It looks like you can hand off *ANY* process to a > thread pool, continue with your

Re: [akka-user] Testing per-request child creation

ms like an anti-pattern. On Wed, Nov 19, 2014 at 11:52 AM, √iktor Ҡlang wrote: > I'm sorry, I didn't imply that you should add a status message, but if the > effects of changing the actors state is not observable in its behavior, > then why does it matter? > > On Wed,

Re: [akka-user] Testing per-request child creation

I already have non-actor classes for the evaluation of notifications and the internal actor state, but I do think it's legitimate to want to test the actor behaviour. I mentioned the GetInfo message, because Viktor was inspiring me to think of this an an integration test and asked if I could check

Re: [akka-user] Testing per-request child creation

its internal state? > > On Wed, Nov 19, 2014 at 4:53 PM, Richard Rodseth > wrote: > >> Sorry. The parent actor P gets a message containing measurement data. It >> calculates a sequence of notifications about that data, which it passes to >> the per-request child af

Re: [akka-user] Testing per-request child creation

internal state. On Wed, Nov 19, 2014 at 3:48 AM, √iktor Ҡlang wrote: > I'm not sure I follow. Test for what message and what effect? > > On Wed, Nov 19, 2014 at 1:05 AM, Richard Rodseth > wrote: > >> This does rather beg the question of what the integration boundary is

Re: [akka-user] Testing per-request child creation

08 PM, Richard Rodseth wrote: > Thanks for the input. I guess I can register a testprobe.ref as a > subscriber to the event bus. I will still need to control the creation of > the per-request child so that I can inject a mock storage interface that > acks with success so that the pos

Re: [akka-user] Testing per-request child creation

at a microlevel). > > On Tue, Nov 18, 2014 at 11:43 PM, Richard Rodseth > wrote: > >> The message A in the parent actor is computing a set of results. The >> per-request child will be saving some state from those results, and if >> successful, posting a domain event conta

Re: [akka-user] Testing per-request child creation

parent actor passed the correct set of results to the child constructor. On Tue, Nov 18, 2014 at 2:24 PM, √iktor Ҡlang wrote: > Hi Richard, > > what effects are you trying to test? > > On Tue, Nov 18, 2014 at 11:17 PM, Richard Rodseth > wrote: > >> I have a parent a

[akka-user] Testing per-request child creation

I have a parent actor which, on receipt of a certain message A, spawns a child actor, and sends it a "Run" message with no parameters. The child actor has constructor parameters derived from the contents of message A. What's the best way to test this? I don't think I can apply techniques like chil

[akka-user] Anticipating Akka Persistence

It must be frustrating for the Akka team to field questions when the solutions will be so much more elegant with Akka Persistence and Reactive Streams :) I have an aggregate which needs to respond to events by updating its own persistent state (using Slick) and firing a domain event. I believe th

[akka-user] Actor State and State Changes

I had in mind that I would strive to have a single var in my actors, which was a reference to an immutable object. One issue I've run into that since the actors go through various states of initialization (using become), I find myself with bits of state which can't be initialized in the constructo

Re: [akka-user] Event versioning revisited

and Heather Miller discusses it on Scalawags https://www.youtube.com/watch?v=uCpw9eBYbOw I also came across this ticket: https://github.com/scala/pickling/issues/39 On Tue, Oct 21, 2014 at 5:17 PM, Richard Rodseth wrote: > Thanks for the input. I wonder if anyone has tried Scala Pickling. At

Re: [akka-user] How to tell if a given persistent actor ever persisted something?

ther options that let you build persistent views by aggregating multiple persistent actors. Hope this helps. I'm new to this too. On Wed, Oct 22, 2014 at 8:14 AM, Richard Rodseth wrote: > I think I would make the sessions persistent actors, children of a > SessionManager

Re: [akka-user] How to tell if a given persistent actor ever persisted something?

I think I would make the sessions persistent actors, children of a SessionManager that is not a persistent actor. The SessionManager can always see if a child exists. http://typesafe.com/activator/template/akka-persistence-event-sourcing http://pkaczor.blogspot.com/2014/04/reactive-ddd-with-akka.h

Re: [akka-user] Event versioning revisited

re their >> experiences. >> >> On Tue, Oct 21, 2014 at 4:57 AM, Patrik Nordwall >> wrote: >> >>> Hi Richard, >>> >>> I'm also interested in what others are currently using. >>> >>> On Sun, Oct 19, 2014 at 3:35 AM, Richard Ro

Re: [akka-user] Event versioning revisited

Thanks for the references, Patrik. I hope others will share their experiences. On Tue, Oct 21, 2014 at 4:57 AM, Patrik Nordwall wrote: > Hi Richard, > > I'm also interested in what others are currently using. > > On Sun, Oct 19, 2014 at 3:35 AM, Richard Rodseth > wr

Re: [akka-user] Resolve of unknown path to dead letters in Akka Persistence test

> > I don't know from where the "resolve of unknown path" originates. I would > guess it is something from deserialization. > It is logged at debug level. Is the result still correct? > > Are you using Akka 2.3.6? > > Regards, > Patrik > > On Sat, Oct 1

[akka-user] Re: One more ask

lot slower than Akka Persistence, but in fairness I'm not looking them up by primary key. Anyway, another endorsement for stamping out ask. On Thu, Oct 16, 2014 at 10:39 PM, Richard Rodseth wrote: > I have an actor with many children (about 900 in my current test). > In the course

[akka-user] Event versioning revisited

I'm hoping to build a case for using Akka Persistence, and expect the event schema evolution to be a sticking point. People are quite used to their database migration scripts. I've seen the threads on this list, but I'm wondering what the current thinking is on the least painful option, and would

[akka-user] Resolve of unknown path to dead letters in Akka Persistence test

I have a simple test of Akka persistence with LevelDB. First app creates 1 aggregates, second app updates them, third app logs them (via a GetContent message). The good news is that the creation and updating seems pretty snappy. In the logging (GetContent) app, I get the following error (many t

Re: [akka-user] Akka Persistence Journal Access

advertise using Views, or well > – our upcoming (in a few months I guess) new views API, which is covered in > detail here: > > http://letitcrash.com/post/96687159512/akka-persistence-on-the-query-side-the-conclusion > ​ > > On Sat, Oct 18, 2014 at 12:38 AM, Richard Rodset

[akka-user] Akka Persistence Journal Access

I feel sure this must have been covered, but my searches are coming up blank. The benefits in terms of write-throughput are clear to me, but "free" auditing is often touted as a benefit of event sourcing, and one that can help sell the concept. So, are there supported APIs to get access to the Ak

Re: [akka-user] Using Tell or Ask with Akka Persistence and REST

t. And there is >> indeed no way for child actors to be created other than by their parent >> (which is very much by design). >> >> Regards, >> >> Roland >> >> 9 okt 2014 kl. 17:38 skrev Richard Rodseth : >> >> One thing I've done t

[akka-user] One more ask

I have an actor with many children (about 900 in my current test). In the course of initializing them, the parent reads some state for each child from the database, one at a time. I'd love to make these children PersistentActors, but haven't yet. I have my DbActor (just one for now) using Slick, as

Re: [akka-user] REST JAVA: Akka HTTP Vs Play Vs Spring

I think he's considering Play even for pure REST, because he can use it from Java, and Akka-HTTP is not ready. On Tue, Oct 14, 2014 at 7:40 AM, Daniel Armak wrote: > Spray / akka-http and Play address two different use cases. > > Spray/akka-http is an HTTP framework; as such it's great for build

Re: [akka-user] Patterns to process futures in receive

actor from creating to > much noise. I do not know it is possible, but I imagine that I could > somehow tell the mailbox of the actor to proceed only when the future the > actor had created is completed. > > Hopefully that makes more sense, > > Markus > > > 2014-10-1

Re: [akka-user] Patterns to process futures in receive

I don't follow your snippet. Receive is a partial function from Any to Unit, so it doesn't return anything. def receive = { case Start => { val futureResult = someFuture someFuture pipeTo sender } } You don't need to add an ask- you can just pipe someFuture to self or the sender. The result will

Re: [akka-user] Using Tell or Ask with Akka Persistence and REST

One thing I've done to preserve layering (and I'm new to this so take it with a grain of salt) is the following: Per-request request handler actor sends a command to a service actor (not per-request), including a requestor reference (self) in the message. Service actor is free to pass the requesto

Re: [akka-user] Using Tell or Ask with Akka Persistence and REST

I would recommend taking a look at the per-request pattern and using "tell" all the way. http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ On Wed, Oct 8, 2014 at 11:57 PM, Prakhyat Mallikarjun wrote: > Team, > > We are working on a simple POC. The POC is developed on the

Re: [akka-user] Akka REST

Once Spray is part of Akka as Akka HTTP I think they have a Java API planned, but I don't know when that is due to be released. There are lots of options for the web tier, including eg. Spring MVC and Play (which are "full stack" frameworks, but can be used to build REST APIs). On Thu, Oct 9, 2014

Re: [akka-user] Akka REST

There are a couple of Activator templates. It's common to use Spray, which is in the process of becoming Akka HTTP. https://typesafe.com/activator/template/activator-akka-spray On Tue, Oct 7, 2014 at 4:52 AM, naveen gayar wrote: > Hi > > > Any example of Akka as a RESTful service? > > Thanks >

Re: [akka-user] Bridging spray router and service actors

This looks interesting. Future.collect. Learn something new every day. http://www.superloopy.io/articles/2013/spray-routing-error-handling.html On Wed, Oct 1, 2014 at 11:00 AM, Richard Rodseth wrote: > Thanks for clarifying. I was using the version of complete I showed in > order t

Re: [akka-user] Bridging spray router and service actors

13 AM, Akka Team wrote: > > Hi Richard, > > No, I mean the other complete() method that you call from the Success and > Failure paths of the onComplete block. Why not just use > complete(result.transform(...))? > > -Endre > > On Wed, Oct 1, 2014 at 2:01 AM, Richard Rodset

Re: [akka-user] Routing to subset of children

Excellent.. Thanks. On Wed, Oct 1, 2014 at 1:00 AM, Roland Kuhn wrote: > > 1 okt 2014 kl. 03:45 skrev Richard Rodseth : > > Thanks, Konrad. I have a little test working, but I'm puzzled by one > thing. If all I want to do is subscribe to individual channel ids (Longs,

Re: [akka-user] Routing to subset of children

kka-eventbus> > some time ago: > http://www.benhowell.net/examples/2014/04/23/scala_and_the_akka_event_bus/ > > Happy hakking! > > > On Sat, Sep 6, 2014 at 7:18 PM, Richard Rodseth > wrote: > >> Thanks. For those, following along, this is helpful: >> >&

Re: [akka-user] Bridging spray router and service actors

Hi Endre Yes, the one I showed (onComplete()) *is* taking a future. The result of my ask is a Future[Long]. On Tue, Sep 30, 2014 at 3:58 AM, Akka Team wrote: > Hi Richard, > > > >> The route looks something like this: >> >> post { >> >> val result = (xyzService ? >> XYZService.Creat

[akka-user] Bridging spray router and service actors

Suppose I have an actor hierarchy like this: SprayAPIRoutingActor XYZServiceActor ..DbActor ..OtherActor1 ..OtherActor2 The DbActor wraps one or more blocking DAOs and has its own dispatcher to isolate the blocking. The router actor has access to the root service actor. I have implemented one ro

Re: [akka-user] Pipe list of futures independently

B/ > > On 22 September 2014 at 19:07:51, Richard Rodseth (rrods...@gmail.com) > wrote: > > I'm aware of the caveats about sender and closing over mutable state, but > in this case the list was a plain list, not a Future. But thanks for > showing an alternative. > &g

Re: [akka-user] Pipe list of futures independently

s $response").recover({ case _ => > "failed"}) pipeTo recipient > }} > > B/ > > On 19 September 2014 at 20:46:50, Richard Rodseth (rrods...@gmail.com) > wrote: > > I'm still getting used to all the flavours of future composition. Fun > stuff.

[akka-user] Pipe list of futures independently

I'm still getting used to all the flavours of future composition. Fun stuff. Is there a better way than the following to pipe a list of futures to the sender (one message per future) ? val requests:List[Future[SomeResponse]] = ... val messages:List[Future[String]] = requests.map { responseFuture

Re: [akka-user] Re: Accumulating responses from child actors

Thanks. I have the happy path working. I think I will make the child count part of the parent's "model". On Mon, Sep 15, 2014 at 1:07 AM, Alex Wouda wrote: > Hi, > > We have an ' aggregation' actor in place. We do not use the Aggregator > pattern. But a have a parent actor that knows how many re

Re: [akka-user] Per-request actor trait

Ref,message: Request) extends PerRequest[Request] > } > > trait PerRequestCreator { this: Actor => > def perRequest[Request](r: RequestContext,target: ActorRef, > message: Request) = context.actorOf(Props(new WithActorRef(r, target, > message))) > } > >

[akka-user] Accumulating responses from child actors

Suppose one wishes to gather information from all chidren of an actor, to return in a REST response, preferably wihout using ask() . What's the best way to go about this? I see that context.chidren returns an Iterable, so I guess I could use the size to know when I've received enough messages back

[akka-user] Per-request actor trait

I asked about this on spray-user, but thought I'd try here since this list rocks and it relates to Akka and an Activator template. I'm wondering how one would make this: https://github.com/NET-A-PORTER/spray-actor-per-request/blob/master/src/main/scala/com/netaporter/routing/PerRequest.scala mor

Re: [akka-user] Manifest Event Sourcing Application's Performance

Not sure if this helps https://github.com/erikvanoosten/metrics-scala/blob/master/docs/Actors.md On Thu, Sep 11, 2014 at 3:48 PM, Ivan Topolnjak wrote: > Prakhyat, > > for the record: Kamon does provide metrics on number of HTTP requests, > average, min, max, counts per response status code and

Re: [akka-user] Routing to subset of children

a/event-bus.html> can help you > there where children can subscribe to an interested channel on a bus. > > > On Fri, Sep 5, 2014 at 11:44 PM, Richard Rodseth > wrote: > >> Suppose I have messages containing a "channel id" coming to a parent >> actor. The

[akka-user] Routing to subset of children

Suppose I have messages containing a "channel id" coming to a parent actor. There are many children, each of which is interested in one or more channels. In other words, a channel message needs to be dispatched to a subset of the children. I'm aware of ActorSelection and have looked at the routing

Re: [akka-user] Kafka journal

urnal backend. This may be ok for some projects, others may think > that operational complexity gets too high when you have to administer a > Kafka/Zookeeper cluster in addition to a Cassandra or MongoDB cluster, for > example. > > Hope that clarifies things a bit. > > Cheers, > M

Re: [akka-user] Questions about akka persistence and scalability

I just watched this ScalaDays talk which was pretty good http://www.parleys.com/play/53a7d2c3e4b0543940d9e53b/chapter0/about As I understand it, you either use ClusterSingleton or ClusterSharding (the latter if your aggregates are actors). The cluster sharding Activator template is a nice clear e

[akka-user] Kafka journal

I saw a tweet from Martin Krasser that he was working on an Akka Persistence journal plug-in for Kafka. This puzzled me a bit since Kafka messages are "durable" rather than "persistent" - they are stored for a configurable time. Could anyone comment on a typical usage? Assuming that your persisten

Re: [akka-user] Re: Akka 5 Year Anniversary--Thank you guys

I'm sure this will be a long thread, but I must join in the congratulations. It's a wonderful piece of software and helpful community. You must be very proud. On Thu, Jul 10, 2014 at 10:00 AM, 09goral wrote: > Great job and thank you all for you work! > > W dniu czwartek, 10 lipca 2014 18:58:20

[akka-user] Re: become(params) vs FSM

I was thinking time rather than space. I'm guessing the cost of swapping is not something I should worry about, but any reassurances or caveats are welcome. Receive block as partial function is so elegant! On Mon, Jul 7, 2014 at 7:54 AM, Richard Rodseth wrote: > I'm considering

[akka-user] become(params) vs FSM

I'm considering using become(processing(params)) in some of my short-lived "job" actors, so that the params are available when the job completes, yet the job can be started separately from its creation. So I'm wondering about the overhead of become, and whether I should be considering the FSM stuf

Re: [akka-user] Re: Work push/pull vs ?

ries ("The Importance of > Pulling") > > Cheers, > Patrik > > > On Thu, Jul 3, 2014 at 8:51 PM, Richard Rodseth > wrote: > >> For some reason I'm really struggling to find the right design here. I >> feel OK about my "channel job"

[akka-user] Re: Work push/pull vs ?

bs their status? Sorry if I'm being dense. On Tue, Jul 1, 2014 at 6:08 PM, Richard Rodseth wrote: > I've had some success using the worker pull pattern to process time series > data in a particular "channel". A channel job actor builds the queue of > time chunk

[akka-user] Work push/pull vs ?

I've had some success using the worker pull pattern to process time series data in a particular "channel". A channel job actor builds the queue of time chunks for a work pull master and workers work on chunks of time. Now I wish to process multiple (possibly millions of) channels in parallel and

Re: [akka-user] Killing a blocked actor

, √iktor Ҡlang wrote: > Also relevant: > https://groups.google.com/forum/#!topic/scala-user/52bq9s1JNY0 > > > On Mon, Jun 30, 2014 at 3:45 PM, Patrik Nordwall < > patrik.nordw...@gmail.com> wrote: > >> >> >> >> On Thu, Jun 26, 2014 at 5:58 AM, Rich

Re: [akka-user] Future[Option[T]] and pipeTo self

ce of value in > the algebra (which I'd prefer). > > > On Sun, Jun 29, 2014 at 3:40 PM, Richard Rodseth > wrote: > >> Hi Viktor >> >> The use case is an actor that processes "commands", creating "jobs". But >> first it has to look up

Re: [akka-user] Future[Option[T]] and pipeTo self

essage for the actor (it just gets a None, it doesn't even > know what Option[T] it was since the T is erased.) > > What's the use-case? > > > On Sun, Jun 29, 2014 at 3:34 AM, Richard Rodseth > wrote: > >> So I've run into the "Monads don't

[akka-user] Future[Option[T]] and pipeTo self

So I've run into the "Monads don't compose" problem and am a bit reluctant to tackle monad transformers and Scalaz at this point. I'm wondering what you all think about mapping the Future[Option[T]} to something like Future[MyMessageType] , piping to self, and then pattern matching on MyMessageTy

[akka-user] Re: Actor lookup design

I see here that I can do context.child(name) http://grokbase.com/t/gg/akka-user/138x5t8xbz/referencing-actor-from-map-string-actorref-vs-referencing-from-path On Sat, Jun 28, 2014 at 4:08 PM, Richard Rodseth wrote: > I'm having an absolute blast building my first non-trivial acto

[akka-user] Actor lookup design

I'm having an absolute blast building my first non-trivial actor system, and learning a lot. Kudos to the team. The tool needs to access different database environments, depending on user input. In order to manage blocking, I have a Database actor which is initialized with a DatabaseRef, and has i

[akka-user] Killing a blocked actor

Not sure if this is the right approach, but I have the makings of a little REPL as shown below (I know this guy will need a dedicated dispatcher). The idea is that console input, including "exit" is sent to the parent which would like to do a graceful shutdown. Is there a way in the parent to kill

<    1   2   3   4   >