Re: [akka-user] Event-sourcing with aka-persistence

[Adam Dohnal]

You understand it right. Unfortunately, your solution won't work. Suppose 
player has 30/100 health (current/max) and 99/100 experience and two 
messages are sent to him with this order:

AddExperience(10)
TakeDamage(40)

Correct behaviour is that first 10 xp is added to 109/100 ... level is 
earned which cause to gain full hp 100/100. Only after then TakeDamage can 
by applied which causes to change player's hp to 60/100.

If you would send LevelEarned to self, it will be processed after 
TakeDamage message and player will die.

I would like to process each command at the time and persist ALL its 
consequence. Problem is that my consequences are found asynchronously :(

Dne pondělí 19. října 2015 12:15:33 UTC+2 Patrik Nordwall napsal(a):
>
> If I understand it correctly your question is about how to persist the 
> LevelEarned event which comes via the 
> asyncrounous player.observable.subscribe callback. Since this is an actor 
> you must turn that callback into a message that is sent to self and when 
> receiving that message you can persist it.
>
> /Patrik
>
> On Mon, Oct 12, 2015 at 3:17 PM, Adam Dohnal  > wrote:
>
>> Hello, 
>>
>> I am new in Akka and I am trying to develop some mini project to test 
>> some things (akka, rx, cqrs, es etc..)
>>
>> I think I understand the concept of cqrs/es and how it fit to akka. My 
>> problem is probably more theoretical than technical.
>>
>> Let's say, I have class Player, which has several Attribute[T] attributes 
>> ... these attributes can be for example player's current health, vitality, 
>> experience, level etc ... These attributes have dependencies ... for 
>> example currentHealth is defined as 10 * vitality ... if experience is > 
>> 100 new level is earns, which causes to add 1 vitality, which causes to add 
>> 10 health ... Hopefully, you get the point.
>>
>> I like the idea to implement this using reactive streams. Each 
>> Attribute[T] should be considered as Observable[T] and with all these 
>> excellent operators I can model dependencies I have described before.
>>
>> Now I am trying to model each Player as actor, which can handle commands 
>> (AddExperience(...), AddVitality(...) etc...) and produce events 
>> (ExperienceAdded(...), LevelEarned(...)) which should be event sourced.
>>
>> Problem is, that when I am handling command I directly don't know what 
>> events should be generated ... for example AddExperience(100) is handled 
>> and after some validation ExperienceAdded(100) should be persisted to event 
>> store. When it success, it should be applied to my domain, which emit value 
>> change in that attribute observable and new level can be earned ... but how 
>> can I persist that event?
>>
>> I try to write some pseudo-code
>>
>> class ExamplePersistentActor extends PersistentActor {
>>   val Player player = ... // domain
>>
>>   val subscription = player.observable.subscribe {
>> // here I get asynchronously information about that level is increased 
>> ... should I call persist here?
>> }
>>
>> val receiveCommand: Receive = {
>> case AddExperience(xp: Int) => {
>>  persist(ExperienceAdded(xp)) { event =>
>>   player.addExperience(xp) // should produce LevelEarned(1) event, which 
>> should be also persisted
>> }   
>>   }
>> }
>>
>> So I have reference to Player which has observable of all events that are 
>> produced ... but I don't how to persist them :/
>>
>> -- 
>> >> 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 http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  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
--- 
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Cluster Sharding

[vikas]

In our architecture, we have API servers communicating to an Actor Cluster. 
This leads to a few questions:

1. Is there a way to make entityProps dynamic? In the examples here 
, it 
seems that the Props are the same for every Actor. However, in our use 
case, every actor has dynamic props (for instance, a database row id). Is 
there an elegant way to do this?

2. It seems like our API servers can either communicate to the cluster as a 
Shard Proxy or as a Cluster Client. What are the advantages and 
disadvantages of each approach? It seems like the disadvantage of the Shard 
Proxy approach is that it requires the API servers to know the functions to 
extract entity and shard ids. The disadvantage of the Cluster Client 
approach is that it imposes syntactic overhead for every tell to a remote 
actor. 

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

Re: [akka-user] Shared cluster shard allocation strategy

[vikas]

Hi Patrik,

Would you be able to provide more info on how to do co-location with 
consistent hashing? That would be very helpful!

Thanks,
Vikas

On Saturday, November 22, 2014 at 8:08:04 AM UTC-8, Patrik Nordwall wrote:
>
> Hi Moritz,
>
> On Wed, Nov 19, 2014 at 3:27 PM, Moritz Schallaböck <
> moritz.sc...@agido.com > wrote:
>
>> Hello fellow hAkkers,
>>
>> we have multiple persistent actor types distributed using cluster 
>> sharding. Some of them logically belong together, lets say they're 
>> customers and their orders. Customers never talk to orders of other 
>> customers, and vice versa. Thus it makes sense to us to have these actors 
>> reside on the same cluster shard (and consequently, in the same VM). 
>>
>> We implemented this by returning identical ShardIds for the customer c123 
>> and its orders c123-o0, c123-o1, etc. But of course, this doesn't work like 
>> we thought it would. :) The ShardResolvers of two instances of ShardRegion 
>> operate independently, and we just end up with two shards -- one for 
>> customers and one for orders -- which share a name but not necessarily a 
>> cluster host. I have seen this misunderstanding crop up a few times before 
>> on this list, which makes it slightly less embarrasing to admit the 
>> mistake. ;)
>>
>> We could stop using cluster sharding for the orders completely, and 
>> instead route all messages for the orders through the customers, which 
>> would restart the actors on demand. But that sounds like a lot of 
>> extraneous code: many other actors talk to the orders[0], and the customers 
>> shouldn't need to route these messages or worry about them, the customer 
>> actors need not even be alive for them. And we'd also have to worry about 
>> the other things that cluster sharding does: support for passivation of 
>> orders, gracefully handling rebalances of customers (killing all order 
>> actors when it happens, I guess), maybe other things.
>>
>> [0] I realize that this will lead to the question: if many other actors 
>> talk to the orders without involving the customers, why do you want them on 
>> the same host? Lets just assume for the sake of argument that circumstances 
>> make this a reasonable requirement, unless you're saying it's not a 
>> reasonable requirement under any circumstances.
>>
>> The alternative would involve writing a custom ShardAllocationStrategy 
>> that's shared among the customer and order ShardRegions. I suppose it would 
>> involve the following:
>>  - maintain the associations between ShardRegion actorRef and ShardIds 
>> for each entity type;
>>  1. for a new requested allocation for entity type X:
>>  2. check if the same shardId is already allocated for any other entity 
>> type Y, yielding (at least one) associated shardRegionActorRefY
>>  3. if so, determine if there is any shardRegionActorX for entity type X 
>> that's on the same host as shardRegionActorRefY
>>  4. if so, allocate the shardId to shardRegionActorX (ie. return it; 
>> optionally balance between several candidates)
>>  5. otherwise, fallback to any other ShardAllocationStrategy (updating 
>> the associations based on its return value)
>>
>> Eugh. I feel dirty now. Apart from the general horrificness, I imagine 
>> step 3 is fraught with peril. And of course, the whole thing would need to 
>> be thread-safe because it will be accessed and modified concurrently by 
>> several ShardRegions. (Time to dust off ye olde ConcurrentHashMap.) The 
>> more I look at it, the more fragile and less feasible it seems.
>>
>
> Yes, there are a lot of pitfalls in that approach
> One more that you perhaps didn't think of is that the shardRegionActorX 
> for entity type X might have been allocated and then later 
> shardRegionActorY for entity type Y is to be allocated by a coordinator 
> running in a different JVM (because of a crash). Then the shared 
> ShardAllocationStrategy has no information about the previous 
> shardRegionActorX.
>
> The design of cluster sharding is based on that each entity type can be 
> managed independent of other entity types. If Customer and Order have a 
> tight coupling I think they should be modelled as one aggregate type.
>  
>
>>
>> At the same time, having this sort of control over the clustering of 
>> several entity types does not seem particularly outrageous. Are we missing 
>> something?
>>
>
> You could do a best effort co-location of associated customer and order 
> shards by using consistent hashing in the ShardAllocationStrategy. I can 
> explain more if you find that interesting.
>
> Cheers,
> Patrik
>  
>
>>
>> Thanks as always for your thoughts,
>> Moritz
>>
>> -- 
>> >> 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 fro

[akka-user] Re: How to synchronize/notify multiple parallel Actors on completion?

[Sean Zhong]

>
> I'd be interested to know if there are other examples which might solve
> this problem without explicitly maintaining state?


@Denis

You can create a only-use-once temporary actor in the router to track all 
acking. After it receive all acking from workers, send a message to router, 
and kill itself.


On Friday, October 16, 2015 at 7:50:58 AM UTC+8, Denis Papathanasiou wrote:
>
> Answering my own question, I found this example[1] which was similar to
> what I needed.
>
> So I wind up maintaining the file contents within the distribution actor,
> and have the workers report back how many lines they've processed
> (analogous to the total number of pints the Bartender tracks in the
> example).
>
> When the distributor gets a total equivalent to the number of lines in
> the first file, it starts processing the contents of the second file.
>
> It's a simple solution which solves my problem, but the idea of keeping
> state in the distribution actor is not as clean/elegant as I would like.
>
> I'd be interested to know if there are other examples which might solve
> this problem without explicitly maintaining state?
>
> [1] 
> http://www.reactive.io/tips/2014/03/28/getting-started-with-actor-based-programming-using-scala-and-akka/
>
> On Wednesday, October 14, 2015 at 8:21:35 PM UTC-4, Denis Papathanasiou 
> wrote:
>>
>> I've written a simple actor system, based on the "calculate Pi"
>> example[1].
>>
>> In my case, I am processing two types of (large) csv files.
>>
>> I load and parse the first one into a list of lines, and then split
>> the lines into equal chunks, for multiple worker actors to process
>> in parallel:
>>
>> lines.grouped(chunks).toList.par.map( lineGroup => router ! Process(
>> lineGroup) )
>>
>> Next, I want to do the exact same thing on all the lines contained in
>> the second file.
>>
>> But, before I issue any new requests to any worker actors, I want to
>> make sure that all the actors who received the initial Process message
>> are finished.
>>
>> I know there is a mechanism to send replies back to the actor which made
>> the request, but I'm not sure how to wait for all the replies to arrive
>> withoout blocking.
>>
>> Are there any good examples of this?
>>
>> [1] 
>> http://doc.akka.io/docs/akka/2.0/intro/getting-started-first-scala.html
>>
>

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

Re: [akka-user] Capturing the message that killed an actor

[Виктор Лобанов]

Hi Viktor and Arne.

Sorry for intrusion, but I have some thoughts about similar problem. 
Recently I had similar design problem and came up with actor-per-request 
solution by myself. I even spawn whole subtree of actors per request, where 
supervisor captured initial sender (e.g. client) for further response and 
delegated all dangerous work to his children. In case of failure of one of 
them, supervisor could immediately notify initial sender with something 
like Status.Failure. So client (initial sender) don't have to wait on 
timeout in case of failure. And that solution was perfectly fine to me.

However, I can suspect a caveat in such approach. I think in that case 
we're losing the "mailbox"-related features, such as message ordering 
between two actors and more important - mailbox boundaries. Because in that 
case we're translating "amount the messages in mailbox" to "amount of 
actors, spawned to handle request", which can cause OOM in "slow consumer 
scenario".

Of course all "boundaries" can be hand-coded in each case - just tracking 
and limiting the count of actors spawned, but what about message ordering? 
All actors-per-request will handle messages in-parallel. Should I pin them 
to "single-threaded dispatcher"?

I know, that Akka is not a Golden Hummer (but close to that :) ), but may 
be there is some general approach, to solve above problems and I am missing 
something.

Best regards and thank you.

On Monday, October 19, 2015 at 10:53:34 AM UTC+3, √ wrote:
>
> Hi Arne,
>
> sounds like spawning a child-actor for each operation would give you both 
> control over failures (supervision) as well as knowing what message was 
> delegated to what actor.
>
> On Sat, Oct 17, 2015 at 6:09 PM, Arne Claassen  > wrote:
>
>> Viktor,
>>
>> Yeah, i can see a crash loop being undesirable, but it shouldn't be a 
>> problem in my scenario, since only one end is really an actor.
>>
>> The scenario is the following:
>> 1. HTTP request comes into play for some analytics for a specific resource
>> 2. The request gets routed to a persistent actor on an akka cluster
>> 3. The resource actor may return a previously calculated result or 
>> calculate one
>> 4. Since the calculation may take some time, my ask has a longish timeout
>> 5. If the actor fails in its operation due to some scenario that wasn't 
>> considered as a possible failure scenario, I want to notify the waiting 
>> HTTP call as soon as possible, rather than have the call time out
>> 6. The HTTP request gets completed with either the 200 analytics response 
>> or a 500, trying to use 408 only for actual timeouts not failures in the 
>> message flow
>>
>> Ideally, the communication channel between the HTTP endpoint and the 
>> resource would be a protocol more resilient than a single ask, such as 
>> having an initial ack, and some heartbeat, but for now it's just that ask 
>> and I'm trying to communicate failure back to the caller in the most timely 
>> fashion.
>>
>> thanks,
>> arne
>>
>> On Saturday, October 17, 2015 at 5:01:52 AM UTC-7, √ wrote:
>>>
>>> Arne,
>>>
>>> if 2 actors have SafeReceive, send messages to eachother and they fail 
>>> on processing OperationFailed, then you have a crash loop.
>>>
>>> What behavior are you implementing? (what are you going to use the 
>>> exception and message for?)
>>>
>>> -- 
>>> Cheers,
>>> √
>>> On 15 Oct 2015 22:44, "Arne Claassen"  wrote:
>>>
 So I came up with this workaround:

 object SafeReceive {  
   def apply(receive: Receive)(recover: Any => 
 PartialFunction[Throwable, Unit]): Receive = 
 new Receive {
  override def isDefinedAt(x: Any): Boolean = receive.isDefinedAt(x) 
   override def apply(v1: Any): Unit = try {
receive(v1) 
   } catch recover(v1)  
 }
 } 

 which I can invoke like this:

 def receive = SafeReceive {
   
 } {
   msg => {
 case e:Exception =>
   sender ! OperationFailed(msg,e)
   throw e
   }
 }

 Any reason why this would be a bad idea?

 cheers,
 arne


 On Thursday, October 15, 2015 at 1:25:13 PM UTC-7, Arne Claassen wrote:
>
> Actually according to those docs, the supervisor stopping does cause 
> the message to be dropped.  The message is taken from the mailbox, causes 
> an exception and then the supervisor stops the actor, never returning the 
> message to the mailbox. I've tested to verify that that is the behavior. 
>
> What confuses me is the following:
>
>> *It is important to understand that it is not put back on the 
>> mailbox. So if you want to retry processing of a message, you need to 
>> deal 
>> with it yourself by catching the exception and retry your flow.*
>
>  
> I.e. I would need to wrap every pattern match or at least every 
> Receive definition in a try/catch to get at the message.I thought the 
> whole 
> 

Re: [akka-user] address is now gated for [5000] ms

[Patrik Nordwall]

I'm afraid I don't know why you get the "association failure" in the first
place or if it is related to the 10 sec delay.
/Patrik

On Mon, Oct 19, 2015 at 3:28 PM, 'Konstantinos Kougios' via Akka User List <
akka-user@googlegroups.com> wrote:

> Thanks Patrik, I tried it and it changes the gate wait, but has no effect
> in the overall wait :
>
> 2015-10-19 14:25:25,524 WARN  [
> akka.tcp://DataDistributionEndToEndTest@dist-index:2720/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FDataDistributionEndToEndTest%40dist-index%3A2721-0]
> a.r.ReliableDeliverySupervisor - REQ_ID: - Association with remote system
> [akka.tcp://DataDistributionEndToEndTest@dist-index:2721] has failed,
> address is now gated for *[500] ms.* Reason: [Association failed with
> [akka.tcp://DataDistributionEndToEndTest@dist-index:2721]] Caused by:
> [Connection refused: dist-index/192.168.0.11:2721]
> waiting cluster
> done waiting cluster, *waited 10812 ms*
>
>
> The code that waits is for the code that awaits for the cluster
> actorsystems to be aware of each other:
>
>
> val start=System.currentTimeMillisawaitCond(
>cluster1.state.members.size == allClusters.size &&
>   cluster2.state.members.size == allClusters.size &&
>   cluster3.state.members.size == allClusters.size &&
>   driverCluster.state.members.size == allClusters.size,   60 seconds
> )val dt=System.currentTimeMillis - startprintln(s"done waiting cluster, 
> waited $dt ms")
>
>
> Normally this takes 1-2 seconds. But when the gate issue occurs, it takes
> a lot more, i.e. 10 secs as per above.
>
> Cheers
>
>
> On 19/10/15 10:50, Patrik Nordwall wrote:
>
> That is probably config property akka.remote.retry-gate-closed-for
> /Patrik
>
> On Wed, Oct 7, 2015 at 6:25 PM, Kostas kougios <
> kostas.koug...@googlemail.com> wrote:
>
>> Hi, I am occasionally getting this when running tests. The test resumes,
>> but I wait for 5 secs. Is there a config property to set it to 500ms?
>> (googling didn't reveal any relevant info)
>>
>> 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 http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Patrik Nordwall
> Typesafe  -  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
> ---
> 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/topic/akka-user/CTJyKGc_Qjo/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 http://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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  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
--- 
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 http://

Re: [akka-user] Modeling synchronous startup behavior

[Rich Henry]

All the other components are thread-safe.

I just need an order of operations including the actorOf call, so coming 
full circle, my original plan was to use some kind of initialization 
message with the ask pattern to sync it up.

I was trying to figure out if this is the best i can do.




On Monday, October 19, 2015 at 11:00:58 AM UTC-4, √ wrote:
>
> Hi Rich,
>
> On Mon, Oct 19, 2015 at 4:50 PM, Rich Henry  > wrote:
>
>> I would if it told me when that chain of events starts and stops relative 
>> to the actorOf call itself.
>>
>
> actorOf is asynchronous so that's completely separate from the lifecycle.
>  
>
>>
>> My actor needs to register with another non-actor subsystem before i 
>> interact with it, so If i write code like...
>>
>> val subsys = new SubSys()
>> val a = system.actorOf(Props(classOf[MyActor], subsys)) // constructor 
>> registers with subsys
>> subsys.go()
>>
>> There is a race condition as the constructor for my actor doesn't get 
>> called before .go(). 
>>
>
> Is `subsys` threadsafe? Can your MyActor send a message somewhere to 
> indicate that it has registered with subsys?
>  
>
>>
>>
>> On Monday, October 19, 2015 at 10:24:32 AM UTC-4, √ wrote:
>>
>>>
>>>
>>> On Mon, Oct 19, 2015 at 4:11 PM, Rich Henry  wrote:
>>>
 I guess that's the why of question 2. Im not clear when the different 
 lifecycle phases, like preStart, occur. 

 I would assume preStart occurs after object construction, and is 
 asynchronous to the system call used to create the actor, is that not so?


>>> Does the documentation help?
>>>
>>> http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#Actor_Lifecycle
>>>
>>>  
>>>
 On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:
>
> Hi Rich,
>
> and why can't it be executed in preStart()?
>
> On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  wrote:
>
>> I had seen a previous post that didn't really seem to come to any 
>> definite conclusion about this subject.
>>
>> I have some synchronous behavior I need to accomplish during my 
>> actor's construction, but the constructor is called asynchronously.
>>
>> 1) Is the accepted way to do this to use an initialization message of 
>> some kind with the ask pattern?
>>
>> 2) Is there any documentation beyond the short section in the manual 
>> that talks about actor lifecycle specifics?
>>
>> -- 
>> >> 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 http://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+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at http://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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://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 s

Re: [akka-user] AllocationStrategy rebalance() is stopping actors outside resharding list

[Eduardo Fernandes]

Ok. I'l work on that.

Thanks.

El lunes, 19 de octubre de 2015, 14:39:46 (UTC+2), Patrik Nordwall escribió:
>
> Hi Eduardo,
>
> That sounds strange. I'm not aware of any know bug here, but that doesn't 
> mean that it is bug free. Could you setup a testcase/example that we can 
> use to reproduce the issue?
>
> Thanks,
> Patrik
>
> On Mon, Oct 19, 2015 at 1:03 PM, Eduardo Fernandes  > wrote:
>
>> Hi.
>>
>> We're using Akka 2.3.13 (Java Interface).
>>
>> We have our own AllocationStrategy implementation and the idea is move 
>> several shards from one node to other.  We have a 2 nodes in the cluster 
>> and 1000 shards in total. When we start 7000 actors we have approximately 
>> 3500 actors on each node inside 500 shards on each node (aprox). Everything 
>> normal and behaving like the user manual.
>>
>> At some point in time we return in the rebalance() method around 300 
>> shards to rebalance. What I'm observing is that some actors not belonging 
>> to a shard in the rebalancing set are being stopped, what is quite strange.
>>
>> I can't find any public issue related to this. There is some known 
>> relocation bug?
>>
>> Many thanks in advance.
>>
>> /Eduardo
>>
>> -- 
>> >> 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 http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  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
--- 
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Modeling synchronous startup behavior

[Viktor Klang]

Hi Rich,

On Mon, Oct 19, 2015 at 4:50 PM, Rich Henry  wrote:

> I would if it told me when that chain of events starts and stops relative
> to the actorOf call itself.
>

actorOf is asynchronous so that's completely separate from the lifecycle.


>
> My actor needs to register with another non-actor subsystem before i
> interact with it, so If i write code like...
>
> val subsys = new SubSys()
> val a = system.actorOf(Props(classOf[MyActor], subsys)) // constructor
> registers with subsys
> subsys.go()
>
> There is a race condition as the constructor for my actor doesn't get
> called before .go().
>

Is `subsys` threadsafe? Can your MyActor send a message somewhere to
indicate that it has registered with subsys?


>
>
> On Monday, October 19, 2015 at 10:24:32 AM UTC-4, √ wrote:
>
>>
>>
>> On Mon, Oct 19, 2015 at 4:11 PM, Rich Henry  wrote:
>>
>>> I guess that's the why of question 2. Im not clear when the different
>>> lifecycle phases, like preStart, occur.
>>>
>>> I would assume preStart occurs after object construction, and is
>>> asynchronous to the system call used to create the actor, is that not so?
>>>
>>>
>> Does the documentation help?
>>
>> http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#Actor_Lifecycle
>>
>>
>>
>>> On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:

 Hi Rich,

 and why can't it be executed in preStart()?

 On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  wrote:

> I had seen a previous post that didn't really seem to come to any
> definite conclusion about this subject.
>
> I have some synchronous behavior I need to accomplish during my
> actor's construction, but the constructor is called asynchronously.
>
> 1) Is the accepted way to do this to use an initialization message of
> some kind with the ask pattern?
>
> 2) Is there any documentation beyond the short section in the manual
> that talks about actor lifecycle specifics?
>
> --
> >> 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 http://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+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Modeling synchronous startup behavior

[Rich Henry]

I would if it told me when that chain of events starts and stops relative 
to the actorOf call itself.

My actor needs to register with another non-actor subsystem before i 
interact with it, so If i write code like...

val subsys = new SubSys()
val a = system.actorOf(Props(classOf[MyActor], subsys)) // constructor 
registers with subsys
subsys.go()

There is a race condition as the constructor for my actor doesn't get 
called before .go(). 


On Monday, October 19, 2015 at 10:24:32 AM UTC-4, √ wrote:
>
>
>
> On Mon, Oct 19, 2015 at 4:11 PM, Rich Henry  > wrote:
>
>> I guess that's the why of question 2. Im not clear when the different 
>> lifecycle phases, like preStart, occur. 
>>
>> I would assume preStart occurs after object construction, and is 
>> asynchronous to the system call used to create the actor, is that not so?
>>
>>
> Does the documentation help?
>
> http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#Actor_Lifecycle
>
>  
>
>> On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:
>>>
>>> Hi Rich,
>>>
>>> and why can't it be executed in preStart()?
>>>
>>> On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  wrote:
>>>
 I had seen a previous post that didn't really seem to come to any 
 definite conclusion about this subject.

 I have some synchronous behavior I need to accomplish during my actor's 
 construction, but the constructor is called asynchronously.

 1) Is the accepted way to do this to use an initialization message of 
 some kind with the ask pattern?

 2) Is there any documentation beyond the short section in the manual 
 that talks about actor lifecycle specifics?

 -- 
 >> 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 http://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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Modeling synchronous startup behavior

[Viktor Klang]

On Mon, Oct 19, 2015 at 4:11 PM, Rich Henry  wrote:

> I guess that's the why of question 2. Im not clear when the different
> lifecycle phases, like preStart, occur.
>
> I would assume preStart occurs after object construction, and is
> asynchronous to the system call used to create the actor, is that not so?
>
>
Does the documentation help?

http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#Actor_Lifecycle



> On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:
>>
>> Hi Rich,
>>
>> and why can't it be executed in preStart()?
>>
>> On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  wrote:
>>
>>> I had seen a previous post that didn't really seem to come to any
>>> definite conclusion about this subject.
>>>
>>> I have some synchronous behavior I need to accomplish during my actor's
>>> construction, but the constructor is called asynchronously.
>>>
>>> 1) Is the accepted way to do this to use an initialization message of
>>> some kind with the ask pattern?
>>>
>>> 2) Is there any documentation beyond the short section in the manual
>>> that talks about actor lifecycle specifics?
>>>
>>> --
>>> >> 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 http://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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Modeling synchronous startup behavior

[Rich Henry]

I guess that's the why of question 2. Im not clear when the different 
lifecycle phases, like preStart, occur. 

I would assume preStart occurs after object construction, and is 
asynchronous to the system call used to create the actor, is that not so?

On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:
>
> Hi Rich,
>
> and why can't it be executed in preStart()?
>
> On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  > wrote:
>
>> I had seen a previous post that didn't really seem to come to any 
>> definite conclusion about this subject.
>>
>> I have some synchronous behavior I need to accomplish during my actor's 
>> construction, but the constructor is called asynchronously.
>>
>> 1) Is the accepted way to do this to use an initialization message of 
>> some kind with the ask pattern?
>>
>> 2) Is there any documentation beyond the short section in the manual that 
>> talks about actor lifecycle specifics?
>>
>> -- 
>> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Modeling synchronous startup behavior

[Viktor Klang]

Hi Rich,

and why can't it be executed in preStart()?

On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  wrote:

> I had seen a previous post that didn't really seem to come to any definite
> conclusion about this subject.
>
> I have some synchronous behavior I need to accomplish during my actor's
> construction, but the constructor is called asynchronously.
>
> 1) Is the accepted way to do this to use an initialization message of some
> kind with the ask pattern?
>
> 2) Is there any documentation beyond the short section in the manual that
> talks about actor lifecycle specifics?
>
> --
> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] address is now gated for [5000] ms

['Konstantinos Kougios' via Akka User List]

Thanks Patrik, I tried it and it changes the gate wait, but has no 
effect in the overall wait :


2015-10-19 14:25:25,524 WARN 
[akka.tcp://DataDistributionEndToEndTest@dist-index:2720/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FDataDistributionEndToEndTest%40dist-index%3A2721-0] 
a.r.ReliableDeliverySupervisor - REQ_ID: - Association with remote 
system [akka.tcp://DataDistributionEndToEndTest@dist-index:2721] has 
failed, address is now gated for *[500] ms.* Reason: [Association failed 
with [akka.tcp://DataDistributionEndToEndTest@dist-index:2721]] Caused 
by: [Connection refused: dist-index/192.168.0.11:2721]

waiting cluster
done waiting cluster, *waited 10812 ms*


The code that waits is for the code that awaits for the cluster 
actorsystems to be aware of each other:



val start=System.currentTimeMillis awaitCond(
   cluster1.state.members.size ==allClusters.size &&
  cluster2.state.members.size ==allClusters.size &&
  cluster3.state.members.size ==allClusters.size &&
  driverCluster.state.members.size ==allClusters.size, 60 seconds
)
val dt=System.currentTimeMillis -start println(s"done waiting cluster, waited 
$dtms")


Normally this takes 1-2 seconds. But when the gate issue occurs, it 
takes a lot more, i.e. 10 secs as per above.


Cheers

On 19/10/15 10:50, Patrik Nordwall wrote:

That is probably config property akka.remote.retry-gate-closed-for
/Patrik

On Wed, Oct 7, 2015 at 6:25 PM, Kostas kougios 
mailto:kostas.koug...@googlemail.com>> 
wrote:


Hi, I am occasionally getting this when running tests. The test
resumes, but I wait for 5 secs. Is there a config property to set
it to 500ms?
(googling didn't reveal any relevant info)

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




--

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

[akka-user] Modeling synchronous startup behavior

[Rich Henry]

I had seen a previous post that didn't really seem to come to any definite 
conclusion about this subject.

I have some synchronous behavior I need to accomplish during my actor's 
construction, but the constructor is called asynchronously.

1) Is the accepted way to do this to use an initialization message of some 
kind with the ask pattern?

2) Is there any documentation beyond the short section in the manual that 
talks about actor lifecycle specifics?

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

Re: [akka-user] Re: Dynamic dependency Injection in AKKA

[Maatary Okouya]

I Use MACWire by the way. Gives more flexibility i think.

On Monday, October 19, 2015 at 4:27:32 AM UTC-4, √ wrote:
>
> Let me be clear: We have no beef with enterprise Java :)
>
> As for Dependency Injection with Akka, this blog post should be 
> informative: 
> http://letitcrash.com/post/55958814293/akka-dependency-injection
>
> On Mon, Oct 19, 2015 at 10:13 AM, Richard Bradley <
> richard.brad...@gmail.com > wrote:
>
>> You can use any JVM dependency injection framework you prefer, such as 
>> Guice.
>>
>> I think that DI is less fashionable amongst Akka users as it is amongst 
>> "enterprise Java". I rarely see DI in Akka examples or Akka codebases.
>>
>> HTH
>>
>>
>> Rich
>>
>>
>> On Friday, October 16, 2015 at 11:05:40 AM UTC+1, Maatary Okouya wrote:
>>>
>>> I'd like to know if there is some pattern to handle dynamic dependency 
>>> injection.
>>>
>>> This concern the situation where we have supervision hierarchy. Let say 
>>> I have a service Z that depend on a service c which is part of the a -> b 
>>> -> c hierarchy.
>>>
>>> Clearly Z does not own C, but would appreciate to use c.
>>>
>>> It seems to me that Z needs to know that hierarchy in advance. In a 
>>> sense that would defeat the all purpose of dependency injection. I don't 
>>> want to couple Z to know that hierarchy. It may change in the future.
>>>
>>> So I wonder how this kind of things work in general ?
>>>
>>> I am thinking of using some configuration file, where this kind of 
>>> information would be set. In other words, the architecture of the system 
>>> would not be hardwire in the actor, but provided in a configuration, that 
>>> the actor could use to request the service he needs.
>>>
>> -- 
>> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Dynamic dependency Injection in AKKA

[Maatary Okouya]

Very informative indeed. But it contains not so many alternative when it 
comes to my specific issue. 


The bean should not expose the ActorSystem directly to consumers of its 
service. Instead it is recommended to offer ActorRefs to components within 
the ActorSystem to clients; these can be the result of looking up actors 
using “system.actorFor(...)” or preferably asking the target actor’s parent 
to send back the reference (which ensures that the actor system is ready to 
receives requests before clients can access it).


This is the closest to what i am talking about specifically here. 

But things like: 

1 - "preferably asking the target actor’s parent to send back the 
reference" sounds weird. *How do you get the ref of the parent in the first 
place ?*


This boils down to what i was originally asking how to do with 
dynamic composition. 


a - The only thing i can think of is to have a specific configuration file 
(would be great to have a standard), where you could specify those things. 
E.g. the Actors and their parents, which would ultimately give the path. In 
other words, we have a declarative dependency injection in config files. 
Not typeSafe but what else can we do ?


b- With that configuration, one can go and ask for the ref of the actors 
that he needs. 


c - We could have a central config or multiple config dedicated per actor, 
which ensure their isolation. 


d- Beside, to avoid pooling maybe using AKKA Event Bus would be the way to 
go. Instead of asking the supervisor all the time. One could subscribe to 
events related to the presence/birth/creation/coming-to-life in 
the system of some actors of interests.


Any shared experience on the matter? or else any comments on my proposal ?



Now concerning the part of the blog added above and the suggestion made, it 
means that the beans containing the actor system, would have access to the 
configuration file, so it can poll the presence/readiness of some actor 
such that to return them to the consuming service.

A Problem arise which is that in turn, if the service in question needs to 
be instantiated with the actor ref, then that's not good because we 
propagate the loss of typesafety in the non actor part of our system that 
connect to actor.















On Monday, October 19, 2015 at 4:27:32 AM UTC-4, √ wrote:
>
> Let me be clear: We have no beef with enterprise Java :)
>
> As for Dependency Injection with Akka, this blog post should be 
> informative: 
> http://letitcrash.com/post/55958814293/akka-dependency-injection
>
> On Mon, Oct 19, 2015 at 10:13 AM, Richard Bradley <
> richard.brad...@gmail.com > wrote:
>
>> You can use any JVM dependency injection framework you prefer, such as 
>> Guice.
>>
>> I think that DI is less fashionable amongst Akka users as it is amongst 
>> "enterprise Java". I rarely see DI in Akka examples or Akka codebases.
>>
>> HTH
>>
>>
>> Rich
>>
>>
>> On Friday, October 16, 2015 at 11:05:40 AM UTC+1, Maatary Okouya wrote:
>>>
>>> I'd like to know if there is some pattern to handle dynamic dependency 
>>> injection.
>>>
>>> This concern the situation where we have supervision hierarchy. Let say 
>>> I have a service Z that depend on a service c which is part of the a -> b 
>>> -> c hierarchy.
>>>
>>> Clearly Z does not own C, but would appreciate to use c.
>>>
>>> It seems to me that Z needs to know that hierarchy in advance. In a 
>>> sense that would defeat the all purpose of dependency injection. I don't 
>>> want to couple Z to know that hierarchy. It may change in the future.
>>>
>>> So I wonder how this kind of things work in general ?
>>>
>>> I am thinking of using some configuration file, where this kind of 
>>> information would be set. In other words, the architecture of the system 
>>> would not be hardwire in the actor, but provided in a configuration, that 
>>> the actor could use to request the service he needs.
>>>
>> -- 
>> >> 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 http://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 em

Re: [akka-user] Cluster sharding shutdown and restart in proxy mode

[Patrik Nordwall]

On Tue, Oct 13, 2015 at 2:04 PM, Johannes Berg  wrote:

> Hi!
>
> I'm running cluster sharding and at a certain point I want to instruct one
> of the nodes to shutdown a certain shardregion and handoff all the shards
> to other nodes. But I still want to keep the node around and restart the
> shardregion in proxy mode. Is this possible? I've looked at Graceful
> Shutdown and proxy mode at
> http://doc.akka.io/docs/akka/snapshot/java/cluster-sharding.html and in
> theory it seems it should work although the example shutdowns the node and
> doesn't restart the shardregion.
>

That is not supported. You must restart the actor system. It would be
complicated to add that feature.


> Also Graceful shutdown doesn't seem to be available in the doces for
> 2.3.X, but is there some possibility of doing the same thing in 2.3.X
> somehow (sending poisonpill to shardregion and restart region with null
> entryProps or something like that)?
>

Graceful shutdown is new in 2.4.0 and I see no way to do it in 2.3.x

Regards,
Patrik


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



-- 

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

Re: [akka-user] AllocationStrategy rebalance() is stopping actors outside resharding list

[Patrik Nordwall]

Hi Eduardo,

That sounds strange. I'm not aware of any know bug here, but that doesn't
mean that it is bug free. Could you setup a testcase/example that we can
use to reproduce the issue?

Thanks,
Patrik

On Mon, Oct 19, 2015 at 1:03 PM, Eduardo Fernandes  wrote:

> Hi.
>
> We're using Akka 2.3.13 (Java Interface).
>
> We have our own AllocationStrategy implementation and the idea is move
> several shards from one node to other.  We have a 2 nodes in the cluster
> and 1000 shards in total. When we start 7000 actors we have approximately
> 3500 actors on each node inside 500 shards on each node (aprox). Everything
> normal and behaving like the user manual.
>
> At some point in time we return in the rebalance() method around 300
> shards to rebalance. What I'm observing is that some actors not belonging
> to a shard in the rebalancing set are being stopped, what is quite strange.
>
> I can't find any public issue related to this. There is some known
> relocation bug?
>
> Many thanks in advance.
>
> /Eduardo
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

[akka-user] Idle connection handling for non-pooled http connections

[Chris Baxter]

Referencing this ticket , I can 
see that the idle connection/timeout handling is not yet in place when 
using pooled connections.  I added a comment around the behavior of 
non-pooled outbound connections with timeouts hoping to get a response but 
nothing so far so I'm adding here in hopes of getting some clarification. 
 If I use a non-pooled connection and use a takeWithin on the Flow to 
handle a timeout, and it does hit that timeout condition, failing the Flow, 
will the underlying single connection be closed immediately or will it stay 
open until a response is received from the remote server even though 
control does return to the code using the connection?  From the debug 
logging it does not look like it closed the connection until a response is 
received.  This seems to run counter to what @sirthias says about using the 
low level Http().outboundConnection API.  How can I get this to work as 
expected, where my takeWithin timeout handling will close the underlying 
connection immediately after hitting the timeout condition?

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

[akka-user] AllocationStrategy rebalance() is stopping actors outside resharding list

[Eduardo Fernandes]

Hi.

We're using Akka 2.3.13 (Java Interface).

We have our own AllocationStrategy implementation and the idea is move 
several shards from one node to other.  We have a 2 nodes in the cluster 
and 1000 shards in total. When we start 7000 actors we have approximately 
3500 actors on each node inside 500 shards on each node (aprox). Everything 
normal and behaving like the user manual.

At some point in time we return in the rebalance() method around 300 shards 
to rebalance. What I'm observing is that some actors not belonging to a 
shard in the rebalancing set are being stopped, what is quite strange.

I can't find any public issue related to this. There is some known 
relocation bug?

Many thanks in advance.

/Eduardo

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

Re: [akka-user] Re: Proposed major simplification of the Akka Streams FlowGraph APIs

[אדם חונן]

"Makes sense, but once you do—is it a no-go or is there a means of doing
it?"

Well, RxJava implements reactive streams, so obviously it's possible to do
the same things.
For example:

For Broadcast, I'd use PublishSubject.
For Balance, I'd create an Observable, that holds multiple subscriptions
and push an item into each according to a balancing strategy.
For UnzipWith, again you'd use an Observable of  and
subscriptions of X, Y, Z, ... and for each item push the unzipped items.
etc.

For the fan in operations, you'd do the reverse by having one subscription
pointed to by many observables, with the only trick being that for that one
subscription, you'd probably use a SerializedSubject (for thread safety).

On Mon, Oct 19, 2015 at 12:00 PM, Viktor Klang 
wrote:

>
>
> On Sun, Oct 18, 2015 at 5:57 PM, אדם חונן  wrote:
>
>> Ah.. I didn't think of that type erasure issue. Makes sense.
>>
>>
> Yeah, that one is somewhat of a silent killer. Everything works until you
> suddenly need both Graph[SourceShape] and Graph[FlowShape] and now it's all
> for nothing…
>
>
>> RxJava doesn't have a graph DSL as far as I know.
>> I'm guessing you'd have to use Subjects to implement something similar to
>> graphs there, but so far I've never had the need for that.
>> I guess what I usually do with RxJava is more similar to only ever using
>> Source from Akka Streams, although I'm pretty sure I'd have to use both
>> Source and Flow.
>>
>
> That's interesting that you mention because we're currently adding a lot
> more surface-area to Source/Flow/Sink to try to make that the 80%-solution,
> so you only have to "drop down" to FlowGraph for the 20% case (more power
> but also more risk).
>
>
>> In my case, we're using RxJava because we're using Couchbase and the java
>> client is based on RxJava.
>> I guess our use case is much more similar to using Futures - we don't
>> need complex graphs for most of our system.
>>
>
> Makes sense, but once you do—is it a no-go or is there a means of doing it?
>
>
>>
>> Methods are simply easier to find inside an IDE than symbols.
>> You start with "builder.", hit ctrl+space and there it is, with properly
>> named arguments and all.
>> But thinking of it further, it actually only matters if the code samples
>> in the documentation use it as well.
>> I mean, my starting point was from a code sample, so if that uses "~>"
>> and I fail to copy all parts (or the sample skips some parts under the
>> assumption that I already know them), it won't matter if addEdge is
>> available or not - my copied code won't work. It might make it clearer if
>> my mistake was to not have "builder =>".
>>
>
> True.
> My main beef with the scaladsl for FlowGraph.Builder is that it both
> requires the builder to be implicit (as in { implicit builder => }) but
> also requires import FlowGraph.Implicits._, both of which are hard to
> discover if all you do is to work with the code (and not reading docs).
>
> The question is how this could be improved, one solution would be to make
> the implicits available from the builder itself, so when you write
> `builder.` you get `dsl`/`ops` and the scaladoc thereof explains that you
> import it and need to make the builder reference an implicit and then you
> can use this awesome DSL to wire your graph.
>
>
>>
>> Anyway, none of the above was what was most difficult to me.
>> I think the difficulties I had are sort of out of scope for this
>> discussion.
>> I think it's mostly knowing what to use where.
>>
>
> I 100% agree. This is why I am trying to cut down the surface area and
> different locations of functionality, with my proposal there is *one way*
> of creating FlowGraphs => FlowGraph.create
>
>
>> With RxJava you have a huge amount of operators, which is sometimes
>> annoying, but it's a one stop shop, so when you're "stumbling in the dark"
>> (although the documentation also makes a difference), you're more likely to
>> bump into the right thing.
>> With Akka Streams things are cleaner, but are also found in different
>> places, so you have to look for them in more places.
>> I guess it's really a design choice. Akka Streams pushes you more towards
>> writing new composable components, which may be nice for the long run, but
>> less intuitive initially.
>>
>
> Agreed. The question is if there's a magic balance to strike—I am betting
> on that.
>
>
>>
>> I'll try to be specific, although I find it hard to remember precisely -
>>
>>1. I often found myself *thinking* that I probably need to call
>>builder.add(something) and I found myself unsure what that "something"
>>should be.
>>
>>
> Yeah, I raised that topic last week, I think the consensus is to always
> require it, or never require it, because not knowing when to do it means
> that it creates a feeling of unease.
>
>
>>
>>1. It's easy to miss stuff like that instead of flatMap, you often
>>need to use join. Initially it takes browsing through lots of 
>> documentation
>>pages. After a while yo

Re: [akka-user] SharedLeveldbJournal questions

[Patrik Nordwall]

SharedLeveldbJournal.setStore must be done once, when the actor system is
started. I agree that this can probably be simplified. We have that
initialization code in several of the activator templates (e.g. Akka
Cluster Sharding with Scala

) and that boilerplate is also an indication that this should be made
easier. I guess we have not payed much attention to SharedLeveldbJournal
since it's only a demo/test toy.

Please create an issue  (and
contributions are also very welcome).

Regards
Patrik

On Wed, Oct 14, 2015 at 1:06 PM, Tal Pressman  wrote:

> Hi,
>
> Now that Akka 2.4 is released with the new persistence-query APIs, we
> upgraded Akka in our application. After doing some searching, I couldn't
> find any persistence-query plugins yet, so in the meantime I switched to
> the shared LevelDB plugin.
>
> So functionally, everything works now, and I can get all my different
> nodes to share persistence queues, and it's great. However, I have a couple
> of questions with regards to injecting the shared store ActorRef.
>
> According to the docs, the recommended way of injecting the reference is
> having actors look do an actorSelection and Identify in their preStart, and
> then call SharedLeveldbJournal.setStore when they get a response. It also
> says that "Internal journal commands (sent by persistent actors) are
> buffered until injection completes". I understood that to mean that I can
> do the injection from my PersistentActor/PersistentView, but that didn't
> work (the actors failed to recover properly). So what I've done instead is
> add a simple 'ask' after initializing my ActorSystem that does the
> injection.
>
> This brings me to the actual questions:
>
>1. Am I misreading the documentation? Should the injection work when
>done from the actual PersistentActor/PersistentView (or rather
>UntypedPersistentActor)?
>2. Why doesn't the plugin do this process on its own when initialized?
>The path to the store can be added to the plugin's configuration and, when
>it's initialized, it can perform the actorSelection and the injection
>itself. This would also make switching to/from the plugin a mere
>configuration change, and not actual code changes.
>
> Thanks,
> Tal
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

Re: [akka-user] Issues in AKKA persistence w/ KAFKA

[Patrik Nordwall]

In 2.4.0 there is a new utility to remove the internal cluster sharding
data
http://doc.akka.io/docs/akka/2.4.0/scala/cluster-sharding.html#Removal_of_Internal_Cluster_Sharding_Data
.

The most common reason for problem a is using auto-down and I highly
recommend that you use the Typesafe Split Brain Resolver

or some similar downing strategy.

Regards,
Patrik

On Tue, Oct 13, 2015 at 5:33 PM, Swaroop Belur 
wrote:

>
> HI all,
>
> Using AKKA 2.3.12 and experimental version of AKKA persistence w/ KAFKA
> plugin
> (Plan to upgrade to prod version soon, just cannot do it immediately)
>
> I am using the KAFKA persistence plugin and see 2 kinds of errors mainly
>
> a. First is with reference to issue -
> https://github.com/akka/akka/issues/17955.
> b. kafka offset out of range exception.
>
> The first one happened randomly and even if i restart the error continues.
> The second one is generally when I kill one of the nodes in cluster
> forcefully .
>
> Basically I am using the clustersharding pattern where i have 4 persisters
> in my cluster of 2 nodes,
> each writing to a specific topic in Kafka.
>
> Help needed
> a. I am not sure how to clean up the coordinator shard data in KAFKA
>- Any pointers here (any kafka commands specically, which topic , also
> do i need to restart the AKKA cluster)
> b. I am not sure why this error comes up frequently just on failover. Is
> this fixed in later version.
> (Pushing messages at very low rate)
>
> Am keen on using the sharding pattern to increase throughput. Just stuck
> here w/ these 2 errors.
>
> Any suggestions appreciated.
>
> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

Re: [akka-user] Event-sourcing with aka-persistence

[Patrik Nordwall]

If I understand it correctly your question is about how to persist the
LevelEarned event which comes via the
asyncrounous player.observable.subscribe callback. Since this is an actor
you must turn that callback into a message that is sent to self and when
receiving that message you can persist it.

/Patrik

On Mon, Oct 12, 2015 at 3:17 PM, Adam Dohnal  wrote:

> Hello,
>
> I am new in Akka and I am trying to develop some mini project to test some
> things (akka, rx, cqrs, es etc..)
>
> I think I understand the concept of cqrs/es and how it fit to akka. My
> problem is probably more theoretical than technical.
>
> Let's say, I have class Player, which has several Attribute[T] attributes
> ... these attributes can be for example player's current health, vitality,
> experience, level etc ... These attributes have dependencies ... for
> example currentHealth is defined as 10 * vitality ... if experience is >
> 100 new level is earns, which causes to add 1 vitality, which causes to add
> 10 health ... Hopefully, you get the point.
>
> I like the idea to implement this using reactive streams. Each
> Attribute[T] should be considered as Observable[T] and with all these
> excellent operators I can model dependencies I have described before.
>
> Now I am trying to model each Player as actor, which can handle commands
> (AddExperience(...), AddVitality(...) etc...) and produce events
> (ExperienceAdded(...), LevelEarned(...)) which should be event sourced.
>
> Problem is, that when I am handling command I directly don't know what
> events should be generated ... for example AddExperience(100) is handled
> and after some validation ExperienceAdded(100) should be persisted to event
> store. When it success, it should be applied to my domain, which emit value
> change in that attribute observable and new level can be earned ... but how
> can I persist that event?
>
> I try to write some pseudo-code
>
> class ExamplePersistentActor extends PersistentActor {
>   val Player player = ... // domain
>
>   val subscription = player.observable.subscribe {
> // here I get asynchronously information about that level is increased ...
> should I call persist here?
> }
>
> val receiveCommand: Receive = {
> case AddExperience(xp: Int) => {
>  persist(ExperienceAdded(xp)) { event =>
>   player.addExperience(xp) // should produce LevelEarned(1) event, which
> should be also persisted
> }
>   }
> }
>
> So I have reference to Player which has observable of all events that are
> produced ... but I don't how to persist them :/
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

[akka-user] How to survive recovery failure?

[Brice Figureau]

Hi,

I've encountered an issue where due to a timeout in Cassandra, some of
my persistent actors couldn't recover and were forcibly stopped.

I would have liked to retry one more time for instance, or keep the
actor running (because the actor could still serve even though without
the recovered state), but it doesn't seem possible.

I'm surprised that this can't be implemented in akka 2.4, and that it
doesn't use the supervisor hierarchy to make the decision about what to
do.

Could that be planned for a future version?
-- 
Brice Figureau 

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

Re: [akka-user] Re: Websockets with Elasticsearch ScrollPublisher - Requesting more elements

[Patrik Nordwall]

Cool, thanks for sharing!
/Patrik

On Sun, Oct 11, 2015 at 5:14 PM, Muki  wrote:

> Hi,
>
> I implemented a working solution and will soon provide it as an activator
> template.
>
> https://github.com/muuki88/akka-http-elasticsearch
>
> cheers,
> Muki
>
> Am Freitag, 2. Oktober 2015 17:29:09 UTC+2 schrieb Muki:
>>
>> Hi,
>>
>> I'm playing around with akka-http and elasti4s reactive extension. My
>> goal is rather simple: I want to stream the elasticsearch results via
>> websocket on request
>>
>>
>>1. Open a websocket ( *wscat -c ws://localhost:9000/es/scroll* )
>>2. Place a query ( *>search:my search term* )
>>3. Get always a bunch (e.g. 5) results and get the next results with
>>*>next*
>>
>>  val commandTriggeredFlow = Flow() { implicit b =>
>>  import FlowGraph.Implicits._
>>  // broadcast the command to the elasticsearch source and the tick
>> system
>>  val bcast = b.add(Broadcast[Command](2))
>>  val zip = b.add(Zip[Command, Seq[Question]]())
>>
>>   // forward the ticks
>> bcast.out(0) ~> zip.in0
>>
>> // filter out the Next commands
>> bcast.out(1)
>>.filter(_.isInstanceOf[Search])
>>.map {
>>  case Search(term) => query(term)
>>}
>>.flatten(FlattenStrategy.concat)
>>// group results to get a "per next result batch"
>>.grouped(2) ~> zip.in1
>>
>>(bcast.in, zip.out)
>> }
>>
>> I had the idea to parse the commands from the websocket and only create a
>> new search on a search command and otherwise trigger the elasticsearch
>> ScrollPublisher source.
>> Well. That doesn't work :D
>>
>> > search:first
>>
>> < (Search(first),Vector(Question(1,First Question ever asked!,This is my
>> first question!), Question(1,First Question ever asked!,This is my first
>> question!)))
>> > next
>>
>> <
>> >
>>
>>
>> I'm getting the results in a batch for my first search. But when I hit
>> next the stream seems not be triggered.
>> I couldn't find any examples for this :(
>>
>> cheers,
>> Muki
>>
>> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

Re: [akka-user] address is now gated for [5000] ms

[Patrik Nordwall]

That is probably config property akka.remote.retry-gate-closed-for
/Patrik

On Wed, Oct 7, 2015 at 6:25 PM, Kostas kougios <
kostas.koug...@googlemail.com> wrote:

> Hi, I am occasionally getting this when running tests. The test resumes,
> but I wait for 5 secs. Is there a config property to set it to 500ms?
> (googling didn't reveal any relevant info)
>
> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

[akka-user] difference between dispatcher and route?

[张留成]

Hi All:


What's the difference between dispatcher and route? when should i use 
dispatcher and when  to use route?




see the above image,if want to send a signal when all complete, show i use 
the dispatcher with fork-join-pool ?



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

Re: [akka-user] Re: Proposed major simplification of the Akka Streams FlowGraph APIs

[Konrad Malawski]

My main beef with the scaladsl for FlowGraph.Builder is that it both requires 
the builder to be implicit (as in { implicit builder => }) but also requires 
import FlowGraph.Implicits._, both of which are hard to discover if all you do 
is to work with the code (and not reading docs).

The question is how this could be improved, one solution would be to make the 
implicits available from the builder itself, so when you write `builder.` you 
get `dsl`/`ops` and the scaladoc thereof explains that you import it and need 
to make the builder reference an implicit and then you can use this awesome DSL 
to wire your graph.
Yes, I'd want to remove that implicits import a lot.

We show the ~> syntax in most places, so it's basically "the" DSL and really 
"oh and by the way there's another one".

I'd definitely lobby for and merge such change as part of the cleanups if you 
had a bit of time to try doing it.



-- 

Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe

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

Re: [akka-user] Re: Proposed major simplification of the Akka Streams FlowGraph APIs

[Viktor Klang]

On Sun, Oct 18, 2015 at 5:57 PM, אדם חונן  wrote:

> Ah.. I didn't think of that type erasure issue. Makes sense.
>
>
Yeah, that one is somewhat of a silent killer. Everything works until you
suddenly need both Graph[SourceShape] and Graph[FlowShape] and now it's all
for nothing…


> RxJava doesn't have a graph DSL as far as I know.
> I'm guessing you'd have to use Subjects to implement something similar to
> graphs there, but so far I've never had the need for that.
> I guess what I usually do with RxJava is more similar to only ever using
> Source from Akka Streams, although I'm pretty sure I'd have to use both
> Source and Flow.
>

That's interesting that you mention because we're currently adding a lot
more surface-area to Source/Flow/Sink to try to make that the 80%-solution,
so you only have to "drop down" to FlowGraph for the 20% case (more power
but also more risk).


> In my case, we're using RxJava because we're using Couchbase and the java
> client is based on RxJava.
> I guess our use case is much more similar to using Futures - we don't need
> complex graphs for most of our system.
>

Makes sense, but once you do—is it a no-go or is there a means of doing it?


>
> Methods are simply easier to find inside an IDE than symbols.
> You start with "builder.", hit ctrl+space and there it is, with properly
> named arguments and all.
> But thinking of it further, it actually only matters if the code samples
> in the documentation use it as well.
> I mean, my starting point was from a code sample, so if that uses "~>" and
> I fail to copy all parts (or the sample skips some parts under the
> assumption that I already know them), it won't matter if addEdge is
> available or not - my copied code won't work. It might make it clearer if
> my mistake was to not have "builder =>".
>

True.
My main beef with the scaladsl for FlowGraph.Builder is that it both
requires the builder to be implicit (as in { implicit builder => }) but
also requires import FlowGraph.Implicits._, both of which are hard to
discover if all you do is to work with the code (and not reading docs).

The question is how this could be improved, one solution would be to make
the implicits available from the builder itself, so when you write
`builder.` you get `dsl`/`ops` and the scaladoc thereof explains that you
import it and need to make the builder reference an implicit and then you
can use this awesome DSL to wire your graph.


>
> Anyway, none of the above was what was most difficult to me.
> I think the difficulties I had are sort of out of scope for this
> discussion.
> I think it's mostly knowing what to use where.
>

I 100% agree. This is why I am trying to cut down the surface area and
different locations of functionality, with my proposal there is *one way*
of creating FlowGraphs => FlowGraph.create


> With RxJava you have a huge amount of operators, which is sometimes
> annoying, but it's a one stop shop, so when you're "stumbling in the dark"
> (although the documentation also makes a difference), you're more likely to
> bump into the right thing.
> With Akka Streams things are cleaner, but are also found in different
> places, so you have to look for them in more places.
> I guess it's really a design choice. Akka Streams pushes you more towards
> writing new composable components, which may be nice for the long run, but
> less intuitive initially.
>

Agreed. The question is if there's a magic balance to strike—I am betting
on that.


>
> I'll try to be specific, although I find it hard to remember precisely -
>
>1. I often found myself *thinking* that I probably need to call
>builder.add(something) and I found myself unsure what that "something"
>should be.
>
>
Yeah, I raised that topic last week, I think the consensus is to always
require it, or never require it, because not knowing when to do it means
that it creates a feeling of unease.


>
>1. It's easy to miss stuff like that instead of flatMap, you often
>need to use join. Initially it takes browsing through lots of documentation
>pages. After a while you get used to where to look for it. I guess I'd say
>it's not as "search friendly" as Rx (for now).
>
> True. Adding it via an implicit is easy enough if one feels that it is
missing.


>
>
>
> On Sun, Oct 18, 2015 at 2:14 PM, Viktor Klang 
> wrote:
>
>> Hi Adam,
>>
>> Thanks for your feedback!
>> Responses inline
>>
>> On 18 Oct 2015 09:36, "Adam"  wrote:
>> >
>> > Hi,
>> >
>> >
>> >
>> > I like most of the described changes.
>> >
>> > Here are my personal reservations:
>> >
>> >
>> >
>> > 1. I prefer a single method name with many overloads over many method
>> names that say what are the arguments.
>>
>> In general I do too, but with erasure and type inference it creates what
>> I've dubbed "Overloading overload" where the compiler (both Java and Scala)
>> will start spitting out nasty error messages with N signatures. Hardly
>> helpful for newcomers, I'd say!
>>
>> >
>> >
>> > 2. I think the

Re: [akka-user] Re: Dynamic dependency Injection in AKKA

[Viktor Klang]

Let me be clear: We have no beef with enterprise Java :)

As for Dependency Injection with Akka, this blog post should be
informative:
http://letitcrash.com/post/55958814293/akka-dependency-injection

On Mon, Oct 19, 2015 at 10:13 AM, Richard Bradley <
richard.bradley.softw...@gmail.com> wrote:

> You can use any JVM dependency injection framework you prefer, such as
> Guice.
>
> I think that DI is less fashionable amongst Akka users as it is amongst
> "enterprise Java". I rarely see DI in Akka examples or Akka codebases.
>
> HTH
>
>
> Rich
>
>
> On Friday, October 16, 2015 at 11:05:40 AM UTC+1, Maatary Okouya wrote:
>>
>> I'd like to know if there is some pattern to handle dynamic dependency
>> injection.
>>
>> This concern the situation where we have supervision hierarchy. Let say I
>> have a service Z that depend on a service c which is part of the a -> b ->
>> c hierarchy.
>>
>> Clearly Z does not own C, but would appreciate to use c.
>>
>> It seems to me that Z needs to know that hierarchy in advance. In a sense
>> that would defeat the all purpose of dependency injection. I don't want to
>> couple Z to know that hierarchy. It may change in the future.
>>
>> So I wonder how this kind of things work in general ?
>>
>> I am thinking of using some configuration file, where this kind of
>> information would be set. In other words, the architecture of the system
>> would not be hardwire in the actor, but provided in a configuration, that
>> the actor could use to request the service he needs.
>>
> --
> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Dynamic dependency Injection in AKKA

[Richard Bradley]

You can use any JVM dependency injection framework you prefer, such as 
Guice.

I think that DI is less fashionable amongst Akka users as it is amongst 
"enterprise Java". I rarely see DI in Akka examples or Akka codebases.

HTH


Rich


On Friday, October 16, 2015 at 11:05:40 AM UTC+1, Maatary Okouya wrote:
>
> I'd like to know if there is some pattern to handle dynamic dependency 
> injection.
>
> This concern the situation where we have supervision hierarchy. Let say I 
> have a service Z that depend on a service c which is part of the a -> b -> 
> c hierarchy.
>
> Clearly Z does not own C, but would appreciate to use c.
>
> It seems to me that Z needs to know that hierarchy in advance. In a sense 
> that would defeat the all purpose of dependency injection. I don't want to 
> couple Z to know that hierarchy. It may change in the future.
>
> So I wonder how this kind of things work in general ?
>
> I am thinking of using some configuration file, where this kind of 
> information would be set. In other words, the architecture of the system 
> would not be hardwire in the actor, but provided in a configuration, that 
> the actor could use to request the service he needs.
>

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

Re: [akka-user] Capturing the message that killed an actor

[Viktor Klang]

Hi Arne,

sounds like spawning a child-actor for each operation would give you both
control over failures (supervision) as well as knowing what message was
delegated to what actor.

On Sat, Oct 17, 2015 at 6:09 PM, Arne Claassen  wrote:

> Viktor,
>
> Yeah, i can see a crash loop being undesirable, but it shouldn't be a
> problem in my scenario, since only one end is really an actor.
>
> The scenario is the following:
> 1. HTTP request comes into play for some analytics for a specific resource
> 2. The request gets routed to a persistent actor on an akka cluster
> 3. The resource actor may return a previously calculated result or
> calculate one
> 4. Since the calculation may take some time, my ask has a longish timeout
> 5. If the actor fails in its operation due to some scenario that wasn't
> considered as a possible failure scenario, I want to notify the waiting
> HTTP call as soon as possible, rather than have the call time out
> 6. The HTTP request gets completed with either the 200 analytics response
> or a 500, trying to use 408 only for actual timeouts not failures in the
> message flow
>
> Ideally, the communication channel between the HTTP endpoint and the
> resource would be a protocol more resilient than a single ask, such as
> having an initial ack, and some heartbeat, but for now it's just that ask
> and I'm trying to communicate failure back to the caller in the most timely
> fashion.
>
> thanks,
> arne
>
> On Saturday, October 17, 2015 at 5:01:52 AM UTC-7, √ wrote:
>>
>> Arne,
>>
>> if 2 actors have SafeReceive, send messages to eachother and they fail on
>> processing OperationFailed, then you have a crash loop.
>>
>> What behavior are you implementing? (what are you going to use the
>> exception and message for?)
>>
>> --
>> Cheers,
>> √
>> On 15 Oct 2015 22:44, "Arne Claassen"  wrote:
>>
>>> So I came up with this workaround:
>>>
>>> object SafeReceive {
>>>   def apply(receive: Receive)(recover: Any => PartialFunction[Throwable,
>>> Unit]): Receive =
>>> new Receive {
>>>  override def isDefinedAt(x: Any): Boolean = receive.isDefinedAt(x)
>>>   override def apply(v1: Any): Unit = try {
>>>receive(v1)
>>>   } catch recover(v1)
>>> }
>>> }
>>>
>>> which I can invoke like this:
>>>
>>> def receive = SafeReceive {
>>>   
>>> } {
>>>   msg => {
>>> case e:Exception =>
>>>   sender ! OperationFailed(msg,e)
>>>   throw e
>>>   }
>>> }
>>>
>>> Any reason why this would be a bad idea?
>>>
>>> cheers,
>>> arne
>>>
>>>
>>> On Thursday, October 15, 2015 at 1:25:13 PM UTC-7, Arne Claassen wrote:

 Actually according to those docs, the supervisor stopping does cause
 the message to be dropped.  The message is taken from the mailbox, causes
 an exception and then the supervisor stops the actor, never returning the
 message to the mailbox. I've tested to verify that that is the behavior.

 What confuses me is the following:

> *It is important to understand that it is not put back on the mailbox.
> So if you want to retry processing of a message, you need to deal with it
> yourself by catching the exception and retry your flow.*


 I.e. I would need to wrap every pattern match or at least every Receive
 definition in a try/catch to get at the message.I thought the whole point
 of the Let It crash philosophy is that I don't need to wrap everything i do
 in a try catch to guard against bugs, since the actor crashing handles that
 behavior.

 cheers,
 arne

 On Thursday, October 15, 2015 at 12:40:34 PM UTC-7, Ryan Tanner wrote:
>
> Actors aren't necessarily stopped due to user-land messages.  If you
> use context.stop(ref), what would be the message in postStop?  Though I
> suppose it could be an Option.
>
> That said, to answer your question, it is definitely intentional.
>
> If an exception is thrown while a message is being processed (i.e.
>> taken out of its mailbox and handed over to the current behavior), then
>> this message will be lost.
>>
>
>
> http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#What_happens_to_the_Message
>
> If the supervisor strategy governing that failure stops the actor
> without restarting it, then yes the messages in the mailbox will go to
> DeadLetters.  If the actor is restarted after failure, the mailbox will be
> unaffected and the new incarnation of the actor will pick up where the 
> dead
> actor left off (minus the actor that caused the failure).
>
> On Thursday, October 15, 2015 at 12:31:39 PM UTC-6, Arne Claassen
> wrote:
>>
>> The scenario in which this came up was one of a bug causing the
>> death. I.e. it wasn't perceived to be a dangerous operation, I wanted a 
>> way
>> to quickly deal with the failure rather than having the sender rely on a
>> timeout.
>>
>> Clearly it was considered desirable to 

Re: [akka-user] Abridged summary of akka-user@googlegroups.com - 10 updates in 5 topics

[Viktor Klang]

Hi Joseph,

please respond on the same thread to keep continuity.

For the Servlet communicating with the actor, I'd propose to use Inbox:
http://doc.akka.io/docs/akka/2.3.14/java/untyped-actors.html#The_Inbox

On Mon, Oct 19, 2015 at 3:49 AM, Joseph Mansigian <
aed.project.c...@gmail.com> wrote:

> Hello Victor,
>
> Thank you for your reply.  Based on your response I think that I did not
> express very well what I am seeking.  Being able to have the servlet send a
> message to an actor and vice versa would be perfectly Okay.  I am searching
> for some code that would be a model of how to effect this interaction in
> which the servlet would always initiate the interaction with a message and
> then the actor would reply.  What I am saying is I don't know the technique
> for sending and receiving messages from inside a servlet.  Would be greatly
> helped by example.  Perhaps I should look at some Play code that must do
> this.  Thank you for your attention to this.
>
> Joe Mansigian
>
> On Sun, Oct 18, 2015 at 1:33 PM,  wrote:
>
>> akka-user@googlegroups.com
>> 
>>  Google
>> Groups
>> 
>> 
>> Today's topic summary
>> View all topics
>> 
>>
>>- Proposed major simplification of the Akka Streams FlowGraph APIs
>><#1507dc9ede05a829_1507c032c1327adf_group_thread_0> - 4 Updates
>>- No Tests to run for MultiJvm
>><#1507dc9ede05a829_1507c032c1327adf_group_thread_1> - 2 Updates
>>- No Tests to run for MultiJvm
>><#1507dc9ede05a829_1507c032c1327adf_group_thread_2> - 1 Update
>>- Behavior of Akka when you sleep in an actor
>><#1507dc9ede05a829_1507c032c1327adf_group_thread_3> - 1 Update
>>- Servlet and Actor
>><#1507dc9ede05a829_1507c032c1327adf_group_thread_4> - 2 Updates
>>
>> Proposed major simplification of the Akka Streams FlowGraph APIs
>> 
>> Viktor Klang : Oct 17 10:57PM +0200
>>
>> Hi everyone,
>>
>> I'm proposing the following (breaking) changes to the FlowGraph-related
>> APIs, in order to make it consistent, with a smaller surface area and with
>> more obvious demarcation of ...more
>> 
>> Adam : Oct 18 12:36AM -0700
>>
>> Hi,
>>
>>
>>
>> I like most of the described changes.
>>
>> Here are my personal reservations:
>>
>>
>>
>> 1. I prefer a single method name with many overloads over many method
>> names
>> that say what are the ...more
>> 
>> Viktor Klang : Oct 18 01:14PM +0200
>>
>> Hi Adam,
>>
>> Thanks for your feedback!
>> Responses inline
>>
>>
>> > I like most of the described changes.
>>
>> > Here are my personal reservations:
>>
>> > 1. I prefer a single method name with many overloads ...more
>> 
>> "אדם חונן" : Oct 18 06:57PM +0300
>>
>> Ah.. I didn't think of that type erasure issue. Makes sense.
>>
>> RxJava doesn't have a graph DSL as far as I know.
>> I'm guessing you'd have to use Subjects to implement something similar to
>> ...more
>> 
>> Back to top <#1507dc9ede05a829_1507c032c1327adf_digest_top>
>> No Tests to run for MultiJvm
>> 
>> Harit Himanshu : Oct 17 10:18PM -0700
>>
>> Hello everyone,
>>
>> I started learning akka-cluster today and was trying to write the
>> multi-ivm
>> test.
>> I followed all through the document but when I run my application, I see
>>
>>
>> ...more
>> 
>> matheuslima...@gmail.com: Oct 18 08:22AM -0700
>>
>> You need create the node class:
>> class:
>>
>> class SimpleClusterListenerSpecMultiJvmNode1 extends
>> SimpleClusterListenerSpec
>> class SimpleClusterListenerSpecMultiJvmNode2 extends ...more
>> 
>> Back to top <#1507dc9ede05a829_1507c032c1327adf_digest_top>
>> No Tests to run for MultiJvm
>> 
>> Harit Himanshu : Oct 17 10:16PM -0700
>>
>> Hello everyone,
>>
>> I started learning akka-cluster today and was trying to write the
>> multi-ivm
>> test.
>>
>> I followed all through the document ...more
>> 

Re: [akka-user] Re: [akka-stream] How to get materialization result in partial flow

[Viktor Klang]

Hi Alexey,

I don't have any suggestion for a fix, but it does seem like your setup is
a bit too entangled.
If you take a step back and look at the lifecycle and propagation pattern
needed by your solution, is it workable or does it make sense to consider
other solutions?

On Mon, Oct 19, 2015 at 7:00 AM, Alexey Romanchuk <
alexey.romanc...@gmail.com> wrote:

> The problem with this solution is absence of actorRef during upstream
> complete. Any ideas how to get it?
>
> пятница, 16 октября 2015 г., 15:18:51 UTC+6 пользователь Alexey Romanchuk
> написал:
>
>> Finally ended with
>>
>> ```scala
>> val managedMySource = FlowGraph.partial(MySource()) {
>> implicit b => source =>
>>   val control = b.add(Flow[Command]])
>>   val zip = b.add(Zip[ActorRef, Command])
>>
>> b.materializedValue.map(Source.repeat).flatten(FlattenStrategy.concat) ~>
>> zip.in0
>>
>> control.outlet ~> zip.in1
>>
>>   zip.out ~> Sink.foreach[(ActorRef, Command)] {
>> case (ref, cmd) => ref ! cmd
>>   }
>>
>>   FlowShape(control.inlet, source.outlet)
>> }
>> ```
>>
>> Any ideas or comments?
>>
>>
>> пятница, 16 октября 2015 г., 11:48:27 UTC+6 пользователь Alexey Romanchuk
>> написал:
>>>
>>> Hey hAkkers!
>>>
>>> I need your advise in akka streams materialization question.
>>>
>>> I have custom protocol source `MySource` of type`Source[String,
>>> ActorRef]` which accepts messages to control protocol via ActorRef after
>>> materialization. Example of message is something like connect to server or
>>> change parameters of existing connection and so on.
>>>
>>> Creation of flow with this API is easy:
>>>
>>> ```
>>> val actor = MySource().to(Sink.ignore).run
>>> actor ! SomeCommand()
>>> ```
>>>
>>> Next, I have `Source[Command, Unit]` and I want to be able to connect it
>>> to `MySource`. So I need to lift `MySource` from source to `Flow`:
>>>
>>> ```
>>> val source: Source[String, ActorRef] = ???
>>>
>>> //some magic with custom stage or partial flow here and
>>> val controlledSource: Flow[Command, String, ActorRef] = ???
>>> ```
>>>
>>> I tried to do it with partial flow:
>>>
>>> ```
>>>   val flow = FlowGraph.partial() { implicit b =>
>>> import FlowGraph.Implicits._
>>> val mySource = MySource
>>> val commandsInput = Sink.foreach[Command](???) //I need ActorRef
>>> here :(
>>> FlowShape(b.add(commandsInput).inlet, b.add(mySource).outlet)
>>>   }
>>> ```
>>>
>>> but to connect commands with source I need result of materialization.
>>>
>>> Any ideas how to keep `Source[String, ActorRef]` and have `Flow[Command,
>>> String, ActorRef]`?
>>>
>> --
> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why is aroundReceive protected[akka]?

[Patrik Nordwall]

There is also the Receive Pipeline
http://doc.akka.io/docs/akka/2.4.0/contrib/receive-pipeline.html

/Patrik
mån 19 okt. 2015 kl. 00:33 skrev Konrad Malawski <
konrad.malaw...@typesafe.com>:

> Hi Jan!
>
> Yes, it's definitely one of those
>
> "Do not do this because you will most likely shoot yourself in the foot"?
>
> methods, and we believe it's much safer to keep it internal than to make
> it public, thus encouraging devs to use it (and end up in around-what-hell).
>
> We have used it very heavily in Akka Persistence and while with one level
> of inheritance it's still easy to wrap your head around it, it gets pretty
> hard once there's multiple traits involved.
>
>
> For application development I'd highly recommend either explicit function
> handling (chaining, or wrapping) or using child actors to perform other
> "additional work" that you might need to do.
>
>
> Hope this explains things :-)
> --
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Typesafe 
>
> --
> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.