Re: [akka-user][deprecated] How to test ReceiveTimeout in Akka typed

['Roland Kuhn' via Akka User List]

Hi Urs,

you can use isAlive 

 to check whether the behavior in the BehaviorTestKit has terminated or not. 
You’ll have to manually feed the actor the "terminated" message (making the 
test timing-independent as a bonus), then you can check for termination.

Regards,

Roland

> 2 jan. 2020 kl. 16:12 skrev Urs Peter :
> 
> Answering part of my own question: 
> 
> I figured out how to watch termination of a typed actor, relying on the 
> classic converters which requires the following import import 
> akka.actor.typed.scaladsl.adapter._:
> 
> "!!! terminate typed actor with ActorTestKit - that's how !!!" in {
>   import akka.actor.typed.scaladsl.adapter._
>   val actorTestKit = ActorTestKit()
>   implicit val classicActorSystem = actorTestKit.system.toClassic
>   val probe = TestProbe()
>   val timeout = actorTestKit.spawn(timeoutBehavior)
>   probe.watch(timeout.toClassic)
>   probe.expectTerminated(timeout.toClassic)
> }
> 
> I assume that's the way to go. If not please let me know. 
> 
> Concerning the BehaviorTestKit approach I would still look for an answer.
>  "??? terminate typed actor with BehaviorTestKit - but how ???" in {
>   val behaviorTestKit = BehaviorTestKit.create(timeoutBehavior)
>   //works ...
>   behaviorTestKit.expectEffect(ReceiveTimeoutSet(500 millis, 
> "terminated"))
>   //...but how to intercept the actual termination (-> Stopped) without 
> sending a message???
> 
> 
> }
> 
> 
> 
> -- 
> *
> ** New discussion forum: https://discuss.akka.io/ replacing akka-user 
> google-group soon.
> ** This group will soon be put into read-only mode, and replaced by 
> discuss.akka.io
> ** More details: 
> https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
> *
> >> 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/akka-user/936b3f29-1a25-42d3-85f5-e8a68179cfd9%40googlegroups.com.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/akka-user/6A374FA2-FF2A-4547-ACBF-AA3E17F24450%40rkuhn.info.

Re: [akka-user] Akka stream out of band data

['Roland Kuhn' via Akka User List]

Sent from my iPhone

> On 18. Feb 2018, at 11:53, Christopher Hunt  wrote:
> 
> 
> 
>> On 18 Feb 2018, at 21:10, Viktor Klang  wrote:
>> 
>> How do you deal with M:N ports or X:Y element permutations?
> 
> No idea. :-) My main question is, has there been any thinking around 
> associating metadata with elements in the past?

Yes, we considered it with varying depth on multiple occasions and never found 
a satisfactory solution. Since graph stages are free to transform not only 
individual elements but also the stream structure the conclusion was that the 
metadata cannot be hidden from the graph stage code, it must be explicitly 
foreseen. This will then also need to be reflected in the types. One idea was 
to create a DSL on top that offers certain well behaved combinators for tagged 
elements, but as far as I know this has not been implemented yet.

Regards,

Roland 

> Thanks. 
> 
> Cheers 
> C
> 
> -- 
>>> Read the docs: http://akka.io/docs/
>>> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Roland Kuhn]

Sent from my iPhone

> On 3. Feb 2018, at 07:25, Christopher Hunt <hunt...@gmail.com> wrote:
> 
> Hi Roland,
> 
>> On 3 Feb 2018, at 5:16 pm, Roland Kuhn <goo...@rkuhn.info> wrote:
>> 
>> could you elaborate on how exactly Akka Typed is expected to help with your 
>> use-case? The only difference I can see is that the new (and currently 
>> removed) implementation contained fewer extension points, but that is 
>> unrelated to whether ActorRef has a type parameter or not.
>> 
> Perhaps Akka Typed doesn’t/wouldn’t help. I only mention it because I feel 
> that the more strongly typed things are, the less use of reflection and other 
> dynamic behaviour there tends to be.

I agree on the tendency. In the case of Akka there are two reasons for using 
reflection and neither of them is caused by a lack of static types: 
extensibility and remote marshaling. A new implementation could remove 
configuration and skip serialization for the local case—in fact that was done 
in my approach. Perhaps reviving that would solve your issue.

Regards, Roland 

> 
> Cheers,
> -C
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Roland Kuhn]

Hi Christopher,

could you elaborate on how exactly Akka Typed is expected to help with your 
use-case? The only difference I can see is that the new (and currently removed) 
implementation contained fewer extension points, but that is unrelated to 
whether ActorRef has a type parameter or not.

Regards, Roland 

Sent from my iPhone

> On 3. Feb 2018, at 06:03, Christopher Hunt  wrote:
> 
> Thanks for the reply Konrad.
> 
> Although my use-case is somewhat forced by working with constrained device 
> memory and enterprise security, I think that there’s a broader concern. My 
> understanding is that the JVM is embracing ahead of time compilation and the 
> potential for dead code elimination during the linking phase. I would think 
> that most forms of reflection would be at odds to that. Shouldn’t Akka 
> therefore be re-considering its position on its use of reflection, and might 
> Akka Typed be a way forward in that regard?
> 
> Cheers,
> -C
> 
>> On 3 Feb 2018, at 3:43 pm, Konrad “ktoso” Malawski 
>>  wrote:
>> 
>> Hi Christopher,
>> I’ve worked in the past on an Scala on Android project, so have had the 
>> “pleasure” of battling proguard for similar reasons.
>> In general I guess the “core stuff” needs to be kept, which would mostly be 
>> the akka.actor and dungeon things.
>> 
>> AFAIR proguard is ale to understand references via “classOf” etc, so user 
>> land actors should be fine. Typed actors also should be nicer to proguard.
>> The only things we’d need to specifically exclude from removal is things 
>> that have classnames defined in configuration,
>> that’ll mostly e mailoxes, perhaps the remoting infra etc.
>> 
>> I guess it can be useful to have a config that is “known to work”, but I 
>> don’t think it is realistic to fully know that “this will work for 
>> everyone”, after all, you’re removing code.
>> If you want to provide the core set of excludes, that sounds useful. We in 
>> the time are unlikely to have the time to maintain or help much with this 
>> though.
>> 
>> -- 
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka @ Lightbend
>> 
>>> On February 3, 2018 at 13:31:35, Christopher Hunt (hunt...@gmail.com) wrote:
>>> 
>>> Hi everyone, 
>>> 
>>> I’ve got a requirement to run services on machines with limited resources, 
>>> memory in particular, but also disk (disk == memory for my use case!) In 
>>> addition, I wish to reduce the attack surface area of a service by 
>>> eliminating code that isn’t used. 
>>> 
>>> I’d therefore like to take a unikernal-style of approach to my services 
>>> which, of course, use Akka. Using Proguard on my service very quickly 
>>> revealed problems relating to Akka. From looking through past posts, it 
>>> seems that the use of Proguard has been a discussion relating to Android 
>>> (which also hasn’t helped me around the issues I’ve been having). 
>>> 
>>> Would there be any interest in seeing Akka become more suitable for dead 
>>> code elimination, particularly with the advent of Akka Typed? (reflection 
>>> and dead code elimination are at odds with each other) 
>>> 
>>> Having an official project declaration of what classes should be kept for 
>>> dead code elimination, and an integration build verifying this to a degree 
>>> is what I’m thinking. I’d be happy contribute a PR with a little help. 
>>> 
>>> Cheers  
>>> C 
>>> 
>>> --  
>>> >> Read the docs: http://akka.io/docs/ 
>>> >> Check the FAQ: 
>>> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
>>> >> Search the archives: https://groups.google.com/group/akka-user 
>>> ---  
>>> You received this message because you are subscribed to the Google Groups 
>>> "Akka User List" group. 
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to akka-user+unsubscr...@googlegroups.com. 
>>> To post to this group, send email to akka-user@googlegroups.com. 
>>> Visit this group at https://groups.google.com/group/akka-user. 
>>> For more options, visit https://groups.google.com/d/optout. 
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 

Re: [akka-user] Akka typed ask and Scheduler

[Roland Kuhn]

That would make it impossible to create an ActorRef without a system, which 
currently should work.

Sent from my iPhone

> On 31. Dec 2017, at 17:03, Patrik Nordwall  wrote:
> 
> Hi Tal,
> 
> I think it would be possible to grab the scheduler from internal impl, also 
> for Typed. Please create an issue.
> 
> /Patrik
>> sön 31 dec. 2017 kl. 13:01 skrev Tal Pressman :
>> Hi,
>> 
>> In "regular" untyped Akka, using `ask` only requires an implicit `Timeout` 
>> whereas the typed version also requires a `Scheduler`.
>> 
>> Other than the fact that this isn't mentioned in the documentation (and 
>> hidden away in `TypedSpec` in the test code), I wonder if it is really 
>> necessary - untyped `ask` gets around the issue by always using the system's 
>> scheduler, so why shouldn't the typed version do the same?
>> 
>> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Distributing lots of large messages to a cluster on startup issue.

[Roland Kuhn]

Yes, I meant an Akka HTTP server for this purpose: spin it up on the node where 
the map is created, can even be on a random port, and send the URL to this 
server around. That server can offer the last ten versions (or whatever), could 
use the hash of the preserialized map as identifier. That way you can 
explicitly manage the dissemination and its resource usage.

Regards,

Roland 

Sent from my iPhone

> On 30. Nov 2017, at 18:43, kraythe  wrote:
> 
> The issue here is that the matrices are recalculated quote frequently, every 
> minute is common so its not that it can be deployed to a static HTML server. 
> I suppose I could put an HTTP endpoint for server to server communication and 
> have that be outside of the Akka communication channels. Is that what you are 
> suggesting? I would have to know which node to send the http request to of 
> course and make sure the nodes can talk to each other directly without using 
> the load balancer. 
> 
> -- Robert
> 
>> On Thursday, November 30, 2017 at 9:15:03 AM UTC-6, rkuhn wrote:
>> May I suggest serving the large blobs via a different mechanisms like HTTP? 
>> Sending around URL (and putting them inside events) seems much better than 
>> putting the data bytes all over the place.
>> 
>> Regards,
>> 
>> Roland
>> 
>>> 30 nov. 2017 kl. 16:11 skrev Patrik Nordwall :
>>> 
>>> Sending 10 MB messages is indeed recipie for trouble. 
>>> 
>>> I’d suggest to split the 10 MB into 100 smaller messages and collect, 
>>> reassembe, them on the receiving side.
>>> 
>>> Perhaps you are fine with loosing such messages since they are periodically 
>>> published again. Otherwise you could use DistributedData to share them.
>>> 
>>> /Patrik
 tors 30 nov. 2017 kl. 14:35 skrev kraythe :
 Greetings, 
 
 We have an actor structure where there is a cluster sharded actor that 
 calculates a parametric matrix of about 7 meg and has to distribute it to 
 5 other nodes for consumption. First of all there are the following 
 constraints. 
 
 1. The matrix has to be generated in one place.
 2. The matrix is needed on all nodes to handle user load. 
 3. The matrix will be periodically generated again to handle changing 
 variables and then sent off to all nodes to handle user load. 
 4. Saving the matrix in a database is probably not viable as it merely 
 shifts the networking load and the database would get very large very 
 fast. The Database only saves the input params. 
 
 We changed the akka max message size to 10 meg to accomplish this but that 
 feels a bit odd, but we didn't see another choice. Normally this works 
 fine even though passing 10 meg messages around a DistributedPubSub seems 
 odd to me. However on startup the system has to stat up 2000 of these all 
 at once. As a result the sharding coordinators scream at us about buffered 
 messages. It eventually calms down and life resumes but I would love to be 
 able to do this without the bloodbath in the logs. 
 
 Can someone recommend an alternative strategy for handling the 
 distribution of the parametric matrix that gets it to every node but 
 doesn't cause shard coordinator complaint bloodbath? 
 
 Thanks in advance. 
 Robert SImmons Jr. MSc.
 
 -- 
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ: 
 >> http://doc.akka.io/docs/akka/current/additional/faq.html
 >> Search the archives: https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to the Google Groups 
 "Akka User List" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to akka-user+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at https://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> 
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 

Re: [akka-user] Distributing lots of large messages to a cluster on startup issue.

[Roland Kuhn]

May I suggest serving the large blobs via a different mechanisms like HTTP? 
Sending around URL (and putting them inside events) seems much better than 
putting the data bytes all over the place.

Regards,

Roland

> 30 nov. 2017 kl. 16:11 skrev Patrik Nordwall :
> 
> Sending 10 MB messages is indeed recipie for trouble. 
> 
> I’d suggest to split the 10 MB into 100 smaller messages and collect, 
> reassembe, them on the receiving side.
> 
> Perhaps you are fine with loosing such messages since they are periodically 
> published again. Otherwise you could use DistributedData to share them.
> 
> /Patrik
> tors 30 nov. 2017 kl. 14:35 skrev kraythe  >:
> Greetings, 
> 
> We have an actor structure where there is a cluster sharded actor that 
> calculates a parametric matrix of about 7 meg and has to distribute it to 5 
> other nodes for consumption. First of all there are the following 
> constraints. 
> 
> 1. The matrix has to be generated in one place.
> 2. The matrix is needed on all nodes to handle user load. 
> 3. The matrix will be periodically generated again to handle changing 
> variables and then sent off to all nodes to handle user load. 
> 4. Saving the matrix in a database is probably not viable as it merely shifts 
> the networking load and the database would get very large very fast. The 
> Database only saves the input params. 
> 
> We changed the akka max message size to 10 meg to accomplish this but that 
> feels a bit odd, but we didn't see another choice. Normally this works fine 
> even though passing 10 meg messages around a DistributedPubSub seems odd to 
> me. However on startup the system has to stat up 2000 of these all at once. 
> As a result the sharding coordinators scream at us about buffered messages. 
> It eventually calms down and life resumes but I would love to be able to do 
> this without the bloodbath in the logs. 
> 
> Can someone recommend an alternative strategy for handling the distribution 
> of the parametric matrix that gets it to every node but doesn't cause shard 
> coordinator complaint bloodbath? 
> 
> Thanks in advance. 
> Robert SImmons Jr. MSc.
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Android client connecting to Akka cluster via sockets

[Roland Kuhn]

Hi Tom,

the core feature of Akka Cluster is location transparency: all Actors within 
the cluster can seamlessly communicate via their ActorRefs. Including something 
that is not really part of the cluster, or that can at least not fully 
participate in the location transparent setting, will likely lead to impedance 
mismatch down the road—and quite possibly some pain and suffering.

Why don’t you communicate between your Android device and some cluster members 
using an established protocol suite like HTTP? That way you will not have 
trouble telling different kinds of ActorRefs apart regarding their semantic 
limitations.

Regards,

Roland

Skickat från min iPad

> 15 nov. 2017 kl. 18:50 skrev Tomasz Ratajczak :
> 
> Hi,
> 
> how difficult would it be to develop socket based Android client for Akka 
> cluster without the Akka client libraries? I would like to have the 
> flexibility of Android network libraries and the power of Akka cluster 
> without going into the incompatibilities of Akka Java and Android Java. Do 
> not see a need for actors on Android device, only need for interaction with 
> the cluster actors.
> 
> This basically would involve reversing the Akka remote protocol and as such 
> may be a maintenance nightmare. Can this be done though?
> 
> It seems to me that frontending the Akka cluster with a custom, stateless 
> proxy that would act as a cluster client would be a much better alternative.
> 
> Thank you,
> Tom
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Roland Kuhn]

You could try to decrease your thread pool size to 1 to exclude wakeup 
latencies when things (like CPU cores) have gone to sleep.

Regards, Roland 

Sent from my iPhone

> On 23. Oct 2017, at 22:49, Gary Malouf  wrote:
> 
> Yes, it gets parsed using entity(as[]) with spray-json support.  Under a load 
> test of say 1000 requests/second these latencies are not visible in the 
> percentiles - they are easy to see because this web server is getting 10-20 
> requests/second currently.  Trying to brainstorm if a dispatcher needed to be 
> tuned or something of that sort but have yet to see evidence supporting that.
> 
> path("foos") {
> traceName("FooSelection") {
> 
> entity(as[ExternalPageRequest]) { pr =>
> val spr = toSelectionPageRequest(pr)
> shouldTracePageId(spr.pageId).fold(
> Tracer.currentContext.withNewSegment(s"Page-${pr.pageId}", "PageTrace", 
> "kamon") {
> processPageRequestAndComplete(pr, spr)
> },
> processPageRequestAndComplete(pr, spr)
> )
> }
> }
> 
> }
> 
>> On Mon, Oct 23, 2017 at 4:42 PM, Viktor Klang  wrote:
>> And you consume the entityBytes I presume?
>> 
>>> On Mon, Oct 23, 2017 at 10:35 PM, Gary Malouf  wrote:
>>> It is from when I start the Kamon trace (just inside of my 
>>> path("myawesomepath") declaration until (theoretically) a 'complete' call 
>>> is made.  
>>> 
>>> path("myawesomepath") {
>>>   traceName("CoolStory") {
>>> ///do some stuff
>>>  complete("This is great")
>>> } }
>>> 
>>> For what it's worth, this route is a 'POST' call.
>>> 
 On Mon, Oct 23, 2017 at 4:30 PM, Viktor Klang  
 wrote:
 No, I mean, is it from first-byte-received to last-byte-sent or what?
 
> On Mon, Oct 23, 2017 at 10:22 PM, Gary Malouf  
> wrote:
> We are using percentiles computed via Kamon 0.6.8.  In a very low request 
> rate environment like this, it takes roughly 1 super slow request/second 
> to throw off the percentiles (which is what I think is happening).  
> 
> 
> 
>> On Mon, Oct 23, 2017 at 4:20 PM, Viktor Klang  
>> wrote:
>> What definition of latency are you using? (i.e. how is it derived)
>> 
>>> On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf  
>>> wrote:
>>> Hi Konrad,
>>> 
>>> Our real issue is that we can not reproduce the results.  The web 
>>> server we are having latency issues with is under peak load of 10-15 
>>> requests/second - obviously not much to deal with.  
>>> 
>>> When we use load tests (https://github.com/apigee/apib), it's easy for 
>>> us to throw a few thousand requests/second at it and get latencies in 
>>> the ~ 3 ms range.  We use kamon to track internal metrics - what we see 
>>> is that our 95th and 99th percentiles only look bad under the 
>>> production traffic but not under load tests.  
>>> 
>>> I've since used kamon to print out the actual requests trying to find 
>>> any pattern in them to hint at what's wrong in my own code, but they 
>>> seem to be completely random.  What we do know is that downgrading to 
>>> spray gets us 99.9th percentile latencies under 2ms, so something 
>>> related to the upgrade is allowing this.
>>> 
>>> Thanks,
>>> 
>>> Gary
>>> 
 On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski 
 wrote:
 Step 1 – don’t panic ;-)
 Step 2 – as I already asked for, please share actual details of the 
 benchmarks. It is not good to discuss benchmarks without any insight 
 into what / how exactly you’re measuring.
 
 -- 
 Cheers,
 Konrad 'ktoso' Malawski
 Akka @ Lightbend
 
> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com) 
> wrote:
> 
> We have a web service that we just finished migrating from spray 1.3 
> to Akka-Http 10.0.9.  While in most cases it is performing well, we 
> are seeing terrible 99th percentile latencies 300-450ms range) 
> starting from a very low request rate (10/second) on an ec2 m3.large. 
>  
> 
> Our service does not do anything complicated - it does a few Map 
> lookups and returns a response to a request.  In spray, even 99th 
> percentile latencies were on the order of 1-3 ms, so we are 
> definitely concerned.  Connections as with many pixel-type servers 
> are short-lived -> we actually pass the Connection: Close header 
> intentionally in our responses.  
> 
> Is there any obvious tuning that should be done on the server 
> configuration that others have found?
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> 

Re: [akka-user] Re: Understanding tuning akka dispatchers (by Jami allan)

[Roland Kuhn]

Sorry for the long delay. Jamie’s advice combines two concerns, one has been 
explained by Rob, the other is that routers have historically been severely 
overused—they serve a very specific need that does not arise frequently.

Regards, Roland 

Sent from my iPhone

> On 19. Oct 2017, at 17:21, AL <123...@gmail.com> wrote:
> 
> don't know really. I take my words back :)  what you wrote makes perfect 
> sense. thanks
> 
>> On Wednesday, October 18, 2017 at 8:25:42 PM UTC+3, Rob Crawford wrote:
>> What do you believe he meant?
>> 
>>> On Wednesday, October 18, 2017 at 11:09:45 AM UTC-4, AL wrote:
>>> Thanks, 
>>> The scala API is different. but I am not sure that this is what he meant
>>> 
>>>> On Tuesday, October 17, 2017 at 4:34:17 PM UTC+3, Rob Crawford wrote:
>>>> With the Java API, something like this:
>>>> 
>>>> public class ComputeIntensiveChild extends AbstactActor {
>>>> private final ActorRef realParent;
>>>> 
>>>> public static Props create(ActorRef realParent) {
>>>> return Props.create(ComputeIntensiveChild.class, realParent);
>>>> }
>>>> 
>>>> public ComputeIntensiveChild(ActorRef realParent) {
>>>> this.realParent = realParent;
>>>> }
>>>> 
>>>> public Receive createReceive() {
>>>> ...
>>>> }
>>>> 
>>>> }
>>>> 
>>>> This way you send the answer to realParent instead of 
>>>> getContext().getParent(). Even if there's a router between the child and 
>>>> realParent, the intended recipient gets the message.
>>>> 
>>>> BUT I'm not sure this isn't a premature optimization. Since there's a 
>>>> possibility of a router in the mix, that means the child is sending a 
>>>> response to a message it received. In that case, just 
>>>> send the response to the sender -- routers always forward messages, 
>>>> preserving the original sender. 
>>>> 
>>>>> On Sunday, October 15, 2017 at 10:50:43 AM UTC-4, AL wrote:
>>>>> Reading tuning akka dispatchers article by Jami allan. he writes:
>>>>> 
>>>>> If you suspect you will need to use a Router somewhere, Akka Team Lead 
>>>>> Roland Kuhn recommends that you pass around actor references from 
>>>>> supervisors to compute-intensive children so that the ‘context.parent’ of 
>>>>> their children are free to become a router later on with minimal impact. 
>>>>> But do not create Routers before you have proven at runtime under load 
>>>>> that you absolutely need to.
>>>>> 
>>>>> can anyone elaborate on that with a simple example ? 
>>>>> 
>>>>> Thanks in advance
>>>>> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[Roland Kuhn]

Another way of putting this is that given enough time any cluster of size N 
with auto-down will eventually end up as N single-node clusters. It is thus not 
a sustainable strategy unless you invest the manpower to constantly manually 
rebuild the cluster.

Regards, Roland 

Sent from my iPhone

> On 30. Aug 2017, at 18:25, Justin du coeur  wrote:
> 
>> On Wed, Aug 30, 2017 at 11:24 AM, Igor Baltiyskiy  wrote:
>> I'd like to clarify the warning given in the documentation:
>> 
>> > We recommend against using the auto-down feature of Akka Cluster in 
>> > production. This is crucial for correct behavior if you use Cluster 
>> > Singleton or Cluster Sharding, especially together with Akka Persistence. 
>> > For Akka Persistence with Cluster Sharding it can result in corrupt data 
>> > in case of network partitions.
>> (http://doc.akka.io/docs/akka/2.5/scala/cluster-usage.html#auto-downing-do-not-use-)
>> 
>> This passage raises several questions:
>> 
>> 1. Does it mean that auto-downing is always a bad idea? Or is it only a bad 
>> idea when using Cluster Singleton and Cluster Sharding, so that if I'm not 
>> using them, using auto-downing in production is perfectly fine?
> 
> It's a more or less *guaranteed* disaster in the long run with Cluster 
> Sharding; it's only a *likely* disaster without, depending on what your app 
> is doing.  But personally, I think it should never, ever be used.
> 
> Look at it this way: the problem with auto-down is that it is likely, in the 
> long run, that you will eventually wind up in a Split Brain situation, with 
> two or more disconnected clusters, each of which thinks that it is The One 
> True Cluster and Source of Truth.  This will usually happen in a realistic 
> network, due to the vagaries of network traffic and the fundamental dumbness 
> of the auto-down algorithm.
> 
> Now, ask yourself: if this is acceptable -- if it is okay to sometimes *not* 
> be a Cluster -- why are you using Clustering at all?
> 
> Basically, if your nodes need to be able to share information in a consistent 
> way, you need Clustering, which means that Split-Brain is deadly, which means 
> that you must not use auto-down.  If the nodes *don't* need to be sharing 
> information, you probably shouldn't be bothering with Clustering at all, so 
> auto-down is irrelevant.
> 
> That's the heart of the argument, and why I personally think auto-down should 
> be simply excised from the library entirely: it is *never* safe to use in 
> anything more than a toy environment, and its existence just confuses 
> people...
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] My initial impressions of akka.typed design.

[Roland Kuhn]

Hi Sean,

removing the self-type would not help: its function is only to ensure that 
every ActorRef also has an appropriate implementation, basically proving that 
the down-cast that is used in many places in the implementation will work out 
fine. In the end every ActorRef needs to support the sendSystem method (not 
equally sure about isLocal, due to missing remoting implementation).

Patrik & team: what is your opinion on this? Should sendSystem become visible 
in order to make ActorRef implementable by user code? In any case we should 
probably prominently point out that suitable stubs for ActorRef and 
ActorContext are provided in the form of Inbox and EffectfulActorContext, and 
that rolling your own is typically not necessary.

On stubbing out ActorSystem or making it easier to override, I have mixed 
feelings: it is a quite complicated machine that is not easy to modify 
correctly—and it is also not easy to provide a stub that actually works, due to 
some semantic requirements. I completely understand that just counting calls to 
terminate() may seem to contradict my statement, but consider the other side of 
the coin: if ActorSystem were as you want it, then people would modify it also 
in cases where that is not appropriate.

To answer your concrete question, a much easier way of ensuring correct 
shutdown would be to supply a function of type () => Unit to the actor that 
shall call it. Production code would supply () => system.terminate(), but the 
test could provide whatever you want.

Regards,

Roland

> 25 aug. 2017 kl. 04:01 skrev Sean Shubin :
> 
> I had a chance to look over the typed actors a bit more.  Here is my 
> feedback.  Whether you agree or disagree, I hope you find it useful.  I am 
> still really excited about typed actors, the main reason I have been 
> reluctant to switch to akka is that I was not willing to give up static 
> typing.  
> 
> Behavior by itself is easy to test as long as you are not doing anything with 
> ActorContext.  I particularly like the separation of the management method to 
> deal with lifecycle signals, from the message method to deal with messages.
> 
> ActorContext can't be stubbed out because it leaks out the private classes 
> InternalActorRef and ActorSystemImpl through its protected methods 
> lookupRoot, guardian, and systemImpl.
> 
> ActorRef can't be stubbed out because of the self type on 
> internal.ActorRefImpl.  I have already demonstrated issue with this in detail 
> with my FooApp and BarApp examples in this thread.  I did look up the 
> ScalaDoc for ActorRefImpl, and while I think its fine to hide the sendSystem 
> and isLocal methods, I do think that if these methods were pushed down into a 
> class that inherits from ActorRef, rather than using a self type, that would 
> make it easier to stub out ActorRef.
> 
> ActorSystem has the same problem as ActorRef for the same reason, but it 
> manifests much worse because the ActorSystem trait has so many more methods.  
> To see why, consider writing a unit test to make sure an actor system is 
> properly shut down once the program is finished.  I want to test the code 
> here:
> https://github.com/SeanShubin/concurrency-samples/blob/master/actor/src/main/scala/com/seanshubin/concurrency/samples/actor/CleanupActorSystems.scala
> It should be as easy as this:
> https://github.com/SeanShubin/concurrency-samples/blob/master/actor/src/test/scala/com/seanshubin/concurrency/samples/actor/CleanupActorSystemsTest.scala
> And from looking at this test it seems like it is, but look what I had to do 
> to get to this point:
> On my dependency injection class I had to add another level of indirection
>   val eventActorSystem: ActorSystem[Event] = ActorSystem("state", stateful)
>   val eventActorSystemContract: ActorSystemContract[Event] = 
> new ActorSystemDelegate[Event](eventActorSystem)
> I had to hide ActorSystem behind an interface
> https://github.com/SeanShubin/concurrency-samples/blob/master/actor/src/main/scala/com/seanshubin/concurrency/samples/actor/ActorSystemContract.scala
> And then delegate to the real ActorSystem
> https://github.com/SeanShubin/concurrency-samples/blob/master/actor/src/main/scala/com/seanshubin/concurrency/samples/actor/ActorSystemDelegate.scala
> That way, for testing I could start with a class where nothing is implemented:
> https://github.com/SeanShubin/concurrency-samples/blob/master/actor/src/test/scala/com/seanshubin/concurrency/samples/actor/ActorSystemNotImplemented.scala
> Then use that not implemented class as a base for my stub
>   class ActorSystemStub extends ActorSystemNotImplemented[Event] {
> var terminateInvocationCount = 0
> 
> override def terminate(): Future[Terminated] = {
>   terminateInvocationCount += 1
>   null
> }
>   }
> Which I finally use in my test
> 

Re: [akka-user] [Akka-typed] How to test message protocol between two typed actors?

[Roland Kuhn]

Since it is Actor-2 that is violating its contract, why don’t you write a test 
that inspects the response of Actor-2 to a Restart message? Sending to `self` 
is tracked by EffectfulActorContext and Actor-1’s role would be stubbed by an 
Inbox that you can inspect as well. The post condition should be that `self` 
gets the Initialize but nothing else, and that the Inbox (for Actor-1) gets the 
Initialized but nothing else.

Then another test verifies the reaction of Actor-1 to the Initialized, ensuring 
that `Run` is sent to the Inbox standing in for Actor-2.

There is no need to write any asynchronous test for these cases. Asynchronous 
tests are only necessary to find holes in the individual actors’ contracts, 
i.e. if step 2.3 was a spec bug then a test with real actors and scalatest’s 
async test support would find it (assuming that double-Run leads to observable 
errors—if not, then why do you care?).

Regards,

Roland

> 18 aug. 2017 kl. 07:56 skrev kpri...@thoughtworks.com:
> 
> I am trying to test following scenario which has a bug in the code but I am 
> not able to write automated test for this!!
> 
> 1. Actor-1 sends a 'Restart' message to Actor-2 (Note that the restart is 
> business specific message and not actor restart)
> 2. Actor-2 does three things => 2.1: Sends 'Initialize' message to self
> 2.2: Sends 'Initialized' message to Actor-1
> 2.3: Sends 'Run' message to self
> 3. Actor-1 receives 'Initialized' message from Actor-2 and sends 'Run' 
> message to Actor-2
> 
> As you can notice the bug here, Actor-2 is sending 'Run' message to self as 
> well as Actor-1 is sending 'Run' message to Actor-2.
> 
> Both EffectfulActorContex and StubbedActorContext does not support two way 
> communication between actors.
> And there is no way, I can assert on which Message received by Actor without 
> using testkit.
> 
> I can see there is a issue opened 4 months back for asynchronous testing of 
> actors. (testkit for asynchronous testing #22764)
> 
> Meanwhile is there any way to test the scenario which i just described above?
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] My initial impressions of akka.typed design.

[Roland Kuhn]

Hi Sean,

thanks for discussing Akka Typed!

The design decision behind splitting the interface into a public and a private 
part is documented in the ScalaDoc for ActorRefImpl: end users shall not ever 
see the top two methods because there cannot possibly be a reason to use 
them—but the implementation will need them. Therefore I felt that internals are 
leaked by having just one interface. Another (minor) issue is that equality and 
toString are fixed by the semantics of the interface and the self-type ensures 
that this contract is not broken.

Thankfully, the whole design of Akka Typed is much different from untyped Akka, 
where this kind of separation was forced by implementation details. In Akka 
Typed we are free to fold ActorRefImpl into ActorRef and revert the decision. 
We should then make ActorRef an abstract class, so that it can also safely be 
used from Java without losing the semantic contract. The downside would remain: 
exposing methods that don’t belong into user space.

May I ask in how far your intended ActorRef implementation would be different 
from TestProbe or Inbox? Since there is only a single purpose to 
ActorRef—sending single messages—we should be able to include all needed stub 
functionality in one implementation; my guess is that your fake/stub/mock would 
reimplement what is already there but I may well be missing something.

Another point that I’d like to hear more about is how you intend to test your 
behaviors in general. This question stems from some surprise at hearing “hard 
to test” in conjunction with Akka Typed :-) (given that testability is an 
explicit design goal)

Regards,

Roland

> 16 aug. 2017 kl. 21:05 skrev Sean Shubin :
> 
> ActorRef has a self type of ActorRefImpl.  This means that if I want to 
> fake/stub/mock an ActorRef for test purposes, I cannot because I am forced to 
> know about ActorRefImpl.  Instead of users of ActorRef being forced to only 
> use the ActorRefImpl implementation, ActorRef should be a minimal interface 
> that only exposes the essential characteristics of an ActorRef, freeing up 
> users to chose among implementations of ActorRef, including fakes/stubs/mocks 
> for testing, and an ActorRefImpl for production.  As it is designed now, I 
> don't see how one can easily test akka.typed code without specialized 
> libraries that know about ActorRefImpl.
> 
> I find that hard to test code is usually a result of design decisions rather 
> than the inherent nature of the problem, and with careful attention and 
> imagination one can make code easy to test without having to use a 
> specialized library.
> 
> I am just starting to learn akka typed, so hopefully I will have time to give 
> more detailed feedback than just the one example once I am more familiar with 
> the design.  I am hoping that before removing the warning about how the 
> akka.typed API and semantics may change, the design is refactored to support 
> a more test driven, design by contract approach.  I love the idea of having a 
> statically typed, event driven option for how I code, so am really glad 
> akka.typed is being worked on.
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka HTTP usage of HttpEntity.toStrict

[Roland Kuhn]

Hi Yannik,

if your logging facility were capable of streaming then you could also avoid 
the double materialization issue using the .alsoTo combinator: you send the 
bytes to the logger while processing them in your business logic. This is also 
beneficial if the logger compacts the data, reducing peak memory usage.

Regards,

Roland 

Sent from my iPhone

> On 16. Aug 2017, at 11:50, Yannick Lazzari  wrote:
> 
> Thanks for confirming. It's just that with the way you said it on the ticket, 
> calling the usage of toStrict a "workaround", you made it sound like even if 
> toStrict was in the API, all its uses were kind of wrong and workarounds for 
> a "proper" and "streaming" way to consume the entity body more than once. 
> Then I started wondering if you hadn't come up with a better alternative. 
> Couldn't figure out how without loading all of the entity content into 
> memory, but who knows what tricks you could have come up with!
> 
> Thanks for the reply!
> 
>> On Tuesday, August 15, 2017 at 11:46:19 AM UTC-4, johannes...@lightbend.com 
>> wrote:
>> Hi Yannick,
>> 
>> if you want to log the complete request contents, then there is no other way 
>> than to collect anything into memory (actually, that's a consequence of 
>> logging, not of the API).
>> 
>> In that case, you can use toStrict method or the toStrictEntity directive at 
>> the root of your routing tree to make sure you load the whole contents into 
>> memory and use it from different places.
>> 
>> Johannes
>> 
>>> On Monday, August 14, 2017 at 7:48:54 PM UTC+2, Yannick Lazzari wrote:
>>> Hi,
>>> 
>>> There is an opened ticket in akka-http regarding exceptions being thrown 
>>> after using HttpEntity.toStrict: 
>>> https://github.com/akka/akka-http/issues/1177.
>>> 
>>> My question is regarding Johannes Rudolph's comment about it being a 
>>> workaround:
>>> 
 Using toStrictEntity is basically only a workaround and not a solution 
 because it will mean that all entity data will be buffered in memory which 
 means that your server will need more memory per concurrent request than 
 necessary.
>>> 
>>> Let's say you have the need to log the complete request payload of all 
>>> requests coming in to a service. If you want to allow the logging logic to 
>>> fully consume to request payload and still allow the entity to be 
>>> unmarshalled to the desired object later on, what would be another way to 
>>> ensure this never fails other than using toStrict, forcing the entire 
>>> payload into memory and allowing it to be consumed more than once?
>>> 
>>> For example, consider the following route:
>>> 
>>> val route = extractExecutionContext & extractMaterializer & extractLog { 
>>> (ec, mat, log) =>
>>>   logRequest(LoggingMagnet(_ => logRequestDetails(_)(ec, mat, log))) {
>>> path("someapi") {
>>>   post {
>>> entity(as[SomeInputClass]) { input =>
>>>   // do something with input
>>> }
>>>   }
>>> } 
>>>   }
>>> }
>>> 
>>> def logRequestDetails(req: HttpRequest)(implicit ec: ExecutionContext, 
>>> materializer: Materializer, log: LoggingAdapter): Unit =
>>>   Unmarshal(req.entity).to[String].map(b => s"The request body is 
>>> $b").onComplete {
>>> case Success(s) => log.info(s)
>>> case Failure(e) => log.error(e, "Error")
>>>   }
>>> 
>>> 
>>> This is obviously a contrived example, but this logs the request body. It 
>>> works, but we've seen such a pattern inconsistently yield 
>>> java.lang.IllegalStateException: Substream Source cannot be materialized 
>>> more than once errors. Isn't this a case where converting to a strict 
>>> entity the correct way to address such problems, i.e. allow the request 
>>> entity to be consumed more than once? If not, what would be the correct way?
>>> 
>>> Thanks for any insight you might have!
>>> 
>>> Yannick
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [akka-user] Akka Typed API discussion

[Roland Kuhn]

There already is ExtensibleBehavior, does that not provide you with all the 
access and tools you need?

> 18 juli 2017 kl. 13:53 skrev Bryan Murphy :
> 
> I mostly agree with you and the NamedStateBehavior may only be useful when 
> you have well defined state transitions (low change frequency) or not useful 
> at all but the point is it I could write it and decide if it was useful if 
> Behavour supported being extensible.  I can't see how I could do that with 
> the current implementation.  Tomorow I might come up with another idea like 
> having a behaviour that acted as a cache for another behavior or ...
> 
> On Tuesday, 18 July 2017 21:40:07 UTC+10, rkuhn wrote:
> Hi Bryan,
> 
> thanks for articulating your points! Regarding the first one I’d like to 
> widen the scope of the discussion: is it useful to access the private state 
> of a state machine for testing purposes? I know that I am guilty of creating 
> the akka-testkit nearly seven years ago, allowing precisely that. My own 
> experience and understanding has evolved since then, and it will likely 
> continue evolving in the future, so take my learnings with a grain of salt.
> 
> My current take on this topic is that tests that access the internal state of 
> a state machine (or any kind of component) tend to be too closely coupled to 
> the implementation, to the point of becoming useless. The latter shows when 
> noticing that every change of the implementation requires a matching change 
> to the test suite—but what good is a test suite that just echoes all changes, 
> including the buggy ones? My preference is to formulate tests on the level of 
> expected and externally observable behavior, this has a greater chance of 
> remaining constant across feature additions, refactorings, etc.
> 
> This is the reason why the focus for Akka Typed tests has been placed on 
> synchronous evaluation with effect capturing, meaning that responses to 
> external stimulus can be observed in a deterministic and efficient fashion. 
> The example of the chat room client list would best be tested by adding 
> clients and then sending a message, followed by checking that all clients 
> (“mocked” by using debugging ActorRefs that just collect incoming messages) 
> received the chatroom communication. This validates a core feature of the 
> chatroom without depending on assumptions regarding the implementation.
> 
> Regards,
> 
> Roland
> 
>> 18 juli 2017 kl. 11:44 skrev Bryan Murphy murphynet.id.au 
>> >:
>> 
>> OK,  I will start it here.  The main thing is get the comments and ideas in 
>> front of the Akka developers - if it is has merit you can run with it.
>> 
>> Overall I like the direction of AkkaTyped but there are a couple of use 
>> cases that I would like to see that seem not supported by the current 
>> implementation (but have become possible with the separation of Behaviour 
>> and Actor).
>> 
>> Behaviours are like state machines so when testing I would like to send a 
>> message to the behaviour and then verify the resultant behaviour is what I 
>> expect.  Ideally a behaviour would have a name (or an identifier with a  
>> generic Identifier type if we want to be more general) and some state data 
>> that we could look at (eg often we keep the same behavior but the internal 
>> state data has been updated eg sessions in the Chat Room example).  The 
>> current approach makes the state data opaque because the state become 
>> parameters to a function that creates the behavior so the state is hidden in 
>> the closure.  In fact the whole Behaviour is opaque (you can only make 
>> behaviors using the provided factory functions because the interpretation of 
>> behaviors has leaked into every Behavior implementation so it would be 
>> unsafe for users to create their own Behaviors) making it impossible to 
>> extend Behavior to add a name or add State data.  For name we could perhaps 
>> override toString but that feels like a hack.
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> 

Re: [akka-user] Akka Typed API discussion

[Roland Kuhn]

Hi Bryan,

thanks for articulating your points! Regarding the first one I’d like to widen 
the scope of the discussion: is it useful to access the private state of a 
state machine for testing purposes? I know that I am guilty of creating the 
akka-testkit nearly seven years ago, allowing precisely that. My own experience 
and understanding has evolved since then, and it will likely continue evolving 
in the future, so take my learnings with a grain of salt.

My current take on this topic is that tests that access the internal state of a 
state machine (or any kind of component) tend to be too closely coupled to the 
implementation, to the point of becoming useless. The latter shows when 
noticing that every change of the implementation requires a matching change to 
the test suite—but what good is a test suite that just echoes all changes, 
including the buggy ones? My preference is to formulate tests on the level of 
expected and externally observable behavior, this has a greater chance of 
remaining constant across feature additions, refactorings, etc.

This is the reason why the focus for Akka Typed tests has been placed on 
synchronous evaluation with effect capturing, meaning that responses to 
external stimulus can be observed in a deterministic and efficient fashion. The 
example of the chat room client list would best be tested by adding clients and 
then sending a message, followed by checking that all clients (“mocked” by 
using debugging ActorRefs that just collect incoming messages) received the 
chatroom communication. This validates a core feature of the chatroom without 
depending on assumptions regarding the implementation.

Regards,

Roland

> 18 juli 2017 kl. 11:44 skrev Bryan Murphy :
> 
> OK,  I will start it here.  The main thing is get the comments and ideas in 
> front of the Akka developers - if it is has merit you can run with it.
> 
> Overall I like the direction of AkkaTyped but there are a couple of use cases 
> that I would like to see that seem not supported by the current 
> implementation (but have become possible with the separation of Behaviour and 
> Actor).
> 
> Behaviours are like state machines so when testing I would like to send a 
> message to the behaviour and then verify the resultant behaviour is what I 
> expect.  Ideally a behaviour would have a name (or an identifier with a  
> generic Identifier type if we want to be more general) and some state data 
> that we could look at (eg often we keep the same behavior but the internal 
> state data has been updated eg sessions in the Chat Room example).  The 
> current approach makes the state data opaque because the state become 
> parameters to a function that creates the behavior so the state is hidden in 
> the closure.  In fact the whole Behaviour is opaque (you can only make 
> behaviors using the provided factory functions because the interpretation of 
> behaviors has leaked into every Behavior implementation so it would be unsafe 
> for users to create their own Behaviors) making it impossible to extend 
> Behavior to add a name or add State data.  For name we could perhaps override 
> toString but that feels like a hack.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Strange java.lang.VerifyError with ActorSystem initialization

[Roland Kuhn]

Just a thought: are you using the Scala distribution’s runner to run the 
application? There were versions that added an old version of Akka to the 
bootclasspath.

Regards,

Roland

> 20 juni 2017 kl. 14:28 skrev Matlik :
> 
> I find it strange that it would be Akka, but this does appear to only impact 
> the Akka/Scala code in my project.  It is effectively a Java application that 
> wraps the Akka/Scala functionality for part of it.  The plain Java 
> functionality appears to be unaffected by this bug.
> 
> I was hoping someone who understands this stack trace output might be able to 
> shed some light on what exactly it means.  I've been working with the JVM for 
> over 15 years and have never before seen this output.  My inclination is to 
> think I've somehow got a different and incompatible version of a lib being 
> used at runtime than what is used at compile time, but I've been unsuccessful 
> at identifying anything like that with Akka's JARs in my build.  Is there 
> enough information to poinpoint exactly what the disconnect is?  
> 
> On Tuesday, June 20, 2017 at 3:04:40 AM UTC-4, Konrad Malawski wrote:
> It’s rather unlikely that Akka itself is at fault here.
> You could try using the latest version of the lib etc, however I don’t think 
> that’s it…
> Do other java apps work in your env (are you sure it’s not weird / broken)?
> 
> 
> On June 19, 2017 at 10:36:34 PM, Matlik (james@gmail.com ) 
> wrote:
> 
>> I'm encountering this issue which I've never seen before, and was wondering 
>> if someone could point me in the right direction.  I have some Akka streams 
>> 2.4.10 code (with Scala 2.11.8) that is embedded into a GlassFish 4.0 server 
>> running Oracle Java 1.8.0_131-b11.  All this is wrapped into a Docker 
>> container for deployment that uses the Ubuntu as the base image. Things were 
>> all working great for a while, but something appears to have changed that is 
>> causing us some grief.  
>> 
>> The docker image is built with the latest Oracle Java 8 JDK and base OS 
>> (Ubuntu 14.04).  When we needed to rebuild the image with a minor 
>> configuration change, we are now consistently getting the following error:
>> 
>>  [#|2017-06-19T19:15:09.770+|WARNING|glassfish 
>> 4.0|javax.enterprise.web|_ThreadID=45;_ThreadName=http-listener-1(1);_TimeMillis=1497899709770;_LevelValue=900;|
>>StandardWrapperValve[TimeSeriesServlet]: Servlet.service() for servlet 
>> TimeSeriesServlet threw exception
>>  java.lang.VerifyError: Stack map does not match the one at exception 
>> handler 98
>>  Exception Details:
>>Location:
>>  akka/dispatch/Envelope.(Ljava/lang/Object;Lakka/actor/ActorRef;)V 
>> @98: athrow
>>Reason:
>>  Current frame's flags are not assignable to stack map frame's.
>>Current Frame:
>>  bci: @0
>>  flags: { flagThisUninit }
>>  locals: { uninitializedThis, 'java/lang/Object', 'akka/actor/ActorRef' }
>>  stack: { 'java/lang/Throwable' }
>>Stackmap Frame:
>>  bci: @98
>>  flags: { }
>>  locals: { top, 'java/lang/Object', 'akka/actor/ActorRef' }
>>  stack: { 'java/lang/Throwable' }
>>Bytecode:
>>  0x000: 2a2b b500 322a 2cb5 0037 2ab7 0085 014e
>>  0x010: b200 8703 3201 0105 bd00 0859 032a 5359
>>  0x020: 0405 bd00 0859 032b 5359 042c 5353 b900
>>  0x030: 8d04 004e a700 053a 052a b800 932d c600
>>  0x040: 232d 1295 0105 bd00 0859 0311 00b1 bb00
>>  0x050: 975a 5fb7 009a 5359 0401 53b9 008d 0400
>>  0x060: 57b1 bf
>>Exception Handler Table:
>>  bci [16, 52] => handler: 55
>>  bci [0, 98] => handler: 98
>>Stackmap Table:
>>  
>> full_frame(@55,{Object[#6],Object[#8],Object[#120],Object[#8]},{Object[#130]})
>>  same_frame(@57)
>>  same_frame(@97)
>>  full_frame(@98,{Top,Object[#8],Object[#120]},{Object[#130]})
>>  
>> at akka.dispatch.Envelope$.apply(AbstractDispatcher.scala:27)
>> at akka.actor.Cell$class.sendMessage(ActorCell.scala:295)
>> at akka.actor.ActorCell.sendMessage(ActorCell.scala:374)
>> at 
>> akka.actor.RepointableActorRef.$bang(RepointableActorRef.scala:171)
>> at akka.actor.ActorRef.tell(ActorRef.scala:128)
>> at 
>> akka.pattern.AskableActorRef$.internalAsk$extension(AskSupport.scala:295)
>> at 
>> akka.pattern.AskableActorRef$.$qmark$extension1(AskSupport.scala:281)
>> at 
>> akka.event.LoggingBus$class.akka$event$LoggingBus$$addLogger(Logging.scala:181)
>> at 
>> akka.event.LoggingBus$$anonfun$4$$anonfun$apply$4.apply(Logging.scala:116)
>> at 
>> akka.event.LoggingBus$$anonfun$4$$anonfun$apply$4.apply(Logging.scala:115)
>> at scala.util.Success$$anonfun$map$1.apply(Try.scala:237)
>> at scala.util.Try$.apply(Try.scala:192)
>> at scala.util.Success.map(Try.scala:237)
>> at akka.event.LoggingBus$$anonfun$4.apply(Logging.scala:115)
>> at 

Re: [akka-user] Resuming on error from flatMapMerge

[Roland Kuhn]

Hi Stephen,

wasn’t your requirement to drop the whole sub-list when a failure occurs during 
its processing? That is not achieved with this design: you’ll have to buffer 
all events and only release the buffer when the substream completes 
successfully. Something like

  .fold(Vector.empty[Int])(_ :+ _)
  .recover { case _ => Vector.empty }
  .mapConcat(identity)

Regards,

Roland

> 9 juni 2017 kl. 00:13 skrev Stephen Duncan :
> 
> So, the suggestion is something like this?: 
> 
>   val subStreamFuture = Source(Seq(Seq(1, 2), Seq(3, 4, 5), Seq(6)))
> .flatMapMerge(5, m => Source.single(m)
>   .mapConcat(identity)
>   .via(subFlow)
>   .map(Success(_))
>   .recover { case t: Throwable => Failure(t) }
>   .collect { case Success(x) => x }
> )
> .runWith(Sink.seq)
> 
> (Is there a nicer way to just drop, or log and drop, the failure if that's 
> what's desired? Would a feature-request for an equivalent to recover that 
> emits 0 elements be reasonable to provide an equivalent of resuming for 
> stream failure/teardown?)
> 
> Does using withAttributes to set the supervision strategy on the mapAsync 
> stage for that version where there is only one stream seem acceptable (i.e. 
> should be reliable)? I'm finding the distinction between where the exception 
> can be handled by supervision and where it has escaped and we change to 
> teardown propagation mode hard to understand. Other than 
> https://github.com/akka/akka/issues/22880, it seems that supervision-strategy 
> works for failures in a future for mapAsync. If it's not reliable, then I 
> must consider also doing map->recover using Try or Either, and then add 
> collect as the next stream stage.
> 
> 
> 
> On Monday, May 29, 2017 at 10:42:05 PM UTC-7, rkuhn wrote:
> The details here are probably too subtle to be useful as a system design 
> tool: there are two kinds of failure handling at play in this example—a 
> caught exception and propagation of teardown—and only one of them is 
> reasonably controlled by the supervisionStrategy. I would recommend using 
> `.recover()` to turn a failed stream into an explicit element instead of 
> relying upon supervision for non-local failure handling.
> 
> Regards,
> 
> Roland
> 
>> 29 maj 2017 kl. 15:45 skrev Martynas Mickevičius 
>> :
>> 
>> From the initial look both of these example should behave the same. 
>> Especially since you explicitly set the supervision strategy. Could that 
>> there is a supervision strategy missing somewhere. What Akka version did you 
>> use? There has been quite a bit of changes how attributes are handled in 
>> Akka 2.5. I wonder if that is going to make a difference.
>> 
>> Otherwise I think this deserves an ticket on the issue tracker.
>> 
>> On Mon, May 29, 2017 at 11:39 AM Stephen Duncan > > wrote:
>> Before I assume and report this as a bug, I wanted to see if there was 
>> something I was missing regarding the error handling with Akka streams here. 
>> I am surprised to see two different outputs for the two example streams:
>> 
>> import akka.actor.ActorSystem
>> import akka.stream.scaladsl.{Flow, Sink, Source}
>> import akka.stream.{ActorAttributes, ActorMaterializer, Supervision}
>> 
>> import scala.collection.immutable.Seq
>> import scala.concurrent.duration._
>> import scala.concurrent.{Await, Future}
>> 
>> object MapMergeConcatError extends App {
>>   implicit val system = ActorSystem("Main")
>>   implicit val materializer = ActorMaterializer()
>>   implicit val ec = system.dispatcher
>> 
>>   val subFlow = {
>> Flow[Int]
>>   .mapAsyncUnordered(5)(i => Future {
>> if (i == 4) sys.error("☠")
>> i * 5
>>   })
>>   
>> .withAttributes(ActorAttributes.supervisionStrategy(Supervision.stoppingDecider))
>>   .reduce(_ + _)
>>   }
>> 
>>   val subStreamFuture = Source(Seq(Seq(1, 2), Seq(3, 4, 5), Seq(6)))
>> .flatMapMerge(5, m => Source.single(m).mapConcat(identity).via(subFlow))
>> 
>> .withAttributes(ActorAttributes.supervisionStrategy(Supervision.resumingDecider))
>> .runWith(Sink.seq)
>> 
>>   val mapAsyncFuture = Source(Seq(Seq(1, 2), Seq(3, 4, 5), Seq(6)))
>> .mapAsyncUnordered(5)(m => 
>> Source.single(m).mapConcat(identity).via(subFlow).runWith(Sink.head))
>> 
>> .withAttributes(ActorAttributes.supervisionStrategy(Supervision.resumingDecider))
>> .runWith(Sink.seq)
>> 
>>   val f1 = Await.ready(subStreamFuture, 10.seconds)
>>   val f2 = Await.ready(mapAsyncFuture, 10.seconds)
>> 
>>   println(s"Using flatMapMerge: $f1")
>>   println(s"Using mapAsyncUnordered: $f2")
>> 
>>   system.terminate()
>> }
>> 
>> The output is:
>> Using flatMapMerge: Future(Failure(java.lang.RuntimeException: ☠))
>> Using mapAsyncUnordered: Future(Success(Vector(30, 15)))
>> The mapAsyncUnordered output is the desired output (the whole item from the 
>> top-level is dropped when there is a failure in the sub-flow, but the 

Re: [akka-user] Issues with reference.conf in libraries not getting referenced after pulling library out of main project and into Nexus

[Roland Kuhn]

Another way to put this: yeah, you can do this, but you’ll have to use a 
suitable ClassLoader implementation that you control :-)

> 31 maj 2017 kl. 09:17 skrev Richard Ney :
> 
> Kinda suspected that would be your answer 
> 
> Sent from my iPhone
> 
> On May 30, 2017, at 11:22 PM, Patrik Nordwall  > wrote:
> 
>> You should never try to override properties defined in one reference.conf in 
>> another reference.conf. The order is undefined and you will not know what 
>> you are running. In other words, Akka properties should be defined in 
>> application.conf, never in reference.conf outside Akka.
>> 
>> The purpose of reference.conf is for a library to define default values. One 
>> library cannot override default values of another library.
>> 
>> /Patrik
>> ons 31 maj 2017 kl. 03:03 skrev Richard Ney > >:
>> We have a project that's composed of 5 different SBT projects. All of the 
>> SBT projects originally pulled a common library so it was built with each 
>> component and contained some common classes and reference.conf files. In our 
>> latest revision we've pulled the common library out into a separate build 
>> with the library getting published and pulled from a Nexus repository.
>> 
>> After changing the reference in the SBT projects so it pulls from Nexus 
>> we've noticed that the default values inside our reference.conf files aren't 
>> getting pulled. The easiest example was akka.actor.provider is specified in 
>> reference.conf inside our common-cluster-model-1.1.0-M3.jar file but I've 
>> had to include this inside the main application's application.conf to get 
>> the application to start up.
>> 
>> -Richard
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/ 
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >> 
>> >> Search the archives: https://groups.google.com/group/akka-user 
>> >> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com 
>> .
>> To post to this group, send email to akka-user@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/ 
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >> 
>> >> Search the archives: https://groups.google.com/group/akka-user 
>> >> 
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/akka-user/il1bivoUm68/unsubscribe 
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> akka-user+unsubscr...@googlegroups.com 
>> .
>> To post to this group, send email to akka-user@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> 

Re: [akka-user] Resuming on error from flatMapMerge

[Roland Kuhn]

The details here are probably too subtle to be useful as a system design tool: 
there are two kinds of failure handling at play in this example—a caught 
exception and propagation of teardown—and only one of them is reasonably 
controlled by the supervisionStrategy. I would recommend using `.recover()` to 
turn a failed stream into an explicit element instead of relying upon 
supervision for non-local failure handling.

Regards,

Roland

> 29 maj 2017 kl. 15:45 skrev Martynas Mickevičius 
> :
> 
> From the initial look both of these example should behave the same. 
> Especially since you explicitly set the supervision strategy. Could that 
> there is a supervision strategy missing somewhere. What Akka version did you 
> use? There has been quite a bit of changes how attributes are handled in Akka 
> 2.5. I wonder if that is going to make a difference.
> 
> Otherwise I think this deserves an ticket on the issue tracker.
> 
> On Mon, May 29, 2017 at 11:39 AM Stephen Duncan  > wrote:
> Before I assume and report this as a bug, I wanted to see if there was 
> something I was missing regarding the error handling with Akka streams here. 
> I am surprised to see two different outputs for the two example streams:
> 
> import akka.actor.ActorSystem
> import akka.stream.scaladsl.{Flow, Sink, Source}
> import akka.stream.{ActorAttributes, ActorMaterializer, Supervision}
> 
> import scala.collection.immutable.Seq
> import scala.concurrent.duration._
> import scala.concurrent.{Await, Future}
> 
> object MapMergeConcatError extends App {
>   implicit val system = ActorSystem("Main")
>   implicit val materializer = ActorMaterializer()
>   implicit val ec = system.dispatcher
> 
>   val subFlow = {
> Flow[Int]
>   .mapAsyncUnordered(5)(i => Future {
> if (i == 4) sys.error("☠")
> i * 5
>   })
>   
> .withAttributes(ActorAttributes.supervisionStrategy(Supervision.stoppingDecider))
>   .reduce(_ + _)
>   }
> 
>   val subStreamFuture = Source(Seq(Seq(1, 2), Seq(3, 4, 5), Seq(6)))
> .flatMapMerge(5, m => Source.single(m).mapConcat(identity).via(subFlow))
> 
> .withAttributes(ActorAttributes.supervisionStrategy(Supervision.resumingDecider))
> .runWith(Sink.seq)
> 
>   val mapAsyncFuture = Source(Seq(Seq(1, 2), Seq(3, 4, 5), Seq(6)))
> .mapAsyncUnordered(5)(m => 
> Source.single(m).mapConcat(identity).via(subFlow).runWith(Sink.head))
> 
> .withAttributes(ActorAttributes.supervisionStrategy(Supervision.resumingDecider))
> .runWith(Sink.seq)
> 
>   val f1 = Await.ready(subStreamFuture, 10.seconds)
>   val f2 = Await.ready(mapAsyncFuture, 10.seconds)
> 
>   println(s"Using flatMapMerge: $f1")
>   println(s"Using mapAsyncUnordered: $f2")
> 
>   system.terminate()
> }
> 
> The output is:
> Using flatMapMerge: Future(Failure(java.lang.RuntimeException: ☠))
> Using mapAsyncUnordered: Future(Success(Vector(30, 15)))
> The mapAsyncUnordered output is the desired output (the whole item from the 
> top-level is dropped when there is a failure in the sub-flow, but the other 
> items that did not have a failure in the sub-flow make it through).
> 
> Is this a bug, or something subtle that could be explained?
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to 

Re: [akka-user] akka-http client: How to ensure response entity is read

[Roland Kuhn]

Hi Daniel & Arno,

consuming  response entities needs to be done so that the connection becomes 
reusable afterwards, i.e. to free up the resource. In this sense, does it 
really matter how long that takes? If the connection goes idle for too long, it 
will be closed anyway, so attaching a `Sink.ignore()` should be all that is 
needed.

Regards,

Roland

> 29 maj 2017 kl. 10:50 skrev Daniel Vigovszky :
> 
> Hi Arno,
> 
> did you figure out anything about this?
> 
> vigoo
> 
> 2017. május 18., csütörtök 7:12:37 UTC+2 időpontban Arno Haase a következőt 
> írta:
> I am aware that response entities must always be consumed with akka-http 
> client. 
> 
> For (very) slow connections I find it difficult to do that reliably. 
> Consuming the entity is asynchronous and therefore requires timeouts - 
> but if the timeouts fire, I may be left with an entity that is only 
> partly consumed. 
> 
> I am probably missing something here - any help would be greatly 
> appreciated. 
> 
> - Arno 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] New Documentation

[Roland Kuhn]

Hi Mike,

it took a bit until your proposal registered properly (I blame the sun): I 
agree that it would be nice to have a link to the API on every page of the 
reference docs, I’ve seen that elsewhere and it makes sense. It would be even 
nicer to have everything in the code samples linked to its API doc where 
applicable :-) Does such technology exist today?

Regards,

Roland

> 28 maj 2017 kl. 18:05 skrev Mike Nielsen :
> 
> I'm sure it is for all but those of us like me who are intensely lazy.
> 
> I just thought it would be handy to have the nav header version in the 
> reference link to the API docs.
> 
> No biggie, really. 
> 
> Again, let me congratulate you on the new site.  I think it's outstanding, 
> and I am very excited about the possibility that there may be more runnable 
> examples using ScalaFiddle!
> 
> Well done and thank you for taking the time on a Sunday to reply!
> 
> Warm regards,
> 
> Mike
> 
> On Sun, May 28, 2017 at 9:33 AM, Patrik Nordwall  > wrote:
> Thanks. Our thinking was that http://akka.io/docs/  
> would be the landing page for all docs including such links. Not enough?
> 
> /Patrik
> sön 28 maj 2017 kl. 15:26 skrev Mike Nielsen  >:
> Congratulations, team, on the new Akka documentation site.  It looks good!
> 
> By way of a minor enhancement, would it be possible to put a link to the API 
> documentation in an easy-to-find place so that those of us with poor memories 
> may find it more easily?
> 
> Thanks!
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and 

Re: [akka-user] Role of Akka in SMACK

[Roland Kuhn]

Whoever this is: would you please abstain from such anonymous unsubstantiated 
claims? I cannot comment on the truthfulness of your critique, common courtesy 
would entail that I know at least your name to ask for supporting evidence.

Regards, Roland 

Sent from my iPhone

> On 3. May 2017, at 06:36, 'Ryan Tanner' via Akka User List 
>  wrote:
> 
> Be careful with Flink.  IME it's got a long way to go.  The core model is 
> fantastic but there's a lot of low-hanging fruit that needs to be fixed.
> 
>> On Tuesday, May 2, 2017 at 4:03:12 PM UTC-6, Evan Chan wrote:
>> Hi Shiva,
>> 
>> Spark will likely be too high latency for you.  Practical minimal batch size 
>> is a couple seconds.
>> 
>> Think of Akka as a best fit for if you want to deploy individual apps each 
>> reading from some set of fixed Kafka partitions.  Each one could then write 
>> to HDFS.  However you would need to handle failover, state, etc. etc.
>> It is likely that Flink has much more built in for you - HDFS integration, 
>> checkpointing, failover, shuffling/routing of messages, integration with 
>> Kafka, etc.
>> 
>> You might want to look into Intel Gearpump - this is Akka-based very low 
>> latency dynamic stream processing, and they have handled distribution 
>> already.
>> 
>> -Evan
>> 
>>> On Friday, April 28, 2017 at 7:52:50 AM UTC-7, Shivakumar Ramagopal wrote:
>>> Viktor,
>>> 
>>> 
 On Fri, Apr 28, 2017 at 5:03 PM, Viktor Klang  wrote:
 
 
> On Fri, Apr 28, 2017 at 1:12 PM, Shiva Ramagopal  wrote:
> Hi Viktor,
> 
>> On Fri, Apr 28, 2017 at 2:55 PM, Viktor Klang  
>> wrote:
>> Hi Shiva,
>> 
>>> On Fri, Apr 28, 2017 at 11:20 AM, Shiva Ramagopal  
>>> wrote:
>>> I'm looking to compare Kafka Streams vs Akka Streams in two areas: 
>>> 
>>> 1. For ingesting between Kafka and HDFS/RDBMS 
>>> 
>>> Requirements are mainly around performance and latency. A Kafka topic 
>>> can have several million events, each corresponding to a database 
>>> change capture. When ingesting this topic into HDFS I'm also looking to 
>>> partition the data by day, typically based on a timestamp field in the 
>>> event record, aggregations on-the-fly (say by a userid field) and 
>>> parquetizing (preferably on the fly to optimize performance by reducing 
>>> two I/O operations).
>> 
>> Looking forward to see your benchmark!
> 
> Hey, you wanted requirements! :) 
>>  
>>> 
>>> 2. Low-latency processing
>>> 
>>> Experiences around performances of Storm/Flink and Akka Streams would 
>>> be *very* nice. Typical use-cases are de-duping and enrichment with 
>>> metrics computation (# duplicate events/records, aggregate metrics 
>>> etc). Low latency and scalability are main considerations
>> 
>> Low latency is not a metric, and scalability is not a profile. :)
>> In other words: What latency distribution are you targeting and what 
>> scalability curve?
> 
> I know latency is a nuanced topic. I'm just looking for broad experiences 
> on performance comparisons if anyone has done that. Currently we have a 
> Storm topology over 5 nodes doing enrichment of events from Kafka that 
> involves a lookup into a db per event. 90th percentile of latency of this 
> processing is under 200 ms and we are happy with this. While Storm is 
> mature, Akka Streams seems more general purpose than Storm. I'd like to 
> use Akka Streams for this reason if performance is comparable to Storm. 
 
 There's one important architectural difference here tho: Akka Streams are 
 local-only (as in materialization). You can of course materialize Akka 
 Streams on multiple nodes and use a transport to coordinate data 
 processing. Interestingly it doesn't lock you in to a particular backend 
 such that Kafka Streams or even Storm would do.
>>> 
>>> The materialization part was something I was not aware of. Thanks for 
>>> pointing it out, really appreciate it.
 
 All of this boils down to requirements. Something like Flink or Google 
 Beam could be viable options here as well. In your situation I'd look at 
 the requirements and make a couple of prototypes before picking a winner.
>>> 
>>> I was also looking for something to unify batch and streaming - which is 
>>> how I came to look at SMACK. I'd really like to keep the tech stack small 
>>> and have the parts integrate tightly with each other. Guess I have to pick 
>>> between Spark, Flink, Beam and Storm. 
  
>  
>>  
>>> 
 On Thu, Apr 27, 2017 at 8:31 PM, Viktor Klang  
 wrote:
 
 
> On Thu, Apr 27, 2017 at 10:39 AM, Shiva Ramagopal  
> wrote:
> Hi,
> 
> I have read through multiple 

Re: [akka-user] Uncaught error from thread shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem

[Roland Kuhn]

Well, the screenshot shows the error quite clearly: the native library for 
leveldb is not found.

Regards,

Roland

> 25 apr. 2017 kl. 08:27 skrev Sachin S V :
> 
>  I am running an assembly jar file in command prompt and getting the 
> exception below. And resulting in termination.
> 
> Uncaught error from thread 
> [ccp-akka.persistence.dispatchers.default-plugin-dispatcher-23] shutting down 
> JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[ccp]
> 
> There is nothing else running in my windows machine while this. No code 
> access is there except a jar file. What might be the issue? I tried 
> restarting the machine a couple of times.
> 
> Attached the screenshot of log.
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Has akka-http has abandoned per request actors in favor an anti-pattern DSL?

[Roland Kuhn]

Hi Robert,

since a Route is just a function from request to future of response you can 
easily achieve all that you describe, delegating as much or as little as you 
wish to actors via the ask pattern (delegating via a parent actor whose ref is 
known to the route). Commonly extracted metadata are conveniently factored out 
into custom or composed directives and the actor may respond with HttpResponse 
for full flexibility in terms of determining the success of the request.

Unfortunately, I am traveling and not at my computer, hence no code.

Regards, Roland 

Sent from my iPhone

> On 3 Apr 2017, at 19:20, kraythe  wrote:
> 
> Yes I know routes can be concatenated from several sources. I addressed that 
> in my original post. It doesn't take away from the core thrust. Even the 
> determination of whether an endpoint ends up in a bad request or an ok or a 
> forbidden could take a significant amount of logic to determine in the real 
> world and some of that logic may be a result of aggregating data from several 
> actors which cant be done in a route without ask pattern and then you are 
> back in imperative programming and there is little point to using actors at 
> all. 
> 
>> On Monday, April 3, 2017 at 11:00:49 AM UTC-5, Rob Wills wrote:
>> If you have lots of endpoints and you want to split them up into multiple 
>> files you can do that using the dsl.  
>> 
>> http://stackoverflow.com/questions/34514372/akka-http-with-multiple-route-configurations/34516168#34516168
>> 
>> I don't think your proposal is a good idea.
>> 
>>> On Mon, Apr 3, 2017 at 4:52 PM, 'Ryan Tanner' via Akka User List 
>>>  wrote:
>>> Leaving aside the tone of this post...
>>> 
>>> Have you looked at the longer example of the DSL?
>>> 
>>> http://doc.akka.io/docs/akka-http/current/scala/http/routing-dsl/index.html#longer-example
>>> 
>>> It has examples of how to delegate an endpoint's business logic off to 
>>> actors or futures.
>>> 
>>> 
 On Sunday, April 2, 2017 at 7:09:32 PM UTC-6, kraythe wrote:
 I was really excited about akka-http as I would be able to unburden my 
 code from the baggage of play and handle my server side as a pure akka 
 actors app but unless I am much mistaken something is dreadfully amiss 
 with the implementation. 
 
 One of the main core features is the actor paradigm and the integration of 
 a rich actor system. However, the preferred approach to akka-http seems to 
 be a throwback to one file programming. The main reason it seems this way 
 is the DSL. Take this example from a tutorial: 
 
  path("bank" / IntNumber) { id =>
 get {
   complete {
 getById(id).map{result =>
   if(result.isDefined)
   HttpResponse(entity =write(result.get))
   else
 HttpResponse(entity ="This bank does not exist")
 }
 
 
   }
 }
   }~
 path("bank" / "update") {
   post {
 entity(as[String]) { bankJson =>
   complete {
 val bank =parse(bankJson).extract[Bank]
 update(bank).map{result => HttpResponse(entity ="Bank has  
 been updated successfully")}
   }
 }
   }
 }
 }
   }
 
 
 Simple enough right? Too me I see the start of an anti-pattern but lets 
 look further. It gets worse though, quickly,  as shown in the akka-http 
 documentation here. Still not bothered? The problem is that these examples 
 are shallow and not rooted in the real world. In the bank application 
 above would be hundreds of endpoints and each endpoint would have to 
 validate data send by the user, check to see whether that data correct 
 against the database and a dozen other things that would alter the nature 
 of the return type to a  bad request or internal error. The banking app 
 would also have to log the problems so forensics can be done on malicious 
 users. Just taking one route "deposit" would be several hundred lines of 
 code INSIDE the route. However, it seems that there is no way to break off 
 the route, offload it to another component (such as a Per Request Actor) 
 and then continue the DSL where you left off. I had the chance to see for 
 an app in another company that was asking my advice and their route is 12k 
 lines long and at one point nested 30 levels deep.
 
 Now I know what you might say, "But Robert, you can break up the route 
 into multiple files" which is true but something has to manually 
 concatenate all of those routes together and they cant be done off of the 
 main route. once you are in the routes DSL you are stuck there. Sure, you 
 can call an actor with a future to do a completion but that actor 

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

[Roland Kuhn]

> 20 feb. 2017 kl. 12:51 skrev Alan Burlison <alan.burli...@gmail.com>:
> 
> On 20 February 2017 at 07:24, Roland Kuhn <goo...@rkuhn.info> wrote:
> 
>> There are two solutions: the pipeTo pattern, or not using Futures at all and
>> collecting the responses within a dedicated ephemeral actor.
> 
> What about the "blocking { ... }" construct?
> 
> http://www.cakesolutions.net/teamblogs/demystifying-the-blocking-construct-in-scala-futures
> 
> Probably best avoided if at all possible, though.

This is not a solution because it creates one new thread for every blocker.

Regards,

Roland

> 
> --
> Alan Burlison
> --
> 
> -- 
>>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>> Check the FAQ: 
>>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[Roland Kuhn]

There might be some miscommunication here: as I understand it the OP is using 
Await.result on an aggregation future. To that the answer is: don’t do that! 
The JVM does not support suspending an active computation to free up the 
thread, so you’re right that doing this can lead to deadlock. There are two 
solutions: the pipeTo pattern, or not using Futures at all and collecting the 
responses within a dedicated ephemeral actor.

Regards,

Roland

> 19 feb. 2017 kl. 22:15 skrev Rafał Krzewski :
> 
> The actor itself is the place where state should be held. If the actor 
> "should not be bothered" by the dispatcher until a specific condition occurs, 
> just stash the incoming messages for processing later. ActorContext.become 
> lets you switch behaviors, for example available / unavailable state. When 
> entering available state, you just unstash the postponed messages.
> 
> As Justin said, all the pieces needed to implement the usecase you describe 
> are already there, and no sleeping or blocking is necessary.
> 
> I wouldn't say that Akka is complicated at the conceptual level. Quite the 
> contrary: in my opinion it is remarkably simple and elegant. It is very 
> different from typical JVM threads and locks concurrency, so it might be hard 
> to wrap your head around at first.
> 
> Cheers,
> Rafał
> 
> W dniu niedziela, 19 lutego 2017 21:30:19 UTC+1 użytkownik scala solist 
> napisał:
> 
> On Sunday, February 19, 2017 at 10:53:01 PM UTC+3, Justin du coeur wrote:
> Do you mean literally calling "sleep()"?  
> 
> I mean sleep as a thread state. Alternative is to save actor state somehow 
> and return thread to dispatcher so it can be reused. The dispatcher should 
> never bother the actor until it become available. It complicates things for 
> the actor system, but Akka is already very complicated and I'm not sure if it 
> is already implemented somewhere 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Order of processing vs Futures in actor

[Roland Kuhn]

> 15 feb. 2017 kl. 22:18 skrev Igor Berman :
> 
> Hello All
> Wanted to get a bit of advice regarding following usecase:
> I have local ActorSystem that handles messages with some key inside. Every 
> such message causes mutation of db state by the key: read old value by key, 
> compute new state given message, write new value to the db.
> 
> To guarantee consistent update per each key I thought of spliting processing 
> of incoming messages by ConsistentHashingPool, so that all messages with same 
> key will be handled by the same child actor. Number of children will give me 
> sort of partitioning of key-set into finite number of actors, it will provide 
> concurrency of updates across keys from different partitions too. Suppose I 
> can't use akka-persistence module and need to maintain "state" inside this db.
> 
> Now concerning implementation of update itself: if I wrap processing in some 
> future (so that actor won't be blocked to read from db and to write to db) 
> and then pipe the result to the sender I might break the order of processing 
> within same key(e.g. when update logic running in future for some msg is not 
> yet finished write to db, the next msg will be taken from mailbox by actor 
> and will submit another processing that might interleave with the first one), 
> so I found technique of becoming "unresponsive" and stashing all messages and 
> then, when future completes unbecoming and unstashing all messages(from here 
> http://chariotsolutions.com/blog/post/order-chaos-maintaining-ordered-processing-messages-akka-actors/)
> 
> On the other hand, I'll need some thread pool anyway for those futures(since 
> reads/writes are blocking), so maybe just doing this blocking work inside 
> actor and configuring it with custom dispatcher will give same effect, while 
> being more simple solution

Yes, this is the right conclusion: Actors establish order within chaos and 
manage resources.

Regards,

Roland

> 
> thanks in advance
> Igor
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: I'm a freshman to Akka, please recommend me some useful learning material... Thanks a lot.

[Roland Kuhn]

While “terrible” is pretty strong wording I think it is fair to say that Akka 
has very good reference documentation but its initial learning experience can 
be improved. Would it help if some of the video courses were available (for 
free, of course) that were part of Principles of Reactive Programming?

Regards, Roland 

Sent from my iPhone

> On 19 Jan 2017, at 20:41, Josep Prat  wrote:
> 
> Welcome to Akka!
> As Lutz already said, I would recommend "Akka in Action". The only catch is 
> that the code is mainly in Scala.
> I have a question though, why do you say the official documentation is 
> terrible? I personally find Akka docs quite good. What would you change/add 
> to the current ones?
> 
> Best,
> Josep
> 
>> On Thursday, January 19, 2017 at 2:34:29 PM UTC+1, Qian Liu wrote:
>> Hello everybody,
>> 
>> I'm new-comer to Akka, the official documents for Akka learning is terrible. 
>> not very well structured. Beginners will soon feel lost with these official 
>> documents. Do you know any better resources to learn? I'm a java developer.
>> 
>> Thanks a lot.
>> 
>> Best regards,
>> 
>> Qian Liu
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Strange behavior with unzip when fusing is on

[Roland Kuhn]

.zip synchronizes its input streams because it requires one element from each 
for every output, .merge consumes its inputs independently (as long as there is 
downstream demand).

Regards,

Roland

> 21 dec. 2016 kl. 22:20 skrev Anil Gursel <anilgur...@gmail.com>:
> 
> Thanks Endre and Roland!  Yes, when I add a buffer just before zip.in0, both 
> tests pass:
> 
> unzip.out0.buffer(10, OverflowStrategy.backpressure) ~> zip.in0
> 
> So, adding the buffer is enabling the parallelism.  However, why does not the 
> first test (the one without zip/unzip) need a buffer to enable parallelism 
> (e.g., just before merge)?
> 
> Thanks,
> Anil
> 
> On Wed, Dec 21, 2016 at 2:40 AM, Endre Varga <endre.va...@lightbend.com 
> <mailto:endre.va...@lightbend.com>> wrote:
> Yes, that might be the case. 
> 
> On Wed, Dec 21, 2016 at 9:39 AM, Roland Kuhn <goo...@rkuhn.info 
> <mailto:goo...@rkuhn.info>> wrote:
> I think what is happening here is that zip does not pull until the delayed 
> element has come out, meaning that the second (less delayed) element will not 
> overtake it. mapAsync is effectively a buffer, so you'll need a buffer in 
> front of zip.in0 as well to enable parallelism.
> 
> Regards, Roland 
> 
> Sent from my iPhone
> 
> On 21 Dec 2016, at 09:34, Endre Varga <endre.va...@lightbend.com 
> <mailto:endre.va...@lightbend.com>> wrote:
> 
>> 
>> 
>> On Tue, Dec 20, 2016 at 11:34 PM, Anil Gursel <anilgur...@gmail.com 
>> <mailto:anilgur...@gmail.com>> wrote:
>> I see that unzip does not pull the next element when fusing is on.  I 
>> understand that when fusing is on, a message goes through the entire stream 
>> and then the next message goes through.
>> 
>> This is not true, messages are handled concurrently even in fused islands, 
>> it is just that they are not parallel. I.e. same thread, but event order is 
>> unspecified. In fact, fused islands are fair in that even in the case of 
>> long-running cycles other parts of the graph can still progress (which would 
>> not be true if what you said would be true)
>>  
>>   However, is it still the case when `mapAsyncUnordered` is used?  
>> 
>> mapAsync wait on asynchronous events, so that needs to wait until those are 
>> ready. In the meantime the rest of the graph can progress.
>>  
>> 
>> Please see the two tests at 
>> https://gist.github.com/anilgursel/aa70497a9431fc8b498c599d9d469e2b 
>> <https://gist.github.com/anilgursel/aa70497a9431fc8b498c599d9d469e2b>.  The 
>> two tests are identical except the second one does an unzip then a zip.  The 
>> first one succeeds and the second one fails.  The first one succeeding means 
>> that when `mapAsyncUnordered` is used, it is not actually waiting for the 
>> previous message to go through the entire stream.  
>> 
>> Again, there is no "previous message go through the entire stream". That 
>> would lead to starving scenarios that you describe. What fusing changes is 
>> that it removes buffers and hence prefetches. Try out higher delays and see 
>> what happens.
>> 
>> -Endre
>> 
>>  
>> 
>> I will appreciate if you can shed some light on what's going on in this 
>> samples.
>> 
>> Thanks,
>> Anil
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/akka-user 
>> <https://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> >>>>

Re: [akka-user] Strange behavior with unzip when fusing is on

[Roland Kuhn]

I think what is happening here is that zip does not pull until the delayed 
element has come out, meaning that the second (less delayed) element will not 
overtake it. mapAsync is effectively a buffer, so you'll need a buffer in front 
of zip.in0 as well to enable parallelism.

Regards, Roland 

Sent from my iPhone

> On 21 Dec 2016, at 09:34, Endre Varga  wrote:
> 
> 
> 
>> On Tue, Dec 20, 2016 at 11:34 PM, Anil Gursel  wrote:
>> I see that unzip does not pull the next element when fusing is on.  I 
>> understand that when fusing is on, a message goes through the entire stream 
>> and then the next message goes through.
> 
> This is not true, messages are handled concurrently even in fused islands, it 
> is just that they are not parallel. I.e. same thread, but event order is 
> unspecified. In fact, fused islands are fair in that even in the case of 
> long-running cycles other parts of the graph can still progress (which would 
> not be true if what you said would be true)
>  
>>   However, is it still the case when `mapAsyncUnordered` is used?  
> 
> mapAsync wait on asynchronous events, so that needs to wait until those are 
> ready. In the meantime the rest of the graph can progress.
>  
>> 
>> Please see the two tests at 
>> https://gist.github.com/anilgursel/aa70497a9431fc8b498c599d9d469e2b.  The 
>> two tests are identical except the second one does an unzip then a zip.  The 
>> first one succeeds and the second one fails.  The first one succeeding means 
>> that when `mapAsyncUnordered` is used, it is not actually waiting for the 
>> previous message to go through the entire stream.  
> 
> Again, there is no "previous message go through the entire stream". That 
> would lead to starving scenarios that you describe. What fusing changes is 
> that it removes buffers and hence prefetches. Try out higher delays and see 
> what happens.
> 
> -Endre
> 
>  
>> 
>> I will appreciate if you can shed some light on what's going on in this 
>> samples.
>> 
>> Thanks,
>> Anil
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Actor creation memory consistency

[Roland Kuhn]

The answer lies in UnstartedCell, but beware that this code may be morally 
challenging: it uses a Lock ;-)

Regards, Roland 

Sent from my iPhone

> On 21 Dec 2016, at 08:02, stella  wrote:
> 
> I'm trying to understand how actor creating is being performed internally. 
> So, once we created our ActorSystem object we can start a top level actor 
> like this:
> 
> val system = ActorSystem("system", config)
> val ref = system.actorOf(MyActor.props, "myactor")
> 
> 
> Internally, it will invoke ActorRefProvider::actorOf(ActorSystemImpl, Props, 
> InternalActorRef, ActorPath, Boolean, Option[Deoploy], Boolean, Boolean) 
> which in my case is ended up with invocation
> 
> if (async) new RepointableActorRef(system, props2, dispatcher, mailboxType, 
> supervisor, path).initialize(async)
> 
> where async=true. The initialize method, in turn invoke
> 
> supervisor.sendSystemMessage(Supervise(this, async))
> 
> which ends up with:
> 
> protected[akka] def systemDispatch(receiver: ActorCell, invocation: 
> SystemMessage): Unit = {
>  val mbox = receiver.mailbox
>  mbox.systemEnqueue(receiver.self, invocation)
>  registerForExecution(mbox, false, true)
> }
> 
> So, in effect, creating RepointableActorRef asynchronously means sending a 
> system message to a supervisor which results in creating the actor instance 
> itself, invoking the startup hook and so forth. 
> 
> QUESTION: Why there is no race condition here when we create ActorRef  that 
> way and immediately send a message to the actor? What thing does guarantee 
> the memory consistency?
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Aeron errors when network temporarily disconnected.

[Roland Kuhn]

Are you on Windows? Windows is known to do very weird things to processes when 
the ethernet link goes down (such as terminating listeners).

> 14 dec. 2016 kl. 01:44 skrev Allan Brighton :
> 
> Using akka-2.4.11 on Ubuntu-16.04: If I pull the network plug for a few 
> seconds while an actor is running I get the errors below.
> It looks like akka kills the ActorSystem. How do you prevent  this or recover 
> from it? 
> (I think it was the same under 2.4.14 when I tested it)
> 
> 16:16:57.508 ERROR a.r.a.ArteryTransport(akka://ConfigService) -- Aeron 
> error: 24473 observations from 2016-12-13 16:16:51.027-0800 to 2016-12-13 
> 16:16:57.507-0800 for: 
> .io.IOException: Invalid argument 
>at sun.nio.ch.DatagramDispatcher.write0(Native Method) 
>at sun.nio.ch.DatagramDispatcher.write(DatagramDispatcher.java:51) 
>at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
>at sun.nio.ch.IOUtil.write(IOUtil.java:51) 
>at sun.nio.ch.DatagramChannelImpl.write(DatagramChannelImpl.java:605) 
>at 
> io.aeron.driver.media.SendChannelEndpoint.send(SendChannelEndpoint.java:160) 
>at 
> io.aeron.driver.NetworkPublication.sendData(NetworkPublication.java:375) 
>at 
> io.aeron.driver.NetworkPublication.send(NetworkPublication.java:192) 
>at io.aeron.driver.Sender.doSend(Sender.java:117) 
>at io.aeron.driver.Sender.doWork(Sender.java:60) 
>at org.agrona.concurrent.CompositeAgent.doWork(CompositeAgent.java:79) 
>at org.agrona.concurrent.AgentRunner.run(AgentRunner.java:122) 
>at java.lang.Thread.run(Thread.java:745) 
> 
> 16:16:58.251 ERROR a.r.a.ArteryTransport(akka://ConfigService) -- Fatal Aeron 
> error DriverTimeoutException. Have to terminate ActorSystem because it lost 
> contact with the embedded Aeron medi
> a driver. Possible configuration properties to mitigate the problem are 
> 'client-liveness-timeout' or 'driver-timeout'. Driver has been inactive for 
> over 2ms 
> io.aeron.exceptions.DriverTimeoutException: Driver has been inactive for over 
> 2ms 
>at 
> io.aeron.ClientConductor.checkDriverHeartbeat(ClientConductor.java:291) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at io.aeron.ClientConductor.onCheckTimeouts(ClientConductor.java:378) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at io.aeron.ClientConductor.doWork(ClientConductor.java:309) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at io.aeron.ClientConductor.doWork(ClientConductor.java:123) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at org.agrona.concurrent.AgentRunner.run(AgentRunner.java:122) 
> ~[org.agrona.Agrona-0.5.4.jar:na] 
>at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_111] 
> 16:16:59.281 ERROR akka.actor.RepointableActorRef -- Error during postStop in 
> [akka.remote.artery.AeronSink@53af6ad1]: Driver is inactive 
> io.aeron.exceptions.DriverTimeoutException: Driver is inactive 
>at 
> io.aeron.ClientConductor.verifyDriverIsActive(ClientConductor.java:299) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at 
> io.aeron.ClientConductor.releasePublication(ClientConductor.java:151) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at io.aeron.Publication.release(Publication.java:229) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at io.aeron.Publication.close(Publication.java:206) 
> ~[io.aeron.aeron-client-1.0.1.jar:na] 
>at akka.remote.artery.AeronSink$$anon$1.postStop(AeronSink.scala:132) 
> ~[com.typesafe.akka.akka-remote_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.GraphInterpreter.finalizeStage(GraphInterpreter.scala:801)
>  ~[com.typesafe.akka.akka-stream_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.GraphInterpreter.afterStageHasRun(GraphInterpreter.scala:780)
>  ~[com.typesafe.akka.akka-stream_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:620) 
> ~[com.typesafe.akka.akka-stream_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:471)
>  ~[com.typesafe.akka.akka-stream_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.GraphInterpreterShell.receive(ActorGraphInterpreter.scala:423)
>  ~[com.typesafe.akka.akka-stream_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:603)
>  ~[com.typesafe.akka.akka-stream_2.11-2.4
> .11.jar:na] 
>at 
> akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:618)
>  ~[com.typesafe.akka.akka-stream_2.11-2.4.11.jar:na] 
>at akka.actor.Actor$class.aroundReceive(Actor.scala:484) 
> ~[com.typesafe.akka.akka-actor_2.11-2.4.11.jar:na] 
>at 
> akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:529)
>  

Re: [akka-user] Akka http create pathPrefix from a list

[Roland Kuhn]

> 12 dec. 2016 kl. 08:16 skrev A. Nigredo :
> 
> Hi all, I've got a list of String e.g. List("public", "assets") and I wanna 
> create pathPrefix from the list.
> 
> I try like:
> List("public", "assets") match {
>   case x::xs if xs.isEmpty  => pathPrefix(x)
>   case x::xs => pathPrefix(xs.foldRight(x./)(_ / _))
> }
> 
> and it is compiled but url not resolved when I run application.

Which URL specifically? Since you are using foldRight, you are building a 
pathPrefix("assets" / "public").

Regards,

Roland

> 
> Is it possible to implement it such an idea?
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Unit test for Persistent Actor Replay

[Roland Kuhn]

Well, it is solved in Akka Typed: removing system.actorOf() and system.stop() 
is the only way to "solve" this. The reason is that the semantics of these 
methods are incompatible with the distributed nature of the ActorSystem.

Regards, Roland 

Sent from my iPhone

> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
> 
> Good question!
> 
> The notification of its death hadn't reached the closest of kin (its parent) 
> so they hadn't even put it in the ground when you proposed to create a new 
> one and call it the same thing, so they (rightfully so) objected to that 
> suggestion.
> 
> This trips people up every now and then, but I've never seen a proposal to 
> solve it.
> 
> -- 
> Cheers,
> √
> 
> 
>> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>> We have a unit test for a persistent actor, which instantiates a second 
>> instance after waiting for termination of the first.
>> 
>> watch(definitionReader)
>> 
>> system.stop(definitionReader)
>> 
>> expectTerminated(definitionReader)
>> 
>> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName)
>> 
>> This test fails intermittently on Bamboo
>> 
>> actor name [name1] is not unique!
>> Any ideas? 
>> 
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] ANNOUNCE: Akka HTTP 10.0.0 – fully stable release!

[Roland Kuhn]

Woohoo, congrats everyone!

Sent from my iPhone

> On 22 Nov 2016, at 17:23, Konrad 'ktoso' Malawski  wrote:
> 
> Dear hakkers,
> 
> Today, we are proud and happy to announce the immediate availability of the 
> fully stable version of Akka HTTP – 10.0.0, charmingly code named “X” by 
> @jonas on gitter!
> 
> Please note that while the version number changed significantly, the actual 
> surface APIs did not by much. The akka-http-core module was already stable 
> back in Akka 2.4, so it remained binary compatible, and the sources for 
> akka-http are almost completely compatible with those that were shipped as 
> Akka 2.4.11 – you should not have any trouble upgrading.
> 
> 
> 
> From here-on the Akka HTTP releases will respect binary compatibility, as 
> expected from stable Akka modules. We will also try out a novel way of 
> introducing new APIs, by shipping them in the stable modules however marking 
> them as “experimental” or “not-sure-if-we-keep-them” so you’d be able to 
> opt-in into those on a case-by case basis. This idea is under discussion in 
> the Consider @Experimental / @ApiMayChange markers on APIs issue on github.
> 
> 
> 
> Along with the new version, and stability of all of the modules, we expect 
> the community to quickly catch up with releasing the various support projects 
> for the new version, such as akka-http-cors, akka-sse, akka-http-session, 
> akka-json. This includes cross releases for Scala 2.12, for which Akka HTTP 
> is now available as well.
> 
> Documentation
> 
> The documentation is available under a separate directory under doc.akka.io, 
> and will follow the following scheme: doc.akka.io/docs/akka-http/[version]/, 
> the usual “current” symlink is also available and we recommend using that if 
> linking to Akka documentation from external sites such as stack overflow or 
> blogs.
> 
> The documentation has moved to the Lightbend Paradox tool, which allows us to 
> write documentation using extended markdown, instead of restructuredtext 
> which we found was making it difficult for first time contributors. Thanks a 
> lot, @jonas, who contributed the biggest part of the conversion!
> 
> 
> 
> We are currently working on a redesign of the documentation pages, so they 
> will soon get a shiny new look. Please bear with us during the transition 
> period. Other projects, like Alpakka, Reactive Kafka have also already 
> adopted Paradox, and Akka itself will soon follow as well. We will be able to 
> provide very interesting features thanks to Paradox, keep your eyes peeled 
> for them soon.
> 
> 
> 
> As always, help is very welcome, and if you find a part of the documentation 
> you’d like to see improved, please open tickets or send in pull requests 
> directly, thanks in advance!
> 
> Versioning
> 
> Akka HTTP from here-on will be versioned separately from Akka “core”. The 
> original purpose of these projects sharing their version number was that Akka 
> HTTP was evolving and providing many real-world requirements for the Akka 
> Streams implementation, thus they were developed together. Now that both 
> projects are stable, we want to be able to move them more independently.
> 
> 
> 
> The version scheme will follow semantic versioning, breaking changes will 
> only be made in major releases (i.e. the next one being 11.0.0). However we 
> will also introduce a new way of marking experimental APIs released inside 
> existing modules – for a discussion on this please see the issue 
> akka/akka-http#3.
> 
> The -experimental suffix has now been dropped for all of Akka HTTP’s module. 
> During the transition period make sure not to transitively depend on old 
> artifacts that still carry the suffix (like akka-http-experimental). 
> Otherwise, you could end up with multiple versions of the same classes on the 
> classpath.
> 
> 
> 
> This version of Akka HTTP depends on Akka 2.4.14, since some critical fixes 
> and improvements were made in the recent version of Akka.
> 
> Community
> 
> We consider ourselves very lucky that we have such vibrant and helpful 
> community around Akka, and Akka HTTP specifically. In recent months we 
> started to include more community members in our github teams for the various 
> projects (reactive-kafka, alpakka, akka-http), and plan on continuing to do 
> so. If you’re interested in becoming part of our extended teams, please read: 
> Akka HTTP - stable, growing and tons of opportunity on akka-meta and keep 
> hakking :-)
> 
> Credits
> 
> A total 22 issues were closed since the last release candidate, most of the 
> work has been fixes, stability improvements and preparing for the upcoming 
> stable release.
> 
> The complete list of closed issues since the split from Akka 2.4.11 can be 
> found on the 3.0.0-RC1, 10.0.0-RC2, 10.0.0 as well as the HTTP/2 PoC 
> milestones on github.
> 
> 
> 
> For this release we had the help of 23 committers – thank you! We continue to 
> be amazed by the steady stream of 

Re: [akka-user] Non-monotonic incremental computation

[Roland Kuhn]

Indeed, these are very interesting points, including persistence. What I would 
like to try out (we have started some experiments at Actyx) is to decouple the 
actual datatype and the management of its δ-state from Akka Cluster: the 
cluster should become a provider of node identity and data dissemination, while 
the datatypes themselves should be able to transcend the cluster’s scope (e.g. 
via REST endpoints between services). This is not entirely trivial, in 
particular the removal of old nodes, but it would greatly expand the reach of 
what we can tackle with CRDTs. Unfortunately I cannot spend much time on this 
right now, but please open an issue on akka-meta for discussing the way forward 
and I’ll join the discussion.

Regards,

Roland

> 20 nov. 2016 kl. 09:06 skrev Patrik Nordwall :
> 
> Hi, delta-CRDTs are very interesting. Contribution to Akka Distributed Data 
> would be much appreciated.
> 
> Let me know if you have something I should review or if you want to discuss 
> any design ideas. Probably best if you create an Akka github issue.
> 
> /Patrik
> lör 19 nov. 2016 kl. 12:06 skrev Merlijn Boogerd  >:
> Hi! For a while now I have developed an interest in developing data-flows 
> which are non-monotonic (i.e. they support updates and deletes), and 
> incremental (between batch/stream, within the Spark community this is also 
> called a continuous application). I have experimented with this in a separate 
> project and I am now looking to take this to the next step; building an 
> actual platform out of it.
> 
> I think that at least part of it could be of interest to the Akka and its 
> community:
> 1) I have working versions of the following delta-CRDTs: Enable-Wins-Flag, 
> Multi-Value-Register, Add-Wins-Set, Remove-Wins-Set and Observed-Removed-Map 
> from "Delta State Replicated Data Types" by Almeida, Shoker and Baquero. 
> I noticed that an earlier paper was referenced in 
> http://doc.akka.io/docs/akka/current/scala/distributed-data.html 
> . I also 
> see some tickets referencing this functionality, but they are either closed 
> or low-priority. I would be willing to try to fit it into distributed-data, 
> if the interest is there.
> 2) I have naive implementations of combinators: map, filter, fold, union, 
> intersection and product for (an old implementation of) ORSet, from 
> Christopher Meiklejohns Lasp paper. An implementation for sharded AWSet, 
> RWSet and ORMap should be feasible and was actually next on my list. A 
> "scala-collections-feel" to collection-like-CRDTs would be useful and fitting 
> in Akka, imo. The combinators use is somewhat limited in a non-sharded 
> memory-only implementation, and I'm not sure how fellow Hakkers would feel 
> about having them? Adding sharding and persistence is on my todo-list, and I 
> wonder if an external module is the right way of adding this functionality to 
> Akka, if of interest at all?
> 
> Disclaimer: my experiments are just that, sloppy, inefficient code that 
> passes some unit tests for the functionality of interest, but still lacks an 
> API for proper composition into larger wholes; add to that the common "it's 
> only a spare-time project, unfortunately" means that nothing of what I 
> sketched above will be realized any time soon. I'm really just exploring 
> where my interests fit in the rest of the distributed-systems ecosystem. 
> Thanks for your attention thus far!
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message 

Re: [akka-user] Problems with Persistence when rolling nodes.

[Roland Kuhn]

Hi Robert,

I cannot comment on whether mysql-async has issues, but assuming that it does 
not this would point towards having two actors with the quoted persistenceId 
active at the same time.

Regards,

Roland

> 18 nov. 2016 kl. 17:49 skrev kraythe :
> 
> Greetings, I am currently using the community plugin for mysql 
> ("com.github.mauricio" %% "mysql-async" % "0.2.16")  for AKKA persistence. 
> However, when I perform a rolling restart I get exceptions like the 
> following: 
> 
> Nov 18 10:11:20 vtest-app01 application-9001.log:  2016-11-18 16:11:19 + 
> - [ERROR] - [PersistentShardCoordinator] 
> akka.tcp://app@10.77.21.34:2551/system/sharding/UserActivityActorCoordinator/singleton/coordinator
>  -  Failed to persist event type 
> [akka.cluster.sharding.ShardCoordinator$Internal$ShardRegionRegistered] with 
> sequence number [837] for persistenceId 
> [/sharding/UserActivityActorCoordinator].
> Nov 18 10:11:20 vtest-app01 application-9001.log:  
> com.github.mauricio.async.db.mysql.exceptions.MySQLException: Error 1062 - 
> #23000 - Duplicate entry '3-837' for key 'PRIMARY'
> Nov 18 10:11:20 vtest-app01 application-9001.log: at 
> com.github.mauricio.async.db.mysql.MySQLConnection.onError(MySQLConnection.scala:124)
> Nov 18 10:11:20 vtest-app01 application-9001.log: at 
> com.github.mauricio.async.db.mysql.codec.MySQLConnectionHandler.channelRead0(MySQLConnectionHandler.scala:105)
> Nov 18 10:11:20 vtest-app01 application-9001.log: at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> 
> Now I grant that this may be because of the persistence plugin having issues 
> but I am wondering if there is something else I am doing wrong in the 
> shutdown. The steps I used to shut down the rolling node are: 
> 
> 1. I send each shard region a graceful shutdown instance and wait for them 
> all to terminate
> 2. send all the top level actors a PoisonPill
> 3. issue a cluster leave and wait for the member to be removed 
> 4. After a 10 second delay terminate the actor system. 
> 
> Is there another persistence plugin that would potentially suit my needs 
> better? I would prefer to store the journal and snapshots in our main SQL 
> based RDBMS if possible but I am open to options. 
> 
> Thanks
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Exposing Akka actors through a REST API

[Roland Kuhn]

Ah, right, I did not understand it that way. Then we are on perfect 
agreement—which is how it should be :-)

Regards, Roland 

Sent from my iPhone

> On 13 Nov 2016, at 15:04, Konrad Malawski <konrad.malaw...@lightbend.com> 
> wrote:
> 
> I think we misunderstood each other somehow.
> I understood your goal is to have "one route" that somehow directly routes 
> requests to representative actors (somehow it sounded to me like you have 
> deep hierarchies you want to expose like that).
> 
> In that sense the "route" would be driven by the structure of your actor tree 
> in a 1:1 way.
> This I'm not sure is very good as it binds your API structure directly to the 
> actor tree.
> 
> If we're talking about something like:
> 
> path("users" / name) { name =>
>   actors(name) ! something
> }
> 
> 
> that's totally fine. I'd just be cautious of not adding too much magic and 
> creating the route magically from the actor tree structure, as in:
> path(part / part2 / part3) { (p1, p2, p3) =>
>   actorSelection(p1 ...) ! ...
> }
> 
> This starts to feel like "exposing your tree" (and also could lead to people 
> exploiting this by passing weird things in `part`.
> 
> -- 
> Konrad `ktoso` Malawski
> Akka @ Lightbend
> 
>> On 12 November 2016 at 12:47:28, Roland Kuhn (goo...@rkuhn.info) wrote:
>> 
>> I'm not sure I agree with Konrad here: what is wrong with using an HTTP 
>> route to expose an actor as service endpoint? This does not imply that the 
>> actual implementation needs to be structured accordingly, the backend is 
>> completely independent a priori. The role of the composable route snippet is 
>> data transport (marshalling, protocol handling) and the actor endpoint 
>> orchestrates the collaboration of backend services.
>> 
>> Regards, Roland 
>> 
>> Sent from my iPhone
>> 
>> On 12 Nov 2016, at 12:10, Alvaro Santuy <asan...@gmail.com> wrote:
>> 
>>> :-(
>>> 
>>> Ok, so I guesss the "correct" pattern is to always use a "Service Layer" 
>>> (non-Akka, so not an actor) between the actors and the REST exposition.  Am 
>>> I correct?
>>> 
>>>> On Thursday, November 10, 2016 at 4:28:10 PM UTC+1, Alvaro Santuy wrote:
>>>> Hello everybody.
>>>> 
>>>> Is there any project out there capable to easily build REST routes to Akka 
>>>> Actors? I would like to map REST resources to Akka Actors and messages 
>>>> other than manually encode the routes in Akka HTTP...
>>>> 
>>>> Thank you.
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: 
>>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google Groups 
>>> "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Exposing Akka actors through a REST API

[Roland Kuhn]

I'm not sure I agree with Konrad here: what is wrong with using an HTTP route 
to expose an actor as service endpoint? This does not imply that the actual 
implementation needs to be structured accordingly, the backend is completely 
independent a priori. The role of the composable route snippet is data 
transport (marshalling, protocol handling) and the actor endpoint orchestrates 
the collaboration of backend services.

Regards, Roland 

Sent from my iPhone

> On 12 Nov 2016, at 12:10, Alvaro Santuy  wrote:
> 
> :-(
> 
> Ok, so I guesss the "correct" pattern is to always use a "Service Layer" 
> (non-Akka, so not an actor) between the actors and the REST exposition.  Am I 
> correct?
> 
>> On Thursday, November 10, 2016 at 4:28:10 PM UTC+1, Alvaro Santuy wrote:
>> Hello everybody.
>> 
>> Is there any project out there capable to easily build REST routes to Akka 
>> Actors? I would like to map REST resources to Akka Actors and messages other 
>> than manually encode the routes in Akka HTTP...
>> 
>> Thank you.
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Abstracting away CommitableMessage

[Roland Kuhn]

Yes, indeed: if it is strictly 1:1 and it retains the order of the messages, 
then this works. Thanks for the sample!

Regards,

Roland

> 26 okt. 2016 kl. 22:12 skrev Itamar Ravid :
> 
> Broadcast/Zip if your existing flow is 1:1. Here's a sample: 
> https://github.com/iravid/stream-processing-talk/blob/master/GraphDSL.scala#L86
> 
> -- 
>>> Read the docs: http://akka.io/docs/
>>> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Abstracting away CommitableMessage

[Roland Kuhn]

Hi Richard,

unfortunately this is not possible in general: you would need to define exactly 
how the extra data (i.e. the commit token) is transported together with the 
data it belongs to through all possible stages. The answer from category theory 
would be a functor, but how do you define one for conflate/expand/fold/etc.? 
Another approach could be to limit the nested flow to only one element at a 
time so that the metadata stay valid in the surrounding context, but there you 
run into the same problem: what if you have stateful stages or how do you 
determine that the element has been dropped? (timeouts are never a real 
solution, only an approximate safe-guard or band-aid)

Notice that none of this is specific to Akka Streams, this is a problem for all 
stream processing that has stages that do not emit one value for each input.

Having said all that, it is possible to implement what you want for a subset of 
operations where it makes sense, and in principle type classes or extension 
methods are a suitable vehicle. Unfortunately you’ll have to implement the type 
machinery specifically for all four FlowOps subtypes (Source, Flow, SubSource, 
SubFlow). I have not yet tried out whether the partial fix for SI-2712 that 
will be in Scala 2.12.0 and 2.11.9 is sufficient to make this generic—I won’t 
say “easy” in any case, because the types you’ll encounter will certainly be 
daunting.

I’d love to sink my teeth into this problem, but unfortunately I don’t have 
time for that right now :-(

Regards,

Roland

> 26 okt. 2016 kl. 18:49 skrev Richard Rodseth :
> 
> Poorly chosen title.
> By abstract away, I meant I want to reuse an existing Flow rather than having 
> to rewrite it to use CommitableMessages all the way through.
> So I think I may need something like a nested flow (the "job") in a stage 
> that hangs onto the current CommitableMessage.
> 
> 
> On Wed, Oct 26, 2016 at 9:23 AM, Viktor Klang  > wrote:
> what would happen if that stage would silently discard the CommittableMessage?
> 
> -- 
> Cheers,
> √
> 
> 
> On Oct 26, 2016 6:09 PM, "Richard Rodseth"  > wrote:
> I'm planning to use a commitableSource from akka-streams-kafka.
> 
> Is there a way to re-use an existing Flow that knows nothing about Kafka, 
> extracting the record value and reconstituting the CommitableMessage at the 
> end of the flow?
> 
> In the past I've experimented with using TypeClasses in my flow definition 
> signatures, but it got a bit messy.
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> 

Re: [akka-user] Re: Akka http vs Spray performance

[Roland Kuhn]

Hi Olga,

establishing a connection is a very expensive operation, which is why all 
modern clients/browsers reuse them for multiple requests. The ab tool needs the 
-k switch to enable this behavior.

Regards, Roland 

Sent from my iPhone

> On 5 Oct 2016, at 01:32, Olga Gorun  wrote:
> 
> 
> I tried to repeat this benchmark and would be glad to see comments to results 
> I got.  
> Tested porjects: gists from original post with the following versions: 
> 
> akka-http, 2.4.11 vs spray, 1.3.1 (akka - 2.3.6). In both cases scala 2.11.8, 
> jvm 8.
> 
> The tests were done on AWS machine of c4.2xlarge type (8 cores CPU, 16GB 
> memory, ulimit - 50). As I can see from jvm and system monitoring, it is 
> far from being limited by CPU, memory, disk IO or networking. OS: Ubuntu 14.04
> 
> See results at: 
> https://docs.google.com/spreadsheets/d/1yuFD7WDOzhWB5_Ob7XgAfFAdWt48SrthbvZSZ45GE-k/edit?usp=sharing
> 
> Starting from the fact that my results are different (spray gives better 
> results than akka-http). In addition I see interesting effects when I use 
> different benchmark tools. I also started from wrk, but in addition to 
> throughput I wanted to see failures if exist, and latency percentiles, so I 
> added  tests with weighttp and ab. 
> 
> Throughput reported by ab is much different than the rest and shows drastic 
> difference between akka-http and spray. Reported latency also don't have much 
> in common. I can think that ab (as a single-threaded tool) can be bottleneck 
> itself. But how to explain such a difference in throughput for akka-htttp and 
> spray? And how to explain difference in reported latency.
> 
> Regards,
> Olga Gorun
> 
> 
> 
>
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Ask or Tell ?

[Roland Kuhn]

> 3 okt. 2016 kl. 14:30 skrev gervais.b :
> 
> Hello,
> 
> I'm fairly new with Akka (and maybe the whole question below is polluted by 
> my synchronous background). In my app, I have to parse 2 CSV available as 
> HTTP, I plan to access them from one actor that accept two messages (one per 
> csv). But I should add another HTTP resources next week. So I'm planning to 
> create one 'HttpFetch'. My question is about the reply for this actor. Should 
> use tell or ask ? 
> 
> With ask everything seems simple, I ask for a resource and receive a Future 
> that I can map. But I have the feeling that ask must be used in border cases.
> With tell then the 'HttpFectch' actor will receive 'Get(target:URI)' and send 
> the response later with a 'Got(target: URI, response:..)'. That's nice and 
> looks simple also. But I have to combine the result of the two CSV (find 
> "tag" in first and filter lines of second based on this "tag"). So I have to 
> maintains state in my actor and I know this is a bad idea.

Maintaining state is the only point of an actor, that’s definitely not a bad 
idea :-) Where did you get the notion that actors should be stateless?

> So, what is the best pattern to send and combine the response of two messages 
> ?

I’d prefer the tell variant and create a new Actor for each such combination. 
This way you can focus on the business logic without getting distracted by 
incidental concerns like managing multiple such processes in parallel—which 
would then be governed by the actor library for you.

Regards,

Roland

> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Control how much cpu are used by the actor system?

[Roland Kuhn]

Hi Jean-François,

the JVM does not offer the functionality you seek, you'll have to use your 
operating system’s capabilities to restrict the resources available to the JVM 
itself.

Regards, Roland 

Sent from my iPhone

> On 30 Sep 2016, at 18:29, Jean-François Côté  
> wrote:
> 
> Hi guys! 
> 
> Is there any way to control how much cpu the akka system use over the total 
> of cpu available in the JVM? For example, I would want all my actor system to 
> only use 75% of the processing power available so that 2 of my 8 core is 
> available for other system on the server. I've checked dispatcher, router, 
> etc but nothing seems to control this kind of thing. But maybe I missed 
> something.
> 
> Thanks!
> J-F
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] how to enable secure tcp socket connection on server side in Akka

[Roland Kuhn]

The library you’re looking for is Akka Streams, not bare Akka IO. Coming from 
Mina you might want to read 
http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html 
 about 
how protocol pipelines are expressed.

Unfortunately I cannot seem to find the documentation section that contained 
the TLS example (nor the BidiFlow). Endre, has this been removed? We should 
definitely have docs for this use-case, HTTPS is not the only thing that uses 
TLS ;-)

Regards,

Roland

> 30 sep. 2016 kl. 07:14 skrev Gaurav Kumar Jayswal :
> 
> Thanks for you reply. I'm new in akka. I didn't get how to enable secure tcp 
> chat server, while binding. Can you plz give some example code...
> 
> Tcp.get(getContext().system()).manager().tell(TcpMessage.bind(getSelf(), 
> inetSocketAddress, 100), getSelf());
> 
> On Thursday, 29 September 2016 17:01:47 UTC+5:30, Konrad Malawski wrote:
> Please refer to the documentation: 
> http://doc.akka.io/docs/akka/2.4.10/java/http/server-side-https-support.html#ssl-config-java
>  
> 
> 
> It has a nice search box which you can use to search for "SSL".
> 
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
> On 29 September 2016 at 13:28:51, Gaurav Kumar Jayswal (me.ga...@gmail.com 
> ) wrote:
> 
>> In Mina Simply I have added by this. 
>> 
>> private static void addSSLSupport(DefaultIoFilterChainBuilder chain) throws 
>> Exception {
>>SslFilter sslFilter = new SslFilter(new 
>> SSLContextGenerator().getSslContext());
>>chain.addFirst("sslFilter", sslFilter);
>> }
>> 
>> Can anyone let me know how to add sslcontext in Akka tcp 
>> --
>> >> Read the docs: http://akka.io/docs/ 
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >> 
>> >> Search the archives: https://groups.google.com/group/akka-user 
>> >> 
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/akka-user 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [Akka Stream] Happens-before relation and runForEach

[Roland Kuhn]

Technically I'm not sure this is correct: since f is only called from within a 
single operator (and assuming only a single materialization) the shown code 
should work just fine. Of course it is necessary to know what you're doing when 
coding like this, and as Konrad says there are better alternatives available, 
but guaranteeing ordering for example for db writes would certainly be 
desirable.

Regards, Roland 

Sent from my iPhone

> On 21 Sep 2016, at 01:33, Konrad Malawski  
> wrote:
> 
>> 
>> final Source source = // ...
>> final MutableInt max = new MutableInt(Integer.MIN_VALUE);
>> final Procedure f = i -> {
>>   if (i > max.intValue()) {
>> max.setValue(i);
>>   }
>> };
>> final CompletionStage result = source
>> .runForeach(f, materializer)
>> .thenApply(__ -> max.intValue());
>> 
>> Is the above code correct in the sense that it always commutes the maximum 
>> (or MIN_VALUE in case the stream is empty)?
>> 
>> According to Akka Stream documentation on Stream Ordering, there is a Java 
>> happens-before relation between invocations of f. Do I still need to use 
>> AtomicInteger so that the effects are seen by all threads?
> 
> You're side-effecting outside the stream, so nothing is guaranteed.
> 
> Yes, it would have to be an atomic integer.
> 
> 
> 
> Instead consider using a better operator for this kind of thing than foreach 
> - like fold (runFold) which is enough for such operation you're doing here.
> 
> 
> 
> Happy hakking.
> 
> -- konrad
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-streams] It is not possible to create Graph with the custom shapes

[Roland Kuhn]

Hi Sergey,

Just add your custom stage using builder.add() and then write the ports of the 
resulting Shape using the normal GraphDSL methods. There is no need to make the 
wiring aware of your special shape.

Regards, Roland 

Sent from my iPhone

> On 19 Sep 2016, at 22:35, Sergey Sopin  wrote:
> 
> Hi,
> 
> Due to performance reasons I decided to create my new custom Shape with 
> several inlets and several outlets (5 in and 3 out in my case). Then I 
> decided to create Graph with the new element and realized that it is not 
> possible without rewriting Graph object. In order to create my own shape I 
> had to create new class which extends Shape one. Then I created custom logic 
> by creating new class which extends GraphStage>. And 
> everything was good. 
> Then while creating graph I realized that my class contains more than one 
> input and one output, so neither UniformFanOutShape nor UniformFanInShape can 
> be used in graph. Due to that fact I created my own BiDirFanShape which 
> contains more than one inlet and one outlet. It allowed me to add my new 
> shape in a graph. But, then I realized that I am not able to connect my shape 
> with others because there are no functions "via" or "to" in a Builder which 
> take such arguments. So now, I have to rewrite object GraphDSL in order to 
> add there such functions. 
> It seems a bit painful. Probably I missed something, but I think that in case 
> you allow to create custom shapes you should have some generic mechanism that 
> allows to work with the newly created elements. I cannot even override 
> ForwardOps and ReverseOps classes because it are final... Could you please 
> let me know if I missed something and there is a better solution?
> 
> Thank you in advance!
> 
> Best regards,
> Sergey
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] probe does not get Terminated message

[Roland Kuhn]

Hi Aditya,

Terminated is only sent upon termination, not for a restart: an ActorRef stays 
valid across a restart so it would be wrong to signal that it becomes invalid 
(which is what Terminated means).

Regards,

Roland

> 16 sep. 2016 kl. 08:02 skrev Aditya Prasad :
> 
> Howdy y'all,
> 
> I'm using a TestKit probe. It receives most messages just fine. But somehow 
> it's not noticing the termination of my actor:
> 
> probe.watch(repActor)
> probe.expectTerminated(repActor, eventTimeout.plus(100.milliseconds))
> 
> I get:
>  
> [info]   java.lang.AssertionError: assertion failed: expected: Terminated 
> Actor[akka://ReplicatorSpec/user/$a#-968221567] but got unexpected message 
> Foo(0)
> [info]   at scala.Predef$.assert(Predef.scala:170)
> [info]   at akka.testkit.TestKitBase$class.expectMsgPF(TestKit.scala:369)
> ... 
> 
> Through logging, I can confirm that (a) the actor did die, and (b) the Foo(0) 
> message is the first thing the actor sends after it restarts (and that's the 
> only time it is sent).
> 
> I'm guessing there's something funky about my setup, but I'm not sure where 
> to start digging. I was thinking using OneInstancePerTest might be helpful 
> (as seen in another bug report) but that causes its own problems.
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [Remote] run akka remotely with a specific ClassLoader

[Roland Kuhn]

This seems more like a configuration problem: you could try to logConfiguration 
to check whether the right settings are applied on both ActorSystems (local & 
remote) and if that does not show anything suspicious then switch on the remote 
debugging options 
.

Regards,

Roland

> 15 sep. 2016 kl. 10:35 skrev Viktor Klang :
> 
> You'll need to provide the ActorSystem (see the .create/.apply methods on 
> ActorSystem) with a ClassLoader which has access to the classes that you 
> intend to load.
> 
> On Thu, Sep 15, 2016 at 11:09 AM, Benjamin Danglot  > wrote:
> Hello,
> 
> I am trying to run akka remotely into a IDEA plugin. First of all, I managed 
> to run akka locally and remotely outside of the plugin framework development.
> 
> Then, I run akka locally (two actors that exchange messages) into the plugin 
> framework. I managed to do so by specify the classloader (The 
> PluginClassloader developed by IntelleJ) when i build the ActorSystem (the 
> solution come from https://github.com/freewind/idea-plugin-akka-demo 
> )
> 
> Now I want to run akka remotely into the plugin. I setted up a little example 
> : https://gist.github.com/danglotb/4300bd36ca2e563a05c673395df1c076 
> 
> 
> But yet, I was not able to retrieve the ActorRef that is running remotely, 
> the ActorSystem returns a 'DeadLetter' instead.
> 
> I know it is because of the Specific ClassLoader of the Plugin FrameWork, but 
> I do not know what it is missing intoto run akka remotely. (in the Git Gist, 
> there is the content of this classloader)
> 
> Could you please give me some lead in order to solve this issue?
> 
> Best,
> 
> Benjamin.
> 
> Dependencies : IDEA CE IC-162.1812.17(SDK), scala 2.11.8, akka-actor 
> 2.11-2.4.10,akka-remote 2.11-2.4.10, akka-protobuf 2.11-2.4.10, config-1.3.10 
> (from akka lib). dependencies to scala/akka added in the module dependencies 
> management as external jars. I can not use maven or sbt to manage my 
> dependencies.
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Cheers,
> √
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Sharing my attempt at contributing to Akka

[Roland Kuhn]

Ah, nice, I was not keeping up it seems! If we control the whole thing then it 
should actually be possible to add the second kind of link as well (directly to 
the snippet’s source).

Regards,

Roland

> 3 sep. 2016 kl. 08:30 skrev Patrik Nordwall :
> 
> Hi Omer,
> 
> Thanks for very valuable feedback. Your email in itself is a great 
> contribution. Thanks for taking the time to write it down. We need to improve 
> here.
> 
> We will migrate all documentation to Markdown with some extensions and 
> tooling called Paradox . After that we 
> should write a short guide focused on how to contribute to the documentation. 
> It's an excellent place to start for new contributors and we must remove the 
> friction.
> 
> First out is actually Akka Http. We will move it to a separate repository 
>  and will migrate its 
> documentation to Paradox in that process.
> 
> It will not happen overnight, but we will work on it. Help from community 
> with improving this and all other things in Akka is very much welcome.
> 
> Cheers,
> Patrik
> 
> 
> On Sat, Sep 3, 2016 at 12:23 AM, Omer van Kloeten  > wrote:
> Hi all,
> 
> First off, let me thank everyone here for their time and energy spent making 
> Akka the amazing toolset it is today.
> 
> Following the Akka developer survey I answered today, I realized I wanted to 
> contribute to Akka and decided to just do it. Since I'm too much of a novice 
> in the details of Akka to solve any open issues and have not had enough 
> experience contributing to large open-source projects in the past, I decided 
> to start off small and contribute documentation.
> My idea was to contribute more code samples to the Custom Directives 
> 
>  page of akka-http to make modifiers more easy to understand.
> 
> The friction involved in the process of contributing made me abandon my 
> attempt. I'd like to share my experience:
> 
> I decided which three lines of code I wanted to contribute. Then I went into 
> the doc page itself and looked for a "contribute" / "edit" / etc. button or 
> the well known "fork me on github" button. None exists. Huh.
> As an aside, I knew the docs were on GitHub (basing this on a conversation I 
> had with Konrad back in Scala Days Berlin) but found no indicator that this 
> was the case on the page itself.
> 
> I went to Akka's GitHub repo and found CONTRIBUTING.MD 
> . I was greeted by a huge wall of text. I searched 
> for "doc" and found the part talking about documentation contribution (I 
> guess?) with a list of requirements and no examples or references (and a 
> confusing last two paragraphs). The references that did exist were to tools: 
> RST and Sphinx. Not sure about whether I need to learn either. I'm great with 
> Markdown, does that help? Also I need to start writing tests for my three 
> lines of code?
> 
> OK let's try to move forward - contributing can't be that hard. Next I 
> decided to just see where the actual docs existed so I searched the repo for 
> "Custom Directives" which raised too many results and then "Configuration 
> Labeling" (a subheader) which showed two results for docs, one for Scala and 
> one for Java. I have to write my sample code in both? this wasn't mentioned 
> anywhere.
> Reading the source of the file (custom-directives.rst) made me realize 
> samples were imported from external files. Where do I put mine?
> 
> I forked the repo, looked at my clock, realized 20 minutes have already 
> passed and that I have achieved almost nothing and decided I didn't have any 
> more time for this.
> 
> I'm sure you can empathize with my frustration, since all I wanted to do was 
> contribute three lines of code that would have made great strides towards 
> explaining something to a new user coming across the official docs. I know I 
> would have been super happy to see them when I first met that page.
> 
> Now I realize things are complicated - you want to verify all code, maintain 
> standards and so on, and I applaud your work - but we have to find a better 
> way to do it.
> 
> My dream docs contribution process? An in-place editor (wiki-style) where 
> after I add / change code, I wait for the code to compile (online) and my 
> tests to run (in a sandbox, of cource) and if they all do, it gets sent to a 
> moderator for approval (opens a pull request behind the scenes?). If only 
> text changed, it just opens that pull request.
> 
> I'll probably try contributing the samples anyway, but I'll wait until I have 
> maybe an hour or two to spend on it.
> 
> HTH,
> Omer
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> 

Re: [akka-user] Strange actor behavior with Akka Spring Integration

[Roland Kuhn]

d which messaging patterns are frequently needed—there happen to be 
> multiple nice books on this topic (e.g. Vaughn Vernon’s «Reactive Messaging 
> Patterns with the Actor Model» or Y.T.’s «Reactive Design Patterns»).
> 
> Regards,
> 
> Roland
> 
>> 20 aug. 2016 kl. 20:11 skrev Mark Kaberman <mkab...@ <>gmail.com 
>> <http://gmail.com/>>:
>> 
>> Hi Roland,
>> 
>> My understanding is (and if this understanding is incorrect that is the root 
>> cause of all my problems) that the things such as number of actors 
>> instances, type and configuration of the thread pool, type of the dispatcher 
>> etc. all all controlled by the routers. Without using the routers Akka 
>> system will only have one instance of each actor without any way to tweak 
>> that actor's behavior. Let's assume that in my (hypothetical) scenario 
>> Actor1 processes tens of millions of messages, but processes them very 
>> quickly. Actor2. Processes much fewermessages, but each message processing 
>> takes time. Actor3 could be something in-between. So I may want to have 
>> large number of instances of Actor1 and may be less for Actor2, but for 
>> Actor2 I want to use pinned dispatcher. Can I achieve all this without using 
>> multiple routers?
>> 
>> 
>> On Saturday, August 20, 2016 at 4:58:14 AM UTC-4, √ wrote:
>> 
>> On Aug 20, 2016 9:22 AM, "Roland Kuhn" <goo...@ <>rkuhn.info 
>> <http://rkuhn.info/>> wrote:
>> >
>> > Hi Mark,
>> >
>> > before we can move on, there is one important thing to do: as far as I can 
>> > see you are describing a broken solution, not the real problem. Please let 
>> > us take a step back to find a real solution.
>> >
>> > Interjection about Routers
>> >
>> > Routers are somewhat like actors that create some other actors—the Routees 
>> > for which you supply the Props—in order to distribute an incoming stream 
>> > of messages to them. The Router itself is an actual actor with a name (the 
>> > one you gave and that you use in the config) and a behavior; its ActorRef, 
>> > however, is a magical one, highly specialized in order to bypass the 
>> > Router actor for the dispatch of those messages you want to send. This is 
>> > only useful if you try to send more than about 3 million messages per 
>> > second to that Router; if you send less than that number please do not use 
>> > routers. Instead, create a normal actor and do the routing in there.
>> >
>> > The child actors created by the Router of course are real actors 
>> > themselves, and they also need names within the namespace of their parent 
>> > (which is the Router actor). These names cannot be given by you because 
>> > how would you tell the Router actor how it should name its own children? 
>> > This is another reason for not using Routers because they are highly 
>> > specialized for a purpose that I am pretty certain you don’t need here.
>> >
>> > Now to the problem
>> >
>> > From what I know you have three actors: actor1, actor2, actor3. Each of 
>> > these has a function, and each of these may or may not send messages to 
>> > the other two. There is absolutely no reason that actor2 should be a child 
>> > of actor1 if you only want to send messages from actor1 to actor2.
>> >
>> > So, start out with the following (and no, do not use system.actorOf in 
>> > here):
>> >
>> > // Using Scala because writing this in Java would only obscure the intent 
>> > // with useless boilerplate; I’m sure that you can extract the meaning.
>> >
>> > case class TheLineup(actor1: ActorRef, actor2: ActorRef, actor3: ActorRef)
>> >
>> > class TheBoss extends Actor {
>> >   val actor1 = context.actorOf(Props(new Actor1), "actor1")
>> >   val actor2 = context.actorOf(Props(new Actor2), "actor1")
>> 
>> "actor2"
>> 
>> >   val actor3 = context.actorOf(Props(new Actor3), "actor1")
>> 
>> "actor3"
>> 
>> >
>> >   // introduce the three actors to each other so they can talk
>> >   val lineup = TheLineup(actor1, actor2, actor3)
>> >   actor1 ! lineup
>> >   actor2 ! lineup
>> >   actor3 ! lineup
>> >
>> >   // route incoming messages to the appropriate destination
>> >   def receive = {
>> > case msg =>
>> >   if (shallGoTo1(msg)) actor1 ! msg
>> >   else if (sha

Re: [akka-user] Strange actor behavior with Akka Spring Integration

[Roland Kuhn]

Hi Mark,

an Actor is always a singleton, this is never different, also not with Routers. 
Every Routee is an Actor with a proper identity, with its own internal state 
and scheduling and so on. A Router cannot (and must not!) be thought of as 
“tweaking the behavior”—I’ll repeat my recommendation to abstain from using 
them until you have enough experience with Akka without them.

There are some aspects about your question that I’m uneasy about:

Using Routers as you describe only makes sense if the processing of those 
messages is completely stateless. As soon as the Routees store and change some 
internal state, then starting a handful of copies of each is going to mess up 
your business logic. If you use shared storage for your state (e.g. a 
ConcurrentHashMap or some [in-memory] database) then duplicating the business 
processing units to add capacity is of dubious utility due to the inherent 
coordination overhead.
Thinking that spawning more actors using Routers is a rate or load adaptation 
tool is not going to make you happy: actors need CPU to run and just creating 
30 of them will on most hardware not make things run 30 times as fast.
If you have a chain of processing steps that must happen then you must have 
flow-control between your actors. Actor2 must keep Actor1 appraised of its 
capacity so that Actor1 can slow down in order to not overwhelm Actor2.

It might be a good idea to read up on how to split up an application into 
actors and which messaging patterns are frequently needed—there happen to be 
multiple nice books on this topic (e.g. Vaughn Vernon’s «Reactive Messaging 
Patterns with the Actor Model» or Y.T.’s «Reactive Design Patterns»).

Regards,

Roland

> 20 aug. 2016 kl. 20:11 skrev Mark Kaberman <mkaber...@gmail.com>:
> 
> Hi Roland,
> 
> My understanding is (and if this understanding is incorrect that is the root 
> cause of all my problems) that the things such as number of actors instances, 
> type and configuration of the thread pool, type of the dispatcher etc. all 
> all controlled by the routers. Without using the routers Akka system will 
> only have one instance of each actor without any way to tweak that actor's 
> behavior. Let's assume that in my (hypothetical) scenario Actor1 processes 
> tens of millions of messages, but processes them very quickly. Actor2. 
> Processes much fewermessages, but each message processing takes time. Actor3 
> could be something in-between. So I may want to have large number of 
> instances of Actor1 and may be less for Actor2, but for Actor2 I want to use 
> pinned dispatcher. Can I achieve all this without using multiple routers?
> 
> 
> On Saturday, August 20, 2016 at 4:58:14 AM UTC-4, √ wrote:
> 
> On Aug 20, 2016 9:22 AM, "Roland Kuhn" <goo...@rkuhn.info > 
> wrote:
> >
> > Hi Mark,
> >
> > before we can move on, there is one important thing to do: as far as I can 
> > see you are describing a broken solution, not the real problem. Please let 
> > us take a step back to find a real solution.
> >
> > Interjection about Routers
> >
> > Routers are somewhat like actors that create some other actors—the Routees 
> > for which you supply the Props—in order to distribute an incoming stream of 
> > messages to them. The Router itself is an actual actor with a name (the one 
> > you gave and that you use in the config) and a behavior; its ActorRef, 
> > however, is a magical one, highly specialized in order to bypass the Router 
> > actor for the dispatch of those messages you want to send. This is only 
> > useful if you try to send more than about 3 million messages per second to 
> > that Router; if you send less than that number please do not use routers. 
> > Instead, create a normal actor and do the routing in there.
> >
> > The child actors created by the Router of course are real actors 
> > themselves, and they also need names within the namespace of their parent 
> > (which is the Router actor). These names cannot be given by you because how 
> > would you tell the Router actor how it should name its own children? This 
> > is another reason for not using Routers because they are highly specialized 
> > for a purpose that I am pretty certain you don’t need here.
> >
> > Now to the problem
> >
> > From what I know you have three actors: actor1, actor2, actor3. Each of 
> > these has a function, and each of these may or may not send messages to the 
> > other two. There is absolutely no reason that actor2 should be a child of 
> > actor1 if you only want to send messages from actor1 to actor2.
> >
> > So, start out with the following (and no, do not use system.actorOf in 
> > here):
> >
> > // Using Scala because writing this in

Re: [akka-user] Strange actor behavior with Akka Spring Integration

[Roland Kuhn]

Hi Mark,

before we can move on, there is one important thing to do: as far as I can see 
you are describing a broken solution, not the real problem. Please let us take 
a step back to find a real solution.

Interjection about Routers

Routers are somewhat like actors that create some other actors—the Routees for 
which you supply the Props—in order to distribute an incoming stream of 
messages to them. The Router itself is an actual actor with a name (the one you 
gave and that you use in the config) and a behavior; its ActorRef, however, is 
a magical one, highly specialized in order to bypass the Router actor for the 
dispatch of those messages you want to send. This is only useful if you try to 
send more than about 3 million messages per second to that Router; if you send 
less than that number please do not use routers. Instead, create a normal actor 
and do the routing in there.

The child actors created by the Router of course are real actors themselves, 
and they also need names within the namespace of their parent (which is the 
Router actor). These names cannot be given by you because how would you tell 
the Router actor how it should name its own children? This is another reason 
for not using Routers because they are highly specialized for a purpose that I 
am pretty certain you don’t need here.

Now to the problem

>From what I know you have three actors: actor1, actor2, actor3. Each of these 
>has a function, and each of these may or may not send messages to the other 
>two. There is absolutely no reason that actor2 should be a child of actor1 if 
>you only want to send messages from actor1 to actor2.

So, start out with the following (and no, do not use system.actorOf in here):

// Using Scala because writing this in Java would only obscure the intent 
// with useless boilerplate; I’m sure that you can extract the meaning.

case class TheLineup(actor1: ActorRef, actor2: ActorRef, actor3: ActorRef)

class TheBoss extends Actor {
  val actor1 = context.actorOf(Props(new Actor1), "actor1")
  val actor2 = context.actorOf(Props(new Actor2), "actor1")
  val actor3 = context.actorOf(Props(new Actor3), "actor1")

  // introduce the three actors to each other so they can talk
  val lineup = TheLineup(actor1, actor2, actor3)
  actor1 ! lineup
  actor2 ! lineup
  actor3 ! lineup

  // route incoming messages to the appropriate destination
  def receive = {
case msg =>
  if (shallGoTo1(msg)) actor1 ! msg
  else if (shallGoTo2(msg)) actor2 ! msg
  else if (shallGoTo3(msg)) actor3 ! msg
  }

  ...
}

TheBoss will be responsible for handling failures in the three actors, and you 
should probably also watch them and handle the Terminated messages.

I hope this helps,

Roland

> 20 aug. 2016 kl. 05:11 skrev Mark Kaberman <mkaber...@gmail.com>:
> 
> Here <https://groups.google.com/forum/#!topic/akka-user/36cetJSGmm0>. My 
> apologies: it wasn't Roland, but Konrad Malawsky. The issue I am 
> investigating is that if I use multiple routers in my path Akka creates huge 
> amount of actor's class  instances and the system runs out of memory If I 
> have three routers in my path with nr-of-instances 10 each Akka will create 
> 1000 actor class instances. My paths have tens of hops and number of actors 
> ends up being huge. Roland suggested here 
> <https://groups.google.com/forum/#!topic/akka-user/Egf8zXiIzBg> to create all 
> actors as children of the supervisor which essentially allows only one router.
> 
> On Friday, August 19, 2016 at 10:39:50 PM UTC-4, Justin du coeur wrote:
> On Fri, Aug 19, 2016 at 4:23 PM, Mark Kaberman <mkab...@gmail.com 
> > wrote:
> The fact that actor names are generated by Akka is also a concern. According 
> to Roland Kuhn that should be avoided. 
> 
> Hmm?  Where does Roland say that?  There are lots of perfectly ordinary 
> circumstances in which the Actor's name is generated by Akka, and routing 
> seems like one of the cases where I would expect that to be the case...
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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...@googleg

Re: [akka-user] Router path in Akka config

[Roland Kuhn]

Why do you conflate the route structure (i.e. the routing hops) with the 
supervisor hierarchy? This is usually a bad idea. Instead, create your three 
actors as children of a supervisor that introduces them to one another—and only 
introduce Routers once you have benchmarked that a single actor is not fast 
enough.

Regards,

Roland

> 19 aug. 2016 kl. 16:23 skrev Mark Kaberman :
> 
> Actually I only need 3 entry instead of 5 and I need to name my routers 
> differently:
> /actor1/router1/
> /actor1/router1/actor2/router2
> /actor1/router1/actor3/router2
> 
> but the point is still valid: I need to accommodate for all possible path 
> permutations in my routers definition.
> 
> On Friday, August 19, 2016 at 10:00:21 AM UTC-4, Mark Kaberman wrote:
> When I define a router in Akka's application.conf I always need to specify 
> the router path. If I have multiple possible routes the messages travel in my 
> application  the configuration file may become very complicated. An example: 
> I have three actors in my system: actor1, actor 2 and actor3. Actor1 can send 
> messages to 2 and 3. Actor 2 can send messages to 3 and actor 3 to 1. My 
> understanding it (and I may be completely wrong here) that I need to define 4 
> routers in my application.conf to accommodate for all paths:
> 
> /actor1/router/actor2
> /actor1/router/actor3
> /actor1/router/actor2/router/actor3
> /actor1/router/actor3/router/actor1
> 
> That will make my config file complex since I need to take into account all 
> possible path permutation. I can use a wildcard in order to avoid specifying 
> an actor name, but the number of elements in the path seems to have to match 
> the actual number of hops. Is there a way to define default router(s) in 
> order to avoid overly complex configuration file?
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How do we handel OversizedPayloadException in Akka

[Roland Kuhn]

Hi Prakash,

“handling exceptions” is not the most useful way to think about distributed 
systems—most of the exceptions are thrown outside of your call stack and 
therefore not visible at all. Failures must be communicated explicitly as 
messages instead. One core aspect here is that Akka is distributed to its core, 
even internally.

So no, you cannot handle such exceptions.

Regards,

Roland

> 17 aug. 2016 kl. 11:42 skrev prakash chinnaswamy 
> :
> 
> So you mean to say we cannot handle any run time exception?
> 
> On Wed, Aug 17, 2016 at 12:43 PM, Viktor Klang  > wrote:
> Then you need to prevalidate the message. Don't rely on serialization size 
> since that is a function of the serializer used.
> 
> -- 
> Cheers,
> √
> 
> 
> On Aug 17, 2016 7:53 AM, "prakash chinnaswamy" 
> > 
> wrote:
> Viktor. Tuning is not a possible solution in our case . we need to inform the 
> clint that the size is large and try with pagination. So we need to handel 
> this exception.
> 
> 
> On Tuesday 16 August 2016, Viktor Klang  > wrote:
> Prakash,
> 
> I think a possible solution is two-fold: start using a more efficient means 
> of serialization (which reduces payload sizes), and don't rely on exception 
> throwing to track lost messages (Akka is at-most-once delivery).
> 
> On Tue, Aug 16, 2016 at 1:40 PM, prakash chinnaswamy 
> > wrote:
> Viktor 
> 
> Could on get in what contest you are asking. Just add more information we use 
> Scala and it is a rest application where this application will talk to a play 
> server (having a remote actor). When trying to send a large record we get 
> this error. We would like to handle this error and send a warning message to 
> the client.
> 
> 
> On Tue, Aug 16, 2016 at 5:00 PM, Viktor Klang > 
> wrote:
> Hi Prakash,
> 
> Do you use Java Serialization?
> 
> On Tue, Aug 16, 2016 at 12:21 PM, prakash chinnaswamy 
> > wrote:
> We have a distributed application on akka cluster. Actor “A” sends message of 
> large size to a remote actor. And we get the following Warning.
> 
> 
> 
> 2016-08-10 23:08:29,737 [EndpointWriter] ERROR - Transient association error 
> (association remains live) akka.remote.OversizedPayloadException: Discarding 
> oversized payload sent to Actor[akka.tcp://abcd@127.0.0.1:51665/temp/$b 
> ]: max allowed size 128000 bytes, actual 
> size of encoded class common.data.model.configuration.UserList was 571444 
> bytes.
> 
> 
> 
> We are aware that we can increase the value in the 
> configuration(http://doc.akka.io/docs/akka/2.2.3/scala/remoting.html#Remote_Configuration
>  
> ).
>  
> 
> 
> 
> But we wanted to handel this OversizedPayloadException and send the message 
> to the client. 
> 
> 
> 
> Regards,
> 
> Prakash
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com <>.
> To post to this group, send email to akka-user@googlegroups.com <>.
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> 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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/oj4YsZpGYGs/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 

Re: [akka-user] Akka Spring integration seems to slowly leak memory

[Roland Kuhn]

I'll try to rephrase:

1) I think your problem is that you create one system per call and never shut 
it down. Don't do that.

2) don't use routers, please.

Sent from my iPhone

> On 22 Jul 2016, at 19:04, Mark Kaberman  wrote:
> 
> 1. Creating an AkkaSystem per POST does not help since each system will still 
> contain large number of actors.
> 
> 2. I am not sure I understand your comment about the routers. My 
> understanding is that if an actor is defined as 
> /someActor {
>router = round-robin-pool
>nr-of-instances = 10
> }
> 
> means that the round robin router will be used to deliver the messages to 10 
> instances of someActor and not that someActor is a router
> 
> 3. I think the problem lies in the way I am defining my actors in the 
> application.conf:  /rootActor/"*"/actor1/"*"/actor5/"*"/actor3 (not the use 
> of the wiled cards. If I define the actor as  /rootActor/actor1/actor5/actor3 
> the call
> actor = 
> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
>  FromConfig()), actorRouterName);
> 
> fails with the following exception
> 
> [ERROR] [07/22/2016 13:02:14.136] [AkkaDemo-akka.actor.default-dispatcher-3] 
> [akka://AkkaDemo/user/rootActor] configuration problem while creating 
> [akka://AkkaDemo/user/rootActor/$a/actor2] with router dispatcher 
> [akka.actor.default-dispatcher] and mailbox [akka.actor.default-mailbox] and 
> routee dispatcher [akka.actor.default-dispatcher] and mailbox 
> [akka.actor.default-mailbox]
> akka.ConfigurationException: configuration problem while creating 
> [akka://AkkaDemo/user/rootActor/$a/actor2] with router dispatcher 
> [akka.actor.default-dispatcher] and mailbox [akka.actor.default-mailbox] and 
> routee dispatcher [akka.actor.default-dispatcher] and mailbox 
> [akka.actor.default-mailbox]
>   at akka.actor.LocalActorRefProvider.actorOf(ActorRefProvider.scala:797)
>   at akka.actor.dungeon.Children$class.makeChild(Children.scala:273)
>   at akka.actor.dungeon.Children$class.actorOf(Children.scala:42)
>   at akka.actor.ActorCell.actorOf(ActorCell.scala:374)
>   at org.mark.demo.BaseActor.sendMessage(BaseActor.java:67)
>   at org.mark.demo.RootActor.onReceive(RootActor.java:38)Enter code 
> here...
> 
> 
> 
> 
> 
> 
> On Friday, July 22, 2016 at 5:03:32 AM UTC-4, rkuhn wrote:
>> 
>>> 21 juli 2016 kl. 18:39 skrev Mark Kaberman :
>>> 
>>> I was able to write a test app which reproduces the problem (attached). 
>>> Based on the application.conf I would expect 65 instances of the actors to 
>>> be created. When I start my actors (by executing POST request to 
>>> http://localhost:8080/start with no body) I see 385 instances created. 
>>> Which each sequential request extra 385 instances are added until the 
>>> system runs out of memory. 
>> 
>> I don’t know Spring that well, but could it be that you create one 
>> ActorSystem per POST request? (you can verify that by looking at the number 
>> of scheduler threads)
>> 
>> Another thing that I’m extremely curious about is why you are making all 
>> these actors routers—this just creates a huge number of actors, very likely 
>> many more than you have processors in your system. A tree of routers almost 
>> never makes sense.
>> 
>> Regards,
>> 
>> Roland
>> 
>>> 
 On Tuesday, June 14, 2016 at 10:47:55 AM UTC-4, rkuhn wrote:
 
> 14 juni 2016 kl. 16:28 skrev Mark Kaberman :
> 
> Hi Roland,
> 
> As I wrote in my original post my application traverses the tree. The 
> depth of the three is small and the paths are known in advance, but the 
> breath is very large. So I have relatively small number of actors (and 
> actorRouterName ) arguments
 
 This is only consistent if I assume that the breadth of the tree is small 
 and the depth is very large (because otherwise there would need to be a 
 very large number of actorRouterNames). In this case I guess that you are 
 simply creating way too many actors—and since you never stop them you will 
 eventually drown in them. Using routers of size 10 at every level is going 
 to explode exponentially as you are certainly aware …
 
 In any case: without seeing the full code (which I wouldn’t have time to 
 read) the most sensible hint is that you should use a memory analyzer to 
 verify my guess or find a different explanation (i.e. where all these 
 beans are coming from). Akka for sure does not create anything when 
 calling context().child(...).get() (which is easy to prove since no Props 
 are given).
 
 Regards,
 
 Roland
 
> 
> My Akka config looks approximately like:
> 
> /rootActor {
>  ...
> }
> 
> /rootActor/myActor1 {
>  ...
> }
> 
> /rootActor/myActor1/myActor2 {
>  ...
> }
> 
> /rootActor/myActor1/myActor2/myActor1 {
>  ...
> }
> 
> 

Re: [akka-user] Akka Spring integration seems to slowly leak memory

[Roland Kuhn]

> 21 juli 2016 kl. 18:39 skrev Mark Kaberman :
> 
> I was able to write a test app which reproduces the problem (attached). Based 
> on the application.conf I would expect 65 instances of the actors to be 
> created. When I start my actors (by executing POST request to 
> http://localhost:8080/start  with no body) I see 
> 385 instances created. Which each sequential request extra 385 instances are 
> added until the system runs out of memory. 

I don’t know Spring that well, but could it be that you create one ActorSystem 
per POST request? (you can verify that by looking at the number of scheduler 
threads)

Another thing that I’m extremely curious about is why you are making all these 
actors routers—this just creates a huge number of actors, very likely many more 
than you have processors in your system. A tree of routers almost never makes 
sense.

Regards,

Roland

> 
> On Tuesday, June 14, 2016 at 10:47:55 AM UTC-4, rkuhn wrote:
> 
>> 14 juni 2016 kl. 16:28 skrev Mark Kaberman >:
>> 
>> Hi Roland,
>> 
>> As I wrote in my original post my application traverses the tree. The depth 
>> of the three is small and the paths are known in advance, but the breath is 
>> very large. So I have relatively small number of actors (and actorRouterName 
>> ) arguments
> 
> This is only consistent if I assume that the breadth of the tree is small and 
> the depth is very large (because otherwise there would need to be a very 
> large number of actorRouterNames). In this case I guess that you are simply 
> creating way too many actors—and since you never stop them you will 
> eventually drown in them. Using routers of size 10 at every level is going to 
> explode exponentially as you are certainly aware …
> 
> In any case: without seeing the full code (which I wouldn’t have time to 
> read) the most sensible hint is that you should use a memory analyzer to 
> verify my guess or find a different explanation (i.e. where all these beans 
> are coming from). Akka for sure does not create anything when calling 
> context().child(...).get() (which is easy to prove since no Props are given).
> 
> Regards,
> 
> Roland
> 
>> 
>> My Akka config looks approximately like:
>> 
>> /rootActor {
>>  ...
>> }
>> 
>> /rootActor/myActor1 {
>>  ...
>> }
>> 
>> /rootActor/myActor1/myActor2 {
>>  ...
>> }
>> 
>> /rootActor/myActor1/myActor2/myActor1 {
>>  ...
>> }
>> 
>> 
>> - The actors are never stopped. The idea was to reuse the actors. They were 
>> only supposed to be stopped as result of supervision strategy triggered by 
>> traversal failures.
>> 
>> - My actors are implemented as Spring beans. I am using Akka/Spring 
>> integration from here 
>> 
>> 
>> - sendAkkaMessage called from the context of the parent actor: as part of 
>> the vertex discovery I determine if a vertex has children and if yes, of 
>> what type. Then I call  sendAkkaMessage  with the proper parameters from the 
>> context of an actor which is currently processing the vertex. 
>> 
>> 
>> On Tuesday, June 14, 2016 at 9:29:37 AM UTC-4, rkuhn wrote:
>> Hi Mark,
>> 
>> it is not easy to help you due to insufficient information:
>> 
>> How many different actorRouterName arguments can there be? Will the 
>> resulting number of actors fit into memory?
>> Do you or do you not stop all created actors eventually? Stopping an actor 
>> requires a call to context().stop(self()) on every routee.
>> You talk about beans, but actors are not beans: where do you create beans 
>> and are you certain that you do not retain references that prevent them from 
>> being collected? (You should log from postStop() instead of from the 
>> finalizer to see whether an actor gets stopped.)
>> What is the context in which the sendAkkaMessage method is called? How many 
>> of these contexts exist?
>> 
>> Regards,
>> 
>> Roland
>> 
>>> 14 juni 2016 kl. 14:39 skrev Mark Kaberman gmail.com 
>>> >:
>>> 
>>> It does not. 
>>> 
>>> On Tuesday, June 14, 2016 at 8:14:20 AM UTC-4, √ wrote:
>>> Is supervision triggering? (i.e. restarts, possibly creating new beans)?
>>> 
>>> On Tue, Jun 14, 2016 at 2:03 PM, Mark Kaberman gmail.com 
>>> > wrote:
>>> I added the static instantiation counter to my actor Spring bean (see my 
>>> original post). When an actor is created via getContext().ActorOf(... I see 
>>> number of logging entries coming from the bean's constructor indicating 
>>> that n instances of the actor beans has been created where n matches 
>>> nr-of-instances from my Akka config. When context().child.(..).get() is 
>>> called, I see a single logging entry coming from bean's constructor 
>>> indicating that a singe actor bean has been created. My logging indicates 
>>> that  getContext().ActorOf(.. is only called once per actor, but 
>>> context().child.(..).get()  is called constantly (as it should). So 

Re: [akka-user] ANNOUNCE: New Remoting Milestone 3

[Roland Kuhn]

Very impressive, congratulations!

> 8 juli 2016 kl. 17:24 skrev Patrik Nordwall :
> 
> Dear hakkers,
> 
> We are pleased to announce the availability of the third development 
> milestone of the new Akka Remoting, codenamed Artery. It’s an early 
> development preview and we encourage you to try it out and give us feedback, 
> but it’s not intended for production usage yet.
> 
> The version number is 2.4-ARTERY-M3 with same artifacts as usual. 
> 
> It is enabled with the following configuration:
> 
> akka.remote.artery {
>   enabled = on
>   # The hostname or ip clients should connect to.
>   hostname = localhost
>   # use 0 if you want a random available port
>   port = 20200
> }
> 
> The protocol part of the actor system address is artery, so you need to 
> change previous akka.tcp to artery in for example configuration of cluster 
> seed-nodes.
> 
> A summary of what is included in M3 compared to M2 
> ::
> 
> compression of sender and recipient actor references in the message envelope 
> header, explained below
> performance improvements, results below
> various bug fixes, all relevant remoting tests are now passing
> 
> The full list of changes since the last milestone is available under the 
> 2.4-ARTERY-M3  milestone 
> on github for your reference.
> 
> The most exciting new feature in this milestone is the envelope header 
> compression. For small messages the sender and recipient Actor references 
> that are included in each remote message can be a large fraction of the total 
> payload since they are encoded as string representation of the full ActorPath 
> and the Actor’s UID. To reduce the message header size we have developed a 
> smart compression algorithm. The most commonly used sender and recipient refs 
> are detected by the recipient system and announced as a compression table to 
> the sender system. Then the sender can encode those actor references as 
> integers indexing the announced compression table. The same thing is also 
> done for serialization manifest strings. Overall allowing us to save up to 
> hundreds of bytes per message that would have otherwise have be transferred 
> over the wire (costing time and resources).
> 
> Another thing that some of you might find interesting is performance. We have 
> now measured the following between two m4.4xlarge EC2 instances (1 Gbit/s 
> bandwidth) using the MaxThroughputSpec 
> 
>  and LatencySpec 
> :
> 
> 630,239 messages/s with message payload of 100 bytes
> 8,245 messages/s with messages payload of 10,000 bytes
> Round trip latency at a message rate of 10,000 messages/s: 50%ile: 155 µs, 
> 90%ile: 173 µs, 99%ile: 196 µs
> 
> We are using Aeron  as the underlying 
> transport and are implementing the layers on top using Akka Streams. You find 
> more details in the design document 
> .
> 
> The development branch is artery-dev 
> , in case you want to take a 
> look or contribute. Issues are labeled with t:remoting:artery 
> .
> 
> We are now taking a “summer break” from Artery development. We don’t only 
> need vacation, but we also have some other important areas to work on before 
> finalizing Artery. You find our  sprint plans at akka/akka-meta 
> . The goal is to complete Artery in 
> end of August and September and then release it in a 2.4.x version of Akka as 
> an optional transport.
> 
> Happy hakking!
> 
> -- 
> 
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> 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 

Re: [akka-user] Is it possible to increase the number of serialization threads?

[Roland Kuhn]

Doesn't the classical remoting perform serialization within the single actor 
responsible for each connection?

Sent from my iPhone

> On 03 Jul 2016, at 12:57, Viktor Klang  wrote:
> 
> Eduardo, are you sure that there aren't any synchronized-blocks or locks 
> used? (i.e. is this a contention problem rather than a paralellization 
> problem?)
> 
>> On Sun, Jul 3, 2016 at 12:28 PM, Eduardo Fernandes  wrote:
>> Ups... sorry for misunderstanding your question. 
>> 
>> My principal problem is not the overhead itself. My problem is that I can't 
>> get more threads serializing objects to a node. Example: one client I have 
>> 30%, lets say. If I add other client talking to other actor instance in 
>> parallel I would expect around 60% cpu usage in my server (I have 6 threads 
>> minimum and I'm pretty sure that the configuration would enable that from 
>> workers and netty perspective).  Nevertheless I get around 40% of my 8 cores 
>> machine working. If I put the actors in different processes I get the 60% I 
>> was expecting. When I say server I mean an actorsystem process (a single 
>> java process). 
>> 
>> Thanks again for your help.
>> 
>>> On Sun, Jul 3, 2016 at 11:55 AM, Viktor Klang  
>>> wrote:
>>> Hi Eduardo,
>>> 
>>> I meant the overhead of the Java Serialization envelope.
>>> 
 On Sat, Jul 2, 2016 at 10:12 PM, Eduardo Fernandes  
 wrote:
 Hi Viktor.
 
 I'm using basic (binary) serialization of basic Java types (int, String 
 (UTF), long, arrays of basic types, etc...). 
 
 The overhead is that depending of internal values there is no send to 
 serialize some members and other not. If you merge your functional logic 
 with the serialization you can make optimizations that a generic 
 serializar can't do. Example. Suppose that if a member A has a null value 
 you don't have to serialize other member B. Maybe the member B you don't 
 have to serialize could have a null value which is fast to serialize but 
 it is even faster you don't have even to serialize the null. This type of 
 overhead is only possible if the serializer knows about your functional 
 logic. 
 
 Regards 
 
> On Sat, Jul 2, 2016 at 10:05 PM, Viktor Klang  
> wrote:
> Hi Eduardo,
> 
> Perhaps I misunderstood, what serialization format are you emitting in 
> your readObject/writeObject?
> What overhead are you observing compared to using a custom Serializer?
> 
>> On Sat, Jul 2, 2016 at 10:02 PM, Eduardo Fernandes  
>> wrote:
>> Hi.
>> 
>> If you have writeObject/readObject defined in your class the Java plain 
>> serialization will invoke those methods. In my case all my internal 
>> members and class references are also serialized using the very same 
>> technique. So this is equivalent to technologies like kryo and similars 
>> since there is no overhead if you serialize basic members. In other 
>> words the pre-compiles classes you get from kryo are already made so 
>> there is no performance enhancement in this case. The big advantage of 
>> kryo is that you don't have to create the writeObject/readObject by 
>> yourself. In my particular case I've already done that job and my 
>> serialization is optimized in particular cases where I don't have to 
>> serialize all members depending of my semantic. I've made some tests and 
>> doing this way is faster than kryo but you have to burn some calories 
>> implementing a optimized serialization code. 
>> 
>> Bests regards and thanks for your comment.
>> 
>> 
>>> On Sat, Jul 2, 2016 at 9:27 PM, Viktor Klang  
>>> wrote:
>>> I'm not sure I understand why write/readObject special methods would 
>>> necessarily be faster? Most of the waste of Java Serialization is its 
>>> envelopes and using class names etc.
>>> 
 On Sat, Jul 2, 2016 at 1:14 AM, Eduardo Fernandes  
 wrote:
 Hi.
 
 I'm using Akka 2.3.13, Java edition.
 
 I'm making some performance tests and in the same machine with 8 cores 
 I see that the serialization process is my bottleneck.  I know that 
 because after an increment of actor cpu usage the throughput is 
 exactly the same. 
 
 My actor system talks to 2 other nodes so I see 2 cores dedicated to 
 serialization. Is is possible to increase the number of threads for 
 serialization?
 
 I'm using standard Java serialization but I have my own serialization 
 implementation in my write/readObject methods so I think that 
 switching to kryo or similar will not enhance too much the throughput. 
 
 Many thanks for your help.
 

Re: [akka-user] Akka Spring integration seems to slowly leak memory

[Roland Kuhn]

Hi Mark,

it is not easy to help you due to insufficient information:

How many different actorRouterName arguments can there be? Will the resulting 
number of actors fit into memory?
Do you or do you not stop all created actors eventually? Stopping an actor 
requires a call to context().stop(self()) on every routee.
You talk about beans, but actors are not beans: where do you create beans and 
are you certain that you do not retain references that prevent them from being 
collected? (You should log from postStop() instead of from the finalizer to see 
whether an actor gets stopped.)
What is the context in which the sendAkkaMessage method is called? How many of 
these contexts exist?

Regards,

Roland

> 14 juni 2016 kl. 14:39 skrev Mark Kaberman :
> 
> It does not. 
> 
> On Tuesday, June 14, 2016 at 8:14:20 AM UTC-4, √ wrote:
> Is supervision triggering? (i.e. restarts, possibly creating new beans)?
> 
> On Tue, Jun 14, 2016 at 2:03 PM, Mark Kaberman  > wrote:
> I added the static instantiation counter to my actor Spring bean (see my 
> original post). When an actor is created via getContext().ActorOf(... I see 
> number of logging entries coming from the bean's constructor indicating that 
> n instances of the actor beans has been created where n matches 
> nr-of-instances from my Akka config. When context().child.(..).get() is 
> called, I see a single logging entry coming from bean's constructor 
> indicating that a singe actor bean has been created. My logging indicates 
> that  getContext().ActorOf(.. is only called once per actor, but 
> context().child.(..).get()  is called constantly (as it should). So I see 
> ever increasing counter logging indicating that more and more Spring beans 
> are created.
> 
> 
> On Tuesday, June 14, 2016 at 7:38:37 AM UTC-4, Patrik Nordwall wrote:
> I'm 100% sure that the child.get method here doesn't create an actor. How do 
> you see that?
> 
> On Fri, Jun 10, 2016 at 10:43 PM, Mark Kaberman > wrote:
> I debugged my application and it seems to be a bug in Akka:
> 
> My routers are defined similarly to each other as
> /myActor/ {
>   dispatcher = my-pinned-dispatcher
>   router = round-robin
>   nr-of-instances = 10
> }
> 
> When I debug into my actor creation and messaging method
> 
> public sendAkkaMessage(String actorBeanName, String actorRouterName, Object 
> message) {
> ActorRef actor = null;
> final scala.Option child = context().child(actorRouterName);
> if (child != null && child.isDefined()) {
> actor = child.get();
> } else {
> actor = 
> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
>  FromConfig()), actorRouterName);
> }
> actor.tell(message, self());
> }
> 
> I see that when a new actor is created by calling getContext().actorOf()...  
> I see 10 new Spring beans being created (as per Akka config). When an actor 
> is created via child.get() I see one Spring bean is created. So it seems that 
> in the case of a get() Akka disregards already created Spring beans and 
> creates one more. 
>  
> 
> 
> On Friday, June 10, 2016 at 1:24:21 PM UTC-4, √ wrote:
> I don't know how your app works or what router config you are using so it is 
> impossible for me to know what's happening.
> 
> Perhaps you have Restarts happening which will create new MyActor instances 
> but the old instances are still reachable by something else. Spring perhaps?
> 
> Use a memory debugger and trace the reachability of those MyActor instances.
> 
> -- 
> Cheers,
> √
> 
> On Jun 10, 2016 6:03 PM, "Mark Kaberman" > wrote:
> Isn't the code:
> 
> if (child != null && child.isDefined()) {
>actor = child.get();
> }
> 
> supposed to fetch existing actor actor reference instead of creating a new 
> one?
> 
> If I call stop() at the end of onReceive() what happens to other instances of 
> the same actor which could be processing different vertices? Will they be 
> shut down as well?
> 
> 
> 
> On Friday, June 10, 2016 at 10:48:48 AM UTC-4, √ wrote:
> If you create new actors continually and never stop any of them then you have 
> by design got a leak.
> 
> -- 
> Cheers,
> √
> 
> On Jun 10, 2016 4:35 PM, "Mark Kaberman" > wrote:
> Hi Viktor,
> 
> I never stop my actors explicitly (except as reaction to failure in 
> supervision strategy). All actors process the vertex data in onReceive() 
> method, determine if a vertex has children, get the children actor by calling 
> my createActorRef, send the message to a child via tell (never ask) and exit 
> onReceive.
> 
> Regards,
> 
> Mark
> 
> 
> On Friday, June 10, 2016 at 10:27:25 AM UTC-4, √ wrote:
> Hi Mark,
> 
> Where are you stopping your actors?
> 
> -- 
> Cheers,
> √
> 
> On Jun 10, 2016 2:55 PM, "Mark Kaberman" > wrote:
> I have Akka application which is essentially traverses a very large tree 
> where each vertex processing is 

Re: [akka-user] Dependent Processing with Millions of Records without Backlogging?

[Roland Kuhn]

Yes, that sounds reasonable. Perhaps a kind of natural batching that 
accumulates changes as long as the previous sort is being executed?

Sent from my iPhone

> On 01 Jun 2016, at 22:43, kraythe  wrote:
> 
> Perhaps, though honestly the entire problem scope is in the post, just 
> generically expressed. :) 
> 
> I cant be more specific because of NDAs though. Basically the B's job is to 
> maintain a sort order of a specific collection of As and when As mutate 
> resort them. It also and manage other metadata associated with the collection 
> of As. No you cant avoid the sort, its part of the core business feature. 
> 
> At any rate I am going to go with an internal batching strategy. I cant think 
> of anything else.
> 
> -- Robert
> 
>> On Wednesday, June 1, 2016 at 1:56:01 PM UTC-5, rkuhn wrote:
>> It seems that your initial description is too vague for direct help—that 
>> sorting aspect is not really clear, at least to me.
>> 
>>> 1 jun 2016 kl. 20:04 skrev kraythe :
>>> 
>>> Pardon? I just said the users are observing the state and observing it 
>>> change in real time.
>>> 
 On Wednesday, June 1, 2016 at 10:31:16 AM UTC-5, √ wrote:
 So If no users are looking why does it need to be already updated?
 
 -- 
 Cheers,
 √
 
> On Jun 1, 2016 4:44 PM, "kraythe"  wrote:
> Users are observing their state via web pages. And no, it's not viable to 
> the business to remove this ability,
> 
> --
> >>  Read the docs: http://akka.io/docs/
> >>  Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>  Search the archives: 
> >> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>>> 
>>> 
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Dependent Processing with Millions of Records without Backlogging?

[Roland Kuhn]

It seems that your initial description is too vague for direct help—that 
sorting aspect is not really clear, at least to me.

> 1 jun 2016 kl. 20:04 skrev kraythe :
> 
> Pardon? I just said the users are observing the state and observing it change 
> in real time.
> 
> On Wednesday, June 1, 2016 at 10:31:16 AM UTC-5, √ wrote:
> So If no users are looking why does it need to be already updated?
> 
> -- 
> Cheers,
> √
> 
> On Jun 1, 2016 4:44 PM, "kraythe"  wrote:
> Users are observing their state via web pages. And no, it's not viable to the 
> business to remove this ability,
> 
> --
> >>  Read the docs: http://akka.io/docs/ 
> >>  Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >>  Search the archives: 
> >> https://groups.google.com/group/akka-user 
> >> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com .
> To post to this group, send email to akka...@googlegroups.com .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Implementing ACID style processing using Akka?

[Roland Kuhn]

Yes, indeed, thanks a lot for writing that up!

Sent from my iPhone

> On 23 May 2016, at 06:47, Ryan Tanner  wrote:
> 
> Great post Matthew!
> 
>> On Sunday, May 22, 2016 at 4:51:39 PM UTC-6, Matthew Howard wrote:
>> ugh double-post... I left out the Pat Helland link 
>> https://www.youtube.com/watch?v=EWSRbRUH7pg 
>> 
>>> On Thursday, May 12, 2016 at 11:41:24 PM UTC-4, kraythe wrote:
>>> I have a system that is a traditional DB centric app for the most part. 
>>> However the data is loaded in a memcache for speed and ease of use. What I 
>>> would be interested in doing is migrating the app to a actor centric 
>>> paradigm. Also keep in mind that I speak Scala but my colleagues don't so I 
>>> would have to be stuck in Java world. The use case I can't get past is this.
>>> A user has an entry in a competition and if they win the competition they 
>>> get a prize. When we want to award that user a prize we need to go update 
>>> the entry noting it has been paid, write multiple transactions to the 
>>> system to track the payment and update their wallet with the prize. Now all 
>>> of these things have to happen or none of them have to happen.
>>> 
>>> It would make sense to make the entry an actor as well as the wallet. The 
>>> transactions are a bit more questionable. What I can't figure out is how I 
>>> can change all of those actors and fail if anything goes wrong. There is no 
>>> option to think that we can avoid ACID here.
>>> 
>>> I have been researching on google and this group and there is a lot of 
>>> information but most is dated and conflicting. Any ideas to help out?
>>> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] AsyncWriteJournal - question about asyncWriteMessages

[Roland Kuhn]

Sent from my iPhone

> On 21 May 2016, at 23:05, Maciej Ciołek  wrote:
> 
> Hello,
> I would like to ask about the docs in AsyncWriteJournal:
> 
> asyncWriteMessages:
> Calls to this method are serialized by the enclosing journal actor. If you 
> spawn work in asynchronous tasks it is alright that they complete the futures 
> in any order, but the actual writes for a specific persistenceId should be 
> serialized to avoid issues such as events of a later 
> write are visible to consumers (query side, or replay) before the events of 
> an earlier write are visible. A PersistentActor will not send a new 
> WriteMessages request before the previous one has been completed.
> 
> 1. The method provides the Seq[AtomicWrite], is it possible that this Seq 
> contains more than one AtomicWrite per persistenceId? Eg. user invokes twice 
> persistAll method?

Yes.

> 2. The docs states that "but the actual writes for a specific persistenceId 
> should be serialized to avoid issues such..." if my answer to my first 
> question is true, does it mean that implementation of this method should 
> firstly group AtomicWrite from messages by persistenceId and next store them 
> in serialized order?

The sequence will only contain AtomicWrites for a single persistenceId, but you 
are correct in any case.

Regards, Roland 

> 
> Thanks,
> Maciej
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] ANNOUNCE: New Remoting Milestone 1

[Roland Kuhn]

Very exciting indeed, can’t wait to play with it!

> 20 maj 2016 kl. 19:03 skrev Filippo De Luca :
> 
> Very good news indeed
> 
> On 20 May 2016 at 18:02, Vitor Vieira  > wrote:
> That's awesome! Can't wait to see the final benchmarks!
> 
> Cheers!
> 
> Vitor Vieira
> 
> 
> 
> Em sexta-feira, 20 de maio de 2016 11:29:04 UTC-3, Patrik Nordwall escreveu:
> Dear hakkers,
> 
> We’re excited to announce that we have released the first development 
> milestone of the new Akka Remoting, which has the code named Artery. It’s an 
> early development preview and we encourage you to try it out and give us 
> feedback, but it’s not intended for production usage yet.
> 
> The version number is 2.4-ARTERY-M1 with same artifacts as usual. 
> 
> It is enabled with the following configuration:
> 
> akka.remote.artery {
>   enabled = on
>   # The hostname or ip clients should connect to.
>   hostname = localhost
>   # use 0 if you want a random available port
>   port = 20200
> }
> 
> The protocol part of the actor system address is artery (*), so you need to 
> change previous akka.tcp to artery in for example configuration of cluster 
> seed-nodes.
> 
> The key features of Artery compared to current implementation will be:
> 
> support high throughput and low latency, such as 1,000,000 msg/s and 
> sub-millisecond latency (more details in the design document 
> , and no hard promises yet)
> improved cluster stability by using isolated streams for control messages, 
> this means less false failure detection in case of heavy message traffic 
> reduce message envelope overhead by smart compression of actor references and 
> other header information
> make it possible to use efficient serialization with ByteBuffers directly
> protocol stability between major Akka versions to support for example rolling 
> upgrade deployments (the protocol is however incompatible with current TCP 
> based protocol)
> internal design that is easier to maintain
> 
> We are using Aeron  as the underlying 
> transport and are implementing the layers on top using Akka Streams. You find 
> more details in the design document 
> .
> 
> The development branch is artery-dev 
> , in case you want to take a 
> look or contribute. Issues are labeled with t:remoting:artery 
> .
> 
> 
> Cheers,
> Akka Team
> 
> (*) The protocol name is not final and may change before the new remoting 
> infrastructure goes stable.
> 
> 
> -- 
> 
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
>  
> 
> Filippo De Luca
> about.me/FilippoDeLuca
> 
>    
>  
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit 

Re: [akka-user] ANNOUNCE: Akka 2.4.5 Released!

[Roland Kuhn]

Great work, everyone! With special thanks to Jan :-)

Sent from my iPhone

> On 18 May 2016, at 02:14, Giovanni  wrote:
> 
> Great!
> 
> giovanni
> 
>> On Tue, May 17, 2016 at 6:01 PM, Johan Andrén  
>> wrote:
>> Dear hakkers,
>> 
>> we—the Akka committers—are proud to announce a new minor release of Akka, 
>> 2.4.5 that contains some pretty major news for those of you who are using 
>> Akka HTTP with Java.
>> 
>> Rise of the “New” Java Routing DSL
>> 
>> This release contains the long-awaited “new” Routing DSL for Java, which is 
>> an initiative started a few months ago by Jan Ypma (jypma) in which the Java 
>> and Scala DSLs were to be made more similar to each other. This has a number 
>> of benefits: simplifying the learning curve of either APIs, actually 
>> achieving feature parity between the APIs, and also a more Java8 feel thanks 
>> to the intense use of lambda expressions. Also, numerous issues were found 
>> and fixed during the transition – be sure to upgrade if you found problems 
>> in the old DSL.
>> 
>> Today, we announce that the API has been completed, and except minor changes 
>> we do not expect to do any large refactorings like this one – we’re on our 
>> road to a stable Routing API. This sadly means that the changes are rather 
>> wide-spread, and migrating from old to new may feel like learning an entire 
>> new API (which it is). If you run into trouble migrating contact us via the 
>> mailing list or gitter chat; customers may of course ask for help via the 
>> Lightbend support portal.
>> 
>> You will notice that directives documentation is complete, however lacking 
>> code examples in some cases. We would like to ask for your help in finishing 
>> the docs by adding code examples – these efforts can be coordinated as part 
>> of the #20466 ticket.
>> 
>> Other important fixes and improvements:
>> 
>> The cluster client and the cluster client receptionist now allow for 
>> subscribers to which the changes to the current set of contacts or clients 
>> will be announced. (#20446)
>> FileIO streams factory methods using java.nio.Path added and the old File 
>> (#20390)
>> A bug in the Akka scheduler making it stop running scheduled events in a 
>> long lived actor system (#20424), thanks to ecartner for finding and 
>> reproducing this issue
>> Registration of custom MediaTypes for Akka HTTP (#20397)
>> The full list of changes since the last milestone is available under the 
>> 2.4.5 milestone on github for your reference.
>> 
>> Credits
>> 
>> Thanks to the Community! For this release we had the help of 48 committers. 
>> Special thanks to Jan Ypma for his involvement in the development of the new 
>> Java routing DSL.
>> 
>> Commits added removed
>>34   117084371 Konrad Malawski
>>3232052924 Johan Andrén
>>13 429 251 Patrik Nordwall
>> 7 889  96 Endre Sándor Varga
>> 7 180 223 2beaucoup
>> 6  67 114 Bernard Leach
>> 4 554 125 Robert Budźko
>> 4  37   5 poojadshende
>> 3 210 159 Daniel Moran
>> 3 331 175 Samuel Tardieu
>> 3  67  33 Nafer Sanabria
>> 2  29   3 Oleksii
>> 2  16  12 Tim Harper
>> 2  14  14 atemerev
>> 2  86  43 zhxiaog
>> 2  97  88 andreaTP
>> 2  14   1 Alexander Temerev
>> 239954059 Jan Ypma
>> 2  83  24 Ganeshwara Herawan Hananda Putra
>> 2 168   8 David Knapp
>> 1 169  20 Rémy-Christophe Schermesser
>> 12570   3 Felix Satyaputra
>> 1   2   3 Anil Gursel
>> 1  10   7 kerr
>> 1   1   1 Paweł Jurczenko
>> 11044  30 leonidb
>> 1  27   6 Stefano Bonetti
>> 1  61   0 Oleksii Tkachuk
>> 1   2   0 杨博 (Yang Bo)
>> 1   2   2 Derek Wickern
>> 1  18  14 Andrea Peruffo
>> 1 610  34 Christopher Hunt
>> 1  20   2 Mark van der Tol
>> 1 129 134 hepin1989(虎鸣)
>> 1   5   7 Leonid Bakaleynik
>> 1  39   3 svezfaz
>> 1   1   1 Alexey Noskov
>> 1  11   0 jsuchenia
>> 1 731  23 Rodolphe BELOUIN
>> 1  10   4 Björn Antonsson
>> 1   9   2 mumutu
>> 1  74   0 Giovanni Caporaletti
>> 1  51  77 Viktor Klang
>> 1 285 123 Michał Kiędyś
>> 1  61  33 Michał Płachta
>> 1  23  13 Martynas Mickevicius
>> 1  16   3 Priyanka Chordia
>> 1   6   9 tpfeifer
>> Happy hakking!
>> 
>> – The Akka Team
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are 

Re: [akka-user] Implementing ACID style processing using Akka?

[Roland Kuhn]

Hi Robert,

I feel your pain, but unfortunately the pain is real as it results from a 
fundamental conflict: if the users expect the system to behave (strictly) 
serializable then the system cannot scale or be highly available because it is 
limited by the CAP theorem. Without giving up this expectation there is no 
technical trick you can pull that would magically fix this. (scary 
interjection: actual databases have bugs and are not actually serializable—also 
for performance reasons)

In practice, though, users are already used to inconsistencies—although they 
clearly prefer them to be rare and small. This is what Viktor was pointing out: 
why is it acceptable that a transaction can be broken by external parties, but 
unacceptable that it can be broken by local failure? If both of these are rare, 
then it shouldn’t matter, but there is this mindset that failure is 
unacceptable which prevents you from progressing.

Eventual consistency does not have to mean that people will see inconsistent 
analytics all the time, but the effort that is needed for implementing those 
analytics depends on both the rate at which the system accepts changes, the 
inconsistency window (typically some milliseconds), and the leniency of the 
observers. If your system runs 1 transaction per second and the inconsistency 
window is 1ms then roughly 1 in 1000 observations may see the effects of a 
partially executed transaction (extremely simplified maths, of course). You can 
build your analytics such that they look at a snapshot to make them fully 
consistent, but that amounts to reconstructing the system’s state from the logs 
for each query—is that really necessary? (it would also require your logs to 
carry transaction IDs and consist of commutative operations, and the analytics 
would not necessarily represent a real intermediate state of the system, etc.)

In summary, you cannot wave your wand and make a traditional transaction-based 
system distributed, performant and highly available without needing to touch 
any of its users. If you want to integrate such a system with other concerns 
that you model as Actors, then the best you can do is to encapsulate and 
represent the whole system in a (pool of) actor(s) that use the horrible 
blocking transaction-offering APIs that you are forced to use; just make sure 
to configure them to run on a separate dispatcher and you should be fine. For 
further reading I also recommend «A Life Beyond Distributed Transactions», 
which describes that objects across which you need transactional behavior need 
to be local (i.e. cannot be distributed) but typically you can separate several 
kinds of objects so that some form of distribution becomes possible within 
these constraints.

Regards,

Roland

> 13 maj 2016 kl. 21:29 skrev kraythe :
> 
> I definitely appreciate your time and point of view Rolland but how do I 
> solve this without transactions? Basically I have a set of things that I have 
> to update as a unit. I have to alter record in one table and write records to 
> two more tables. I would love to completely purge the system of the need for 
> transactions. I would love to do that to make it more scalable and 
> performant. What I cant figure out is how to get around it. In an app like 
> twitter or facebook, its pretty simple. If a post or tweet gets lost, no 
> biggie. In a financial oriented system I need 100% certainty that either the 
> Wallet records were written and entry updated or that neither of those things 
> happen. 
> 
> Thats a critique i have had in my research of Akka and its applicability to 
> systems I work on. The examples, use cases and demos seem to be systems 
> unlike anything I actually have worked on in my career. I have never had to 
> write a blog engine or a messaging app. Every one of the apps I work on is 
> from the point of view of one or another part of the financial sector where 
> you are moving people's money around and they get CRANKY when you lose it. 
> For example, if a user wants to withdraw 200 from the bank you have to make 
> sure you record the withdrawal and decrement their account as well. We cant 
> decrement the account and "fail" to record the withdrawal. They both have to 
> happen or nothing at all. Here is where we use transactions to talk to the 
> db. 
> 
> BEGINE TRANSACTION;
> UPDATE account SET balance = 800;
> INSERT INTO records (id,  ) VALUES (.)
> COMMIT TRANSACTION;
> 
> None of those are optional, we cant give the user the money if the node 
> registering the withdrawal records is down, nor can we sent a big guy named 
> Vinny to go collect the money if the withdrawal record is lost. We have to do 
> an all or nothing issue. 
> 
> Every time I try to transition to the Reactive - Akka way of doing things I 
> hit this wall. The demos don't help because they are trivial applications and 
> I cant sell a conversion until I can answer this question. Each time I come 
> and try to make such 

Re: [akka-user] Implementing ACID style processing using Akka?

[Roland Kuhn]

Hi Robert!

> 13 maj 2016 kl. 19:37 skrev kraythe :
> 
> Well we dont have to deal with that. Its so rare that its not in the 
> software. Security team would deal with that. 

This is exactly the point: what is the probability that the system crashes 
while performing a given transaction? Usually it is extremely small.

Another consideration is that for atomicity and durability you don’t need full 
ACID transactions, you only need a means of ensuring that the logic runs to 
completion (which may also be a rollback due to a permanent failure). This 
means that using a process manager (cf. «SAGAS» by Hector Garcia–Molina) is a 
suitable solution as long as no isolation or consistency concerns enter the 
picture, i.e. when eventual consistency is fine. Eventual consistency entails 
reaching a consistent state eventually, which usually is good enough.

The point with “Akka vs. Transactions” is that Akka models distribution, which 
is inherently at odds with traditional ACID, therefore you won’t find an 
idiomatic solution to your question—if you want ACID you shouldn’t distribute 
your objects.

Regards,

Roland

> 
> If we had to, I would debit the account based on the amounts that were 
> credited in the account. 
> 
> I know what yo uare getting at but its pretty impossible to bypass the notion 
> of a "unit of work which spans domain objects". 
> 
> -- Robert
> 
> On Friday, May 13, 2016 at 8:38:26 AM UTC-5, √ wrote:
> No, I mean if the bank reverses a payment which was previously accepted.
> 
> -- 
> Cheers,
> √
> 
> On May 13, 2016 3:25 PM, "kraythe"  wrote:
> Well currently the system is designed such that the remote transaction 
> failing rolls back the transaction. So in this one scenario, that is how it 
> is handled. However, this particular use case could be redesigned to say: 
> 
> 1) When user wins prize, write transactions and change state to 
> TRANSACTIONS_WRITTEN
> 2) When transactions in CREATED state, increment wallet and move transactions 
> to CREDITED state.
> 
> Essentially powering on everything like it has state. However, you notice we 
> still have to change two objects which could nominally be independent actors 
> at the same time and have them all work or none at all. Furthermore we will 
> have to have a process that combs the system constantly looking for objects 
> that are stuck in a state because a node died or something happened so as to 
> not orphan objects in the pipeline. 
> 
> HOWEVER, there are other ACID situations in the platform that cannot be 
> designed that way. Situations where we really need modifications to several 
> objects to all happen or none at all. So I am back into the question of a 
> general paradigm in an Akka platform. 
> 
> On Thursday, May 12, 2016 at 11:36:25 PM UTC-5, √ wrote:
> What will you do if the bank reverses the payment?
> 
> On Thu, May 12, 2016 at 11:41 PM, kraythe > wrote:
> I have a system that is a traditional DB centric app for the most part. 
> However the data is loaded in a memcache for speed and ease of use. What I 
> would be interested in doing is migrating the app to a actor centric 
> paradigm. Also keep in mind that I speak Scala but my colleagues don't so I 
> would have to be stuck in Java world. The use case I can't get past is this.
> 
> A user has an entry in a competition and if they win the competition they get 
> a prize. When we want to award that user a prize we need to go update the 
> entry noting it has been paid, write multiple transactions to the system to 
> track the payment and update their wallet with the prize. Now all of these 
> things have to happen or none of them have to happen.
> 
> It would make sense to make the entry an actor as well as the wallet. The 
> transactions are a bit more questionable. What I can't figure out is how I 
> can change all of those actors and fail if anything goes wrong. There is no 
> option to think that we can avoid ACID here.
> 
> I have been researching on google and this group and there is a lot of 
> information but most is dated and conflicting. Any ideas to help out?
> 
> --
> >>  Read the docs: http://akka.io/docs/ 
> >>  Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >>  Search the archives: 
> >> https://groups.google.com/group/akka-user 
> >> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com <>.
> To post to this group, send email to akka...@googlegroups.com <>.
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, 

Re: [akka-user] Akka Remoting Ports

[Roland Kuhn]

Perhaps a more definitive answer: what you are asking for is not possible 
because that would require binding to the listen port also for the outgoing 
connections, but that is not legal (it results in a BindException saying 
“Address already in use”). This is why the source port of TCP connections is in 
almost protocols random and not fixed (in fact I know of no counterexample).

You will have to do it like everybody else and only filter on the destination 
port, not the source port.

Regards,

Roland

> 11 maj 2016 kl. 10:34 skrev enovo.s...@gmail.com:
> 
> Hi,
> Still waiting to hear, could anybody please give me some hint
> 
> Regards
>  
> 
> On Tuesday, May 10, 2016 at 6:29:03 PM UTC+5, enovo...@gmail.com wrote:
> Hi,
> I have two remote actor systems deployed on two different cloud platforms, 
> one deployed on Google (port 80) and the other one on AWS (port 2552). I am 
> managing AWS machine only,  Google machine is being managed by client.
> I am instantiating connection from AWS actor to Google actor, sending a 
> message and receiving results back. I want to block all unnecessary ports, so 
> i added two rules to firewall
> 1. Allowed outbound connection to port 80  (to connect to remote actor)
> 2. Allowed incoming connection to port 2552 (to receive data back from remote 
> actor)
> 
> Blocked all other ports, as soon as i block other ports, application stops 
> connecting with remote actor. I have verified that actor system is listening 
> at port 2552 (  [akka.tcp://Client@amd-machine:2552]  ).
> 
> It turns out that connection is using some dynamic ports for AWS deployed 
> actor,  here are the logs of traffic captured using tcpdump command:
> 
> 16:05:46.811270 IP 10.0.2.15.56756 > 102.150.24.190.80: Flags [S], seq 
> 1968780725, win 29200, options [mss 1460,sackOK,TS val 6205965 ecr 
> 0,nop,wscale 7], length 0
> 16:05:46.849800 IP 102.150.24.190.80 > 10.0.2.15.56756: Flags [S.], seq 
> 2602112001, ack 1968780726, win 65535, options [mss 1460], length 0
> 16:05:46.849841 IP 10.0.2.15.56756 > 102.150.24.190.80: Flags [.], ack 1, win 
> 29200, length 0
> 16:05:46.850027 IP 10.0.2.15.56756 > 102.150.24.190.80: Flags [F.], seq 1, 
> ack 1, win 29200, length 0
> 16:05:46.850164 IP 102.150.24.190.80 > 10.0.2.15.56756: Flags [.], ack 2, win 
> 65535, length 0
> 
> where
> 102.150.24.190.80 is Google actor address 
> 10.0.2.15.56756 is AWS actor address 
> as can be seen from above logs, that actor system is picking some dynamic 
> port for remote communication. 
> 
> Could anybody please help me understand why dynamic port is being used when 
> actor system is listening at port 2552, and how can i make sure dynamic port 
> is not used?
> 
> Regards
> Abud
> 
> 
> 
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] migrating from an earlier version of akka-streams ..

[Roland Kuhn]

Hi Debasish,

The current fusing algorithm is called «aggressive» for a reason: it will fuse 
everything it can. To run the subflows in parallel you will have to add a 
.async after the fold. But that will only be beneficial if the monoid’s |+| is 
rather expensive.

Regards, Roland 

Sent from my iPhone

> On 27 Apr 2016, at 06:10, Debasish Ghosh <ghosh.debas...@gmail.com> wrote:
> 
> Thanks Roland a lot for the clarification .. I can do this ..
> 
> val netTxn: RunnableGraph[Future[akka.Done]] = 
> transactions.map(validate)
> .groupBy(MaxGroupCount, _.accountNo)
> .fold(TransactionMonoid.zero)(_ |+| _)
> .mergeSubstreams
> 
> Only difference with the 1.0 API is that I cannot do the fold in the Sink - 
> instead I have to do it here. I don't mind, it may even be better this way. 
> Just one clarification .. In the above snippet are the folds on individual 
> substreams done in parallel ?
> 
> Thanks again for the help ..
> Regards.
> 
> 
>> On Wed, Apr 27, 2016 at 2:53 AM, Roland Kuhn <goo...@rkuhn.info> wrote:
>> 
>>> 26 apr 2016 kl. 20:14 skrev Debasish Ghosh <ghosh.debas...@gmail.com>:
>>> 
>>> Just for the sake of completeness, this works ..
>>> 
>>> transactions.map(validate)
>>> .groupBy(MaxGroupCount, _.accountNo)
>>> .fold(Map.empty[String, Transaction])((l, r) => l |+| 
>>> Map(r.accountNo -> r))
>>> .mergeSubstreams
>> 
>> Yes, this is what I proposed a while ago :-) (more or less, see below)
>> 
>>> Since I cannot access the sub-streams I need to simulate this through a Map 
>>> ..
>> 
>> I don’t fully understand: the fold is running on each of the substreams, 
>> there is nothing that is inaccessible. The only difference to the old API is 
>> that the key is not available in pre-extracted form (i.e. things are not 
>> wrapped in tuples). You also don’t need to use a Map, you could also keep 
>> the last r.accountNo in the first position of a tuple and the current 
>> Transaction in the second—the result then looks exactly the same as it did 
>> with streams 1.0. OTOH I suspect that your monoid leaves the accountNo 
>> intact, so there is not even a need to allocate those tuples.
>> 
>> Would you please explain how our groupBy loses the semantics from SQL? I’m a 
>> bit rusty, but the group “name” is also not made available in a dedicated 
>> fashion there, AFAIR. The current shape of the API was inspired by BigData 
>> analytics tools that model this operation in the same way, because the 
>> previous scheme was simply too powerful (it allowed arbitrary dynamic 
>> treatment of each of the substreams—SQL grouping is also homogenous and not 
>> different for each group). Dynamic elements also defeat optimizations like 
>> fusing and graph simplification.
>> 
>> Regards,
>> 
>> Roland
>> 
>>> 
>>> Thanks.
>>> 
>>>> On Tue, Apr 26, 2016 at 11:32 PM, Debasish Ghosh 
>>>> <ghosh.debas...@gmail.com> wrote:
>>>> Thanks Viktor .. my main issue is that we lose the natural semantics of 
>>>> groupBy as we learnt from SQL. We cannot access the substreams as separate 
>>>> abstractions that groupBy creates.
>>>> 
>>>>> On Tue, Apr 26, 2016 at 11:28 PM, Viktor Klang <viktor.kl...@gmail.com> 
>>>>> wrote:
>>>>> Debasish,
>>>>> 
>>>>> The problem with groupBy was that it was too easy to create leaks and 
>>>>> silently broken solutions with it, but I sympathize with your situation, 
>>>>> I also felt the original as being more ergonomic. I think there is room 
>>>>> for improvement in the current solution.
>>>>> 
>>>>> -- 
>>>>> Cheers,
>>>>> √
>>>>> On Apr 26, 2016 7:20 PM, "Debasish Ghosh" <ghosh.debas...@gmail.com> 
>>>>> wrote:
>>>>> Roland -
>>>>> 
>>>>> The problem is I cannot access the substreams separately within the fold. 
>>>>> In the earlier solution the fold was on individual substreams (not on the 
>>>>> whole stream). Here the fold gets *all* the elements from all substreams 
>>>>> and I lose the ability to process substreams separately. Hence I lose the 
>>>>> ability to compose with a Monoid. Possibly I need to create a separate 
>>>>> Map and then do the aggregation. It will be clunky .. I am already 
>>

Re: [akka-user] migrating from an earlier version of akka-streams ..

[Roland Kuhn]

> 26 apr 2016 kl. 20:14 skrev Debasish Ghosh <ghosh.debas...@gmail.com>:
> 
> Just for the sake of completeness, this works ..
> 
> transactions.map(validate)
> .groupBy(MaxGroupCount, _.accountNo)
> .fold(Map.empty[String, Transaction])((l, r) => l |+| 
> Map(r.accountNo -> r))
> .mergeSubstreams
> 

Yes, this is what I proposed a while ago :-) (more or less, see below)

> Since I cannot access the sub-streams I need to simulate this through a Map ..

I don’t fully understand: the fold is running on each of the substreams, there 
is nothing that is inaccessible. The only difference to the old API is that the 
key is not available in pre-extracted form (i.e. things are not wrapped in 
tuples). You also don’t need to use a Map, you could also keep the last 
r.accountNo in the first position of a tuple and the current Transaction in the 
second—the result then looks exactly the same as it did with streams 1.0. OTOH 
I suspect that your monoid leaves the accountNo intact, so there is not even a 
need to allocate those tuples.

Would you please explain how our groupBy loses the semantics from SQL? I’m a 
bit rusty, but the group “name” is also not made available in a dedicated 
fashion there, AFAIR. The current shape of the API was inspired by BigData 
analytics tools that model this operation in the same way, because the previous 
scheme was simply too powerful (it allowed arbitrary dynamic treatment of each 
of the substreams—SQL grouping is also homogenous and not different for each 
group). Dynamic elements also defeat optimizations like fusing and graph 
simplification.

Regards,

Roland

> 
> Thanks.
> 
> On Tue, Apr 26, 2016 at 11:32 PM, Debasish Ghosh <ghosh.debas...@gmail.com 
> <mailto:ghosh.debas...@gmail.com>> wrote:
> Thanks Viktor .. my main issue is that we lose the natural semantics of 
> groupBy as we learnt from SQL. We cannot access the substreams as separate 
> abstractions that groupBy creates.
> 
> On Tue, Apr 26, 2016 at 11:28 PM, Viktor Klang <viktor.kl...@gmail.com 
> <mailto:viktor.kl...@gmail.com>> wrote:
> Debasish,
> 
> The problem with groupBy was that it was too easy to create leaks and 
> silently broken solutions with it, but I sympathize with your situation, I 
> also felt the original as being more ergonomic. I think there is room for 
> improvement in the current solution.
> 
> -- 
> Cheers,
> √
> On Apr 26, 2016 7:20 PM, "Debasish Ghosh" <ghosh.debas...@gmail.com 
> <mailto:ghosh.debas...@gmail.com>> wrote:
> Roland -
> 
> The problem is I cannot access the substreams separately within the fold. In 
> the earlier solution the fold was on individual substreams (not on the whole 
> stream). Here the fold gets *all* the elements from all substreams and I lose 
> the ability to process substreams separately. Hence I lose the ability to 
> compose with a Monoid. Possibly I need to create a separate Map and then do 
> the aggregation. It will be clunky .. I am already starting to feel the loss 
> of the 1.0 API, which I thought was very idiomatic from groupBy point of view.
> 
> Let me see if I can at all get a solution for this ..
> 
> regards.
> 
> On Tue, Apr 26, 2016 at 10:33 PM, Roland Kuhn <goo...@rkuhn.info 
> <mailto:goo...@rkuhn.info>> wrote:
> Instead of using a fold sink which materializes to a Future you’ll need to 
> use a fold combinator which produces the result as its only value after the 
> substream has completed, i.e. you keep the computation results within the 
> streaming domain a bit longer instead of going to the Future domain 
> immediately. Your 1.0 solution must have done something very similar, only 
> with a different API (i.e. you folded the substreams and then probably used 
> mapAsync to flatten the resulting stream of Futures).
> 
> Regards,
> 
> Roland
> 
>> 26 apr 2016 kl. 18:05 skrev Debasish Ghosh <ghosh.debas...@gmail.com 
>> <mailto:ghosh.debas...@gmail.com>>:
>> 
>> Roland -
>> 
>> I need to merge into a fold sink w/ a Monoid. Consider the following example 
>> ..
>> 
>> case class Transaction(id: String, accountNo: String, debitCredit: 
>> TransactionType, amount: Amount, date: Date = today)
>> 
>> and I have the following list of Transactions ..
>> 
>> val txns =
>> Seq(
>>   Transaction("t-1", "a-1", Debit, 1000),
>>   Transaction("t-2", "a-2", Debit, 1000),
>>   Transaction("t-3", "a-3", Credit, 1000),
>>   Transaction("t-4", "a-1", Credit, 1000),
>>   Transaction("t-5", "a-1", Debit, 1000)

Re: [akka-user] migrating from an earlier version of akka-streams ..

[Roland Kuhn]

Instead of using a fold sink which materializes to a Future you’ll need to use 
a fold combinator which produces the result as its only value after the 
substream has completed, i.e. you keep the computation results within the 
streaming domain a bit longer instead of going to the Future domain 
immediately. Your 1.0 solution must have done something very similar, only with 
a different API (i.e. you folded the substreams and then probably used mapAsync 
to flatten the resulting stream of Futures).

Regards,

Roland

> 26 apr 2016 kl. 18:05 skrev Debasish Ghosh <ghosh.debas...@gmail.com>:
> 
> Roland -
> 
> I need to merge into a fold sink w/ a Monoid. Consider the following example 
> ..
> 
> case class Transaction(id: String, accountNo: String, debitCredit: 
> TransactionType, amount: Amount, date: Date = today)
> 
> and I have the following list of Transactions ..
> 
> val txns =
> Seq(
>   Transaction("t-1", "a-1", Debit, 1000),
>   Transaction("t-2", "a-2", Debit, 1000),
>   Transaction("t-3", "a-3", Credit, 1000),
>   Transaction("t-4", "a-1", Credit, 1000),
>   Transaction("t-5", "a-1", Debit, 1000),
>   Transaction("t-6", "a-2", Debit, 1000),
>   Transaction("t-7", "a-3", Credit, 1000),
>   Transaction("t-8", "a-3", Debit, 1000),
>   Transaction("t-9", "a-2", Credit, 1000),
>   Transaction("t-10", "a-2", Debit, 1000),
>   Transaction("t-11", "a-1", Credit, 1000),
>   Transaction("t-12", "a-3", Debit, 1000)
> )
> 
> I do a group by accountNo, which gives me 3 substreams. Each substream needs 
> to go into a fold sink where I fold using a Monoid. The Monoid has the logic 
> of merging transactions belonging to the same accountNo. The logic that u 
> suggest will not do this. I need to access the substreams separately. That's 
> why I did a groupBy (similar to SQL groupBy). And I could do this in the 1.0 
> version.
> 
> Any workaround that u suggest ?
> 
> Thanks.
> 
> On Tue, Apr 26, 2016 at 9:18 PM, Roland Kuhn <goo...@rkuhn.info 
> <mailto:goo...@rkuhn.info>> wrote:
> If you need the results from the substreams you’ll have to merge them back 
> into the mainstream and aggregate them there:
> 
> transactions.groupBy(100, 
> ...).fold(...).mergeSubstreams.grouped(100).to(Sink.head)
> 
> Regards,
> 
> Roland
> 
>> 26 apr 2016 kl. 17:36 skrev debasish <ghosh.debas...@gmail.com 
>> <mailto:ghosh.debas...@gmail.com>>:
>> 
>> Viktor -
>> 
>> Here's the same stuff that works for akka-streams version 
>> akka-stream-experimental 1.0 RC4. .. 
>> https://gist.github.com/debasishg/4d596c1f26d4759ed65e281bb2e6fd2c 
>> <https://gist.github.com/debasishg/4d596c1f26d4759ed65e281bb2e6fd2c> ..
>> 
>> The upgrade that I am having trouble with is defining netTxn (pls see the 
>> gist). The groupBy works like a charm in the older version. But in the newer 
>> version it returns a Subflow and I was stumped how to get hold of each of 
>> the substreams and fold them using a Monoid on a fold sink. Konrad's 
>> solution was to use the to method of subflow. But somehow it's not giving 
>> the desired result .. help ?
>> 
>> Thanks.
>> 
>> 
>> On Tuesday, April 26, 2016 at 8:46:11 PM UTC+5:30, √ wrote:
>> What are you expecting to be returned?
>> 
>> -- 
>> Cheers,
>> √
>> 
>> On Apr 26, 2016 3:49 PM, "Debasish Ghosh" <ghosh.d...@gmail.com <>> wrote:
>> Thanks Konrad for the pointer .. when I run the graph I get a NotUsed .. 
>> That's not hwat I get with the earlier implementation. Please have a look at 
>> the gist .. 
>> https://gist.github.com/debasishg/a42e867bb2bc8ad18243597178bbce93 
>> <https://gist.github.com/debasishg/a42e867bb2bc8ad18243597178bbce93> .. what 
>> am I doing wrong.
>> 
>> Thanks.
>> 
>> On Tue, Apr 26, 2016 at 6:22 PM, Konrad Malawski <konrad@typesafe.com 
>> <>> wrote:
>> (I did a quick mock Transaction type, your Monoid should work fine there 
>> ofc).
>> 
>> -- Konrad
>> 
>> On Sunday, 24 April 2016 21:42:43 UTC+2, debasish wrote:
>> Hi -
>> 
>> I am trying to migrate some akka-streams code from an earlier version 
>> (akka-stream-experimental 1.0.RC4) .. please have a look at the following ..
>> 
>> /**
>>  * Create multiple streams out of a single stream. The s

Re: [akka-user] Re: migrating from an earlier version of akka-streams ..

[Roland Kuhn]

If you need the results from the substreams you’ll have to merge them back into 
the mainstream and aggregate them there:

transactions.groupBy(100, 
...).fold(...).mergeSubstreams.grouped(100).to(Sink.head)

Regards,

Roland

> 26 apr 2016 kl. 17:36 skrev debasish :
> 
> Viktor -
> 
> Here's the same stuff that works for akka-streams version 
> akka-stream-experimental 1.0 RC4. .. 
> https://gist.github.com/debasishg/4d596c1f26d4759ed65e281bb2e6fd2c ..
> 
> The upgrade that I am having trouble with is defining netTxn (pls see the 
> gist). The groupBy works like a charm in the older version. But in the newer 
> version it returns a Subflow and I was stumped how to get hold of each of the 
> substreams and fold them using a Monoid on a fold sink. Konrad's solution was 
> to use the to method of subflow. But somehow it's not giving the desired 
> result .. help ?
> 
> Thanks.
> 
> 
> On Tuesday, April 26, 2016 at 8:46:11 PM UTC+5:30, √ wrote:
> What are you expecting to be returned?
> 
> -- 
> Cheers,
> √
> 
> On Apr 26, 2016 3:49 PM, "Debasish Ghosh"  > wrote:
> Thanks Konrad for the pointer .. when I run the graph I get a NotUsed .. 
> That's not hwat I get with the earlier implementation. Please have a look at 
> the gist .. 
> https://gist.github.com/debasishg/a42e867bb2bc8ad18243597178bbce93 
>  .. what 
> am I doing wrong.
> 
> Thanks.
> 
> On Tue, Apr 26, 2016 at 6:22 PM, Konrad Malawski  > wrote:
> (I did a quick mock Transaction type, your Monoid should work fine there ofc).
> 
> -- Konrad
> 
> On Sunday, 24 April 2016 21:42:43 UTC+2, debasish wrote:
> Hi -
> 
> I am trying to migrate some akka-streams code from an earlier version 
> (akka-stream-experimental 1.0.RC4) .. please have a look at the following ..
> 
> /**
>  * Create multiple streams out of a single stream. The stream "transactions" 
> is being
>  * demultiplexed into many streams split by account number. Each of the 
> sub-streams are
>  * then materialized to the fold sink "txnSink", which folds each of the 
> transaction
>  * substreams to compute the net value of the transaction for that account
>  */
>  val netTxn: Source[RunnableGraph[Future[Transaction]], Unit] = 
>transactions.map(validate).groupBy(_.accountNo).map { case (a, s) => 
> s.toMat(txnSink)(Keep.right) }
> 
> I am trying to create substreams based on a field accountNo within a 
> Transaction. Then I pass each substream to toMat with a Sink which is a fold 
> Sink defined as below ..
> 
> /**
>  * Would like to fold transactions through monoid append
>  */
>  val txnSink: Sink[Transaction, Future[Transaction]] =
>Sink.fold[Transaction, Transaction](TransactionMonoid.zero)(_ |+| _)
> 
> The idea is to apply a monoid over each substream and do some netting on 
> transactions belonging to the same accountNo.
> 
> How can I migrate this to 2.4.4 ? Now groupBy returns a Subflow and I am not 
> sure how to apply each of the substreams to the materializer. One option that 
> works will be to create a Map[String, Transaction] upfront and then directly 
> apply the monoid to the Map in the main stream and not create any substream. 
> But I would like to have the substreams fro some other purpose as well.
> 
> Any help will be appreciated ..
> 
> Regards.
> - Debasish
> 
> 
> 
> 
> 
> -- 
> >> 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/YhJfghLqnhw/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> akka-user+...@googlegroups.com .
> To post to this group, send email to akka...@googlegroups.com .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Debasish Ghosh
> http://manning.com/ghosh2 
> http://manning.com/ghosh 
> 
> Twttr: @debasishg
> Blog: http://debasishg.blogspot.com 
> Code: http://github.com/debasishg 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 

Re: [akka-user] Future to CompletionStage

[Roland Kuhn]

If you show a bit more context of what you are trying to achieve then we might 
be able to help you with that :-)

Happy hakking,

Roland

> 15 apr 2016 kl. 13:05 skrev Federico Jakimowicz :
> 
> Sure, well to be honest and I know this will not speak well about me... I got 
> a bit rusty so I need to catch up with Lambdas and some Java8 features.
> So I'm learning akka in the same time i'm catching up with java8.
> 
> thanks a lot for your help
> 
> 
> El viernes, 15 de abril de 2016, 3:19:36 (UTC-3), rkuhn escribió:
> There’s a Java 8 ask implementation in PatternsCS that will give you a 
> CompletionStage instead of a Future.
> 
> May I ask why you prefer the vastly more verbose anonymous class syntax 
> instead of a lambda?
> 
> Regards,
> 
> Roland
> 
>> 15 apr 2016 kl. 03:06 skrev Federico Jakimowicz gmail.com 
>> >:
>> 
>> Hi,
>> 
>> I'm definitely  having a bad time with akka http.
>> If I want that an actor do something and then use that result in the 
>> response of an httpRequest. How would be the right way to do so?
>> I thought that using Patterns.ask in this way 
>> 
>> 
>> Future handler = Patterns.ask(greeterActor, "Hello", 1000)
>>  
>>  .map(new Mapper(){
>>  
>>  public RouteResult apply(String o) {
>>  
>>  return ctx.complete(o.toString());
>>  
>>  }
>>  
>>}, ctx.executionContext());
>> 
>> and then passing  ctx.completeWith(handler) however completeWith receives a 
>> CompletionStage so that wont work and I'm stuck.
>> How could i get a CompletionStage out of that?
>> 
>> thanks you
>> 
>> 
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/ 
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >> 
>> >> Search the archives: https://groups.google.com/group/akka-user 
>> >> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@ <>googlegroups.com .
>> To post to this group, send email to akka...@ <>googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Future to CompletionStage

[Roland Kuhn]

There’s a Java 8 ask implementation in PatternsCS that will give you a 
CompletionStage instead of a Future.

May I ask why you prefer the vastly more verbose anonymous class syntax instead 
of a lambda?

Regards,

Roland

> 15 apr 2016 kl. 03:06 skrev Federico Jakimowicz :
> 
> Hi,
> 
> I'm definitely  having a bad time with akka http.
> If I want that an actor do something and then use that result in the response 
> of an httpRequest. How would be the right way to do so?
> I thought that using Patterns.ask in this way
> 
> 
> Future handler = Patterns.ask(greeterActor, "Hello", 1000)
>  
>  .map(new Mapper(){
>  
>  public RouteResult apply(String o) {
>  
>  return ctx.complete(o.toString());
>  
>  }
>  
>}, ctx.executionContext());
> 
> and then passing  ctx.completeWith(handler) however completeWith receives a 
> CompletionStage so that wont work and I'm stuck.
> How could i get a CompletionStage out of that?
> 
> thanks you
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka streams: stage that combines consecutive elements

[Roland Kuhn]

Well, you could also concat an EOF marker and use that to flush …

> 12 apr 2016 kl. 11:33 skrev Endre Varga :
> 
> No, for that you need to write a custom stage.
> 
> -Endre
> 
> On Tue, Apr 12, 2016 at 11:01 AM, Arno Haase  > wrote:
> Hi Endre,
> 
> thanks for the reply. Is there any way I can get statefulMapConcat to
> emit cached data after upstream is completed?
> 
> - Arno
> 
> Am 12.04.2016 um 09:27 schrieb Endre Varga:
> > Hi Arno,
> >
> > statefulMapConcat is likely what you need. If that does not work, then
> > build a custom stage.
> >
> > -Endre
> >
> > On Mon, Apr 11, 2016 at 8:09 PM, Arno Haase
> > 
> >  > >> wrote:
> >
> > I have a Source of element type A, and I am looking for a way to build a
> > stage combining several of them into elements of type B. This is done
> > based on size and count, and an 'incomplete' instance of B needs to be
> > generated at the end of the stream.
> >
> > Source.mapConcat() with a buffering function that emits whenever enough
> > instances of A have arrived to create an instance of B pretty much does
> > what I want, but when the stream is completed, the last bunch of
> > elements get lost: The function is not notified of stream completion and
> > can not flush its contents.
> >
> > Any ideas or suggestions would be greatly appreciated.
> >
> > - Arno
> >
> >
> > --
> > >>  Read the docs: http://akka.io/docs/ 
> > 
> > >>  Check the FAQ: 
> > http://doc.akka.io/docs/akka/current/additional/faq.html 
> > 
> > >>  Search the archives: 
> > https://groups.google.com/group/akka-user 
> > 
> > ---
> > You received this message because you are subscribed to the Google
> > Groups "Akka User List" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to akka-user+unsubscr...@googlegroups.com 
> > 
> >  > >.
> > To post to this group, send email to akka-user@googlegroups.com 
> > 
> > >.
> > Visit this group at https://groups.google.com/group/akka-user 
> > .
> > For more options, visit https://groups.google.com/d/optout 
> > .
> >
> >
> > --
> >>> Read the docs: http://akka.io/docs/ 
> >>> Check the FAQ:
> > http://doc.akka.io/docs/akka/current/additional/faq.html 
> > 
> >>> Search the archives: https://groups.google.com/group/akka-user 
> >>> 
> > ---
> > You received this message because you are subscribed to the Google
> > Groups "Akka User List" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to akka-user+unsubscr...@googlegroups.com 
> > 
> >  > >.
> > To post to this group, send email to akka-user@googlegroups.com 
> > 
> > >.
> > Visit this group at https://groups.google.com/group/akka-user 
> > .
> > For more options, visit https://groups.google.com/d/optout 
> > .
> 
> --
> >>  Read the docs: http://akka.io/docs/ 
> >>  Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >>  Search the archives: 
> >> https://groups.google.com/group/akka-user 
> >> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> 

Re: [akka-user] Akka HTTP bind exception on Windows

[Roland Kuhn]

[forget the last paragraph, found the answer in the first post]

> 5 apr 2016 kl. 18:00 skrev Roland Kuhn <goo...@rkuhn.info>:
> 
>> 
>> 5 apr 2016 kl. 17:50 skrev Michi <michael.tha...@physik.tu-muenchen.de 
>> <mailto:michael.tha...@physik.tu-muenchen.de>>:
>> 
>> Hi Endre,
>> 
>> I wrote a small test program that creates a socket channel, closes it and 
>> creates another one using the same port:
>> 
>> import java.io.IOException;
>> import java.net.InetSocketAddress;
>> import java.net.SocketAddress;
>> import java.net.StandardSocketOptions;
>> import java.nio.channels.NetworkChannel;
>> import java.nio.channels.ServerSocketChannel;
>> 
>> public class Main {
>> 
>> public static void main(String[] args) throws IOException, 
>> InterruptedException {
>> int port = Integer.parseInt(args[0]);
>> SocketAddress addr = new InetSocketAddress(port);
>> System.out.println("Binding server socket to " + addr);
>> ServerSocketChannel s = ServerSocketChannel.open();
>> s.setOption(StandardSocketOptions.SO_REUSEADDR, true);
>> System.out.println("Created server socket channel " + s);
>> NetworkChannel c = s.bind(addr);
>> System.out.println("Bound server socket to " + addr);
>> s.close();
>> System.out.println("Closed channel: " + s);
>> Thread.sleep(1000);
>> System.out.println("Binding server socket to " + addr);
>> ServerSocketChannel s2 = ServerSocketChannel.open();
>> s2.setOption(StandardSocketOptions.SO_REUSEADDR, true);
>> System.out.println("Created server socket channel " + s2);
>> NetworkChannel c2 = s2.bind(addr);
>> System.out.println("Bound server socket to " + addr);
>> s2.close();
>> System.out.println("Closed channel: " + s2);
>> 
>> }
>> }
>> 
>> It works perfectly both on Linux and on Windows. Here is the output on 
>> Windows:
>> 
>> C:\Users\Michael\Desktop>java Main 
>> Binding server socket to 0.0.0.0/0.0.0.0:
>> Created server socket channel sun.nio.ch.ServerSocketChannelImpl[unbound]
>> Bound server socket to 0.0.0.0/0.0.0.0:
>> Closed channel: sun.nio.ch.ServerSocketChannelImpl[closed]
>> Binding server socket to 0.0.0.0/0.0.0.0:
>> Created server socket channel sun.nio.ch.ServerSocketChannelImpl[unbound]
>> Bound server socket to 0.0.0.0/0.0.0.0:
>> Closed channel: sun.nio.ch.ServerSocketChannelImpl[closed]
>> 
>> There is also AsynchronousServerSocketChannel, but I doubt this makes a big 
>> difference. I really don't think that NIO does not properly unbind sockets 
>> on Windows. There might be a small delay, but certainly not 10 Minutes! As 
>> far as I know StandardSocketOptions.SO_REUSEADDR should allow to reuse 
>> sockets that are no longer in use, even if the operating system did not 
>> unbind them yet.
> 
> This is slightly incorrect: it only allows binding to specific address while 
> there is a bound listen socket for the wildcard address, or binding during 
> the TIME_WAIT period. Otherwise binding to a local address for which an 
> active listener exists is still forbidden.
> 
> Are you sure that the socket is still bound when using Akka HTTP, or could it 
> be the post-unbind grace period (TIME_WAIT on Linux)? (i.e. does the re-bind 
> fail?)
> 
> Regards,
> 
> Roland
> 
>> 
>> If there is anything I can do to help, let me know.
>> 
>> Best regards,
>> Michael
>> 
>> On Tuesday, April 5, 2016 at 5:08:09 PM UTC+2, drewhk wrote:
>> 
>> 
>> On Tue, Apr 5, 2016 at 5:04 PM, Michi <michael...@physik.tu-muenchen.de <>> 
>> wrote:
>> Hi Endre,
>> 
>> even after 10 Minutes TCPView shows that the socket is still bound by 
>> jawaw.exe. If I close the application, the socket gets unbound immediately. 
>> That's why I am wondering if I do something wrong or if this is a bug in 
>> Akka HTTP. 
>> 
>> We use NIO underneath and don't do anything special, so I am not sure what 
>> we can do here (it works on all other OSes).
>>  
>> 
>> I tried to use a independent Actor System for the Http Server class and shut 
>> the system down after unbinding, but that does not help either.
>> 
>> At that point Akka had cleaned up every actor, so I am not sure what else to 
>> do :(
>>  
>> 
>> Unfortunately our customer

Re: [akka-user] Akka HTTP bind exception on Windows

[Roland Kuhn]

> 5 apr 2016 kl. 17:50 skrev Michi :
> 
> Hi Endre,
> 
> I wrote a small test program that creates a socket channel, closes it and 
> creates another one using the same port:
> 
> import java.io.IOException;
> import java.net.InetSocketAddress;
> import java.net.SocketAddress;
> import java.net.StandardSocketOptions;
> import java.nio.channels.NetworkChannel;
> import java.nio.channels.ServerSocketChannel;
> 
> public class Main {
> 
> public static void main(String[] args) throws IOException, 
> InterruptedException {
> int port = Integer.parseInt(args[0]);
> SocketAddress addr = new InetSocketAddress(port);
> System.out.println("Binding server socket to " + addr);
> ServerSocketChannel s = ServerSocketChannel.open();
> s.setOption(StandardSocketOptions.SO_REUSEADDR, true);
> System.out.println("Created server socket channel " + s);
> NetworkChannel c = s.bind(addr);
> System.out.println("Bound server socket to " + addr);
> s.close();
> System.out.println("Closed channel: " + s);
> Thread.sleep(1000);
> System.out.println("Binding server socket to " + addr);
> ServerSocketChannel s2 = ServerSocketChannel.open();
> s2.setOption(StandardSocketOptions.SO_REUSEADDR, true);
> System.out.println("Created server socket channel " + s2);
> NetworkChannel c2 = s2.bind(addr);
> System.out.println("Bound server socket to " + addr);
> s2.close();
> System.out.println("Closed channel: " + s2);
> 
> }
> }
> 
> It works perfectly both on Linux and on Windows. Here is the output on 
> Windows:
> 
> C:\Users\Michael\Desktop>java Main 
> Binding server socket to 0.0.0.0/0.0.0.0:
> Created server socket channel sun.nio.ch.ServerSocketChannelImpl[unbound]
> Bound server socket to 0.0.0.0/0.0.0.0:
> Closed channel: sun.nio.ch.ServerSocketChannelImpl[closed]
> Binding server socket to 0.0.0.0/0.0.0.0:
> Created server socket channel sun.nio.ch.ServerSocketChannelImpl[unbound]
> Bound server socket to 0.0.0.0/0.0.0.0:
> Closed channel: sun.nio.ch.ServerSocketChannelImpl[closed]
> 
> There is also AsynchronousServerSocketChannel, but I doubt this makes a big 
> difference. I really don't think that NIO does not properly unbind sockets on 
> Windows. There might be a small delay, but certainly not 10 Minutes! As far 
> as I know StandardSocketOptions.SO_REUSEADDR should allow to reuse sockets 
> that are no longer in use, even if the operating system did not unbind them 
> yet.

This is slightly incorrect: it only allows binding to specific address while 
there is a bound listen socket for the wildcard address, or binding during the 
TIME_WAIT period. Otherwise binding to a local address for which an active 
listener exists is still forbidden.

Are you sure that the socket is still bound when using Akka HTTP, or could it 
be the post-unbind grace period (TIME_WAIT on Linux)? (i.e. does the re-bind 
fail?)

Regards,

Roland

> 
> If there is anything I can do to help, let me know.
> 
> Best regards,
> Michael
> 
> On Tuesday, April 5, 2016 at 5:08:09 PM UTC+2, drewhk wrote:
> 
> 
> On Tue, Apr 5, 2016 at 5:04 PM, Michi  > wrote:
> Hi Endre,
> 
> even after 10 Minutes TCPView shows that the socket is still bound by 
> jawaw.exe. If I close the application, the socket gets unbound immediately. 
> That's why I am wondering if I do something wrong or if this is a bug in Akka 
> HTTP. 
> 
> We use NIO underneath and don't do anything special, so I am not sure what we 
> can do here (it works on all other OSes).
>  
> 
> I tried to use a independent Actor System for the Http Server class and shut 
> the system down after unbinding, but that does not help either.
> 
> At that point Akka had cleaned up every actor, so I am not sure what else to 
> do :(
>  
> 
> Unfortunately our customer uses Windows and I am wondering if there is 
> anything I can do about it or if it would be better to reimplement the code 
> with Apache Http Components.
> 
> You can try out other frameworks, if they happen to work (and use NIO) then 
> at least we can see what magic they do to make Windows happy :(
> 
> -Endre
>  
> 
> best regards,
> Michael
> 
> On Tuesday, April 5, 2016 at 2:07:52 PM UTC+2, drewhk wrote:
> Hi,
> 
> As far as I know event though NIO reports the unbind, unbinding on Windows is 
> not immediate and you are not guaranteed to be able to bind again 
> immediately. I don't know if this comes from Windows or the NIO windows 
> drivers though.
> 
> -Endre
> 
> On Tue, Apr 5, 2016 at 2:05 PM, Michi > 
> wrote:
> Hi,
> 
> we have a problem with Akka HTTP on Windows: after creating a server binding 
> and unbinding it, it is not possible to bind it again. We get a 
> akka.stream.BindFailedException. On Linux, this works without problems.
> 
> The application 

Re: [akka-user] postStop doesn't get invoked after actor initialization failure

[Roland Kuhn]

> 2 apr 2016 kl. 10:31 skrev Guido Medina :
> 
> I was only thinking in a consistent life cycle for both.
> 
> With the new behavior I think I will never use preStart again in Akka Typed.
> 
> That will be the only way we the users make sure we have control on 
> triggering conditions to execute postStop or not.

This is rather polemic and also wrong. The simple rule is that it is always 
invoked, there are no conditions. And the nice thing about Akka Typed is that 
processing PreStart returns the next behavior, so you get to install different 
PostStop reactions based on whether PreStart was successful or not.

Regards,

Roland

> 
> Regards,
> 
> Guido.
> 
> -- 
>>> Read the docs: http://akka.io/docs/
>>> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] postStop doesn't get invoked after actor initialization failure

[Roland Kuhn]

Created ticket 20205 .

> 2 apr 2016 kl. 09:56 skrev Patrik Nordwall :
> 
> +1 to changing in Akka Typed
> -1 to changing untyped, or adding more hooks (the call chain is complicated 
> as is)
> 
> /Patrik
> fre 1 apr. 2016 kl. 14:44 skrev Guido Medina  >:
> And the order would be:
> 
> new instance -> preStart() -> postStop() - if started -> preDestroy() - if 
> instantiated
> 
> 
> On Friday, April 1, 2016 at 1:42:16 PM UTC+1, Guido Medina wrote:
> I'll throw you an idea, what if you add another method, say preDestroy() to 
> match the construction of an object, here is the representation:
> 
> new object successful ? -> execute preDestroy()
> preStart() invocation successful? -> execute postStop()
> 
> but with the difference that new object and preDestroy only happen once 
> during that actor life time where preStart can retry few times if it failed 
> to start.
> 
> WDYT?
> 
> Guido.
> 
> On Friday, April 1, 2016 at 1:10:58 PM UTC+1, rkuhn wrote:
> Hi Guido,
> 
> I agree with your point; I’m currently leaning towards changing the behavior 
> of Akka Typed (which is still experimental) to be what I consider more 
> consistent now, but leaving untyped actors unchanged. Any objections?
> 
> Regards,
> 
> Roland
> 
>> 1 apr 2016 kl. 13:58 skrev Guido Medina >:
>> 
>> @Roland,
>> 
>> Indeed it is an interesting discussion, I think it is what some people might 
>> call a "definition by assumption", basically (as a parallel example):
>> 
>> we were given something that behaves like a car (we were not told that it is 
>> a car) but it behaves like it and hence we assumed and used it like it,
>> then in the future we are going to be told (empirically) that it is a plane 
>> and that it will consistently behave as such which,
>> will bring problem if people were using actions like "brake", etc, it might 
>> be painful for systems that treated it like a car.
>> 
>> Cheers,
>> 
>> Guido.
>> 
>> On Thursday, March 31, 2016 at 3:49:14 PM UTC+1, rkuhn wrote:
>> Another angle on this discussion comes into play when considering Akka 
>> Typed: there we make it very obvious that PreStart and PostStop are signals 
>> that the actor may react to if it so chooses. In this spirit it would make 
>> sense to disregard the outcome of such signal processing if it fails and 
>> continue with the actor lifecycle just as if it were any other message that 
>> triggered the fault. In other words, Akka Typed might want to implement the 
>> newly proposed behavior instead of the current one.
>> 
>> The same reasoning applies if preStart() and postStop() are regarded as 
>> lifecycle hooks—i.e. code that is “informed” of some lifecycle events—as 
>> opposed to active state transition steps. This view would be consistent with 
>> the description of these methods in the JavaDoc/ScalaDoc or reference 
>> documentation as well.
>> 
>> The current behavior would be consistent with the view that preStart() 
>> transforms the actor into the running state, it is nor merely a “hook”.
>> 
>> Interestingly, I have never pondered these semantics in this light before, 
>> thanks for the discussion!
>> 
>> Regards,
>> 
>> Roland
>> 
>> PS: changing this behavior is indeed not trivial since nulling out the actor 
>> field is required for proper handling of everything that follows—simply 
>> declaring the actor failed would not achieve the right semantics.
>> 
>> 31 mar 2016 kl. 15:34 skrev Endre Varga >:
>> 
>> Ok, since the change is not completely trivial either, let's keep the 
>> current behavior until someone cries about it again :)
>> 
>> -Endre
>> 
>> On Thu, Mar 31, 2016 at 3:31 PM, Tal Pressman > wrote:
>> Hmm, I guess I wasn't very clear... What I was trying to say is, let's say I 
>> have something like this:
>> preStart {
>>   allocate resource
>>   something that can fail
>> }
>> 
>> I can wrap the part that can fail with a try catch, and release the resource 
>> that was allocated. Because I am still in preStart I have the context of 
>> what was and wasn't initialized. But if preStart finished successfully, then 
>> I know for sure all the resources were acquired and have to be released.
>> Granted, this isn't the most elegant code (takes me back to my C days, all 
>> that's missing are goto's), but I really dislike the double-failure solution.
>> 
>> Tal
>> 
>> 
>> 
>> On Thursday, March 31, 2016 at 4:23:19 PM UTC+3, drewhk wrote:
>> 
>> 
>> On Thu, Mar 31, 2016 at 3:10 PM, Tal Pressman > wrote:
>> 
>> Here's my (unimportant and unsolicited ^_^) opinion.
>> I think this should be left as is for a couple of reasons.
>> 1. In the case you mentioned where a file is opened in the c'tor, 
>> 
>> But what I was arguing is if you allocate the file in preStart(). We cannot 
>> do anything with ctor failures.
>>  
>> the file could have been 

Re: [akka-user] postStop doesn't get invoked after actor initialization failure

[Roland Kuhn]

Hi Guido,

I agree with your point; I’m currently leaning towards changing the behavior of 
Akka Typed (which is still experimental) to be what I consider more consistent 
now, but leaving untyped actors unchanged. Any objections?

Regards,

Roland

> 1 apr 2016 kl. 13:58 skrev Guido Medina :
> 
> @Roland,
> 
> Indeed it is an interesting discussion, I think it is what some people might 
> call a "definition by assumption", basically (as a parallel example):
> 
> we were given something that behaves like a car (we were not told that it is 
> a car) but it behaves like it and hence we assumed and used it like it,
> then in the future we are going to be told (empirically) that it is a plane 
> and that it will consistently behave as such which,
> will bring problem if people were using actions like "brake", etc, it might 
> be painful for systems that treated it like a car.
> 
> Cheers,
> 
> Guido.
> 
> On Thursday, March 31, 2016 at 3:49:14 PM UTC+1, rkuhn wrote:
> Another angle on this discussion comes into play when considering Akka Typed: 
> there we make it very obvious that PreStart and PostStop are signals that the 
> actor may react to if it so chooses. In this spirit it would make sense to 
> disregard the outcome of such signal processing if it fails and continue with 
> the actor lifecycle just as if it were any other message that triggered the 
> fault. In other words, Akka Typed might want to implement the newly proposed 
> behavior instead of the current one.
> 
> The same reasoning applies if preStart() and postStop() are regarded as 
> lifecycle hooks—i.e. code that is “informed” of some lifecycle events—as 
> opposed to active state transition steps. This view would be consistent with 
> the description of these methods in the JavaDoc/ScalaDoc or reference 
> documentation as well.
> 
> The current behavior would be consistent with the view that preStart() 
> transforms the actor into the running state, it is nor merely a “hook”.
> 
> Interestingly, I have never pondered these semantics in this light before, 
> thanks for the discussion!
> 
> Regards,
> 
> Roland
> 
> PS: changing this behavior is indeed not trivial since nulling out the actor 
> field is required for proper handling of everything that follows—simply 
> declaring the actor failed would not achieve the right semantics.
> 
> 31 mar 2016 kl. 15:34 skrev Endre Varga  >:
> 
> Ok, since the change is not completely trivial either, let's keep the current 
> behavior until someone cries about it again :)
> 
> -Endre
> 
> On Thu, Mar 31, 2016 at 3:31 PM, Tal Pressman  > wrote:
> Hmm, I guess I wasn't very clear... What I was trying to say is, let's say I 
> have something like this:
> preStart {
>   allocate resource
>   something that can fail
> }
> 
> I can wrap the part that can fail with a try catch, and release the resource 
> that was allocated. Because I am still in preStart I have the context of what 
> was and wasn't initialized. But if preStart finished successfully, then I 
> know for sure all the resources were acquired and have to be released.
> Granted, this isn't the most elegant code (takes me back to my C days, all 
> that's missing are goto's), but I really dislike the double-failure solution.
> 
> Tal
> 
> 
> 
> On Thursday, March 31, 2016 at 4:23:19 PM UTC+3, drewhk wrote:
> 
> 
> On Thu, Mar 31, 2016 at 3:10 PM, Tal Pressman > wrote:
> 
> Here's my (unimportant and unsolicited ^_^) opinion.
> I think this should be left as is for a couple of reasons.
> 1. In the case you mentioned where a file is opened in the c'tor, 
> 
> But what I was arguing is if you allocate the file in preStart(). We cannot 
> do anything with ctor failures.
>  
> the file could have been opened during preStart. That way if you allocate the 
> resource, you will get to postStop
> 
> But this is exactly what is not true here. If preStart fails, you don't get 
> to postStop.
> 
> Basically there is no contention on that once an actor is considered running, 
> postStop should be called. The contention is when should an actor considered 
> to be running, just before the invocation of preStart, of after the 
> successful invocation of preStart.
>  
> , and if you fail in preStart you haven't allocated resources (or you know 
> how far along the initialization you are so you can clean up the resources 
> that were actually allocated).
> 2. I generally think of preStart and postStop as being associated, like a 
> constructor and destructor (in languages that have them). In such cases, if 
> the constructor fails the destructor isn't called, and I think this case is 
> similar.
> 
> Interesting, for me preStart is being associated in my head in a completely 
> different way: if preStart has been called, then postStop will be called, 
> too, independently of exceptions thrown.
>  
> 3. And finally, of course, there's the backwards-compatibility issue that was 
> 

Re: [akka-user] postStop doesn't get invoked after actor initialization failure

[Roland Kuhn]

Another angle on this discussion comes into play when considering Akka Typed: 
there we make it very obvious that PreStart and PostStop are signals that the 
actor may react to if it so chooses. In this spirit it would make sense to 
disregard the outcome of such signal processing if it fails and continue with 
the actor lifecycle just as if it were any other message that triggered the 
fault. In other words, Akka Typed might want to implement the newly proposed 
behavior instead of the current one.

The same reasoning applies if preStart() and postStop() are regarded as 
lifecycle hooks—i.e. code that is “informed” of some lifecycle events—as 
opposed to active state transition steps. This view would be consistent with 
the description of these methods in the JavaDoc/ScalaDoc or reference 
documentation as well.

The current behavior would be consistent with the view that preStart() 
transforms the actor into the running state, it is nor merely a “hook”.

Interestingly, I have never pondered these semantics in this light before, 
thanks for the discussion!

Regards,

Roland

PS: changing this behavior is indeed not trivial since nulling out the actor 
field is required for proper handling of everything that follows—simply 
declaring the actor failed would not achieve the right semantics.

> 31 mar 2016 kl. 15:34 skrev Endre Varga :
> 
> Ok, since the change is not completely trivial either, let's keep the current 
> behavior until someone cries about it again :)
> 
> -Endre
> 
> On Thu, Mar 31, 2016 at 3:31 PM, Tal Pressman  > wrote:
> Hmm, I guess I wasn't very clear... What I was trying to say is, let's say I 
> have something like this:
> preStart {
>   allocate resource
>   something that can fail
> }
> 
> I can wrap the part that can fail with a try catch, and release the resource 
> that was allocated. Because I am still in preStart I have the context of what 
> was and wasn't initialized. But if preStart finished successfully, then I 
> know for sure all the resources were acquired and have to be released.
> Granted, this isn't the most elegant code (takes me back to my C days, all 
> that's missing are goto's), but I really dislike the double-failure solution.
> 
> Tal
> 
> 
> 
> On Thursday, March 31, 2016 at 4:23:19 PM UTC+3, drewhk wrote:
> 
> 
> On Thu, Mar 31, 2016 at 3:10 PM, Tal Pressman > wrote:
> 
> Here's my (unimportant and unsolicited ^_^) opinion.
> I think this should be left as is for a couple of reasons.
> 1. In the case you mentioned where a file is opened in the c'tor, 
> 
> But what I was arguing is if you allocate the file in preStart(). We cannot 
> do anything with ctor failures.
>  
> the file could have been opened during preStart. That way if you allocate the 
> resource, you will get to postStop
> 
> But this is exactly what is not true here. If preStart fails, you don't get 
> to postStop.
> 
> Basically there is no contention on that once an actor is considered running, 
> postStop should be called. The contention is when should an actor considered 
> to be running, just before the invocation of preStart, of after the 
> successful invocation of preStart.
>  
> , and if you fail in preStart you haven't allocated resources (or you know 
> how far along the initialization you are so you can clean up the resources 
> that were actually allocated).
> 2. I generally think of preStart and postStop as being associated, like a 
> constructor and destructor (in languages that have them). In such cases, if 
> the constructor fails the destructor isn't called, and I think this case is 
> similar.
> 
> Interesting, for me preStart is being associated in my head in a completely 
> different way: if preStart has been called, then postStop will be called, 
> too, independently of exceptions thrown.
>  
> 3. And finally, of course, there's the backwards-compatibility issue that was 
> already mentioned here. I doubt it'll cause many issues, but the ones it will 
> cause will probably be fairly hard to detect (most projects don't have tests 
> for every object failing initialization).
> 
> This wouldn't be in a minor anyway as we discussed before, and majors can and 
> do break semantics from time to time.
> 
> Anyway, seems like apart from the original poster and me, noone is interested 
> in this change. Stream stages do call postStop even after preStart failures 
> though, so be aware of it.
> 
> Also, consider that after an actor restart postRestart() is called, which 
> will call preStart(), which, if fails will cause postStop to be called if the 
> actor is stopped - unlike the normal startup scenario. This is inconsistent 
> in a sense.
>  
> 
> Tal
> 
> 
> On Thursday, March 31, 2016 at 3:50:00 PM UTC+3, drewhk wrote:
> That is an orthogonal concern in my eyes. The following options are possible 
> now
>  - init fails
>  - init; preStart fails
>  - init; preStart; postStop (fails)?
> 
> 

Re: [akka-user] [akka java 2.4.2] Future callbacks for already completed futures

[Roland Kuhn]

I'm no Klang but I can assure you that all callbacks MUST be dispatched on the 
provided ExecutionContext—otherwise someone will invariably find a way to 
trigger a StackOverflowError. These docs should probably be removed completely 
since we also moved to Scala futures.

Regards,

Roland 

Sent from my iPhone

> On 24 Mar 2016, at 15:20, Akka Team  wrote:
> 
> I have a feeling that that doc remark is obsolete (these sections were not 
> touched in years), but let the expert/Klang speak.
> 
> -Endre
> 
>> On Thu, Mar 24, 2016 at 3:18 PM, Johannes Berg  wrote:
>> Hi!
>> 
>> I've read the documentation at 
>> http://doc.akka.io/docs/akka/2.4.2/java/futures.html and where the map 
>> function is explained it's stated that "If the Future is already complete 
>> though, it will be run in our current thread.". I've just done some tests 
>> suggesting this statement would be false, it seems like it's always 
>> dispatched on the execution context even though it's already completed.
>> 
>> For example this prints two different thread ID:s:
>> 
>> System.out.println(Thread.currentThread().getId());
>> Futures.successful(new Object()).map(new Mapper() {
>> public Object apply(Object obj) {
>> System.out.println(Thread.currentThread().getId());
>> }
>> }, system.dispatcher());
>> 
>> Indeed I would prefer that behaviour and would like to trust that fact but 
>> then the statement in the docs needs to be changed.
>> 
>> Can somebody confirm this, I'm happy to create a bug report in github if you 
>> think this indeed is a bug in the documentation.
>> 
>> I also found some old stuff about this:
>> https://www.assembla.com/spaces/akka/tickets/1054-complete-futures-asynchronously-when-replying-through-a-channel/details#
>> http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/
>> 
>> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Usage of EventFilters in akka.testkit

[Roland Kuhn]

Yes, indeed, thanks for sharing! It would be awesome if you could add this to 
the docs, if you don’t mind.

Regards,

Roland

> 23 mar 2016 kl. 10:17 skrev Sven Hodapp :
> 
> I've found a solution:
> 
>   EventFilter.info(pattern="log content", occurrences=1) intercept {
> ac ! Consume(...)
>   }
> 
> Regards,
> Sven 
> 
> Am Dienstag, 22. März 2016 09:13:13 UTC+1 schrieb Sven Hodapp:
> Dear reader,
> 
> I've seen in the documentation that it is possible to do assertions on Akka 
> log messages.
> 
> http://doc.akka.io/docs/akka/current/scala/testing.html#Expecting_Log_Messages
>  
> 
> 
> But the documentation is here a bit sparsely and doesn't explain how to do 
> "non-exception" assertions.
> You can give me an hint how to do it?
> 
> My current code looks similar to this:
> 
> class TheActorSpec(_system: ActorSystem)
>   extends TestKit(_system)
>   with ImplicitSender
>   with Matchers
>   with FlatSpecLike
>   with BeforeAndAfterAll {
> 
>   def this() = this(ActorSystem("testsystem", ConfigFactory.parseString("""
>   akka.loggers = ["akka.testkit.TestEventListener"]
>   """)))
> 
>   override def afterAll: Unit = {
> system.shutdown()
> system.awaitTermination(10.seconds)
>   }
> 
>   "An Actor" should "be able to assert log messages" in {
> val ac = TestActorRef(Props[TheActor])
> 
> ac ! Consume(...)
>  
> // Or with pattern="..."?
> EventFilter.info(message="the log content", 
> source=classOf[TheActor].getName, occurrences=1).assertDone(1.second)  
> 
>   }
> 
> }
> 
> But I get Stacktraces like "[...] java.lang.AssertionError: assertion failed: 
> 1 messages outstanding on InfoFilter [...]".
> Within TheActor Consume is log.info ("the log content") 
> called.
> 
> Anybody an idea what's wrong or how to use EventFilter correctly?
> 
> Thanks!
> 
> Regards,
> Sven
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Can this be done with the build in stages?

[Roland Kuhn]

Yes, and for the immediate case you can use Future.successful.

Regards, Roland 

Sent from my iPhone

> On 20 Mar 2016, at 15:41, john.vie...@gmail.com wrote:
> 
> Something very simple which come to my mind is  to mapAsync to the ask 
> pattern and then do a "schedule of 10 secs" if the element is an empty list.
> 
> 
> 
> Am Sonntag, 20. März 2016 14:31:51 UTC+1 schrieb john@gmail.com:
>> 
>> val input  = Source(List(List(1, 2, 3), List(1, 2, 3), List(), 
>> List(),List(),List(),List(1, 2, 3))
>> 
>> 1) Process input. for example input.via(throttleFlow).mapConcat(t => t)
>> where throttleFlow show do the following:
>> 
>> 2) If element of source has size > 0 pass it immediately  downstream.
>> 3) Or if element of source has size == 0 wait 10 secs
>> 
>> Can this be done with the build in stages?
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Apparent thread leak with non-default akka dispatcher

[Roland Kuhn]

Hi Jesse,

the prime suspect for threads that are known to the O/S but not to the JVM is 
any sort of native library—Akka does not do anything of this kind.

Regards,

Roland

> 21 mar 2016 kl. 15:12 skrev Jesse C <crimson.core...@gmail.com>:
> 
> the 600 threads do not show up in JStack. JStack shows the expected number of 
> threads. However, looking in the 'task' folder for the process in the '/proc' 
> directory shows all 600 or so, which is why this feels like some sort of 
> leak. The thread is being cleaned up in Java, but not at the OS level. I was 
> wondering if it was a garbage collection issue, but I used jcmd to force a 
> full collection for the process and that did not result in any of the native 
> threads being removed.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Restart does not work with my zipper? What am I doing wrong?

[Roland Kuhn]

Hi John,

in your setup the two flows between the broadcast and the zip must always be 
perfectly balanced, if one of them may lose elements then eventually the whole 
graph will get stuck. Either you make sure that failure does not happen (and 
when it does you don’t restart but kill the whole stream because you know that 
it will be broken and needs to be recreated) or you make up elements on demand, 
e.g. using the expand() combinator. The second possibility leads to 
non-deterministic behavior, though: it is not predetermined which element will 
be expanded exactly.

A buffer does not help in this scenario. The difference in the “balancing 
buffer” blog post is that elements are distributed dynamically to the branches 
whereas here you want to always feed every input into all branches.

Regards,

Roland

> 18 mar 2016 kl. 06:29 skrev john.vie...@gmail.com:
> 
> I tried inserting a buffer but ist still doesn't work. Any other ideas? 
> 
> Am Donnerstag, 17. März 2016 18:58:33 UTC+1 schrieb john@gmail.com:
> I guess that I am suffering from deadlock? this post semms to apply to my 
> problem 
> http://blog.lancearlaus.com/akka/streams/scala/2015/05/27/Akka-Streams-Balancing-Buffer/
>  
> <http://blog.lancearlaus.com/akka/streams/scala/2015/05/27/Akka-Streams-Balancing-Buffer/>
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] awaitTermination not working?

[Roland Kuhn]

Hi Eduardo,

threads created by other libraries are not managed by Akka, you will have to 
shut down that external DB interface yourself. The best place to do this would 
be in the actor’s postStop() hook (I mean that actor which also creates and 
uses that DB).

Regards,

Roland

> 14 mar 2016 kl. 01:23 skrev Eduardo Fernandes <edu...@gmail.com>:
> 
> Hum... it's look like an actor which uses an asynchronous DB persistor from 
> an external library sometimes launches a thread. When the thread is running 
> the shutdown() does nothing and the awaitTermination() doesn't block. If I 
> stop the thread (I have to  say that in a not very documented way) the 
> shutdown stops all Akka threads and the system appears to be released 
> correctly (nevertheless in a single node configuration I don't see the 
> typical shutdowing messages in the log).
> 
> Doing this the problem is solved. Thanks for your comments.
> 
> I still don't understand why the shutdown()/awaitTermination()  have no 
> effect when those external threads are running. Probably when we migrate to 
> 2.4 the problem will just vanish.
> 
> Thanks again!
> 
> 
> El viernes, 11 de marzo de 2016, 13:45:59 (UTC+1), Eduardo Fernandes escribió:
> Me too :(
> 
> I'l prepare a minimum example. Typically when I do this the problem get clear 
> and I could fix my test code :)
> 
> Regards.
>  
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka.actor.PreRestartException Happening whenever there is restart

[Roland Kuhn]

Hi Biniam,

from the stack trace it is pretty obvious that you should look at 
AbstractActor.groovy—which is not an Akka source file.

Regards,

Roland

> 11 mar 2016 kl. 12:28 skrev Biniam Asnake <biniamasn...@gmail.com>:
> 
> Hello everyone,
> 
> Please guide me in the right direction to solve this issue.
> 
> On Thursday, March 10, 2016 at 10:21:26 AM UTC+1, Biniam Asnake wrote:
> Hello,
> 
> I always get this exception whenever the actor restarts and send the message 
> again to the actor.
> 
> Why does it happen and how do I solve it?
> 
> Thanks.
> 
> akka.actor.PreRestartException: exception in preRestart(class 
> com.google.api.ads.adwords.axis.v201509.cm.ApiException, None)
> at 
> akka.actor.dungeon.FaultHandling$$anonfun$1.apply(FaultHandling.scala:69)
> at 
> akka.actor.dungeon.FaultHandling$$anonfun$1.apply(FaultHandling.scala:68)
> at 
> akka.actor.dungeon.FaultHandling$$anonfun$handleNonFatalOrInterruptedException$1.applyOrElse(FaultHandling.scala:302)
> at 
> akka.actor.dungeon.FaultHandling$$anonfun$handleNonFatalOrInterruptedException$1.applyOrElse(FaultHandling.scala:297)
> at 
> scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:36)
> at 
> akka.actor.dungeon.FaultHandling$class.faultRecreate(FaultHandling.scala:68)
> at akka.actor.ActorCell.faultRecreate(ActorCell.scala:369)
> at akka.actor.ActorCell.invokeAll$1_aroundBody2(ActorCell.scala:459)
> at akka.actor.ActorCell$AjcClosure3.run(ActorCell.scala:1)
> at 
> org.aspectj.runtime.reflect.JoinPointImpl.proceed(JoinPointImpl.java:149)
> at 
> akka.kamon.instrumentation.ActorSystemMessageInstrumentation$$anonfun$aroundSystemMessageInvoke$1.apply(ActorSystemMessageInstrumentation.scala:34)
> at kamon.trace.Tracer$.withContext(TracerModule.scala:57)
> at 
> akka.kamon.instrumentation.ActorSystemMessageInstrumentation.aroundSystemMessageInvoke(ActorSystemMessageInstrumentation.scala:34)
> at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:1)
> at akka.actor.ActorCell.systemInvoke(ActorCell.scala:478)
> at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:279)
> at akka.dispatch.Mailbox.run(Mailbox.scala:220)
> at akka.dispatch.Mailbox.exec(Mailbox.scala:231)
> at 
> scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
> at 
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.pollAndExecAll(ForkJoinPool.java:1253)
> at 
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1346)
> at 
> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at 
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
> Caused by: java.util.NoSuchElementException: None.get
> at scala.None$.get(Option.scala:347)
> at 
> com.bonial.megan.execution.actors.AbstractActor.preRestart(AbstractActor.groovy:52)
> at akka.actor.Actor$class.aroundPreRestart(Actor.scala:480)
> at akka.actor.UntypedActor.aroundPreRestart(UntypedActor.scala:97)  
> at 
> akka.actor.dungeon.FaultHandling$class.faultRecreate(FaultHandling.scala:67)
> ... 17 more
> 2016-03-07 15:05:42,886 [AdwordsJobExecutor-akka.actor.default-dispatcher-99] 
> ERROR
> 
> com.bonial.megan.execution.actors.bulkCpcChange.mutate.BulkCpcBidChangeActor.apply$mcV$sp([...])
>  at Line 66
> None.get
> 
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https

Re: [akka-user] Re: Akka.NET or Alternative

[Roland Kuhn]

Ah, this reminds me: together with the core Orleans developers I did a 
comparison of the two approaches, take a look at 
https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md 
<https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md> for 
in-depth information.

Regards,

Roland

> 8 mar 2016 kl. 11:20 skrev Jamie Allen <jamie.al...@lightbend.com>:
> 
> One thing to remember with Orleans - it makes completely different guarantees 
> than Akka.  Where Akka and Erlang focus on the lowest possible costs so that 
> you choose when to pay them, Orleans loads them in up front.  That can make 
> it easier on developers, but likely not as efficient.
> 
> Good luck!
> 
> On Monday, March 7, 2016 at 9:01:20 PM UTC, Andy Czerwonka wrote:
> Hello All,
> 
> I've been asked to port our Java stack to .NET.  We use Akka to facilitate 
> the distribution of our optimization/computation load across cores and 
> eventually a cluster or nodes. I'm looking into Akka.NET and just wondering 
> if the community this this is a viable port? Are there other products in the 
> .NET ecosystem that I should consider for this use case?
> 
> -andy
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] change of Tech Lead

[Roland Kuhn]

> 8 mar 2016 kl. 11:03 skrev Rafał Krzewski <rafal.krzew...@gmail.com>:
> 
> Twitter, very soon: "They told him to work on this new enterprise Java 
> framework, so he flipped his s* and left! Death of Scala AND Akka imminent! 
> Let's run around flailing our arms in panic!"

No, I don’t think so, especially because this is so definitely untrue :-)

> Seriously though, many thanks to Roland and best of luck with the new job!

Thanks!

> 
> Cheers,
> Rafał 
> 
> W dniu poniedziałek, 7 marca 2016 18:42:32 UTC+1 użytkownik rkuhn napisał:
> Dear fellow hakkers,
> 
> as of today I am passing on the baton of Akka Tech Lead @ Lightbend to Patrik 
> Nordwall. Don’t worry, I will stay around and keep working on Akka, but it 
> will no longer be my day job come April: I am co-founding actyx 
> <https://www.actyx.io/en/>—a new start-up in Munich that aims at bringing 
> reactive design principles to the IT behind industrial manufacturing—where I 
> will build and lead the engineering organization. It was always my plan to 
> solve concrete customer challenges once I have collected enough experience 
> with building the tools, and while I had not yet started looking for an 
> opportunity I could also not pass this one up when it presented itself.
> 
> Akka will be in good hands with Patrik and the rest of the team, he is as 
> passionate about distributed systems as I am and he is a much more 
> disciplined coder—not to mention that he joined the Akka team before any 
> other current member including myself. I am very grateful that I had the 
> chance to be part of this amazing team for the past 4.5 years and I have no 
> desire to leave this awesome community anytime soon.
> 
> Regards,
> 
> Roland
> 
> 
> Lightbend – Reactive apps on the JVM.
> twitter: @rolandkuhn
>  <http://twitter.com/#!/rolandkuhn>
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] change of Tech Lead

[Roland Kuhn]

Dear fellow hakkers,

as of today I am passing on the baton of Akka Tech Lead @ Lightbend to Patrik 
Nordwall. Don’t worry, I will stay around and keep working on Akka, but it will 
no longer be my day job come April: I am co-founding actyx 
—a new start-up in Munich that aims at bringing 
reactive design principles to the IT behind industrial manufacturing—where I 
will build and lead the engineering organization. It was always my plan to 
solve concrete customer challenges once I have collected enough experience with 
building the tools, and while I had not yet started looking for an opportunity 
I could also not pass this one up when it presented itself.

Akka will be in good hands with Patrik and the rest of the team, he is as 
passionate about distributed systems as I am and he is a much more disciplined 
coder—not to mention that he joined the Akka team before any other current 
member including myself. I am very grateful that I had the chance to be part of 
this amazing team for the past 4.5 years and I have no desire to leave this 
awesome community anytime soon.

Regards,

Roland


Lightbend – Reactive apps on the JVM.
twitter: @rolandkuhn
 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to? - Sink.foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]]

[Roland Kuhn]

Unfortunately these solutions create unbounded amounts of futures without back 
pressure, so I'd recommend against this approach. But it is late and I'm on the 
phone so cannot suggest a proper solution.

Regards,

Roland 

Sent from my iPhone

> On 05 Mar 2016, at 17:41, Giovanni Alberto Caporaletti  
> wrote:
> 
> how about this:
> 
> def foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]] = {
>   Sink
> .fold[Future[U], T](Future.successful(zero))((fu, t) => fu.flatMap(f(_, 
> t)))
> .mapMaterializedValue(_ flatMap identity)
> }
> or this:
> 
> def foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]] = {
>   Flow[T]
> .fold(Future.successful(zero))((fu, t) => fu.flatMap(f(_, t)))
> .mapAsync(1)(identity)
> .toMat(Sink.head)(Keep.right)
> }
> 
> 
>> On Saturday, 5 March 2016 17:00:08 UTC+1, Andrew Gaydenko wrote:
>> Hi! There is 
>> 
>> f: (U, T) ⇒ Future[U] 
>> 
>> rather than 
>> 
>> f: (U, T) ⇒ U
>> 
>> in hands. How to create 
>> 
>> Sink[T, Future[U]]
>> 
>> ?
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Async console output

[Roland Kuhn]

Hi Richard,

> 3 mar 2016 kl. 00:24 skrev Richard Rodseth <rrods...@gmail.com>:
> 
> This whole area of async boundaries in akka streams is still very confusing 
> to me. I don't know what to suggest in terms of documentation, other than 
> numerous examples of code, with corresponding diagrams showing the resultant 
> boundaries and actor instances after materialization.
> 
> As an example, I have a Sink which I use for console output. I'm sure you 
> will tell me to use logging, but I didn't wish to deal with log levels and 
> formatting for what is the real UI of the tool.
> 
> So I have a  Sink:
> 
>   def printSinkWithLabel[T](extractor: T => String): Sink[T, 
> Future[akka.Done]] = Sink.foreach[T] { e => println(extractor(e)) }
> 
> 
> .withAttributes(ActorAttributes.dispatcher("dispatcher-for-blocking-console"))
> 
> .async // Should I have this?
> 
> and a flow which uses it in an alsoTo()
> 
>   def progress[T](extractor: T => String) = {
> 
> val flow = Flow[T]
> 
> .alsoTo(Sinks.printSinkWithLabel(extractor) )
> 
> 
> .withAttributes(ActorAttributes.dispatcher("dispatcher-for-blocking-console"))
> 
> flow
> 
> 
>   }
> 
> WIth these I can do a via(progress(extractor)) as needed.
> 
> Do I need the dispatcher attributes in both places?
> 

No, running the Sink on that dispatcher is sufficient, you don’t need (or want) 
to run the alsoTo on that dispatcher as well.

> Which is more appropriate?
> 

Running alsoTo on a different dispatcher slows down the “fast path” of your 
data through the progress indicator, so I wouldn’t recommend that.

> Is the .async on the Sink necessary/appropriate?
> 

Strictly speaking the .async is unnecessary if you know that the surrounding 
combinators (.alsoTo in this case) run on a different dispatcher, but I think 
it clearly spells out the intent to add this attribute explicitly.

> Does it make any difference if it's before or after the withAttributes?
> 

Yes, and that is something we should definitely put into the ScalaDoc as well 
as reference docs: .withAttributes replaces the attributes that were already on 
the Sink.foreach (which is just a .named("foreachSink") here, but it would 
include the .async if the order is swapped). If you use .addAttributes instead 
then the order does not matter.

Regards,

Roland

> Thanks in advance.
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Saga compensation

[Roland Kuhn]

Hi sergch,

the compensating action must be performed reliably as well, which means 
at-least-once delivery of the associated commands; in that sense these actions 
are completely symmetric with the transactions on the happy path.

Regards,

Roland

> 1 mar 2016 kl. 16:06 skrev sergch <serga...@gmail.com>:
> 
> Hello Akka team and hAkkers,
> 
> I'm implementing Saga that handles money transfer between 2 accounts. 
> Actor handling the saga is persistent one.
> Commands within Saga are acknowledged by respective events and retried if not 
> event received.
> 
> Now let's say one of the commands has failed (e.g. max retries reached) and I 
> need to compensate past commands all the way back. 
> 
> How would you suggest to implement compensation given AtMostOnce delivery? 
> Taking the same path as original commands doesn't seem efficient (retry 
> compensation if no Ack? who would recover/rollback if compensation fails?). 
> Implementing separate infrastructure for compensation path - doesn't look as 
> a right way to go either.
> Any provisions in Akka to help developers handle such scenarios? 
> 
> Regards,
> sergch
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Intended use for akka.Done and akka.NotUsed

[Roland Kuhn]

t;>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/akka-user 
>> <https://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> 
>> --
>> Patrik Nordwall
>> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
>> Twitter: @patriknw
>> 
>>  <http://www.lightbend.com/>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/akka-user 
>> <https://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Disable hostname verification

[Roland Kuhn]

>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>>> >>>>>>>>>> Check the FAQ: 
>>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>>> >>>>>>>>>> <https://groups.google.com/group/akka-user>
>>> ---
>>> You received this message because you are subscribed to the Google Groups 
>>> "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to akka-user+...@googlegroups.com <>.
>>> To post to this group, send email to akka...@googlegroups.com <>.
>>> Visit this group at https://groups.google.com/group/akka-user 
>>> <https://groups.google.com/group/akka-user>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <https://groups.google.com/d/optout>.
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <https://groups.google.com/group/akka-user>
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/akka-user 
>> <https://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Thread interrupt during message send

[Roland Kuhn]

Hi Hbf,

(which is a bit funny because I always read «Hauptbahnhof» :-) )

there are no guarantees, we only promise at-most-once messaging. That said, 
local message sends are hard to drop without killing the JVM in the process. 
But interrupting threads may result in undefined behavior (in particular the 
interrupt and/or the message may get lost, depending on the mailbox and 
dispatcher implementations).

May I ask why you intend to interrupt Actor threads?

Regards,

Roland

> 19 feb 2016 kl. 06:45 skrev hbf <k...@iaeth.ch>:
> 
> Hi everybody,
> 
> If a thread gets interrupted during a actor.tell(msg, sender), is it 
> guaranteed that the message still gets sent?
> 
> In my test case, the actor probe confirms that the message is indeed sent but 
> having read that there are minor differences between the dispatcher used for 
> tests and the "real" one, I'd like to confirm this.
> 
> Thanks!
> Hbf
> 
> [ERROR] [02/18/2016 21:39:03.400] [Thread-3] 
> [akka://default/system/testProbe-2] interrupted during message send
> java.lang.InterruptedException
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1245)
>   at 
> java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:442)
>   at 
> akka.testkit.CallingThreadDispatcher.runQueue(CallingThreadDispatcher.scala:275)
>   at 
> akka.testkit.CallingThreadDispatcher.dispatch(CallingThreadDispatcher.scala:208)
>   at akka.actor.dungeon.Dispatch$class.sendMessage(Dispatch.scala:132)
>   at akka.actor.ActorCell.sendMessage(ActorCell.scala:374)
>   at akka.actor.Cell$class.sendMessage(ActorCell.scala:295)
>   at akka.actor.ActorCell.sendMessage(ActorCell.scala:374)
>   at akka.actor.RepointableActorRef.$bang(RepointableActorRef.scala:169)
>   at akka.actor.ActorRef.tell(ActorRef.scala:128)
>   at org.foo.lambda$run$3(Bar.java:62)
>   at java.util.Optional.ifPresent(Optional.java:159)
>   at org.foo.run(Bar.java:57)
> 
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.