Re: [akka-user] Re: Intercept STDOUT of other process

If your Akka program creates the process (for example, using ProcessBuilder), then you can capture the output and do whatever you want with it, including routing it into an Akka stream. If the process is started by some other means then it would be harder - you would need to capture the outpu

[akka-user] Re: [offtopic] Bibliography in distributed systems

ra, 25 de agosto de 2015 14:11:11 UTC-3, Eric Pederson > escreveu: >> >> Hi mathe... >> >> Here's a starting place: >> https://groups.google.com/d/msg/akka-user/Snx8ufCvSEw/DhiTSIsXSW8J >> >> Also, Jonas' "Road to Akka Cluster and Beyond&

[akka-user] Re: [offtopic] Bibliography in distributed systems

Hi mathe... Here's a starting place: https://groups.google.com/d/msg/akka-user/Snx8ufCvSEw/DhiTSIsXSW8J Also, Jonas' "Road to Akka Cluster and Beyond" talk has a ton of good references. On Monday, August 24, 2015 at 8:04:10 AM UTC-4, mathe...@sagaranatech.com wrote: > > Hello, > I'm need bibl

Re: [akka-user] Access to current message in actor

doc.akka.io/docs/akka/snapshot/contrib/receive-pipeline.html> > (only in master). > > Cheers, > Patrik > > On Tue, Mar 24, 2015 at 7:37 PM, Eric Pederson wrote: > >> Dear Akka Team - could you comment on this? >> >> Thanks,

Re: [akka-user] Access to current message in actor

Dear Akka Team - could you comment on this? Thanks, (I realized after the fact that posting the original question during ScalaDays was a bad idea...) -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additiona

Re: [akka-user] Access to current message in actor

Thanks. Coincidentally I've recently considered that (using an akka package) for a class similar to LoggingReceive. LoggingReceive gets the actor class from the ActorCell to set the source of the Debug message sent to the event stream. I've worked around it for now by passing the actor's log i

Re: [akka-user] Access to current message in actor

Actually, though, methods in an actor really shouldn't be called asynchronously. That would circumvent the actor model. That's why things like pipeTo exist, to minimize the chance that a future could interact with the guts of an actor. An actor's methods should really only be called from a th

Re: [akka-user] Access to current message in actor

10:53:23 PM UTC+3, Eric Pederson wrote: >> >> Hi there - >> >> Somewhat regularly I have a need to access the current message in an >> actor method outside of the receive. It's usually some case where I want >> to do something generic with it, like logg

[akka-user] Access to current message in actor

Hi there - Somewhat regularly I have a need to access the current message in an actor method outside of the receive. It's usually some case where I want to do something generic with it, like logging. There are two general approaches that I've used. The first approach is pass the message down

[akka-user] Re: Database Actor Read Model

Hi Andy - we are using an implementation of the Message Sequence EIP, which chunks the messages. The code is here: https://github.com/sourcedelica/akka/blob/wip-3842-message-sequence-pattern-ericp/akka-contrib/src/main/scala/akka/contrib/patter

Re: [akka-user] Best way to integrate akka into a legacy/existing app

Hi Francois: I've integrated Akka into a couple of applications after the fact. One integration was adding a caching layer over a database. It is written up here: http://doc.akka.io/docs/akka/2.3.4/scala/howto.html#case-study-an-auto-updating-cache-using-actors. In another application I adde

Re: [akka-user] Re: Best book(s) on "distributed system" ?

Hi Joseph - That's a good idea about the wiki. I was thinking of doing a blog post. There are a couple other books that are related to your "no downtime and seamless upgrades" requirements that I would recommend: Continuous Delivery Relea

Re: [akka-user] Best book(s) on "distributed system" ?

t; Best > Joseph > > On Thu, Oct 2, 2014 at 2:21 PM, Eric Pederson > wrote: > >> Hi Joseph - >> >> I'm on a similar journey. It's a really interesting subject that wasn't >> covered at all (at least at the undergrad level) when I went to

Re: [akka-user] Best book(s) on "distributed system" ?

Hi Joseph - I'm on a similar journey. It's a really interesting subject that wasn't covered at all (at least at the undergrad level) when I went to school. I would definitely recommend checking out Jonas's awesome list of references from his recent talk at Strange Loop

Re: [akka-user] Event Sourcing Single Writers

4 9:39:02 PM UTC-4, Eric Pederson wrote: > > I'm don't know of any implementations personally. It's not distributed > transactions though - it's a series of separate transactions and if there > is a rollback of the overall saga, compensating transactions are made

Re: [akka-user] Event Sourcing Single Writers

I'm don't know of any implementations personally. It's not distributed transactions though - it's a series of separate transactions and if there is a rollback of the overall saga, compensating transactions are made to reverse the initially committed transactions. On Sunday, August 10, 2014 10:

Re: [akka-user] Event Sourcing Single Writers

This sounds a lot like the Sagas paper that Konrad linked to in one of his presentations. http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf On Friday, August 8, 2014 11:33:10 AM UTC-4, Prakhyat Mallikarjun wrote: > > Konard, > > Thanks again. > > I understand one actor per aggrega

Re: [akka-user] Re: Akka Remoting fails for large messages

Another approach, if you don't have access to shared filesystem, is the MessageSequence pattern, where a message is broken up into multiple chunks. Here is an implementation that we are using: https://gist.github.com/ericacm/7947424 On Friday, August 8, 2014 10:02:41 AM UTC-4, Konrad Malawski

Re: [akka-user] Side effect stream combinator

does exactly that. It gives you back a >>> Flow[Unit] which will produce exactly one element at the end of the >>> processing (so you can easily convert it to a Future[Unit] for example). >>> >>> Is this covering what you need? >>> >>> -Endre >

Re: [akka-user] Side effect stream combinator

Correction def doOnEach(f: T => Unit): Flow[T] -- Eric On Wed, Jul 23, 2014 at 9:10 PM, Eric Pederson wrote: > Hi guys: > > Something that would be useful is a side effecting combinator. For > example, like doOnEach from RxJava. This would be particularly useful in >

[akka-user] Side effect stream combinator

Hi guys: Something that would be useful is a side effecting combinator. For example, like doOnEach from RxJava. This would be particularly useful in the actor world to insert an actor tell into the flow. def doOnEach(f: => Unit): Flow[T] For example: flow.doOnEach { msg => if (msg.isSometh

[akka-user] Re: akka-zk-cluster-seed extension

Hey Scott - This is fantastic - thanks so much for making it available! -- Eric On Monday, June 2, 2014 10:08:24 PM UTC-4, Scott Clasen wrote: > > Hey all > > Just whipped this up today for those who have easy access to zookeeper, > it lets you bootstrap your cluster without configuring seed

Re: [akka-user] quorum-based split brain resolution

> >> Regards, >> >> Roland >> >> 9 maj 2014 kl. 23:58 skrev Lawrence Wagerfield < >> lawr...@dmz.wagerfield.com >: >> >> Yes, precisely what I was wondering, although probably not as well >> articulated! >> >> I am curious

Re: [akka-user] Re: quorum-based split brain resolution

Lawrence - were you wondering where the existing Akka-based Raft implementations (eg. ktoso/akka-raft ) sit in Roland's auto downing to no downing spectrum and/or if RAFT has any particular consistency requirements that map to one of Roland's categories? I'm curi

Re: [akka-user] quorum-based split brain resolution

+1 for adding it to the docs. It's essential info. On Wednesday, May 7, 2014 4:13:25 AM UTC-4, drewhk wrote: > > That is a really good summary, Roland. This should go into docs or at > least a blog post? > > -Endre > > > On Tue, May 6, 2014 at 8:28 PM, Akka Team > > wrote: > >> Hi Shikhar, >>

Re: [akka-user] Trying to join member with wrong ActorSystem name, but was ignored, expected [X] but was [Y]

g and Identify/ActorIdentity. Thanks, -- Eric On Tue, Apr 8, 2014 at 4:28 AM, Carsten Saathoff wrote: > Hi, > > Am Montag, 7. April 2014 20:56:24 UTC+2 schrieb Eric Pederson: > >> I'm probably going to move away from having the launcher join the cluster >> because th

Re: [akka-user] actorSelection.resolveOne - does it retry?

the supplied timeout." > > Heiko > > On 07 Apr 2014, at 23:04, Eric Pederson > > > wrote: > > Hi guys: > > Does actorSelection(path).resolveOne(timeout) retry? For example, if it > is called before the target actor is started, but the target actor does ge

[akka-user] actorSelection.resolveOne - does it retry?

Hi guys: Does actorSelection(path).resolveOne(timeout) retry? For example, if it is called before the target actor is started, but the target actor does get started before the timeout elapses. >From the source it doesn't look like it but I may not be looking hard enough. Thanks, -- >>>

Re: [akka-user] Trying to join member with wrong ActorSystem name, but was ignored, expected [X] but was [Y]

Thanks Konrad - I have an app that launches cluster members by ssh-ing into each box and running a script. The launcher app is joining the cluster to simplify the logic of knowing when everything is up. I had a different actor system name for the launcher because it's a different app. But it's

[akka-user] Trying to join member with wrong ActorSystem name, but was ignored, expected [X] but was [Y]

Hi guys: If one of my actor system names is different from the actor system name of the seed nodes I get this message: WARN: Trying to join member with wrong ActorSystem name, but was ignored, expected [X] but was [Y] And actually the cluster fails to start up at all. If I change the actor

[akka-user] Re: Send much data to remote actors

Akka 2.2.3. Some of these settings will be moot with Akka 2.3. On Thursday, February 13, 2014 9:38:40 PM UTC-5, Eric Pederson wrote: > > Hi Christian: > > Here are some ideas: > 1. Write the data to a file in a filesystem accessible by both actor > systems, send the filename as

[akka-user] Re: Send much data to remote actors

Hi Christian: Here are some ideas: 1. Write the data to a file in a filesystem accessible by both actor systems, send the filename as a message. When the message is received, read and delete the file. 2. Same as 1 but with a database. 3. Break up the message into multiple messages and reassembl

[akka-user] Re: Multi-Machine Distributed Work

nd tracks work in the > same way that post describes. We never send messages to the router itself, > we just use it to automatically deploy routees for us. > > On Friday, January 10, 2014 7:51:34 PM UTC-7, Eric Pederson wrote: >> >> Hi Ryan - I'm curious to learn more

[akka-user] Re: Multi-Machine Distributed Work

Hi Ryan - I'm curious to learn more about how you are using the cluster-aware router and what it provides over the basic clustering membership functionality. Matt - we are also using a variation of "Balancing Workload Across Nodes" (pre Akka Cluster) and it works great. Thanks, On Friday, Jan

[akka-user] Is Identify "out of band"?

Hi guys: I had a question about this new feature of 2.3-M2. (It also relates to https://groups.google.com/d/msg/akka-user/qbMiOAaDZEs/MMn8qhQfAtQJ) - ActorSelection was made faster and not blocked by intermediate actors performing long-running tasks. If the target actor of my Identify