Re: [akka-user] How to pass a Spring security context to all actors in a Akka system?

[Bernd Götz]

Thanks, sounds interesting, I'll have a closer look at it.

2016-03-17 22:03 GMT+01:00 Carlos Dañel Ferreyra :

> I believe the tracing module 
> of Kamon  can help you here.
> After authentication you should dispatch the first message within a new
> tracer context, Kamon will ensure that context is propagated to all actors
> involved.
>
>
> El jueves, 17 de marzo de 2016, 17:17:30 (UTC-3), Ryan Tanner escribió:
>>
>> Don't pass auth info into the *system, *pass with with each message into
>> the *actor*.  When a request comes in and its identity is authenticated,
>> pass that authentication along with your messages.  Then, if needed, let
>> your actors figure out authorization based on that authenticated identity
>> with whatever requirements are necessary for that component.
>>
>> This avoids both the ThreadLocal issue *and* makes it trivial to scale
>> that across nodes—you pass whatever information is required all the way
>> through your application.  So long as it's serializable, it doesn't matter
>> if those messages cross your cluster or stay local.
>>
>> On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote:
>>>
>>> Hi Konrad, thanks for the heads up.
>>>
>>> Good point, I will also ask around in the Spring community.
>>>
>>> It can be looked at, however, as a general question of security in a
>>> Akka system - how can I pass user identity information into a Akka system
>>> so that it can be picked up by any Actor receiving messages? After thinking
>>> a bit about it, it's of course not that straight forward - even if I'm able
>>> to bring the Spring SecurityContext onto each thread in the Akka system (by
>>> overriding the ExecutionContext (
>>> http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what
>>> should be happening when an actor is actually executed on a remote machine?
>>>
>>> So my question for this community is: How is identity passed into an
>>> Akka System? Or put differently, how do you solve the issue of
>>> authorization within an Actor? As an Actor is responsible for the state of
>>> a certain resource, it is also its responsibility to make sure to block
>>> unauthorized users to change its state.
>>>
>>> Best Regards,
>>> Bernd
>>>
>>> On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:

 Hi there Bernd,
 I think this is more of a Spring Security question... I don't really
 know if those strategies they provide work in such contexts.

 In general you could ask such question on a Spring group and explain
 that the context needs to survive being used
 from one thread at a time, but it could be a different one each time.
 Anything ThreadLocal based generally will not work (in any kind of
 async toolkits, not just Akka).

 --
 Cheers,
 Konrad 'ktoso’ Malawski
 Akka  @ Lightbend 
 

 On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote:

 Hello All,

 we have a small service that implements a REST API, and we use Akka to
 enable concurrency, for structure and readibility of our code. All works
 fine, except I'm struggling now with our security integration. We're using
 Spring as our 'container' framework and Spring Security to handle
 authentication and authorization. My question now is: How can I use

 String userId =
 SecurityContextHolder.getContext().getAuthentication().getName();

 in our actors? I know that the Spring security context is by default
 put into a ThreadLocal. One idea I had is to create an ExecutionContext and
 pass this to the Actor system create method, thus letting Spring create the
 threads, and using the security context passing strategy '
 MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if
 anybody has done this thing already. 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+...@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 

Re: [akka-user] How to pass a Spring security context to all actors in a Akka system?

[Bernd G.]

Thanks, sounds interesting, I'll have a closer look at it.

On Friday, 18 March 2016 00:13:51 UTC+1, Carlos Dañel Ferreyra wrote:
>
> I believe the tracing module  
> of Kamon  can help you here.
> After authentication you should dispatch the first message within a new 
> tracer context, Kamon will ensure that context is propagated to all actors 
> involved.
>
> El jueves, 17 de marzo de 2016, 17:17:30 (UTC-3), Ryan Tanner escribió:
>>
>> Don't pass auth info into the *system, *pass with with each message into 
>> the *actor*.  When a request comes in and its identity is authenticated, 
>> pass that authentication along with your messages.  Then, if needed, let 
>> your actors figure out authorization based on that authenticated identity 
>> with whatever requirements are necessary for that component.
>>
>> This avoids both the ThreadLocal issue *and* makes it trivial to scale 
>> that across nodes—you pass whatever information is required all the way 
>> through your application.  So long as it's serializable, it doesn't matter 
>> if those messages cross your cluster or stay local.
>>
>> On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote:
>>>
>>> Hi Konrad, thanks for the heads up. 
>>>
>>> Good point, I will also ask around in the Spring community. 
>>>
>>> It can be looked at, however, as a general question of security in a 
>>> Akka system - how can I pass user identity information into a Akka system 
>>> so that it can be picked up by any Actor receiving messages? After thinking 
>>> a bit about it, it's of course not that straight forward - even if I'm able 
>>> to bring the Spring SecurityContext onto each thread in the Akka system (by 
>>> overriding the ExecutionContext (
>>> http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what 
>>> should be happening when an actor is actually executed on a remote machine? 
>>>
>>> So my question for this community is: How is identity passed into an 
>>> Akka System? Or put differently, how do you solve the issue of 
>>> authorization within an Actor? As an Actor is responsible for the state of 
>>> a certain resource, it is also its responsibility to make sure to block 
>>> unauthorized users to change its state.
>>>  
>>> Best Regards,
>>> Bernd
>>>
>>> On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:

 Hi there Bernd,
 I think this is more of a Spring Security question... I don't really 
 know if those strategies they provide work in such contexts.

 In general you could ask such question on a Spring group and explain 
 that the context needs to survive being used
 from one thread at a time, but it could be a different one each time.
 Anything ThreadLocal based generally will not work (in any kind of 
 async toolkits, not just Akka).

 -- 
 Cheers,
 Konrad 'ktoso’ Malawski
 Akka  @ Lightbend 
 

 On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote:

 Hello All,

 we have a small service that implements a REST API, and we use Akka to 
 enable concurrency, for structure and readibility of our code. All works 
 fine, except I'm struggling now with our security integration. We're using 
 Spring as our 'container' framework and Spring Security to handle 
 authentication and authorization. My question now is: How can I use

 String userId = 
 SecurityContextHolder.getContext().getAuthentication().getName();

 in our actors? I know that the Spring security context is by default 
 put into a ThreadLocal. One idea I had is to create an ExecutionContext 
 and 
 pass this to the Actor system create method, thus letting Spring create 
 the 
 threads, and using the security context passing strategy '
 MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if 
 anybody has done this thing already. 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+...@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: 

Re: [akka-user] Re: Clarification on unreachable nodes in cluster

[Guido Medina]

How long is enough time? I tried sleep 1 sec between leave and terminate 
calls and it didn't work.

On Friday, March 18, 2016 at 5:13:50 PM UTC, Konrad Malawski wrote:
>
> Also, please don't do that:
>cluster.leave(cluster.selfAddress());
> system.terminate();
> It is wrong.
>
> You need to give the cluster gossip enough time to complete the leaving 
> "nicely".
>
> Proper graceful shutdown means you need to wait for _your own_ address to 
> come back as MemberRemoved event,
> and THEN you can shut down the actor system and JVM.
>
> Related: 
> this mistake is exactly something I warn against in my recent talk "Zen of 
> Akka", you may enjoy it :-)
> https://youtu.be/tC-joPMPJLs
>
>
>
> On Fri, Mar 18, 2016 at 5:58 PM, Patrik Nordwall  > wrote:
>
> Hi Ben
>
> There are some subtle exceptions to the convergence rule. Unreachable 
> members with status Down or Exiting are not counted.
>
> /Patrik
>
> On Thu, Mar 17, 2016 at 11:25 PM, Guido Medina  > wrote:
>
> In fact in the other nodes you get the following:
>
> INFO  22:10:20,383 ster) - Cluster Node [akka.tcp://
> DevCluster@127.0.0.1:2552] - Leader is moving node [akka.tcp://
> DevCluster@127.0.0.1:38845] to [Exiting]
> INFO  22:10:20,384 orRef - Message [akka.cluster.GossipEnvelope] from 
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
> Actor[akka://DevCluster/deadLetters] was not delivered. [1] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:20,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>  
> to Actor[akka://DevCluster/deadLetters] was not delivered. [2] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:21,383 orRef - Message [akka.cluster.GossipEnvelope] from 
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
> Actor[akka://DevCluster/deadLetters] was not delivered. [3] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:21,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>  
> to Actor[akka://DevCluster/deadLetters] was not delivered. [4] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:22,383 orRef - Message [akka.cluster.GossipEnvelope] from 
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
> Actor[akka://DevCluster/deadLetters] was not delivered. [5] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:22,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>  
> to Actor[akka://DevCluster/deadLetters] was not delivered. [6] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:23,383 orRef - Message [akka.cluster.GossipEnvelope] from 
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
> Actor[akka://DevCluster/deadLetters] was not delivered. [7] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:23,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>  
> to Actor[akka://DevCluster/deadLetters] was not delivered. [8] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:24,382 orRef - Message [akka.cluster.GossipEnvelope] from 
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
> Actor[akka://DevCluster/deadLetters] was not delivered. [9] dead letters 
> encountered. This logging can be turned off or adjusted with configuration 
> settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:24,384 ster) - Cluster Node [akka.tcp://
> DevCluster@127.0.0.1:2552] - Marking exiting node(s) as UNREACHABLE 
> [Member(address = 

Re: [akka-user] Akka remote communication roadmap?

[Guido Medina]

Hi Patrik,

Good morning news, I think a light framework like Aeron will be most 
welcome, UDP shouldn't be a problem as long as (as you mentioned) reliable 
delivery can be implemented/configured on top.
About Netty 3 I don't understand what you are saying, akka-remote is 
already based on Netty 3 and the only thing I did on the Netty 3 side was 
to give them a PR to allow Netty 3 to use JDK 8 CHMv8,
which would only benefit anything that is still based on Netty 3.

I do agree that going forward and trying to do anything else based on Netty 
will just be a waste of time and effort as it is not towards the final 
goal; if that was what you meant.

Best regards,

Guido.



On Friday, March 18, 2016 at 9:47:00 AM UTC, Patrik Nordwall wrote:
>
> Hi all,
>
> A quick update of the roadmap for Akka Remoting. Lightbend's core Akka 
> team will be able to start working on a new implementation for Akka 
> Remoting next sprint, which starts April 4. We will then start with 
> describing the goals and overall design ideas and share with you.
>
> We are interested in something based on UDP, and Aeron 
>  looks promising, but we have not 
> decided anything yet.
>
> Do you think UDP is acceptable in most production environments? Of course 
> we would implement the message ordering and "reliable" delivery on top. 
> When is TCP required from an infrastructure perspective?
>
> Regarding the current Netty based implementation we would like to touch it 
> as little as possible to avoid risks of introducing new bugs. Therefore we 
> will not update to Netty 3. When we have a stable replacement the old 
> implementation will be removed.
>
> We are looking forward to working on this important area, and community 
> involvement is very much welcome.
>
> Cheers,
> Patrik
>
> On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina  > wrote:
>
>> In the meantime I can't stay idle so I started digging inside Netty 3 and 
>> at the moment I'm using my own Netty 3.10.6.Final (Not release yet) which 
>> replaces the Netty internal CHM (Was the one from JDK 5)
>> There is a PR which most likely will be on 3.10.6.Final so be watching, I 
>> didn't bother to measure it, it should be slightly faster for JDK 7 or 8 
>> but if anyone is curious just take Netty branch 3.10 and add my PR:
>>
>> https://github.com/netty/netty/pull/4905
>>
>> I wish I was a Scala expert, maybe in few months ;-)
>>
>> HTH,
>>
>> 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+...@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.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] 
>
>

-- 
>>  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: Scheduling long term processes in cluster

[Guido Medina]

Think of the following:

node_a (tasks issuer)

node_[1..N]/taskCreator (1 task creator per node)

router <- round robin router -> list -> [node_1/taskCreator, ..., 
node_N/taskCreator]

new task -> router.tell(task, sender)

each task creator creates an actor for a received task and each of this 
actors are the ones that actually create the Future.

That's the best I can come up in few minutes,

Guido.

On Friday, March 18, 2016 at 9:25:14 PM UTC, Guido Medina wrote:
>
> Remember amount of active actors != amount of running processes, you can 
> have 100 actors monitoring and/or ready to receive a task status but
> each actor will only execute something when it receives a message, the 
> thing to be careful is the dispatcher for the real tasks, these I recommend 
> you
> to create a Future per task and again, each task has its own logic and 
> from time to time such task sends a message to the owning actor.
>
> Another idea without killing this idea is to have a list of nodes in your 
> tasks issuer and put them in a round robin logic, each time you issue a 
> task, it will go
> to the next corresponding node in a cycle, but the monitoring idea there 
> isn't much you can do about it anyway.
>
> HTH,
>
> Guido.
>
> On Friday, March 18, 2016 at 8:50:57 PM UTC, Filippo De Luca wrote:
>>
>> Thanks Guido,
>> I had in mind something very similar. 
>>
>> A alternative solution I am thinking of, because I don't want more than 
>> one process running at the same time on the same node, is using a cluster 
>> aware router with one routee per node.
>>
>> When some actor send something like:
>> StartProces(...)
>>
>> the sender will be notified every now and then with the process progress 
>> and with the final result.
>>
>> So I will have one Actor instance for each execution, lets call it 
>> ProcessMonitor and one Actor instance for each node as executor. These will 
>> be reused.
>>
>> I think I may work as I want.
>>
>> On 17 March 2016 at 21:20, Guido Medina  wrote:
>>
>>> Hi Filippo,
>>>
>>> One idea (of many I guess):
>>>
>>>1. Have a dispatcher for long running futures.
>>>2. For each task create an actor and within that actor create a 
>>>future that each time such task status changes it sends a message to its 
>>>actor.
>>>3. Query such actor to get statuses.
>>>
>>> The reason that you need an actor and a future is because an actor can 
>>> do one thing at the time so you wouldn't be able to execute the job and 
>>> query status at the same time,
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Wednesday, March 16, 2016 at 10:02:25 PM UTC, Filippo De Luca wrote:

 Hi Guys,
 I have a task to schedule a long term task on the cluster. I am 
 thinking to model this task as an Actor that got deployed remotely. What 
 is 
 the best approach to do that? 
 I want to have a way to control the amount of concurrent process I run 
 in the cluster. 

 Also the Actor that run the process, run it in a Future, and it only 
 monitor it by receiving update on the progress from the future. Should I 
 use a child actor instead? The idea is that, the actor should be 
 query-able 
 to ask the progress status.

 Any help will be very welcome.


 -- 
>>> >> 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.
>>>
>>
>>
>>
>> -- 
>>  
>>
>> [image: --]
>> Filippo De Luca
>> [image: http://]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 https://groups.google.com/d/optout.

Re: [akka-user] Re: Scheduling long term processes in cluster

[Filippo De Luca]

Thanks Guido,
I had in mind something very similar.

A alternative solution I am thinking of, because I don't want more than one
process running at the same time on the same node, is using a cluster aware
router with one routee per node.

When some actor send something like:
StartProces(...)

the sender will be notified every now and then with the process progress
and with the final result.

So I will have one Actor instance for each execution, lets call it
ProcessMonitor and one Actor instance for each node as executor. These will
be reused.

I think I may work as I want.

On 17 March 2016 at 21:20, Guido Medina  wrote:

> Hi Filippo,
>
> One idea (of many I guess):
>
>1. Have a dispatcher for long running futures.
>2. For each task create an actor and within that actor create a future
>that each time such task status changes it sends a message to its actor.
>3. Query such actor to get statuses.
>
> The reason that you need an actor and a future is because an actor can do
> one thing at the time so you wouldn't be able to execute the job and query
> status at the same time,
>
> HTH,
>
> Guido.
>
> On Wednesday, March 16, 2016 at 10:02:25 PM UTC, Filippo De Luca wrote:
>>
>> Hi Guys,
>> I have a task to schedule a long term task on the cluster. I am thinking
>> to model this task as an Actor that got deployed remotely. What is the best
>> approach to do that?
>> I want to have a way to control the amount of concurrent process I run in
>> the cluster.
>>
>> Also the Actor that run the process, run it in a Future, and it only
>> monitor it by receiving update on the progress from the future. Should I
>> use a child actor instead? The idea is that, the actor should be query-able
>> to ask the progress status.
>>
>> Any help will be very welcome.
>>
>>
>> --
> >> 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.
>



-- 


[image: --]
Filippo De Luca
[image: http://]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 https://groups.google.com/d/optout.

Re: [akka-user] Akka Cluster without Remoting?

[Endre Varga]

Hi Curt,

On Fri, Mar 18, 2016 at 5:35 AM, Curt Siffert  wrote:

> Hi, I'm supporting a pre-existing Akka project that is currently set up to
> run 1 Master instance and N Worker instances.
>
> It does not use routing/remoting.
>

What do you mean by not using routing? How does that relate to remoting? I
sense some confusion here.


> We start them in 'Master' or 'Worker' modes via startup flags - each
> instance has its own actor system, and the only information they
> communicate to each other is through Redis Pubsub.  Each of them does
> accept API requests so they are all behind a load balancer.
>
> The Master actor system and the Worker actor system are slightly
> different, in that Master polls some information and publishes to Redis,
> while Worker subscribes to Redis so they all have the same information to
> serve to the API requests.
>
> Now we have a desire to start up N instances without using the startup
> flags, and have the instances just figure out for themselves which is
> Master - and if it goes down, another would be master, etc. We don't want
> more than one Master, since only one should poll the external information.
> We don't need to send application messages across nodes since we'd keep
> Redis.
>
> Looking at the Akka Cluster tutorials, I'm seeing a couple of options on
> how to do this:
>
> 1) Just use leader election, and listen for LeaderChanged messages to make
> Leader always be Master (stopping the Worker actor system and starting the
> Master actor system if necessary). But this seems against the spirit of
> keeping leader election decoupled from application functionality. Plus, in
> experimenting, I'm seeing nodes switch Leader more often than I'd like
> Master to switch (like if I take node #1 down and then bring it back up -
> node #1 seems to end up Leader again even if node #2 was Leader for that
> intervening time).
>

The internal leader election is not to be used for these tasks. It is
rather special, you should use ClusterSingleton.



> 2) Use ClusterSingleton - but if I did this, what would be the way for the
> Worker nodes to realize it is not the Master Singleton and start up the
> different Worker actor system?
>

The cluster singleton can be at a known path in each of the systems. You
can dedicate one actor that pings this path on the local system
periodically (every 1-2 sec) and if it sees that there is a singleton there
it starts up the worker subsystem, and when it no longer sees a singleton
there (because it was migrated) then it starts up the worker subsystem
again.

With no routing/remoting, Master would not be sending messages to them.
>

Clustering works on top of remoting. I sense a confusion here, again.


>
> It seems like this is a bit against the spirit of using Akka Cluster which
> seems to assume routing. Is there a better way?
>
> Thanks,
> Curt
>
> --
> >> 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 Websockets Java with Actor

[Guido Medina]

Give me cookies first, oreos !!!
I'm sure I will, it is just a matter of time and spend sometime migrating, 
I just initially didn't have the time to be the first with headaches,
That said I think in a couple of weeks I should be moved over.

Thanks to Akka team and contributors for all the effort put here,

Guido.

On Friday, March 18, 2016 at 4:06:08 PM UTC, Konrad Malawski wrote:
>
> New Java API is comign in very large steps, I think the new one you'll 
> like a lot and come back to plain Akka :-)
>
>
> On Mon, Mar 14, 2016 at 5:13 PM, Guido Medina  > wrote:
>
>> Also there are other aspects you should be aware like back-pressure which 
>> is better handled at Akka, to be fair both teams are awesome (Vert.x and 
>> Akka)
>> But in my case my decision was influenced by the fact that my company has 
>> 1 man team for the project => me, so I need things to be done faster than 
>> normal workflow.
>> Also I'm streaming many small messages (prices) and they need to get to 
>> the client fast so speed is an important factor for me.
>>
>> HTH,
>>
>> Guido.
>>
>>
>> On Monday, March 14, 2016 at 4:03:41 PM UTC, Guido Medina wrote:
>>>
>>> Vert.x is just another reactive framework, I found it easier to use than 
>>> Akka HTTP for Java that's all, and I think (at least today) it is faster.
>>> I cannot really recommend you one or the other just state what I know, 
>>> the decision is still yours.
>>> I know Akka team works very hard on improving things so always be open 
>>> and treat my recommendation as a biased opinion.
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Monday, March 14, 2016 at 11:50:57 AM UTC, Alan Klikic wrote:

 Hi Guido,

 thank you for the shared info.
 We are planing to use Google's Protocol Buffer (
 https://developers.google.com/protocol-buffers/) instead of JSON.
 You recommend using Vort.x with Netty implementation instead of Akka 
 HTTP for now?

 Br,
 Alan

 Dana srijeda, 9. ožujka 2016. u 11:11:43 UTC+1, korisnik Guido Medina 
 napisao je:
>
> *Disclaimer:* The Akka HTTP performance on that page is outdated, 
> now; if Akka HTTP is around 75% performance of Play 2, you can guess 
> where 
> it would be on that list.
>
> On Wednesday, March 9, 2016 at 9:58:04 AM UTC, Guido Medina wrote:
>>
>> Hi Alan,
>>
>> I hope the Akka/Java example has helped, I will eventually migrate to 
>> it when Akka HTTP websockets performance gets better compared to Vert.x 
>> with Netty implementation:
>>
>>
>> https://www.techempower.com/benchmarks/#section=data-r12=peak=json
>>
>> If you notice on my original source code (in case you still need the 
>> answer), I'm passing the upgraded socket to the actor so it should just 
>> be 
>> a final property of the newly created actor.
>> Such socket has a write method, I'll post here again another -and 
>> working- example with two paths, notice that for each path a different 
>> type 
>> of actor is created and the upgraded socket is part of the actor creator:
>>
>>
>>   vertx.createHttpServer().requestHandler(request -> {
>> switch (request.path()) {
>>   case "/price": {
>> final ServerWebSocket socket = request.upgrade();
>> final ActorRef actorRef = context.actorOf(Props.create(new 
>> PriceWebsocketCreator(TargetSupervisor.this, socket)));
>> socket.setWriteQueueMaxSize(1024).
>>   handler(event -> actorRef.tell(event, NO_SENDER)).
>>   closeHandler(event -> 
>> actorRef.tell(PoisonPill.getInstance(), NO_SENDER));
>> log.info("Price websocket connection from '{}' to '{}' 
>> established.", socket.remoteAddress(), socket.localAddress());
>> break;
>>   }
>>   case "/ticket": {
>> final ServerWebSocket socket = request.upgrade();
>> final ActorRef actorRef = context.actorOf(Props.create(new 
>> TicketWebsocketCreator(TargetSupervisor.this, socket)));
>> socket.setWriteQueueMaxSize(1024).
>>   handler(event -> actorRef.tell(event, NO_SENDER)).
>>   closeHandler(event -> 
>> actorRef.tell(PoisonPill.getInstance(), NO_SENDER));
>> log.info("Ticket websocket connection from '{}' to '{}' 
>> established.", socket.remoteAddress(), socket.localAddress());
>> break;
>>   }
>>   default:
>> request.response().setStatusCode(400).end();
>> }
>>   }).listen(config.getInt("http.port"), 
>> config.getString("http.host"));
>>
>>
>> HTH,
>>
>> Guido.
>>
>> On Tuesday, March 8, 2016 at 10:03:23 AM UTC, Alan Klikic wrote:
>>>
>>> Hi Guido,
>>>
>>> this post helped me allot. Thanks.
>>> How can 

[akka-user] Re: Dedicated seed nodes for akka cluster

[Rafał Krzewski]

There are ways to boot up Akka cluster without dedicated seed node: 
whichever node comes up first becomes the seed of the cluster and lets in 
the other nodes. An external KV is used to perform the initial coordination.
Take a look at: https://github.com/hseeberger/constructr 
and https://github.com/rkrzewski/akka-cluster-etcd

Cheers,
Rafał

W dniu piątek, 18 marca 2016 00:13:51 UTC+1 użytkownik Christian 
Hoffmeister napisał:
>
> Hello,
>
> I am just starting to dive into akka-cluster and have a question regarding 
> the seed nodes:
>
> My test project consists of 4 projects so far:
>
> * PROTOCOL contains messaging case classes
> * API contains cluster node, that also exposes a rest api (akka-cluster + 
> akka-http)
> * AUTH contains cluster node for auth stuff (akka-cluster)
> * USERS contains cluster node to manage user data (akka-cluster)
>
> At the moment I just set one API and one AUTH instance as seed nodes 
> (could also have been some other nodes). Is it good practice to have 
> another special project (called SEED), that does not do anything in 
> particular,
> except for joining the cluster, to act as seed node?
>
> From my first thoughts, this might be a good idea, since this nodes would 
> have to be restarted less often then other nodes (that have business 
> logic). Basically only when updating infrastructure like host machine or 
> akka.
>
> Am I getting something wrong here?
>
> Greetings
> Christian
>

-- 
>>  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] Problems connecting a remote node using the sample cluster project

[Scott Mackie]

Hi folks,

I've been taking a look at the clustering sample project provided with the 
Typesafe Activator 
, 
and I'm having some trouble with joining a remotely running cluster.

I've got the project set up on two machines, the first machine has two 
instances of the "SimpleClusterApp" running. The consoles for these two 
processes is showing what I'd expect, membership messages showing that both 
nodes are on the cluster.

I wanted to see if I could connect a third instance of this from the second 
machine, but I can't get the config right. In the application.conf file, 
I've got the following:

akka {
  actor {
provider = "akka.cluster.ClusterActorRefProvider"
  }
  remote {
log-remote-lifecycle-events = off
netty.tcp {
  hostname = "Scott-PC"
  port = 0
}
  }

  cluster {
seed-nodes = [
  "akka.tcp://ClusterSystem@Scott-PC:2551",
  "akka.tcp://ClusterSystem@Scott-PC:2552"]

auto-down-unreachable-after = 10s
  }
}

# Disable legacy metrics in akka-cluster.
akka.cluster.metrics.enabled=off

# Enable metrics extension in akka-cluster-metrics.
akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]

# Sigar native library extract location during tests.
# Note: use per-jvm-instance folder when running multiple jvm on one host. 
akka.cluster.metrics.native-library-extract-folder=${user.dir}/target/native


Where Scott-PC is the hostname of the machine running the first two 
processes. The two parts that I've changed here are the 
"akka.remote.netty.tcp.hostname" and the "cluster.seed-nodes" properties 
(to use the other machine's hostname).

When I try to run a new process on the second machine I get the following 
output:

PS C:\Users\smackie\akka-sample-cluster-java> .\activator "runMain 
sample.cluster.simple.SimpleClusterApp 2551"
[info] Loading project definition from 
C:\Users\smackie\akka-sample-cluster-java\project
[info] Set current project to akka-sample-cluster-java (in build 
file:/C:/Users/smackie/akka-sample-cluster-java/)
[info] Running sample.cluster.simple.SimpleClusterApp 2551
[info] [INFO] [03/17/2016 00:10:18.495] [main] [akka.remote.Remoting] 
Starting remoting
[info] [ERROR] [03/17/2016 00:10:18.799] 
[ClusterSystem-akka.remote.default-remote-dispatcher-5] 
[NettyTransport(akka://
ClusterSystem)] failed to bind to Scott-PC/192.168.0.2:2551, shutting down 
Netty transport
[error] Exception in thread "main" 
org.jboss.netty.channel.ChannelException: Failed to bind to: 
Scott-PC/192.168.0.2:255
1
[error] at 
org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272)
[error] at 
akka.remote.transport.netty.NettyTransport$$anonfun$listen$1.apply(NettyTransport.scala:410)
[error] at 
akka.remote.transport.netty.NettyTransport$$anonfun$listen$1.apply(NettyTransport.scala:406)
[error] at scala.util.Success$$anonfun$map$1.apply(Try.scala:237)
[error] at scala.util.Try$.apply(Try.scala:192)
[info] [INFO] [03/17/2016 00:10:18.808] 
[ClusterSystem-akka.remote.default-remote-dispatcher-6] 
[akka://ClusterSystem/sy
stem/remoting-terminator] Shutting down remote daemon.
[error] at scala.util.Success.map(Try.scala:237)
[error] at 
scala.concurrent.Future$$anonfun$map$1.apply(Future.scala:235)
[info] [INFO] [03/17/2016 00:10:18.810] 
[ClusterSystem-akka.remote.default-remote-dispatcher-6] 
[akka://ClusterSystem/sy
stem/remoting-terminator] Remote daemon shut down; proceeding with flushing 
remote transports.
[error] at 
scala.concurrent.Future$$anonfun$map$1.apply(Future.scala:235)
[error] at 
scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
[error] at 
akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55)
[error] at 
akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:91)
[info] [INFO] [03/17/2016 00:10:18.812] 
[ClusterSystem-akka.remote.default-remote-dispatcher-6] 
[akka://ClusterSystem/sy
stem/remoting-terminator] Remoting shut down.
[error] at 
akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91)
[info] [ERROR] [03/17/2016 00:10:18.813] 
[ClusterSystem-akka.remote.default-remote-dispatcher-5] 
[akka.remote.Remoting]
Remoting system has been terminated abrubtly. Attempting to shut down 
transports
[error] at 
akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91)
[error] at 
scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72)
[error] at 
akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:90)
[error] at 
akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:39)
[error] at 
akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:399)
[error] at 

[akka-user] Re: Scheduling long term processes in cluster

[Guido Medina]

Hi Filippo,

One idea (of many I guess):

   1. Have a dispatcher for long running futures.
   2. For each task create an actor and within that actor create a future 
   that each time such task status changes it sends a message to its actor.
   3. Query such actor to get statuses.

The reason that you need an actor and a future is because an actor can do 
one thing at the time so you wouldn't be able to execute the job and query 
status at the same time,

HTH,

Guido.

On Wednesday, March 16, 2016 at 10:02:25 PM UTC, Filippo De Luca wrote:
>
> Hi Guys,
> I have a task to schedule a long term task on the cluster. I am thinking 
> to model this task as an Actor that got deployed remotely. What is the best 
> approach to do that? 
> I want to have a way to control the amount of concurrent process I run in 
> the cluster. 
>
> Also the Actor that run the process, run it in a Future, and it only 
> monitor it by receiving update on the progress from the future. Should I 
> use a child actor instead? The idea is that, the actor should be query-able 
> to ask the progress status.
>
> Any help will be very welcome.
>
>
>

-- 
>>  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] Re: Problems connecting a remote node using the sample cluster project

[Scott Mackie]

I think I may have realised one part of my mistake, 
the "akka.remote.netty.tcp.hostname" needs to be set to the hostname of the 
machine that the application is running on, so that the remote nodes can 
talk back to it.

Now that I've changed that, I'm successfully starting up the application, 
but its still failing to register with the seed nodes on the first machine. 
For example :

[info] [WARN] [03/17/2016 00:56:07.070] 
[ClusterSystem-akka.remote.default-remote-dispatcher-21] 
[akka.tcp://ClusterSyst
em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
has failed, address is now gated for [5000] m
s. Reason: [Association failed with 
[akka.tcp://ClusterSystem@Scott-PC:2552]] Caused by: [connection timed out: 
Scott-PC
/192.168.0.2:2552]
[info] [WARN] [03/17/2016 00:56:17.371] 
[ClusterSystem-akka.remote.default-remote-dispatcher-22] 
[akka.tcp://ClusterSyst
em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2551-
0] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2551] 
has failed, address is now gated for [5000] m
s. Reason: [Association failed with 
[akka.tcp://ClusterSystem@Scott-PC:2551]] Caused by: [connection timed out: 
Scott-PC
/192.168.0.2:2551]
[info] [WARN] [03/17/2016 00:56:27.171] 
[ClusterSystem-akka.remote.default-remote-dispatcher-21] 
[akka.tcp://ClusterSyst
em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
has failed, address is now gated for [5000] m
s. Reason: [Association failed with 
[akka.tcp://ClusterSystem@Scott-PC:2552]] Caused by: [connection timed out: 
Scott-PC
/192.168.0.2:2552]
[info] [WARN] [03/17/2016 00:56:42.229] 
[ClusterSystem-akka.remote.default-remote-dispatcher-22] 
[akka.tcp://ClusterSyst
em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2551-
0] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2551] 
has failed, address is now gated for [5000] m
s. Reason: [Association failed with 
[akka.tcp://ClusterSystem@Scott-PC:2551]] Caused by: [connection timed out: 
Scott-PC
/192.168.0.2:2551]
[info] [WARN] [03/17/2016 00:56:47.272] 
[ClusterSystem-akka.remote.default-remote-dispatcher-22] 
[akka.tcp://ClusterSyst
em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
has failed, address is now gated for [5000] m
s. Reason: [Association failed with 
[akka.tcp://ClusterSystem@Scott-PC:2552]] Caused by: [connection timed out: 
Scott-PC
/192.168.0.2:2552]



On Thursday, 17 March 2016 00:25:06 UTC, Scott Mackie wrote:
>
> Hi folks,
>
> I've been taking a look at the clustering sample project provided with 
> the Typesafe Activator 
> , 
> and I'm having some trouble with joining a remotely running cluster.
>
> I've got the project set up on two machines, the first machine has two 
> instances of the "SimpleClusterApp" running. The consoles for these two 
> processes is showing what I'd expect, membership messages showing that both 
> nodes are on the cluster.
>
> I wanted to see if I could connect a third instance of this from the 
> second machine, but I can't get the config right. In the application.conf 
> file, I've got the following:
>
> akka {
>   actor {
> provider = "akka.cluster.ClusterActorRefProvider"
>   }
>   remote {
> log-remote-lifecycle-events = off
> netty.tcp {
>   hostname = "Scott-PC"
>   port = 0
> }
>   }
>
>   cluster {
> seed-nodes = [
>   "akka.tcp://ClusterSystem@Scott-PC:2551",
>   "akka.tcp://ClusterSystem@Scott-PC:2552"]
>
> auto-down-unreachable-after = 10s
>   }
> }
>
> # Disable legacy metrics in akka-cluster.
> akka.cluster.metrics.enabled=off
>
> # Enable metrics extension in akka-cluster-metrics.
> akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]
>
> # Sigar native library extract location during tests.
> # Note: use per-jvm-instance folder when running multiple jvm on one host. 
>
> akka.cluster.metrics.native-library-extract-folder=${user.dir}/target/native
>
>
> Where Scott-PC is the hostname of the machine running the first two 
> processes. The two parts that I've changed here are the 
> "akka.remote.netty.tcp.hostname" and the "cluster.seed-nodes" properties 
> (to use the other machine's hostname).
>
> When I try to run a new process on the second machine I get the following 
> output:
>
> PS C:\Users\smackie\akka-sample-cluster-java> .\activator "runMain 
> sample.cluster.simple.SimpleClusterApp 2551"
> [info] 

Re: [akka-user] Problems connecting a remote node using the sample cluster project

[Heiko Seeberger]

You need to start one node with akka.remote.netty.tcp.port=2551 (the first seed 
node) at least, e.g. via a JVM argument. Read up the details in the Cluster 
docs.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de 
Twitter: @hseeberger 
Public key: keybase.io/hseeberger 
> On 17 Mar 2016, at 01:57, Scott Mackie  wrote:
> 
> I think I may have realised one part of my mistake, the 
> "akka.remote.netty.tcp.hostname" needs to be set to the hostname of the 
> machine that the application is running on, so that the remote nodes can talk 
> back to it.
> 
> Now that I've changed that, I'm successfully starting up the application, but 
> its still failing to register with the seed nodes on the first machine. For 
> example :
> 
> [info] [WARN] [03/17/2016 00:56:07.070] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-21] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
> 1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2552]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2552]
> [info] [WARN] [03/17/2016 00:56:17.371] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-22] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2551-
> 0] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2551] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2551]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2551]
> [info] [WARN] [03/17/2016 00:56:27.171] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-21] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
> 1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2552]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2552]
> [info] [WARN] [03/17/2016 00:56:42.229] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-22] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2551-
> 0] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2551] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2551]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2551]
> [info] [WARN] [03/17/2016 00:56:47.272] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-22] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
> 1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2552]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2552]
> 
> 
> 
> On Thursday, 17 March 2016 00:25:06 UTC, Scott Mackie wrote:
> Hi folks,
> 
> I've been taking a look at the clustering sample project provided with the 
> Typesafe Activator 
> , and 
> I'm having some trouble with joining a remotely running cluster.
> 
> I've got the project set up on two machines, the first machine has two 
> instances of the "SimpleClusterApp" running. The consoles for these two 
> processes is showing what I'd expect, membership messages showing that both 
> nodes are on the cluster.
> 
> I wanted to see if I could connect a third instance of this from the second 
> machine, but I can't get the config right. In the application.conf file, I've 
> got the following:
> 
> akka {
>   actor {
> provider = "akka.cluster.ClusterActorRefProvider"
>   }
>   remote {
> log-remote-lifecycle-events = off
> netty.tcp {
>   hostname = "Scott-PC"
>   port = 0
> }
>   }
> 
>   cluster {
> seed-nodes = [
>   "akka.tcp://ClusterSystem@Scott-PC:2551",
>   "akka.tcp://ClusterSystem@Scott-PC:2552"]
> 
> auto-down-unreachable-after = 10s
>   }
> }
> 
> # Disable legacy metrics in akka-cluster.
> akka.cluster.metrics.enabled=off
> 
> # Enable metrics extension in akka-cluster-metrics.
> akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]
> 
> # Sigar native library extract location during tests.
> # Note: use per-jvm-instance folder when running multiple jvm on one 

[akka-user] Re: Dedicated seed nodes for akka cluster

['Christian Hoffmeister' via Akka User List]

So basically the known seed nodes are replaces with a known etcd cluster 
for the information sharing, if I understand this right?

Somewhat like this?

* A joins, no one is there, so it puts inself into etcd and starts a single 
node cluster
* B joins, finds A in etcd and joins A
* C joins, finds A
* A gets shut down
* After a timeout, B or C are put into etcd as new seed node
* D joins, finds B or C

In the examples 
(https://github.com/rkrzewski/akka-cluster-etcd/blob/master/examples/cluster-monitor/src/main/resources/application.conf)
 
I found that auto-downing is used. What happens in case of temporory 
network separation? For example:

* A is in etcd as seed node
* A/B (can access each other, but neither etcd nor C/D)
* C/D (can access each other, but not A/B)

What happens now? And what happen when network is fully up again and 
A/B/C/D/etcd can communicate again. Do the two isle recombine into a single 
cluster?

Greetings
/c

Am Freitag, 18. März 2016 00:13:51 UTC+1 schrieb Christian Hoffmeister:
>
> Hello,
>
> I am just starting to dive into akka-cluster and have a question regarding 
> the seed nodes:
>
> My test project consists of 4 projects so far:
>
> * PROTOCOL contains messaging case classes
> * API contains cluster node, that also exposes a rest api (akka-cluster + 
> akka-http)
> * AUTH contains cluster node for auth stuff (akka-cluster)
> * USERS contains cluster node to manage user data (akka-cluster)
>
> At the moment I just set one API and one AUTH instance as seed nodes 
> (could also have been some other nodes). Is it good practice to have 
> another special project (called SEED), that does not do anything in 
> particular,
> except for joining the cluster, to act as seed node?
>
> From my first thoughts, this might be a good idea, since this nodes would 
> have to be restarted less often then other nodes (that have business 
> logic). Basically only when updating infrastructure like host machine or 
> akka.
>
> Am I getting something wrong here?
>
> Greetings
> Christian
>

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

[Владимир Морозов]

Thank you, I dig in it :)

пятница, 18 марта 2016 г., 20:17:57 UTC+3 пользователь Konrad Malawski 
написал:
>
>
> On Sun, Mar 13, 2016 at 7:12 PM, Владимир Морозов  > wrote:
>
>> If two Player's actors live in two different remote actor systems - how 
>> safely transfer item from one player to other (read transactionally or 
>> guaranteed) 
>>
> We don't do distributed transactions, they're  the root of all evil in 
> distributed systems ;-)
>
> Instead you would send the message over, and expect an acknowlagement from 
> the other player "ok, I received your item",
> and if you didn't receive an ACK, you would try to send it again (because 
> maybe his node was down, right?).
>
> We have utils to help with that, in Akka Persistence it's 
> AtLeastOnceDelivery 
> 
>  
>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> Akka  @ Lightbend 
>

-- 
>>  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] Reader Writer Lock using Actor Model in Akka

[neel choudhury]

I want to implement the famous reader writer model using actor model. We 
can have multiple reader reading but only one writer can write. Also when a 
writer writes no reader can read and vice versa.

To solve this problem i thought of using a superviser actor which maintains 
a set for reader actors and a queue for writer actors. Now a writer can be 
dequeued and start writing when the set for readers are empty. Also when 
the writer completes all reader actors from the set can start reading.

Can we have a better problem of solving this famous problem using actor 
model?

Also is this model better than the original reader writer problem soved 
using read or write locks?

-- 
>>  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 remote communication roadmap?

[Endre Varga]

Nope. We just drop out-of-order messages. There will be no reliable
delivery (except system messages). But even if we need to add it, it is not
hard to implement.

-Endre

On Fri, Mar 18, 2016 at 11:21 AM, Guido Medina  wrote:

> Message ordering would be challenging to implement with UDP right?
>
> On Friday, March 18, 2016 at 10:20:19 AM UTC, Patrik Nordwall wrote:
>>
>>
>>
>> On Fri, Mar 18, 2016 at 11:09 AM, Filippo De Luca > > wrote:
>>
>>> Hi Patrick, what is the advantage of the UPD over TCP if we have to
>>> develop the order and delivery reliability on top of that?
>>>
>>
>> There are probably several performance reasons, but also the connection
>> lifecycle is not a good fit for actor messaging.
>>
>>
>>>
>>> The only scenario I see is the multicast, is it needed for akka-remoting?
>>>
>>> Cheers
>>>
>>> On 18 March 2016 at 09:46, Patrik Nordwall  wrote:
>>>
 Hi all,

 A quick update of the roadmap for Akka Remoting. Lightbend's core Akka
 team will be able to start working on a new implementation for Akka
 Remoting next sprint, which starts April 4. We will then start with
 describing the goals and overall design ideas and share with you.

 We are interested in something based on UDP, and Aeron
  looks promising, but we have not
 decided anything yet.

 Do you think UDP is acceptable in most production environments? Of
 course we would implement the message ordering and "reliable" delivery on
 top. When is TCP required from an infrastructure perspective?

 Regarding the current Netty based implementation we would like to touch
 it as little as possible to avoid risks of introducing new bugs. Therefore
 we will not update to Netty 3. When we have a stable replacement the old
 implementation will be removed.

 We are looking forward to working on this important area, and community
 involvement is very much welcome.

 Cheers,
 Patrik

 On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina  wrote:

> In the meantime I can't stay idle so I started digging inside Netty 3
> and at the moment I'm using my own Netty 3.10.6.Final (Not release yet)
> which replaces the Netty internal CHM (Was the one from JDK 5)
> There is a PR which most likely will be on 3.10.6.Final so be
> watching, I didn't bother to measure it, it should be slightly faster for
> JDK 7 or 8 but if anyone is curious just take Netty branch 3.10 and add my
> PR:
>
> https://github.com/netty/netty/pull/4905
>
> I wish I was a Scala expert, maybe in few months ;-)
>
> HTH,
>
> 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+...@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.
>



 --

 Patrik Nordwall
 Akka Tech Lead
 Lightbend  -  Reactive apps on the JVM
 Twitter: @patriknw

 [image: Lightbend] 

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

>>>
>>>
>>>
>>> --
>>>
>>>
>>> [image: --]
>>> Filippo De Luca
>>> [image: http://]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] Re: Akka Actor Hierarchy Question

[nkasvosve]

@Tal
Ecxellent answer

On Tuesday, 15 March 2016 07:35:10 UTC, Tal Pressman wrote:
>
> Hi,
>
> Basically it boils down to which actors should supervise others - if you 
> want to have a single actor responsible for supervising all the chat rooms 
> that's fine. Note that this *doesn't* mean that all requests have to be 
> routed through the supervisor actor. Messages can be sent between any 2 
> actors, regardless of their relation in the actor hierarchy.
>
> Regarding what happens when you make the actor persistent - this shouldn't 
> change anything. The supervisor is still only responsible for restarting 
> (or whatever strategy you choose) the child actors, while the 
> PersistentActor is responsible for recovering its own state when it is 
> restarted.
>
> So to answer your "root" question(s):
>
>1. It's fine if you want to have a single actor that's in charge of 
>all the chat room actors. It's also OK to just let them be supervised by 
>the default user guardian actor, if there is nothing special about their 
>recovery strategy.
>2. Basically, all you need to communicate with an actor is its 
>ActorRef. You can either use the built-in ActorSelection to lookup actors 
>based on their name (possibly with caching), or you can have the 
> supervisor 
>actor manage such a cache to lookup the chat room actors.
>
> Hope this helps,
> Tal
>
>
> On Monday, March 14, 2016 at 2:29:53 AM UTC+2, Neale Genereux wrote:
>>
>> Hello all,
>>
>> I'm playing around with Akka in conjunction with the Play framework, 
>> working in Java. I have a reasonable understanding of how the actor system 
>> works in general, but I need some help wrapping my head around how to set 
>> up the system efficiently. 
>>
>> Let's take the Chat server example. Let's say my Play server has several 
>> chat rooms, each identified by an ID. Each chat room has a single actor 
>> which stores the chat history as state, and handles requests to post new 
>> messages, forwarding them in turn to all other listeners. It can also 
>> handle a request to get all previous chat history. My question is: How do 
>> you setup the actor hierarchy for this system to work efficiently?
>>
>> My first instinct is to create some sort of chat room supervisor actor 
>> which will store a map of chat room id's to child actor refs. This 
>> supervisor can now handle chat room failures, and requests to create or 
>> remove chat rooms. However, every request to every chat room now has to go 
>> through this supervisor, creating a bottleneck. 
>>
>> Additionally, if I decide to make my chat room actors persistent, I'm not 
>> sure whether it is this supervisor's job to recreate those actors after a 
>> system restart. If not, how can the supervisor get its list of child actors 
>> back?
>>
>> I guess my root question is this: 
>> How do I setup a system which will have many stateful, persistent actors 
>> of the same type, all identified by a unique id such that:
>> 1) Each actor is supervised by an actor which can handle issues with its 
>> lifecycle
>> 2) Clients, such as HTTP requests from the Play framework, can 
>> efficiently communicate with these actors assuming they have that actor's ID
>>
>> Thanks for any help you can give me!
>>
>

-- 
>>  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 remote communication roadmap?

[Patrik Nordwall]

Hi all,

A quick update of the roadmap for Akka Remoting. Lightbend's core Akka team
will be able to start working on a new implementation for Akka Remoting
next sprint, which starts April 4. We will then start with describing the
goals and overall design ideas and share with you.

We are interested in something based on UDP, and Aeron
 looks promising, but we have not
decided anything yet.

Do you think UDP is acceptable in most production environments? Of course
we would implement the message ordering and "reliable" delivery on top.
When is TCP required from an infrastructure perspective?

Regarding the current Netty based implementation we would like to touch it
as little as possible to avoid risks of introducing new bugs. Therefore we
will not update to Netty 3. When we have a stable replacement the old
implementation will be removed.

We are looking forward to working on this important area, and community
involvement is very much welcome.

Cheers,
Patrik

On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina  wrote:

> In the meantime I can't stay idle so I started digging inside Netty 3 and
> at the moment I'm using my own Netty 3.10.6.Final (Not release yet) which
> replaces the Netty internal CHM (Was the one from JDK 5)
> There is a PR which most likely will be on 3.10.6.Final so be watching, I
> didn't bother to measure it, it should be slightly faster for JDK 7 or 8
> but if anyone is curious just take Netty branch 3.10 and add my PR:
>
> https://github.com/netty/netty/pull/4905
>
> I wish I was a Scala expert, maybe in few months ;-)
>
> HTH,
>
> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

[image: Lightbend] 

-- 
>>  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 remote communication roadmap?

[Patrik Nordwall]

On Fri, Mar 18, 2016 at 11:14 AM, Guido Medina  wrote:

> Hi Patrik,
>
> Good morning news, I think a light framework like Aeron will be most
> welcome, UDP shouldn't be a problem as long as (as you mentioned) reliable
> delivery can be implemented/configured on top.
> About Netty 3 I don't understand what you are saying, akka-remote is
> already based on Netty 3 and the only thing I did on the Netty 3 side was
> to give them a PR to allow Netty 3 to use JDK 8 CHMv8,
> which would only benefit anything that is still based on Netty 3.
>

Sorry, of course I mean Netty 4, which has several performance
improvements. We will stay on Netty 3, and if there is a compatible minor
version we can upgrade.


>
> I do agree that going forward and trying to do anything else based on
> Netty will just be a waste of time and effort as it is not towards the
> final goal; if that was what you meant.
>
> Best regards,
>
> Guido.
>
>
>
> On Friday, March 18, 2016 at 9:47:00 AM UTC, Patrik Nordwall wrote:
>>
>> Hi all,
>>
>> A quick update of the roadmap for Akka Remoting. Lightbend's core Akka
>> team will be able to start working on a new implementation for Akka
>> Remoting next sprint, which starts April 4. We will then start with
>> describing the goals and overall design ideas and share with you.
>>
>> We are interested in something based on UDP, and Aeron
>>  looks promising, but we have not
>> decided anything yet.
>>
>> Do you think UDP is acceptable in most production environments? Of course
>> we would implement the message ordering and "reliable" delivery on top.
>> When is TCP required from an infrastructure perspective?
>>
>> Regarding the current Netty based implementation we would like to touch
>> it as little as possible to avoid risks of introducing new bugs. Therefore
>> we will not update to Netty 3. When we have a stable replacement the old
>> implementation will be removed.
>>
>> We are looking forward to working on this important area, and community
>> involvement is very much welcome.
>>
>> Cheers,
>> Patrik
>>
>> On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina  wrote:
>>
>>> In the meantime I can't stay idle so I started digging inside Netty 3
>>> and at the moment I'm using my own Netty 3.10.6.Final (Not release yet)
>>> which replaces the Netty internal CHM (Was the one from JDK 5)
>>> There is a PR which most likely will be on 3.10.6.Final so be watching,
>>> I didn't bother to measure it, it should be slightly faster for JDK 7 or 8
>>> but if anyone is curious just take Netty branch 3.10 and add my PR:
>>>
>>> https://github.com/netty/netty/pull/4905
>>>
>>> I wish I was a Scala expert, maybe in few months ;-)
>>>
>>> HTH,
>>>
>>> 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+...@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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> [image: Lightbend] 
>>
>> --
> >> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

[image: Lightbend] 

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

[akka-user] Dedicated seed nodes for akka cluster

['Christian Hoffmeister' via Akka User List]

Hello,

I am just starting to dive into akka-cluster and have a question regarding 
the seed nodes:

My test project consists of 4 projects so far:

* PROTOCOL contains messaging case classes
* API contains cluster node, that also exposes a rest api (akka-cluster + 
akka-http)
* AUTH contains cluster node for auth stuff (akka-cluster)
* USERS contains cluster node to manage user data (akka-cluster)

At the moment I just set one API and one AUTH instance as seed nodes (could 
also have been some other nodes). Is it good practice to have another 
special project (called SEED), that does not do anything in particular,
except for joining the cluster, to act as seed node?

>From my first thoughts, this might be a good idea, since this nodes would 
have to be restarted less often then other nodes (that have business 
logic). Basically only when updating infrastructure like host machine or 
akka.

Am I getting something wrong here?

Greetings
Christian

-- 
>>  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] Akka Cluster without Remoting?

[Curt Siffert]

Hi, I'm supporting a pre-existing Akka project that is currently set up to 
run 1 Master instance and N Worker instances.

It does not use routing/remoting. We start them in 'Master' or 'Worker' 
modes via startup flags - each instance has its own actor system, and the 
only information they communicate to each other is through Redis Pubsub. 
 Each of them does accept API requests so they are all behind a load 
balancer.

The Master actor system and the Worker actor system are slightly different, 
in that Master polls some information and publishes to Redis, while Worker 
subscribes to Redis so they all have the same information to serve to the 
API requests.

Now we have a desire to start up N instances without using the startup 
flags, and have the instances just figure out for themselves which is 
Master - and if it goes down, another would be master, etc. We don't want 
more than one Master, since only one should poll the external information. 
We don't need to send application messages across nodes since we'd keep 
Redis.

Looking at the Akka Cluster tutorials, I'm seeing a couple of options on 
how to do this:

1) Just use leader election, and listen for LeaderChanged messages to make 
Leader always be Master (stopping the Worker actor system and starting the 
Master actor system if necessary). But this seems against the spirit of 
keeping leader election decoupled from application functionality. Plus, in 
experimenting, I'm seeing nodes switch Leader more often than I'd like 
Master to switch (like if I take node #1 down and then bring it back up - 
node #1 seems to end up Leader again even if node #2 was Leader for that 
intervening time).

2) Use ClusterSingleton - but if I did this, what would be the way for the 
Worker nodes to realize it is not the Master Singleton and start up the 
different Worker actor system? With no routing/remoting, Master would not 
be sending messages to them.

It seems like this is a bit against the spirit of using Akka Cluster which 
seems to assume routing. Is there a better way?

Thanks,
Curt

-- 
>>  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] Akka-camel alternatives

[Jay Hutfles]

Hi,

I've just discovered Apache Camel for enterprise integration patterns, and 
Akka's support through akka-camel. At first I was disappointed in myself for 
not knowing about it sooner.  But there isn't much discussion around it.  I 
know this may be subjective, but is Camel still a best practice solution when 
writing Scala apps which need to tie in with various services?  Where are 
people putting their efforts when considering similar problems?

Thanks in advance, and sorry for such a vague question...

-- 
>>  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: Clarification on unreachable nodes in cluster

[Konrad Malawski]

Also, please don't do that:
   cluster.leave(cluster.selfAddress());
system.terminate();
It is wrong.

You need to give the cluster gossip enough time to complete the leaving
"nicely".

Proper graceful shutdown means you need to wait for _your own_ address to
come back as MemberRemoved event,
and THEN you can shut down the actor system and JVM.

Related:
this mistake is exactly something I warn against in my recent talk "Zen of
Akka", you may enjoy it :-)
https://youtu.be/tC-joPMPJLs



On Fri, Mar 18, 2016 at 5:58 PM, Patrik Nordwall 
wrote:

> Hi Ben
>
> There are some subtle exceptions to the convergence rule. Unreachable
> members with status Down or Exiting are not counted.
>
> /Patrik
>
> On Thu, Mar 17, 2016 at 11:25 PM, Guido Medina  wrote:
>
>> In fact in the other nodes you get the following:
>>
>> INFO  22:10:20,383 ster) - Cluster Node [akka.tcp://
>> DevCluster@127.0.0.1:2552] - Leader is moving node [akka.tcp://
>> DevCluster@127.0.0.1:38845] to [Exiting]
>> INFO  22:10:20,384 orRef - Message [akka.cluster.GossipEnvelope] from
>> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
>> Actor[akka://DevCluster/deadLetters] was not delivered. [1] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:20,403 orRef - Message [akka.cluster.
>> ClusterHeartbeatSender$Heartbeat] from 
>> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>> to Actor[akka://DevCluster/deadLetters] was not delivered. [2] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:21,383 orRef - Message [akka.cluster.GossipEnvelope] from
>> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
>> Actor[akka://DevCluster/deadLetters] was not delivered. [3] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:21,403 orRef - Message [akka.cluster.
>> ClusterHeartbeatSender$Heartbeat] from 
>> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>> to Actor[akka://DevCluster/deadLetters] was not delivered. [4] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:22,383 orRef - Message [akka.cluster.GossipEnvelope] from
>> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
>> Actor[akka://DevCluster/deadLetters] was not delivered. [5] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:22,403 orRef - Message [akka.cluster.
>> ClusterHeartbeatSender$Heartbeat] from 
>> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>> to Actor[akka://DevCluster/deadLetters] was not delivered. [6] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:23,383 orRef - Message [akka.cluster.GossipEnvelope] from
>> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
>> Actor[akka://DevCluster/deadLetters] was not delivered. [7] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:23,403 orRef - Message [akka.cluster.
>> ClusterHeartbeatSender$Heartbeat] from 
>> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
>> to Actor[akka://DevCluster/deadLetters] was not delivered. [8] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:24,382 orRef - Message [akka.cluster.GossipEnvelope] from
>> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
>> Actor[akka://DevCluster/deadLetters] was not delivered. [9] dead letters
>> encountered. This logging can be turned off or adjusted with configuration
>> settings 'akka.log-dead-letters' and
>> 'akka.log-dead-letters-during-shutdown'.
>> INFO  22:10:24,384 ster) - Cluster Node [akka.tcp://
>> DevCluster@127.0.0.1:2552] - Marking exiting node(s) as UNREACHABLE
>> [Member(address = akka.tcp://DevCluster@127.0.0.1:38845, status =
>> Exiting)]. This is expected and they will be removed.
>> INFO  22:10:24,403 orRef - Message [akka.cluster.
>> ClusterHeartbeatSender$Heartbeat] from 
>> 

[akka-user] Re: Akka remote small/many messages throughput discussion?

[Guido Medina]

To clarify further, I suspect the following:

   - With the current akka-remote no design have advantage over the other 
   in as long as your are sending from same node1 to node 2.
   - With the future akka-remote different threads will be broadcasting my 
   messages depending on the sender-receiver pair which will scale better.

Again, I only suspect that's the answer but I want to double check.

Regards,

Guido.

On Friday, March 18, 2016 at 11:13:19 AM UTC, Guido Medina wrote:
>
> Given the following scenario, which design would fit best:
>
> Assume I have 2 receivers@node-1, for simplicity lets call them (I know 
> I'm using the wrong convention):
>
>- receiver-1@node-1
>- receiver-2@node-1
>
> Assume I have 4 processors@node-2, for simplicity again lets call them:
>
>- processor-1@node-2
>- processor-2@node-2
>- processor-3@node-2
>- processor-4@node-2
>
> Design 1:
>
>- All messages from receivers@node-1 go to a supervisor@node-2 which 
>using a round-robin processor-router@node-2 of processor[1..4]@node-2 
> which 
>distribute them to a respective processor.
>
> Design 2:
>
>- The round-robin processor-router is sitting at node-1 
>(processor-router@node-1 instead of processor-router@node-2) and has a 
> list 
>of actor refs processors that are at node-2 (they were sent from node-2 to 
>node-2 in order to build the router)
>
> Questions:
>
> Which of the designs has a better throughput with the current akka-remote?
> Which will perform better with the future akka-remote?
>
> By throughput I mean amount of messages that can be deliver from 
> receivers@node-1 to processors@node-2
>
> Thanks in advanced for the answers,
>
> 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.

[akka-user] Re: Reader Writer Lock using Actor Model in Akka

[Stephen McDonald]

On Friday, 18 March 2016 08:59:14 UTC+11, Rafał Krzewski wrote:
>
> Are you sure you are approaching the problem from the best angle? Akka 
> gives you a guarantee that the execution of actor code is single threaded, 
> so each time a message is processed, the code has an "exclusive lock" on 
> the actor's internal state (quotation marks because there is actually no 
> lock involved, just smart thread scheduling). 
>
> Does your writer need to exchange several messages with the target actor, 
> and the messages from readers should not be processed over the duration of 
> that conversation? In such case, you should be able to implement it with 
> little effort using become [1] and Stash [2]. For extra style points, you 
> can use FSM [3] :) Just watch out for unbounded mailboxes when using Stash! 
> Stashing large number of messages may exhaust heap space.
>

Stash is perfect for this use case. We use it to implement write 
transactions in CurioDB (https://github.com/stephenmcd/curiodb)

- Each command an actor receives is read or write, and has its own 
transaction ID
- When a write command is received and there's no current transaction, we 
store the transaction ID as the current transaction
- When a write command is received and there is a current transaction ID, 
we stash the command
- Once the transaction is finished, remove the transaction ID, and unstash 
all previously stashed commands to be replayed
- Read commands can always read, no stash-base-lock needed


 

>
> Cheers,
> Rafał
>
> [1] http://doc.akka.io/docs/akka/2.4.2/scala/actors.html#Become_Unbecome
> [2] http://doc.akka.io/docs/akka/2.4.2/scala/actors.html#Stash
> [3] http://doc.akka.io/docs/akka/2.4.2/scala/fsm.html
>
> W dniu czwartek, 17 marca 2016 16:52:47 UTC+1 użytkownik neel choudhury 
> napisał:
>>
>> I want to implement the famous reader writer model using actor model. We 
>> can have multiple reader reading but only one writer can write. Also when a 
>> writer writes no reader can read and vice versa.
>>
>> To solve this problem i thought of using a superviser actor which 
>> maintains a set for reader actors and a queue for writer actors. Now a 
>> writer can be dequeued and start writing when the set for readers are 
>> empty. Also when the writer completes all reader actors from the set can 
>> start reading.
>>
>> Can we have a better problem of solving this famous problem using actor 
>> model?
>>
>> Also is this model better than the original reader writer problem soved 
>> using read or write locks?
>>
>

-- 
>>  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 xcustom balance junction using Akka Streams graphstage is not working as intended

[Konrad Malawski]

What you're trying to build here is pretty similar to "Balance",
so readint it's source may help you out:
https://github.com/akka/akka/blob/master/akka-stream/src/main/scala/akka/stream/scaladsl/Graph.scala#L596

Also please note that the current impl:
- will eventually blow up with double-push or double-pull (one can not push
a port twice), in the current impl:
- the wiring seems wrong to me, it should specifically pick which output
port you're connecting from (`E.out(1) ~> ...`).

Can't solve the entire stage for you right now but hope this helped!

On Tue, Mar 15, 2016 at 2:40 PM, Ismail Kelebek 
wrote:

> I wanted to create a custom balance junction starting with the code below.
> First of all it behaves different in debug and run mode. They both have sth
> in common, they stop at 52. When i run it it gives this result :
>
> run: debug :
>
> 0   nnn0
> 1   nnn1
> 2   nnn2
> 3   nnn3
> ......
> ......
> ......
> 52 nnn52
>
> When i debug it , it starts with the out0's OutHandler, when i run it it
> starts with the out1's OutHandler.
> My main issue here is it stops after a pull event to a different
> OutHandler. After the OutHandler block completed with the pull(in) method,
> nothing arrives at the InHandler of inlet in.
>
>
> class MyBalance extends GraphStage[UniformFanOutShape[Int, Int]] {
>
> val in = Inlet[Int]("myBalance.in")
> val out0 = Outlet[Int]("myBalance.out0")
> val out1 = Outlet[Int]("myBalance.out1")
> val out2 = Outlet[Int]("myBalance.out2")
> val out3 = Outlet[Int]("myBalance.out3")
>
> val shape = UniformFanOutShape(in,out0,out1,out2,out3)
>
> override def createLogic(inheritedAttributes: Attributes):
> GraphStageLogic =
> new GraphStageLogic(shape) {
>
>var whichOutlet = 0
>
>setHandler(in, new InHandler {
>override def onPush(): Unit = {
>val elem = grab(in)
>whichOutlet match {
>case 0 => push(out0, elem)
>case 1 => push(out1, elem)
>case 2 => push(out2, elem)
>case 3 => push(out3, elem)
>case _ => println("wrong outlet")
>}
>
>}
>})
>setHandler(out0, new OutHandler {
>override def onPull(): Unit = {
>whichOutlet = 0
>pull(in)
>}
>})
>setHandler(out1, new OutHandler {
>override def onPull(): Unit = {
>whichOutlet = 1
>pull(in)
>}
>})
>setHandler(out2, new OutHandler {
>override def onPull(): Unit = {
>whichOutlet = 2
>pull(in)
>
>}
>})
>setHandler(out3, new OutHandler {
>override def onPull(): Unit = {
>whichOutlet = 3
>pull(in)
>}
>})
>
>
> }
> }
>
> val runnableGraphBalanceTest =
> RunnableGraph.fromGraph(GraphDSL.create() { implicit builder =>
> val A: Outlet[Int]  = builder.add(Source((0 to
> 1000).toList)).out
> val E: UniformFanOutShape[Int, Int] =
> builder.add(balanceGraphStage)
>
>
> A  ~> E ~>  Sink.foreach[Int](x => println("nnn" + x))
> E ~>  Sink.foreach[Int](x => println(x))
> E ~>  Sink.foreach[Int](x => println("h" + x))
> E ~>  Sink.foreach[Int](x => println("" +
> x))
>
> ClosedShape
> })
>
> runnableGraphBalanceTest.run
>
> --
> >> 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,
Konrad 'ktoso' 

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

[Konrad Malawski]

That's what bash pipes are for :-)

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Lightbend

On 19 March 2016 at 15:51:10, Arun Sethia (sethia.a...@gmail.com) wrote:

Thanks.

My question is more on STDOUT of any other process, specially if it is non java.

On Saturday, March 19, 2016 at 6:54:51 AM UTC-5, Konrad Malawski wrote:
Hi there,

Please don't immediately cross post your questions here and stack overflow, it 
makes it harder to track answered questions. It's ok to cross post if after a 
while you did not receive an answer, but please don't do so immediately.



In order to "intercept" stdout in Java you can setOut on the System object. It 
takes a PrintWriter, which we are able to create by wrapping an OutputStream 
"bridge" that Akka Streams provide, here's how:


 val is: OutputStream = StreamConverters.asOutputStream()
   .to(Sink.foreach(println)) // your logic pipeline here
   .run()
 System.setOut(new PrintStream(is))

-- 
Konrad
Akka @ Lightbend

W dniu sobota, 19 marca 2016 01:29:33 UTC+1 użytkownik Arun Sethia napisał:
Hi,

Is it possible to intercept STDOUT of any other process and stream them via 
akka streaming?

Thanks
Arun
--
>> 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.

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

[Arun Sethia]

Thanks.

My question is more on STDOUT of any other process, specially if it is non 
java.

On Saturday, March 19, 2016 at 6:54:51 AM UTC-5, Konrad Malawski wrote:
>
> Hi there,
>
> Please don't *immediately* cross post your questions here and stack 
> overflow 
> ,
>  
> it makes it harder to track answered questions. It's ok to cross post if 
> after a while you did not receive an answer, but please don't do so 
> immediately.
>
>
> In order to "intercept" stdout in Java you can setOut on the System object. 
> It takes a PrintWriter, which we are able to create by wrapping an 
> OutputStream "bridge" that Akka Streams provide, here's how:
>
>  val is: OutputStream = StreamConverters.asOutputStream()
>.to(Sink.foreach(println)) // your logic pipeline here
>.run()
>  System.setOut(new PrintStream(is))
>
>
> -- 
> Konrad
> Akka @ Lightbend
>
> W dniu sobota, 19 marca 2016 01:29:33 UTC+1 użytkownik Arun Sethia napisał:
>>
>> Hi,
>>
>> Is it possible to intercept STDOUT of any other process and stream them 
>> via akka streaming?
>>
>> Thanks
>> Arun
>>
>

-- 
>>  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 pass a Spring security context to all actors in a Akka system?

[Konrad Malawski]

Having that said, we do have such mechanisms in place – that act "like a
thread local, but across actors",
metadata can be transferred along with messages transparently using our
Lightbend Monitoring infrastructure:

Here's an example which does so with MDC data, but it could do the same for
security data:
http://resources.typesafe.com/monitoring/docs/integrations/slf4j-mdc.html

So the tech is there, but we're not planning to solve the security thing
right now.
If you'd like to know more or roadmap things you can ping
sa...@lightbend.com (monitoring is a commercial offering).

On Fri, Mar 18, 2016 at 8:30 AM, Bernd G.  wrote:

> Thanks, sounds interesting, I'll have a closer look at it.
>
> On Friday, 18 March 2016 00:13:51 UTC+1, Carlos Dañel Ferreyra wrote:
>>
>> I believe the tracing module
>>  of Kamon 
>> can help you here.
>> After authentication you should dispatch the first message within a new
>> tracer context, Kamon will ensure that context is propagated to all actors
>> involved.
>>
>> El jueves, 17 de marzo de 2016, 17:17:30 (UTC-3), Ryan Tanner escribió:
>>>
>>> Don't pass auth info into the *system, *pass with with each message
>>> into the *actor*.  When a request comes in and its identity is
>>> authenticated, pass that authentication along with your messages.  Then, if
>>> needed, let your actors figure out authorization based on that
>>> authenticated identity with whatever requirements are necessary for that
>>> component.
>>>
>>> This avoids both the ThreadLocal issue *and* makes it trivial to scale
>>> that across nodes—you pass whatever information is required all the way
>>> through your application.  So long as it's serializable, it doesn't matter
>>> if those messages cross your cluster or stay local.
>>>
>>> On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote:

 Hi Konrad, thanks for the heads up.

 Good point, I will also ask around in the Spring community.

 It can be looked at, however, as a general question of security in a
 Akka system - how can I pass user identity information into a Akka system
 so that it can be picked up by any Actor receiving messages? After thinking
 a bit about it, it's of course not that straight forward - even if I'm able
 to bring the Spring SecurityContext onto each thread in the Akka system (by
 overriding the ExecutionContext (
 http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what
 should be happening when an actor is actually executed on a remote machine?

 So my question for this community is: How is identity passed into an
 Akka System? Or put differently, how do you solve the issue of
 authorization within an Actor? As an Actor is responsible for the state of
 a certain resource, it is also its responsibility to make sure to block
 unauthorized users to change its state.

 Best Regards,
 Bernd

 On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:
>
> Hi there Bernd,
> I think this is more of a Spring Security question... I don't really
> know if those strategies they provide work in such contexts.
>
> In general you could ask such question on a Spring group and explain
> that the context needs to survive being used
> from one thread at a time, but it could be a different one each time.
> Anything ThreadLocal based generally will not work (in any kind of
> async toolkits, not just Akka).
>
> --
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Lightbend
> 
> 
>
> On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote:
>
> Hello All,
>
> we have a small service that implements a REST API, and we use Akka to
> enable concurrency, for structure and readibility of our code. All works
> fine, except I'm struggling now with our security integration. We're using
> Spring as our 'container' framework and Spring Security to handle
> authentication and authorization. My question now is: How can I use
>
> String userId =
> SecurityContextHolder.getContext().getAuthentication().getName();
>
> in our actors? I know that the Spring security context is by default
> put into a ThreadLocal. One idea I had is to create an ExecutionContext 
> and
> pass this to the Actor system create method, thus letting Spring create 
> the
> threads, and using the security context passing strategy '
> MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if
> anybody has done this thing already. 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:

[akka-user] Re: Clarification on unreachable nodes in cluster

[Guido Medina]

Hi Benjamin,

I also rely on cluster events and AFAIK you can expect (and trust) 
*MemberUp* and *MemberRemoved*, these IMHO are the only two consistent 
states you can trust.
In other words, I register some actors only when their nodes reach 
*MemberUp* and unregister only when their nodes reach *MemberRemoved*
Any other state in between I would treat them as information only.

So far I haven't got any issue with my mini-shard implementation relying on 
these only 2 statuses, the draw back is that it will only have to wait for 
a longer time to react.

HTH,

Guido.

On Thursday, March 17, 2016 at 6:07:48 PM UTC, Benjamin Black wrote:
>
> Hello,
>
> I'm adding logic to our service so that when a node is being restarted it 
> gracefully leaves the cluster using cluster.leave(cluster.selfAddress). 
> In the cluster specification doc it states:
>
> If a node is unreachable then gossip convergence is not possible and 
> therefore any leader actions are also not possible (for instance, 
> allowing a node to become a part of the cluster). To be able to move 
> forward the state of theunreachable nodes must be changed. It must become 
> reachable again or marked as down
>
> Is this totally true? If a node is unreachable and is the 
> leaving/exiting/removed state will this stop the leader from adding a new 
> node? I ask because I have an actor that subscribes to cluster events and I 
> can see a node is being added whilst another node is considered unreachable 
> and in the exiting status:
>
> 14:02:46.843 INFO  Exited member Member(address = akka.tcp://
> geyser@172.16.120.160:7000, status = Exiting)
> 14:02:51.842 INFO  Unreachable member Member(address = akka.tcp://
> geyser@172.16.120.160:7000, status = Exiting)
> 14:02:53.843 INFO  Removing member Member(address = akka.tcp://
> geyser@172.16.120.160:7000, status = Removed)
> 14:02:57.843 INFO  Exited member Member(address = akka.tcp://
> geyser@172.16.119.46:7000, status = Exiting)
> 14:03:02.760 INFO  Unreachable member Member(address = akka.tcp://
> geyser@172.16.119.46:7000, status = Exiting)
> 14:03:04.843 INFO  Adding member Member(address = akka.tcp://
> geyser@172.16.120.160:7000, status = Up)
>
> Thanks,
> Ben
>
>

-- 
>>  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 remote small/many messages throughput discussion?

[Endre Varga]

On Fri, Mar 18, 2016 at 12:31 PM, Guido Medina  wrote:

> Thanks for the quick response:
>
> Nodes pair or actors pair?
>

Sorry I meant actors pair. But honestly, in the case of UDP there will be
no performance increase by having these subchannels at all, at least in
terms of throughput, the difference will be better latency in case of
messages that wildly differ in size. The only reason why multiple TCP
connections are better in throughput than one is because of the congestion
control which you "cheat" by opening multiple connections (TCP is fair *per
connection*). But this does not apply to UDP at all.

-Endre


> I used the wrong convention when describing the scenario, in both designs
> I'm sending from node-1 to node-2.
> The only difference between the 2 is that design 1 is sending to the same
> actor@node-2 and design 2 is cycling the actors@node-2
>
> Regards,
>
> Guido.
>
> On Friday, March 18, 2016 at 11:26:07 AM UTC, drewhk wrote:
>>
>>
>>
>> On Fri, Mar 18, 2016 at 12:13 PM, Guido Medina  wrote:
>>
>>> Given the following scenario, which design would fit best:
>>>
>>> Assume I have 2 receivers@node-1, for simplicity lets call them (I know
>>> I'm using the wrong convention):
>>>
>>>- receiver-1@node-1
>>>- receiver-2@node-1
>>>
>>> Assume I have 4 processors@node-2, for simplicity again lets call them:
>>>
>>>- processor-1@node-2
>>>- processor-2@node-2
>>>- processor-3@node-2
>>>- processor-4@node-2
>>>
>>> Design 1:
>>>
>>>- All messages from receivers@node-1 go to a supervisor@node-2 which
>>>using a round-robin processor-router@node-2 of
>>>processor[1..4]@node-2 which distribute them to a respective processor.
>>>
>>> Design 2:
>>>
>>>- The round-robin processor-router is sitting at node-1
>>>(processor-router@node-1 instead of processor-router@node-2) and has
>>>a list of actor refs processors that are at node-2 (they were sent from
>>>node-2 to node-2 in order to build the router)
>>>
>>> Questions:
>>>
>>> Which of the designs has a better throughput with the current
>>> akka-remote?
>>>
>>
>> Doesn't metter with the current.
>>
>>
>>> Which will perform better with the future akka-remote?
>>>
>>
>> Likely Design 2 as it will be able to exploit the lack of ordering
>> requirements between the different node pairs.
>>
>> -Endre
>>
>>
>>>
>>> By throughput I mean amount of messages that can be deliver from
>>> receivers@node-1 to processors@node-2
>>>
>>> Thanks in advanced for the answers,
>>>
>>> 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+...@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] Restart does not work with my zipper? What am I doing wrong?

[john . vieten]

hi roland, thanx that helps alot! And great that you still follow the list. 
Mang Greetings John

-- 
>>  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 remote communication roadmap?

[Filippo De Luca]

Hi Patrick, what is the advantage of the UPD over TCP if we have to develop
the order and delivery reliability on top of that?

The only scenario I see is the multicast, is it needed for akka-remoting?

Cheers

On 18 March 2016 at 09:46, Patrik Nordwall 
wrote:

> Hi all,
>
> A quick update of the roadmap for Akka Remoting. Lightbend's core Akka
> team will be able to start working on a new implementation for Akka
> Remoting next sprint, which starts April 4. We will then start with
> describing the goals and overall design ideas and share with you.
>
> We are interested in something based on UDP, and Aeron
>  looks promising, but we have not
> decided anything yet.
>
> Do you think UDP is acceptable in most production environments? Of course
> we would implement the message ordering and "reliable" delivery on top.
> When is TCP required from an infrastructure perspective?
>
> Regarding the current Netty based implementation we would like to touch it
> as little as possible to avoid risks of introducing new bugs. Therefore we
> will not update to Netty 3. When we have a stable replacement the old
> implementation will be removed.
>
> We are looking forward to working on this important area, and community
> involvement is very much welcome.
>
> Cheers,
> Patrik
>
> On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina  wrote:
>
>> In the meantime I can't stay idle so I started digging inside Netty 3 and
>> at the moment I'm using my own Netty 3.10.6.Final (Not release yet) which
>> replaces the Netty internal CHM (Was the one from JDK 5)
>> There is a PR which most likely will be on 3.10.6.Final so be watching, I
>> didn't bother to measure it, it should be slightly faster for JDK 7 or 8
>> but if anyone is curious just take Netty branch 3.10 and add my PR:
>>
>> https://github.com/netty/netty/pull/4905
>>
>> I wish I was a Scala expert, maybe in few months ;-)
>>
>> HTH,
>>
>> 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.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] 
>
> --
> >> 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.
>



-- 


[image: --]
Filippo De Luca
[image: http://]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 https://groups.google.com/d/optout.

Re: [akka-user] Akka remote small/many messages throughput discussion?

[Endre Varga]

On Fri, Mar 18, 2016 at 12:13 PM, Guido Medina  wrote:

> Given the following scenario, which design would fit best:
>
> Assume I have 2 receivers@node-1, for simplicity lets call them (I know
> I'm using the wrong convention):
>
>- receiver-1@node-1
>- receiver-2@node-1
>
> Assume I have 4 processors@node-2, for simplicity again lets call them:
>
>- processor-1@node-2
>- processor-2@node-2
>- processor-3@node-2
>- processor-4@node-2
>
> Design 1:
>
>- All messages from receivers@node-1 go to a supervisor@node-2 which
>using a round-robin processor-router@node-2 of processor[1..4]@node-2
>which distribute them to a respective processor.
>
> Design 2:
>
>- The round-robin processor-router is sitting at node-1
>(processor-router@node-1 instead of processor-router@node-2) and has a
>list of actor refs processors that are at node-2 (they were sent from
>node-2 to node-2 in order to build the router)
>
> Questions:
>
> Which of the designs has a better throughput with the current akka-remote?
>

Doesn't metter with the current.


> Which will perform better with the future akka-remote?
>

Likely Design 2 as it will be able to exploit the lack of ordering
requirements between the different node pairs.

-Endre


>
> By throughput I mean amount of messages that can be deliver from
> receivers@node-1 to processors@node-2
>
> Thanks in advanced for the answers,
>
> 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] Re: Clarification on unreachable nodes in cluster

[Patrik Nordwall]

Hi Ben

There are some subtle exceptions to the convergence rule. Unreachable
members with status Down or Exiting are not counted.

/Patrik

On Thu, Mar 17, 2016 at 11:25 PM, Guido Medina  wrote:

> In fact in the other nodes you get the following:
>
> INFO  22:10:20,383 ster) - Cluster Node [akka.tcp://
> DevCluster@127.0.0.1:2552] - Leader is moving node [akka.tcp://
> DevCluster@127.0.0.1:38845] to [Exiting]
> INFO  22:10:20,384 orRef - Message [akka.cluster.GossipEnvelope] from
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
> Actor[akka://DevCluster/deadLetters] was not delivered. [1] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:20,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
> to Actor[akka://DevCluster/deadLetters] was not delivered. [2] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:21,383 orRef - Message [akka.cluster.GossipEnvelope] from
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
> Actor[akka://DevCluster/deadLetters] was not delivered. [3] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:21,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
> to Actor[akka://DevCluster/deadLetters] was not delivered. [4] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:22,383 orRef - Message [akka.cluster.GossipEnvelope] from
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
> Actor[akka://DevCluster/deadLetters] was not delivered. [5] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:22,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
> to Actor[akka://DevCluster/deadLetters] was not delivered. [6] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:23,383 orRef - Message [akka.cluster.GossipEnvelope] from
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
> Actor[akka://DevCluster/deadLetters] was not delivered. [7] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:23,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
> to Actor[akka://DevCluster/deadLetters] was not delivered. [8] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:24,382 orRef - Message [akka.cluster.GossipEnvelope] from
> Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to
> Actor[akka://DevCluster/deadLetters] was not delivered. [9] dead letters
> encountered. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:24,384 ster) - Cluster Node [akka.tcp://
> DevCluster@127.0.0.1:2552] - Marking exiting node(s) as UNREACHABLE
> [Member(address = akka.tcp://DevCluster@127.0.0.1:38845, status =
> Exiting)]. This is expected and they will be removed.
> INFO  22:10:24,403 orRef - Message [akka.cluster.
> ClusterHeartbeatSender$Heartbeat] from 
> Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769]
> to Actor[akka://DevCluster/deadLetters] was not delivered. [10] dead
> letters encountered, no more dead letters will be logged. This logging can
> be turned off or adjusted with configuration settings
> 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
> INFO  22:10:25,387 ster) - Cluster Node [akka.tcp://
> DevCluster@127.0.0.1:2552] - Leader is removing exiting node [akka.tcp://
> DevCluster@127.0.0.1:38845]
>
> Notice the 1st status is [Exiting], then you see from [Exiting] to
> [Unreachable] and then you get [MemberRemoved] which isn't logged by Akka
> but I can assure you it happens, and 

[akka-user] What is the impact of Kafka Streams on reactive-kafka?

['Axel Poigné' via Akka User List]

Seems to me that Kafka streams support distribution but not back pressure, 
reactive-kafka vice versa.

Anyway, using Kafka streams seems to be very lightweight when using Kafka.

Any comments?

-- 
>>  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] Akka HTTP POST accepted media types

[Christian Pérez-Llamas]

Hi, I am doing my first steps with Akka HTTP with no previous experience 
with Spray. I need to implement a POST that can accept either *text/plain* 
or *application/json* and returns *application/json*. I am using 
akka-http-json  library for 
marshalling/unmarshalling json.

This is the part of the route that deals with it:

path("things") {
  post {
decodeRequest {
request.entity.contentType.mediaType match {
  case MediaTypes.`text/plain` =>
import PredefinedFromEntityUnmarshallers.stringUnmarshaller
entity(as[String]) { body => // Every line can contain things, 
empty lines or comments
  complete {
Source.fromString(body).getLines
  .map(_.trim)
  .filterNot(line => line.isEmpty || line.startsWith("#"))
  .toSeq
  }
}
  case MediaTypes.`application/json` =>
entity(as[List[Thing]]) { things =>
  complete(things.map(_.name))
}
  case _ =>
reject
}
}
  }
}


When I do a request with curl with '*Content-Type:text/csv*' for example I 
get a:

HTTP/1.1 404 Not Found
The requested resource could not be found.

My gut intuition tells me that I am not doing the media type multiplexing 
the right way. What is the idiomatic way to handle different media types ?, 
and how can I specify the allowed ContentTypes (or media types) so the 
response error is more specific ?

Thank you very much,
Christian

-- 
>>  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 remote communication roadmap?

[Guido Medina]

@Filippo,

I haven't watched it but it looks 
interesting: http://www.infoq.com/presentations/aeron-messaging

Cheers,

Guido.

On Friday, March 18, 2016 at 10:09:06 AM UTC, Filippo De Luca wrote:
>
> Hi Patrick, what is the advantage of the UPD over TCP if we have to 
> develop the order and delivery reliability on top of that?
>
> The only scenario I see is the multicast, is it needed for akka-remoting?
>
> Cheers
>
> On 18 March 2016 at 09:46, Patrik Nordwall  > wrote:
>
>> Hi all,
>>
>> A quick update of the roadmap for Akka Remoting. Lightbend's core Akka 
>> team will be able to start working on a new implementation for Akka 
>> Remoting next sprint, which starts April 4. We will then start with 
>> describing the goals and overall design ideas and share with you.
>>
>> We are interested in something based on UDP, and Aeron 
>>  looks promising, but we have not 
>> decided anything yet.
>>
>> Do you think UDP is acceptable in most production environments? Of course 
>> we would implement the message ordering and "reliable" delivery on top. 
>> When is TCP required from an infrastructure perspective?
>>
>> Regarding the current Netty based implementation we would like to touch 
>> it as little as possible to avoid risks of introducing new bugs. Therefore 
>> we will not update to Netty 3. When we have a stable replacement the old 
>> implementation will be removed.
>>
>> We are looking forward to working on this important area, and community 
>> involvement is very much welcome.
>>
>> Cheers,
>> Patrik
>>
>> On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina > > wrote:
>>
>>> In the meantime I can't stay idle so I started digging inside Netty 3 
>>> and at the moment I'm using my own Netty 3.10.6.Final (Not release yet) 
>>> which replaces the Netty internal CHM (Was the one from JDK 5)
>>> There is a PR which most likely will be on 3.10.6.Final so be watching, 
>>> I didn't bother to measure it, it should be slightly faster for JDK 7 or 8 
>>> but if anyone is curious just take Netty branch 3.10 and add my PR:
>>>
>>> https://github.com/netty/netty/pull/4905
>>>
>>> I wish I was a Scala expert, maybe in few months ;-)
>>>
>>> HTH,
>>>
>>> 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+...@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.
>>>
>>
>>
>>
>> -- 
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> [image: Lightbend] 
>>
>> -- 
>> >> 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.
>>
>
>
>
> -- 
>  
>
> [image: --]
> Filippo De Luca
> [image: http://]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 https://groups.google.com/d/optout.

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

[Jesse C]

I've got an application that is using akka and I'm seeing some really 
strange behavior. I'm assuming this is something dumb that I'm doing in my 
configuration.

The setup is
CentOS 6.7
Java 1.8.0_71-b15
Scala 2.11.7
Akka 2.4.2

Here is what I'm seeing. First noticed the issue because the application 
hit the system thread limit today and crashed (CentOS defaults to 1024 
processes/threads per user). That seemed very odd to me since it is pretty 
lightweight and there is only one actor in the application. So I started 
monitoring it.  From the Java side, it appears that nothing is amiss. Using 
jstack I see the expected number of threads and nothing grows over time. 
However, watching the process on the OS side, I see a fairly rapidly 
growing number of threads being created. After about 8 hours, I'm up to 
around 600 native threads. It seems like threads are being created and not 
being destroyed, but Java is losing track of them somehow.

I've got some other akka applications with the same basic stack that are 
not exhibiting this behavior. That leads me to conclude that either my 
configuration on this particular service is just wrong or my configuration 
is tickling a bug somewhere.

Here is what seems to be the relevant config pieces:

I'm creating a config for my actor system so that it will use a really 
basic custom mailbox I wrote to make sure messages get ordered:
  private[this]
  val actorConfig = ConfigFactory.parseString("""
prio-dispatcher {
  mailbox-type = "com.company.server.PriorityMailbox"
}
  """).withFallback(conf)

Then I make my actor system with this config

 private[this]
 val system = ActorSystem("mySystem", actorConfig)



Mailbox is here:
class PriorityMailbox(settings: ActorSystem.Settings, config: Config)
  extends UnboundedStablePriorityMailbox(PriorityMailbox.priority)

I create my actor with:

private[this]
val priorityActor = system.actorOf(PriorityActor.props(db).withDispatcher(
"prio-dispatcher"))

The only other thing I do that in anyway really interacts with the actor 
system at a thread/scheduling level is in the preStart for the 
priorityActor, where I set up a schedule to send a message:

  override
  def preStart()
  {
import context.dispatcher
context.system.scheduler.schedule(1.5 minutes, 1.5 minutes, self, 
NEWCALLBACK)
  }

And that's basically it. And yet, I get what appears to be an unbounded 
number of OS threads over time.

I tried tweaking my actorConfig to a fixed-sized thread pool

  private[this]
  val actorConfig = ConfigFactory.parseString("""
prio-dispatcher {
  mailbox-type = "com.company.server.PriorityMailbox"
  type = PinnedDispatcher
  executor = "thread-pool-executor"
  thread-pool-executor {
fixed-pool-size = 2
  }
  throughput = 1
}
  """).withFallback(conf)

And that did not change anything.

So here is what else I've been noticing. When I use jstack to print out the 
current threads I usually see something like this at the top
"mySystem-prio-dispatcher-395" #3305 prio=5 os_prio=0 
tid=0x7f64e1642000 nid=0x6c49 waiting on condition [0x7f6668fd3000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x80177350> (a akka.dispatch.
ForkJoinExecutorConfigurator$AkkaForkJoinPool)
at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:
2075)
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.
java:1979)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(
ForkJoinWorkerThread.java:107)


This isn't unexpected, since you expect a ForkJoinPool to clean-up old 
threads and spawn new ones over time. But it does appear to be the only 
thing in the system that is actually spawning new threads. Which would seem 
to indicate to me that this the most likely source of the thread leak. And 
that number after the thread, which I'm pretty sure is basically a running 
count of the total number of threads that have been made in the process, 
keeps going up.


Anyone have any thoughts on what I might be doing wrong or places I can 
look for more information.

cheers,
Jesse 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.

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

[Konrad Malawski]

Hi there,

Please don't *immediately* cross post your questions here and stack overflow 
,
 
it makes it harder to track answered questions. It's ok to cross post if 
after a while you did not receive an answer, but please don't do so 
immediately.


In order to "intercept" stdout in Java you can setOut on the System object. 
It takes a PrintWriter, which we are able to create by wrapping an 
OutputStream "bridge" that Akka Streams provide, here's how:

 val is: OutputStream = StreamConverters.asOutputStream()
   .to(Sink.foreach(println)) // your logic pipeline here
   .run()
 System.setOut(new PrintStream(is))


-- 
Konrad
Akka @ Lightbend

W dniu sobota, 19 marca 2016 01:29:33 UTC+1 użytkownik Arun Sethia napisał:
>
> Hi,
>
> Is it possible to intercept STDOUT of any other process and stream them 
> via akka streaming?
>
> Thanks
> Arun
>

-- 
>>  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] Re: Reader Writer Lock using Actor Model in Akka

[Guido Medina]

Trying to emulate a read/write lock with actors can be very difficult, 
maybe agents can do?

http://doc.akka.io/docs/akka/snapshot/java/agents.html

HTH,

Guido.

On Thursday, March 17, 2016 at 3:52:47 PM UTC, neel choudhury wrote:
>
> I want to implement the famous reader writer model using actor model. We 
> can have multiple reader reading but only one writer can write. Also when a 
> writer writes no reader can read and vice versa.
>
> To solve this problem i thought of using a superviser actor which 
> maintains a set for reader actors and a queue for writer actors. Now a 
> writer can be dequeued and start writing when the set for readers are 
> empty. Also when the writer completes all reader actors from the set can 
> start reading.
>
> Can we have a better problem of solving this famous problem using actor 
> model?
>
> Also is this model better than the original reader writer problem soved 
> using read or write locks?
>

-- 
>>  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: CORS Support Akka-http

[Lomig Mégard]

Hi, 

Jumping in this thread to share the akka-http CORS implementation I have 
been working on recently:

https://github.com/lomigmegard/akka-http-cors

The goal was to follow the recommendation from W3C 
(https://www.w3.org/TR/cors/) and be still easy to use. Not production 
ready as I would like to write more tests and do some benchmarks. 

Let me know if you would be interested to have this published to maven. And 
don't hesitate to open an issue to motivate me :)

Cheers, 
Lomig

On Wednesday, 3 February 2016 22:25:40 UTC+1, tdroz...@exceda.com wrote:
>
> Seems like as of akka-http 2.0.3 the pre-flight OPTIONS handling via 
> RejectionHandler no longer works as expected - at least if you're trying to 
> use the directive once to wrap all routes.
>
> It appears that the behavior of akka-http is to only return the first 
> HttpMethod that was rejected - even if all of them were.  As a result, we 
> only are handed the first one - usually GET in the 
> Access-Control-Allow-Methods header, so it looks like:
>
>  Access-Control-Allow-Methods OPTIONS, GET
>
> Which for the following PUT, POST, etc isn't really valid...
>
> On Tuesday, October 6, 2015 at 2:47:18 AM UTC-7, Filippo De Luca wrote:
>>
>> Hi,
>> This implementation works fine. But it does not handle a case in which a 
>> CORS request has been rejected. The headers are not set on the rejection 
>> handler.
>>
>> I don't know if it is an expected behavior or not. If so how we can wrap 
>> an existing RejectionHandler to add headers to all the cases?
>>
>> Thanks.
>>
>> On 25 September 2015 at 15:19, Patrik Nordwall  
>> wrote:
>>
>>> Thanks for sharing, Patrick.
>>>
>>> On Tue, Sep 22, 2015 at 1:42 PM, Patrick Ting  wrote:
>>>
 Hi Everyone,

 I ended up porting and modifying Ganta's original CORS support with an 
 existing one I had that I pulled from the Spray mailing list awhile back 
 and posted it here: https://gist.github.com/pcting/2e65c36f868c5cee7d6a

 The most frustrating part was finding a way around the loss of 
 RequestContext.withRouteResponseHandling and 
 RequestContext.withHttpResponseHeadersMapped.

 Please fork it, poke holes int it, and send feedback!

 Cheers,
 Patrick

 On Monday, August 17, 2015 at 1:40:42 PM UTC-7, Austin Guest wrote:
>
> Hi Yar. Thanks for getting back! The error message was regarding 
> headers missing from the *server's* response to the actual POST request 
> (it 
> handled the "pre-flight" OPTIONS request just fine, which is why I was 
> puzzled.
>
> I've since resolved the question, as it was a matter (as the blog you 
> linked to helpfully pointed out) of the wildcard `*` as a value for the 
> `Allow-Access-Origin` header being incompatible with setting 
> `Allow-Access-Credentials` to `true`. I temporarily resolved the issue by 
> disabling access credentials. Thanks for pointing me in the right 
> direction! :)
>
> Not the best long-term fix, but necessary for the time being as a 
> workaround for running locally (since I will always have the origin 
> 'localhost'. As a longer term fix, I plan on using Chrome's 
> Allow-Access-Origin 
> Dev Tools add-on 
> ,
>  
> which spoofs a '*' header for running locally -- just as soon as I can 
> figure out how to get my webpack dev server 
> to disable 
> credentials so the the Allow-Access headers won't conflict.
>
> If anyone's stuck on a similar problem and is interested in results, 
> I'm happy to post them here. (Though that set of problem solving would 
> belong more properly on a React mailing list than one pertaining to 
> akka-http! :P)
>
> /a/
>
> On Sunday, August 16, 2015 at 5:12:29 AM UTC-4, Yar Ilich wrote:
>>
>> Hi, 
>>
>> pleasure to be of use. I got confused: did client part omit headers 
>> from POST request? Where did you get the message "No 
>> 'Access-Control-Allow-Origin' header is present on the requested 
>> resource." 
>> from? The problem may be some caveats of using 
>> Access-Control-Allow-Origin. 
>> See 
>> http://www.webdavsystem.com/ajax/programming/cross_origin_requests, 
>> specifically the first Important! box.
>>
>> On 16 August 2015 at 10:07, Austin Guest  wrote:
>>
>>> Great implementation `yar...`!
>>>
>>> Question: I borrowed this code in my own implementation but ran into 
>>> an odd problem where it worked just fine on the preflight `OPTIONS` 
>>> request, but then omitted the CORS headers from the subsequent `POST` 
>>> that 
>>> was getting preflighted, causing the request to be rejected with a 400 
>>> Error. ("No 

Re: [akka-user] akka.stream.scaladsl.One2OneBidiFlow$OutputTruncationException$: null exception

[Konrad Malawski]

This will be addressed by: https://github.com/akka/akka/issues/19777

Also, please upgrade to Akka 2.4.2, here's the migration guide:
http://doc.akka.io/docs/akka/2.4.2/scala/stream/migration-guide-2.0-2.4-scala.html
:-)
Lots of things have been fixed in 2.4.

-- ktoso

On Thu, Mar 17, 2016 at 10:57 AM,  wrote:

> I am getting occasional the above exception. Unfortunately without a
> stackstrace.
> It is also difficult for me to reproduce the problem so I am just fishing
> for ideas or hints?
>
> The error happens when processing a stream with a Flow using  Http.get(
> actorSystem).superPool(materializer);
> I am using akka-stream-experimental_2.11 Version 2.0.2
>
>
> Many Greetings
> John
>
> --
> >> 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,
Konrad 'ktoso' Malawski
Akka  @ Lightbend 

-- 
>>  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: Clarification on unreachable nodes in cluster

[Guido Medina]

Won't happen, the micro-services are being sent Linux SIGTERM, which is why 
I'm hooking on the JVM shutdown.

On Friday, March 18, 2016 at 5:26:01 PM UTC, Konrad Malawski wrote:
>
> I precisely explained for what event you need to wait :-)
>
> Proper graceful shutdown means you need to wait for *_your own_ address* 
> to come back as *MemberRemoved* event,
> and THEN you can shut down the actor system and JVM.
>
>
> -- 
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Lightbend 
>

-- 
>>  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] Re: Clarification on unreachable nodes in cluster

[Benjamin Black]

Hi Guido,

I think in your case you are shutting down before the node has communicated 
to the leader that it wants to leave. I wait to get the MemberExited 
message before shutting down the node. Maybe I should wait for the 
MemberRemoved? Either way the ultimate aim is to not have the unreachable 
logic kick in and have to wait x seconds (I use 10 seconds) for the node to 
be auto downed by the leader. And the reason why I don't want to wait is 
according to the docs the leader wouldn't be able to add nodes whilst any 
node in the cluster is considered unreachable, which is a problem if I'm 
doing a rolling restart of all the nodes.

Regards,
Ben

On Thursday, March 17, 2016 at 4:51:30 PM UTC-4, Guido Medina wrote:
>
> As for cluster.leave(cluster.selfAddress) my micro-services use the 
> following to leave:
>
> Runtime.getRuntime().addShutdownHook(new Thread() {
>   @Override
>   public void run() {
> final Cluster cluster = Cluster.get(system);
> cluster.leave(cluster.selfAddress());
> system.terminate();
> Configurator.shutdown((LoggerContext) LogManager.getContext());
>   }
> });
>
> But honestly I have never seen that work, the other nodes just report it 
> as unreachable until it times out and it is completely removed,
> maybe the shutdown happens so fast that it is useless in my case.
>
> HTH,
>
> Guido.
>
> On Thursday, March 17, 2016 at 8:33:29 PM UTC, Guido Medina wrote:
>>
>> Hi Benjamin,
>>
>> I also rely on cluster events and AFAIK you can expect (and trust) 
>> *MemberUp* and *MemberRemoved*, these IMHO are the only two consistent 
>> states you can trust.
>> In other words, I register some actors only when their nodes reach 
>> *MemberUp* and unregister only when their nodes reach *MemberRemoved*
>> Any other state in between I would treat them as information only.
>>
>> So far I haven't got any issue with my mini-shard implementation relying 
>> on these only 2 statuses, the draw back is that it will only have to wait 
>> for a longer time to react.
>>
>> HTH,
>>
>> Guido.
>>
>> On Thursday, March 17, 2016 at 6:07:48 PM UTC, Benjamin Black wrote:
>>>
>>> Hello,
>>>
>>> I'm adding logic to our service so that when a node is being restarted 
>>> it gracefully leaves the cluster using cluster.leave(cluster
>>> .selfAddress). In the cluster specification doc it states:
>>>
>>> If a node is unreachable then gossip convergence is not possible and 
>>> therefore any leader actions are also not possible (for instance, 
>>> allowing a node to become a part of the cluster). To be able to move 
>>> forward the state of theunreachable nodes must be changed. It must 
>>> become reachable again or marked as down
>>>
>>> Is this totally true? If a node is unreachable and is the 
>>> leaving/exiting/removed state will this stop the leader from adding a new 
>>> node? I ask because I have an actor that subscribes to cluster events and I 
>>> can see a node is being added whilst another node is considered unreachable 
>>> and in the exiting status:
>>>
>>> 14:02:46.843 INFO  Exited member Member(address = akka.tcp://
>>> geyser@172.16.120.160:7000, status = Exiting)
>>> 14:02:51.842 INFO  Unreachable member Member(address = akka.tcp://
>>> geyser@172.16.120.160:7000, status = Exiting)
>>> 14:02:53.843 INFO  Removing member Member(address = akka.tcp://
>>> geyser@172.16.120.160:7000, status = Removed)
>>> 14:02:57.843 INFO  Exited member Member(address = akka.tcp://
>>> geyser@172.16.119.46:7000, status = Exiting)
>>> 14:03:02.760 INFO  Unreachable member Member(address = akka.tcp://
>>> geyser@172.16.119.46:7000, status = Exiting)
>>> 14:03:04.843 INFO  Adding member Member(address = akka.tcp://
>>> geyser@172.16.120.160:7000, status = Up)
>>>
>>> Thanks,
>>> Ben
>>>
>>>

-- 
>>  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] Re: Clarification on unreachable nodes in cluster

[Guido Medina]

I just tried this:

final Cluster cluster = Cluster.get(system);
cluster.leave(cluster.selfAddress());
try {
  Thread.sleep(1000);
} catch (InterruptedException ignored) {
}
system.terminate();

and it didn't work, still the dead node has to timeout in the others,
in other words I don't see any cluster event message coming to the node 
that just left so by default I'm just shutting down letting gossip failures 
take care of it,
and reacting only upon MemberUp and MemberRemoved instead, I have that 
working for like 10 months now no problem.

Regards,

Guido.

On Thursday, March 17, 2016 at 10:04:27 PM UTC, Benjamin Black wrote:
>
> Hi Guido,
>
> I think in your case you are shutting down before the node has 
> communicated to the leader that it wants to leave. I wait to get the 
> MemberExited message before shutting down the node. Maybe I should wait for 
> the MemberRemoved? Either way the ultimate aim is to not have the 
> unreachable logic kick in and have to wait x seconds (I use 10 seconds) for 
> the node to be auto downed by the leader. And the reason why I don't want 
> to wait is according to the docs the leader wouldn't be able to add nodes 
> whilst any node in the cluster is considered unreachable, which is a 
> problem if I'm doing a rolling restart of all the nodes.
>
> Regards,
> Ben
>
> On Thursday, March 17, 2016 at 4:51:30 PM UTC-4, Guido Medina wrote:
>>
>> As for cluster.leave(cluster.selfAddress) my micro-services use the 
>> following to leave:
>>
>> Runtime.getRuntime().addShutdownHook(new Thread() {
>>   @Override
>>   public void run() {
>> final Cluster cluster = Cluster.get(system);
>> cluster.leave(cluster.selfAddress());
>> system.terminate();
>> Configurator.shutdown((LoggerContext) LogManager.getContext());
>>   }
>> });
>>
>> But honestly I have never seen that work, the other nodes just report it 
>> as unreachable until it times out and it is completely removed,
>> maybe the shutdown happens so fast that it is useless in my case.
>>
>> HTH,
>>
>> Guido.
>>
>> On Thursday, March 17, 2016 at 8:33:29 PM UTC, Guido Medina wrote:
>>>
>>> Hi Benjamin,
>>>
>>> I also rely on cluster events and AFAIK you can expect (and trust) 
>>> *MemberUp* and *MemberRemoved*, these IMHO are the only two consistent 
>>> states you can trust.
>>> In other words, I register some actors only when their nodes reach 
>>> *MemberUp* and unregister only when their nodes reach *MemberRemoved*
>>> Any other state in between I would treat them as information only.
>>>
>>> So far I haven't got any issue with my mini-shard implementation relying 
>>> on these only 2 statuses, the draw back is that it will only have to wait 
>>> for a longer time to react.
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Thursday, March 17, 2016 at 6:07:48 PM UTC, Benjamin Black wrote:

 Hello,

 I'm adding logic to our service so that when a node is being restarted 
 it gracefully leaves the cluster using cluster.leave(cluster
 .selfAddress). In the cluster specification doc it states:

 If a node is unreachable then gossip convergence is not possible and 
 therefore any leader actions are also not possible (for instance, 
 allowing a node to become a part of the cluster). To be able to move 
 forward the state of theunreachable nodes must be changed. It must 
 become reachable again or marked as down

 Is this totally true? If a node is unreachable and is the 
 leaving/exiting/removed state will this stop the leader from adding a new 
 node? I ask because I have an actor that subscribes to cluster events and 
 I 
 can see a node is being added whilst another node is considered 
 unreachable 
 and in the exiting status:

 14:02:46.843 INFO  Exited member Member(address = akka.tcp://
 geyser@172.16.120.160:7000, status = Exiting)
 14:02:51.842 INFO  Unreachable member Member(address = akka.tcp://
 geyser@172.16.120.160:7000, status = Exiting)
 14:02:53.843 INFO  Removing member Member(address = akka.tcp://
 geyser@172.16.120.160:7000, status = Removed)
 14:02:57.843 INFO  Exited member Member(address = akka.tcp://
 geyser@172.16.119.46:7000, status = Exiting)
 14:03:02.760 INFO  Unreachable member Member(address = akka.tcp://
 geyser@172.16.119.46:7000, status = Exiting)
 14:03:04.843 INFO  Adding member Member(address = akka.tcp://
 geyser@172.16.120.160:7000, status = Up)

 Thanks,
 Ben



-- 
>>  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] Re: Restart does not work with my zipper? What am I doing wrong?

[john . vieten]

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/

-- 
>>  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] Clarification on unreachable nodes in cluster

[Benjamin Black]

Hello,

I'm adding logic to our service so that when a node is being restarted it 
gracefully leaves the cluster using cluster.leave(cluster.selfAddress). In 
the cluster specification doc it states:

If a node is unreachable then gossip convergence is not possible and 
therefore any leader actions are also not possible (for instance, allowing 
a node to become a part of the cluster). To be able to move forward the 
state of theunreachable nodes must be changed. It must become reachable again 
or marked as down

Is this totally true? If a node is unreachable and is the 
leaving/exiting/removed state will this stop the leader from adding a new 
node? I ask because I have an actor that subscribes to cluster events and I 
can see a node is being added whilst another node is considered unreachable 
and in the exiting status:

14:02:46.843 INFO  Exited member Member(address = 
akka.tcp://geyser@172.16.120.160:7000, status = Exiting)
14:02:51.842 INFO  Unreachable member Member(address = 
akka.tcp://geyser@172.16.120.160:7000, status = Exiting)
14:02:53.843 INFO  Removing member Member(address = 
akka.tcp://geyser@172.16.120.160:7000, status = Removed)
14:02:57.843 INFO  Exited member Member(address = 
akka.tcp://geyser@172.16.119.46:7000, status = Exiting)
14:03:02.760 INFO  Unreachable member Member(address = 
akka.tcp://geyser@172.16.119.46:7000, status = Exiting)
14:03:04.843 INFO  Adding member Member(address = 
akka.tcp://geyser@172.16.120.160:7000, status = Up)

Thanks,
Ben

-- 
>>  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] Restart does not work with my zipper? What am I doing wrong?

[john . vieten]

Hi,
I am using SupervisionStrategy restart. If I add a Zipper to the graph 
"restart" doesn't work.

What am I doing wrong?
The code is here: http://pastebin.com/8L6LBZ5R

I am just throwing a Exception on the count of 2. I would expect that 
"continue doing work" gets printed to system.out 4 times.

Many Greetings
John

-- 
>>  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 HTTP POST accepted media types

[Konrad Malawski]

Ah yes :-)
Agreed and that's because of what I hinted at "things can be improved, will 
follow up" in the first email :-)

Effectively the response you want is indeed produced by Akka, however only when 
content negotiation is left up to Akka,
whereas you basically did it manually (i.e. if doesnt match you manually reject 
– which results in "nothing matched... 404!").

I'll write up an example of properly doing that eventually, soon I hope, as I 
think it needs a proper docs page.
Thanks for your patience, will ping here :)

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Lightbend

On 18 March 2016 at 13:27:22, Christian Pérez-Llamas (chri...@gmail.com) wrote:

Hi, sorry, I was asking too many things and not being clear.

I am doing a curl with an intentionally unsupported content-type to see the 
response in those cases. I was expecting something more specific such as:

HTTP/1.1 415 Unsupported Media Type
The request's Content-Type is not supported. Expected:
application/json
text/plain

but getting "404 The requested resource could not be found." made me think that 
the way I am handling multiple content types is not the right way with Akka 
Http.

Thank you so much,
Christian

On Friday, 18 March 2016 12:03:27 UTC, Konrad Malawski wrote:
Hi, there's some things that can be improved here (I'll follow up later),
however the first thing that confused me:

You mention (and handle) text/plain everywhere, yet your CURL example is about 
text/csv - 
which is different so I'd expect the 404 actually.

Is that a typo or the actual question?

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Lightbend

On 18 March 2016 at 12:58:11, Christian Pérez-Llamas (chr...@gmail.com) wrote:

Hi, I am doing my first steps with Akka HTTP with no previous experience with 
Spray. I need to implement a POST that can accept either text/plain or 
application/json and returns application/json. I am using akka-http-json 
library for marshalling/unmarshalling json.

This is the part of the route that deals with it:

  
path("things") {
  post {
decodeRequest {
request.entity.contentType.mediaType match {
  case MediaTypes.`text/plain` =>
import PredefinedFromEntityUnmarshallers.stringUnmarshaller
entity(as[String]) { body => // Every line can contain things, 
empty lines or comments
  complete {
Source.fromString(body).getLines
  .map(_.trim)
  .filterNot(line => line.isEmpty || line.startsWith("#"))
  .toSeq
  }
}
  case MediaTypes.`application/json` =>
entity(as[List[Thing]]) { things =>
  complete(things.map(_.name))
}
  case _ =>
reject
}
}
  }
}


When I do a request with curl with 'Content-Type:text/csv' for example I get a:

HTTP/1.1 404 Not Found
The requested resource could not be found.

My gut intuition tells me that I am not doing the media type multiplexing the 
right way. What is the idiomatic way to handle different media types ?, and how 
can I specify the allowed ContentTypes (or media types) so the response error 
is more specific ?

Thank you very much,
Christian
--
>> 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] Re: Clarification on unreachable nodes in cluster

[Guido Medina]

In fact in the other nodes you get the following:

INFO  22:10:20,383 ster) - Cluster Node [akka.tcp://DevCluster@127.0.0.1:2552] 
- Leader is moving node [akka.tcp://DevCluster@127.0.0.1:38845] to [Exiting]
INFO  22:10:20,384 orRef - Message [akka.cluster.GossipEnvelope] from Actor[
akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [1] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:20,403 orRef - Message [akka.cluster.
ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [2] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:21,383 orRef - Message [akka.cluster.GossipEnvelope] from Actor[
akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [3] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:21,403 orRef - Message [akka.cluster.
ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [4] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:22,383 orRef - Message [akka.cluster.GossipEnvelope] from Actor[
akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [5] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:22,403 orRef - Message [akka.cluster.
ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [6] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:23,383 orRef - Message [akka.cluster.GossipEnvelope] from Actor[
akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [7] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:23,403 orRef - Message [akka.cluster.
ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [8] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:24,382 orRef - Message [akka.cluster.GossipEnvelope] from Actor[
akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [9] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
INFO  22:10:24,384 ster) - Cluster Node [akka.tcp://DevCluster@127.0.0.1:2552] 
- Marking exiting node(s) as UNREACHABLE [Member(address = 
akka.tcp://DevCluster@127.0.0.1:38845, status = Exiting)]. This is expected 
and they will be removed.
INFO  22:10:24,403 orRef - Message [akka.cluster.
ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [10] dead 
letters encountered, no more dead letters will be logged. This logging can 
be turned off or adjusted with configuration settings 
'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:25,387 ster) - Cluster Node [akka.tcp://DevCluster@127.0.0.1:2552] 
- Leader is removing exiting node [akka.tcp://DevCluster@127.0.0.1:38845]

Notice the 1st status is [Exiting], then you see from [Exiting] to 
[Unreachable] and then you get [MemberRemoved] which isn't logged by Akka 
but I can assure you it happens, and if you log the events the last two 
will be:

INFO  22:23:00,968 ster) - Cluster Node [akka.tcp://DevCluster@127.0.0.1:2552] 
- Leader is auto-downing unreachable node 
[akka.tcp://DevCluster@127.0.0.1:54621]
INFO  22:23:00,969 ster) - Cluster Node [akka.tcp://DevCluster@127.0.0.1:2552] 
- Marking unreachable node 

Re: [akka-user] Akka remote communication roadmap?

[Patrik Nordwall]

On Fri, Mar 18, 2016 at 11:09 AM, Filippo De Luca 
wrote:

> Hi Patrick, what is the advantage of the UPD over TCP if we have to
> develop the order and delivery reliability on top of that?
>

There are probably several performance reasons, but also the connection
lifecycle is not a good fit for actor messaging.


>
> The only scenario I see is the multicast, is it needed for akka-remoting?
>
> Cheers
>
> On 18 March 2016 at 09:46, Patrik Nordwall 
> wrote:
>
>> Hi all,
>>
>> A quick update of the roadmap for Akka Remoting. Lightbend's core Akka
>> team will be able to start working on a new implementation for Akka
>> Remoting next sprint, which starts April 4. We will then start with
>> describing the goals and overall design ideas and share with you.
>>
>> We are interested in something based on UDP, and Aeron
>>  looks promising, but we have not
>> decided anything yet.
>>
>> Do you think UDP is acceptable in most production environments? Of course
>> we would implement the message ordering and "reliable" delivery on top.
>> When is TCP required from an infrastructure perspective?
>>
>> Regarding the current Netty based implementation we would like to touch
>> it as little as possible to avoid risks of introducing new bugs. Therefore
>> we will not update to Netty 3. When we have a stable replacement the old
>> implementation will be removed.
>>
>> We are looking forward to working on this important area, and community
>> involvement is very much welcome.
>>
>> Cheers,
>> Patrik
>>
>> On Thu, Mar 3, 2016 at 6:29 PM, Guido Medina  wrote:
>>
>>> In the meantime I can't stay idle so I started digging inside Netty 3
>>> and at the moment I'm using my own Netty 3.10.6.Final (Not release yet)
>>> which replaces the Netty internal CHM (Was the one from JDK 5)
>>> There is a PR which most likely will be on 3.10.6.Final so be watching,
>>> I didn't bother to measure it, it should be slightly faster for JDK 7 or 8
>>> but if anyone is curious just take Netty branch 3.10 and add my PR:
>>>
>>> https://github.com/netty/netty/pull/4905
>>>
>>> I wish I was a Scala expert, maybe in few months ;-)
>>>
>>> HTH,
>>>
>>> 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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> [image: Lightbend] 
>>
>> --
>> >> 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.
>>
>
>
>
> --
>
>
> [image: --]
> Filippo De Luca
> [image: http://]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 https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

[image: Lightbend] 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: 

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



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – 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] How to pass a Spring security context to all actors in a Akka system?

[Carlos Dañel Ferreyra]

I believe the tracing module  
of Kamon  can help you here.
After authentication you should dispatch the first message within a new 
tracer context, Kamon will ensure that context is propagated to all actors 
involved.

El jueves, 17 de marzo de 2016, 17:17:30 (UTC-3), Ryan Tanner escribió:
>
> Don't pass auth info into the *system, *pass with with each message into 
> the *actor*.  When a request comes in and its identity is authenticated, 
> pass that authentication along with your messages.  Then, if needed, let 
> your actors figure out authorization based on that authenticated identity 
> with whatever requirements are necessary for that component.
>
> This avoids both the ThreadLocal issue *and* makes it trivial to scale 
> that across nodes—you pass whatever information is required all the way 
> through your application.  So long as it's serializable, it doesn't matter 
> if those messages cross your cluster or stay local.
>
> On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote:
>>
>> Hi Konrad, thanks for the heads up. 
>>
>> Good point, I will also ask around in the Spring community. 
>>
>> It can be looked at, however, as a general question of security in a Akka 
>> system - how can I pass user identity information into a Akka system so 
>> that it can be picked up by any Actor receiving messages? After thinking a 
>> bit about it, it's of course not that straight forward - even if I'm able 
>> to bring the Spring SecurityContext onto each thread in the Akka system (by 
>> overriding the ExecutionContext (
>> http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what 
>> should be happening when an actor is actually executed on a remote machine? 
>>
>> So my question for this community is: How is identity passed into an Akka 
>> System? Or put differently, how do you solve the issue of authorization 
>> within an Actor? As an Actor is responsible for the state of a certain 
>> resource, it is also its responsibility to make sure to block unauthorized 
>> users to change its state.
>>  
>> Best Regards,
>> Bernd
>>
>> On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:
>>>
>>> Hi there Bernd,
>>> I think this is more of a Spring Security question... I don't really 
>>> know if those strategies they provide work in such contexts.
>>>
>>> In general you could ask such question on a Spring group and explain 
>>> that the context needs to survive being used
>>> from one thread at a time, but it could be a different one each time.
>>> Anything ThreadLocal based generally will not work (in any kind of async 
>>> toolkits, not just Akka).
>>>
>>> -- 
>>> Cheers,
>>> Konrad 'ktoso’ Malawski
>>> Akka  @ Lightbend 
>>> 
>>>
>>> On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote:
>>>
>>> Hello All,
>>>
>>> we have a small service that implements a REST API, and we use Akka to 
>>> enable concurrency, for structure and readibility of our code. All works 
>>> fine, except I'm struggling now with our security integration. We're using 
>>> Spring as our 'container' framework and Spring Security to handle 
>>> authentication and authorization. My question now is: How can I use
>>>
>>> String userId = 
>>> SecurityContextHolder.getContext().getAuthentication().getName();
>>>
>>> in our actors? I know that the Spring security context is by default put 
>>> into a ThreadLocal. One idea I had is to create an ExecutionContext and 
>>> pass this to the Actor system create method, thus letting Spring create the 
>>> threads, and using the security context passing strategy '
>>> MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if 
>>> anybody has done this thing already. 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+...@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 

Re: [akka-user] Re: Talking to Akka Actors from non Java/Scala languages

[Konrad Malawski]

Hi there,
AFAIR it's not that hard to just use the raw 0MQ APIs and bridge into
Actors when you need to.

On Tue, Mar 15, 2016 at 3:13 PM, Brandon Barker 
wrote:

> Maybe I shouldn't be digging up an old discussion, but I'm curious what
> 0MQ interface people are now choosing? As a newcomer to both 0MQ and Akka,
> my inclination is to try JeroMQ as it seems to be well maintained.
>
> On Tuesday, February 5, 2013 at 7:51:42 PM UTC-5, Jeremy Pierre wrote:
>>
>> FWIW we use ZMQ for communication between older PHP stuff and Akka
>> nodes.  Works great so far.  AMQP tends to be better for different problems
>> but I guess it depends on what precisely the outside stuff is trying to do
>> with Akka.
>>
>> Jeremy
>>
>>
>> On Tue, Feb 5, 2013 at 4:42 PM, Marek Dolgos  wrote:
>>
>>> Thanks for the answers so far!
>>>
>>> It looks like Zmq for the time being is probably what to use if someone
>>> wants to "talk directly" to an Akka system from a non JVM language,
>>> otherwise introduce a broker, such as an AMQP broker.
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://akka.io/faq/
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_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.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
Akka  @ Lightbend 

-- 
>>  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 pass a Spring security context to all actors in a Akka system?

[Bernd G.]

Hi Konrad, thanks for the heads up. 

Good point, I will also ask around in the Spring community. 

It can be looked at, however, as a general question of security in a Akka 
system - how can I pass user identity information into a Akka system so 
that it can be picked up by any Actor receiving messages? After thinking a 
bit about it, it's of course not that straight forward - even if I'm able 
to bring the Spring SecurityContext onto each thread in the Akka system (by 
overriding the ExecutionContext 
(http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what should 
be happening when an actor is actually executed on a remote machine? 

So my question for this community is: How is identity passed into an Akka 
System? Or put differently, how do you solve the issue of authorization 
within an Actor? As an Actor is responsible for the state of a certain 
resource, it is also its responsibility to make sure to block unauthorized 
users to change its state.
 
Best Regards,
Bernd

On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:
>
> Hi there Bernd,
> I think this is more of a Spring Security question... I don't really know 
> if those strategies they provide work in such contexts.
>
> In general you could ask such question on a Spring group and explain that 
> the context needs to survive being used
> from one thread at a time, but it could be a different one each time.
> Anything ThreadLocal based generally will not work (in any kind of async 
> toolkits, not just Akka).
>
> -- 
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Lightbend 
> 
>
> On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com ) 
> wrote:
>
> Hello All,
>
> we have a small service that implements a REST API, and we use Akka to 
> enable concurrency, for structure and readibility of our code. All works 
> fine, except I'm struggling now with our security integration. We're using 
> Spring as our 'container' framework and Spring Security to handle 
> authentication and authorization. My question now is: How can I use
>
> String userId = 
> SecurityContextHolder.getContext().getAuthentication().getName();
>
> in our actors? I know that the Spring security context is by default put 
> into a ThreadLocal. One idea I had is to create an ExecutionContext and 
> pass this to the Actor system create method, thus letting Spring create the 
> threads, and using the security context passing strategy '
> MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if anybody 
> has done this thing already. 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+...@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.

Re: [akka-user] Akka HTTP POST accepted media types

[Christian Pérez-Llamas]

Hi, sorry, I was asking too many things and not being clear.

I am doing a curl with an intentionally unsupported content-type to see the 
response in those cases. I was expecting something more specific such as:

HTTP/1.1 415 Unsupported Media Type
The request's Content-Type is not supported. Expected:
application/json
text/plain

but getting "404 The requested resource could not be found." made me think 
that the way I am handling multiple content types is not the right way with 
Akka Http.

Thank you so much,
Christian

On Friday, 18 March 2016 12:03:27 UTC, Konrad Malawski wrote:
>
> Hi, there's some things that can be improved here (I'll follow up later),
> however the first thing that confused me:
>
> You mention (and handle) text/plain everywhere, yet your CURL example is 
> about text/csv - 
> which is different so I'd expect the 404 actually.
>
> Is that a typo or the actual question?
>
> -- 
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Lightbend 
> 
>
> On 18 March 2016 at 12:58:11, Christian Pérez-Llamas (chr...@gmail.com 
> ) wrote:
>
> Hi, I am doing my first steps with Akka HTTP with no previous experience 
> with Spray. I need to implement a POST that can accept either *text/plain* 
> or *application/json* and returns *application/json*. I am using 
> akka-http-json  library for 
> marshalling/unmarshalling json.
>
> This is the part of the route that deals with it:
>
> path("things") {
>   post {
> decodeRequest {
> request.entity.contentType.mediaType match {
>   case MediaTypes.`text/plain` =>
> import PredefinedFromEntityUnmarshallers.stringUnmarshaller
> entity(as[String]) { body => // Every line can contain things, 
> empty lines or comments
>   complete {
> Source.fromString(body).getLines
>   .map(_.trim)
>   .filterNot(line => line.isEmpty || line.startsWith("#"))
>   .toSeq
>   }
> }
>   case MediaTypes.`application/json` =>
> entity(as[List[Thing]]) { things =>
>   complete(things.map(_.name))
> }
>   case _ =>
> reject
> }
> }
>   }
> }
>
>
> When I do a request with curl with '*Content-Type:text/csv*' for example 
> I get a:
>
> HTTP/1.1 404 Not Found
> The requested resource could not be found.
>
> My gut intuition tells me that I am not doing the media type multiplexing 
> the right way. What is the idiomatic way to handle different media types ?, 
> and how can I specify the allowed ContentTypes (or media types) so the 
> response error is more specific ?
>
> Thank you very much,
> Christian
> --
> >> 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.

Re: [akka-user] How to pass a Spring security context to all actors in a Akka system?

[Bernd Götz]

Hi Ryan, many thanks, your proposal makes sense to me, and I think I will
take that approach.

On the other hand, I don't really like the idea to have the user id passed
along as a member of my messages, like I don't think we should pass around
the user id as method parameters in the non-Akka code. One more potential
issue is 'rogue impersonation' - would it not be possible for an attacker
to connect to my Akka system and send messages with -any- user id? How
would I be able to protect my Akka system from something like that
happening?

Anyway, as long as I have a local Akka system, things are safe, I guess.

2016-03-17 21:17 GMT+01:00 Ryan Tanner :

> Don't pass auth info into the *system, *pass with with each message into
> the *actor*.  When a request comes in and its identity is authenticated,
> pass that authentication along with your messages.  Then, if needed, let
> your actors figure out authorization based on that authenticated identity
> with whatever requirements are necessary for that component.
>
> This avoids both the ThreadLocal issue *and* makes it trivial to scale
> that across nodes—you pass whatever information is required all the way
> through your application.  So long as it's serializable, it doesn't matter
> if those messages cross your cluster or stay local.
>
>
> On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote:
>>
>> Hi Konrad, thanks for the heads up.
>>
>> Good point, I will also ask around in the Spring community.
>>
>> It can be looked at, however, as a general question of security in a Akka
>> system - how can I pass user identity information into a Akka system so
>> that it can be picked up by any Actor receiving messages? After thinking a
>> bit about it, it's of course not that straight forward - even if I'm able
>> to bring the Spring SecurityContext onto each thread in the Akka system (by
>> overriding the ExecutionContext (
>> http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what
>> should be happening when an actor is actually executed on a remote machine?
>>
>> So my question for this community is: How is identity passed into an Akka
>> System? Or put differently, how do you solve the issue of authorization
>> within an Actor? As an Actor is responsible for the state of a certain
>> resource, it is also its responsibility to make sure to block unauthorized
>> users to change its state.
>>
>> Best Regards,
>> Bernd
>>
>> On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:
>>>
>>> Hi there Bernd,
>>> I think this is more of a Spring Security question... I don't really
>>> know if those strategies they provide work in such contexts.
>>>
>>> In general you could ask such question on a Spring group and explain
>>> that the context needs to survive being used
>>> from one thread at a time, but it could be a different one each time.
>>> Anything ThreadLocal based generally will not work (in any kind of async
>>> toolkits, not just Akka).
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso’ Malawski
>>> Akka  @ Lightbend 
>>> 
>>>
>>> On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote:
>>>
>>> Hello All,
>>>
>>> we have a small service that implements a REST API, and we use Akka to
>>> enable concurrency, for structure and readibility of our code. All works
>>> fine, except I'm struggling now with our security integration. We're using
>>> Spring as our 'container' framework and Spring Security to handle
>>> authentication and authorization. My question now is: How can I use
>>>
>>> String userId =
>>> SecurityContextHolder.getContext().getAuthentication().getName();
>>>
>>> in our actors? I know that the Spring security context is by default put
>>> into a ThreadLocal. One idea I had is to create an ExecutionContext and
>>> pass this to the Actor system create method, thus letting Spring create the
>>> threads, and using the security context passing strategy '
>>> MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if
>>> anybody has done this thing already. 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+...@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 

Re: [akka-user] How to stop an Actor using akka-http's actor-per-request example without getting an Abrupt Termination?

[Konrad Malawski]

Yeah, thanks Samuel for linking to the issue.
Interested parties please watch that issue and PR :)

On Tue, Mar 15, 2016 at 9:51 AM, Samuel Tardieu  wrote:

> I think this is a bug: https://github.com/akka/akka/issues/20032
>
>
> Le mar. 15 mars 2016 à 03:57, Sam Smoot  a écrit :
>
>> That fixed it! I can't thank you enough!
>>
>>
>> On Monday, March 14, 2016 at 5:43:05 PM UTC-5, Samuel Tardieu wrote:
>>
>>> Could it be that since you define an implicit Materializer in your
>>> actor which is tied to the implicit ActorRefFactory (which would be
>>> context inside the actor), it is the one used for singleRequest which
>>> requires an implicit Materializer? Can you try defining your
>>> Materializer as ActorMaterializer()(context.system) and see if it
>>> changes the outcome?
>>> ​
>>>
>>>
>>> Le lun. 14 mars 2016 à 18:36, Sam Smoot  a écrit :
>>>
>> So if you look at the example in the docs:
 http://doc.akka.io/docs/akka/2.4.2/scala/http/client-side/request-level.html#Using_the_Future-Based_API_in_Actors

 That works fine. Except it's incomplete since it's obviously a
 single-use Actor (the request is fired off in preStart) and it doesn't show
 how to clean it up.

 I'm trying to implement this in my project, but sending context.self !
 PoisonPill to my Actor after consuming the response will reliably cause an
 AbruptTerminationException.

 I've whipped up a gist here that hopefully demonstrates the issue (with
 lots of comments): https://gist.github.com/sam/7731f883a62b329c6592

 Any help? I got a suggestion it might have something to do with the
 connection pool, but I'm not sure how to handle that. Should I pass the
 pool into my actor's constructor? Where do I get the pool? How do I pass it
 to singleRequest, which appears to take a ConnectionPoolSettings object?

 Thanks, -Sam

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



-- 
Cheers,
Konrad 'ktoso' Malawski
Akka  @ Lightbend 

-- 
>>  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] Re: Clarification on unreachable nodes in cluster

[Guido Medina]

As for cluster.leave(cluster.selfAddress) my micro-services use the 
following to leave:

Runtime.getRuntime().addShutdownHook(new Thread() {
  @Override
  public void run() {
final Cluster cluster = Cluster.get(system);
cluster.leave(cluster.selfAddress());
system.terminate();
Configurator.shutdown((LoggerContext) LogManager.getContext());
  }
});

But honestly I have never seen that work, the other nodes just report it as 
unreachable until it times out and it is completely removed,
maybe the shutdown happens so fast that it is useless in my case.

HTH,

Guido.

On Thursday, March 17, 2016 at 8:33:29 PM UTC, Guido Medina wrote:
>
> Hi Benjamin,
>
> I also rely on cluster events and AFAIK you can expect (and trust) 
> *MemberUp* and *MemberRemoved*, these IMHO are the only two consistent 
> states you can trust.
> In other words, I register some actors only when their nodes reach 
> *MemberUp* and unregister only when their nodes reach *MemberRemoved*
> Any other state in between I would treat them as information only.
>
> So far I haven't got any issue with my mini-shard implementation relying 
> on these only 2 statuses, the draw back is that it will only have to wait 
> for a longer time to react.
>
> HTH,
>
> Guido.
>
> On Thursday, March 17, 2016 at 6:07:48 PM UTC, Benjamin Black wrote:
>>
>> Hello,
>>
>> I'm adding logic to our service so that when a node is being restarted it 
>> gracefully leaves the cluster using cluster.leave(cluster.selfAddress). 
>> In the cluster specification doc it states:
>>
>> If a node is unreachable then gossip convergence is not possible and 
>> therefore any leader actions are also not possible (for instance, 
>> allowing a node to become a part of the cluster). To be able to move 
>> forward the state of theunreachable nodes must be changed. It must 
>> become reachable again or marked as down
>>
>> Is this totally true? If a node is unreachable and is the 
>> leaving/exiting/removed state will this stop the leader from adding a new 
>> node? I ask because I have an actor that subscribes to cluster events and I 
>> can see a node is being added whilst another node is considered unreachable 
>> and in the exiting status:
>>
>> 14:02:46.843 INFO  Exited member Member(address = akka.tcp://
>> geyser@172.16.120.160:7000, status = Exiting)
>> 14:02:51.842 INFO  Unreachable member Member(address = akka.tcp://
>> geyser@172.16.120.160:7000, status = Exiting)
>> 14:02:53.843 INFO  Removing member Member(address = akka.tcp://
>> geyser@172.16.120.160:7000, status = Removed)
>> 14:02:57.843 INFO  Exited member Member(address = akka.tcp://
>> geyser@172.16.119.46:7000, status = Exiting)
>> 14:03:02.760 INFO  Unreachable member Member(address = akka.tcp://
>> geyser@172.16.119.46:7000, status = Exiting)
>> 14:03:04.843 INFO  Adding member Member(address = akka.tcp://
>> geyser@172.16.120.160:7000, status = Up)
>>
>> Thanks,
>> Ben
>>
>>

-- 
>>  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] Akka remote small/many messages throughput discussion?

[Guido Medina]

Given the following scenario, which design would fit best:

Assume I have 2 receivers@node-1, for simplicity lets call them (I know I'm 
using the wrong convention):

   - receiver-1@node-1
   - receiver-2@node-1

Assume I have 4 processors@node-2, for simplicity again lets call them:

   - processor-1@node-2
   - processor-2@node-2
   - processor-3@node-2
   - processor-4@node-2

Design 1:

   - All messages from receivers@node-1 go to a supervisor@node-2 which 
   using a round-robin processor-router@node-2 of processor[1..4]@node-2 which 
   distribute them to a respective processor.

Design 2:

   - The round-robin processor-router is sitting at node-1 
   (processor-router@node-1 instead of processor-router@node-2) and has a list 
   of actor refs processors that are at node-2 (they were sent from node-2 to 
   node-2 in order to build the router)

Questions:

Which of the designs has a better throughput with the current akka-remote?
Which will perform better with the future akka-remote?

By throughput I mean amount of messages that can be deliver from 
receivers@node-1 to processors@node-2

Thanks in advanced for the answers,

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.

Re: [akka-user] Re: Clarification on unreachable nodes in cluster

[Konrad Malawski]

I precisely explained for what event you need to wait :-)

Proper graceful shutdown means you need to wait for _your own_ address to come 
back as MemberRemoved event,
and THEN you can shut down the actor system and JVM.

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Lightbend

On 18 March 2016 at 18:24:58, Guido Medina (oxyg...@gmail.com) wrote:

How long is enough time? I tried sleep 1 sec between leave and terminate calls 
and it didn't work.

On Friday, March 18, 2016 at 5:13:50 PM UTC, Konrad Malawski wrote:
Also, please don't do that:
       cluster.leave(cluster.selfAddress());
        system.terminate();
It is wrong.

You need to give the cluster gossip enough time to complete the leaving 
"nicely".

Proper graceful shutdown means you need to wait for _your own_ address to come 
back as MemberRemoved event,
and THEN you can shut down the actor system and JVM.

Related: 
this mistake is exactly something I warn against in my recent talk "Zen of 
Akka", you may enjoy it :-)
https://youtu.be/tC-joPMPJLs



On Fri, Mar 18, 2016 at 5:58 PM, Patrik Nordwall  wrote:
Hi Ben

There are some subtle exceptions to the convergence rule. Unreachable members 
with status Down or Exiting are not counted.

/Patrik

On Thu, Mar 17, 2016 at 11:25 PM, Guido Medina  wrote:
In fact in the other nodes you get the following:

INFO  22:10:20,383 ster) - Cluster Node [akka.tcp://DevCluster@127.0.0.1:2552] 
- Leader is moving node [akka.tcp://DevCluster@127.0.0.1:38845] to [Exiting]
INFO  22:10:20,384 orRef - Message [akka.cluster.GossipEnvelope] from 
Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [1] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:20,403 orRef - Message 
[akka.cluster.ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [2] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:21,383 orRef - Message [akka.cluster.GossipEnvelope] from 
Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [3] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:21,403 orRef - Message 
[akka.cluster.ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [4] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:22,383 orRef - Message [akka.cluster.GossipEnvelope] from 
Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [5] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:22,403 orRef - Message 
[akka.cluster.ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [6] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:23,383 orRef - Message [akka.cluster.GossipEnvelope] from 
Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [7] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:23,403 orRef - Message 
[akka.cluster.ClusterHeartbeatSender$Heartbeat] from 
Actor[akka://DevCluster/system/cluster/core/daemon/heartbeatSender#1423910769] 
to Actor[akka://DevCluster/deadLetters] was not delivered. [8] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:24,382 orRef - Message [akka.cluster.GossipEnvelope] from 
Actor[akka://DevCluster/system/cluster/core/daemon#1435915897] to 
Actor[akka://DevCluster/deadLetters] was not delivered. [9] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
INFO  22:10:24,384 ster) - Cluster 

[akka-user] akka.stream.scaladsl.One2OneBidiFlow$OutputTruncationException$: null exception

[john . vieten]

I am getting occasional the above exception. Unfortunately without a 
stackstrace.
It is also difficult for me to reproduce the problem so I am just fishing 
for ideas or hints?

The error happens when processing a stream with a Flow using  Http.get(
actorSystem).superPool(materializer);
I am using akka-stream-experimental_2.11 Version 2.0.2


Many Greetings
John

-- 
>>  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: ${spray.version} not find

[Konrad Malawski]

I don't know about Spray to be honest actually.
In Akka we certainly include the akka.version in config.

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Lightbend

On 15 March 2016 at 18:59:52, abhishek jain (aa.jai...@gmail.com) wrote:

I am using sbt assembly to generate a fat jar file...

On Tuesday, 15 March 2016 17:50:52 UTC, abhishek jain wrote:
Hi where did you mention the classpath...

On Friday, 23 November 2012 09:26:55 UTC, Matthieu Ravey wrote:
It was indeed a problem in my classpath. Thank you again.

Matthieu


2012/11/22 Mathias 
Matthieu,

apparently you messed up your classpath.
The spray-util module contains a `reference.conf` defining the missing config 
value, if the spray-util.jar cannot be found you'll get this error.
For some reason your spray-can.jar is on the classpath, but the spray-util.jar 
(which is a required dependency) apparently is not there.

HTH and cheers,
Mathias


On Thursday, November 22, 2012 5:37:21 PM UTC+1, Matthieu Ravey wrote:
Hi,

A few days ago I I moved one of my akka application from one directory to 
another on my computer and since then I can not execute my anymore. I get the 
following exception :

com.typesafe.config.ConfigException$UnresolvedSubstitution: reference.conf: 
107: Could not resolve substitution to a value: ${spray.version}
com.typesafe.config.ConfigException$UnresolvedSubstitution: reference.conf: 
107: Could not resolve substitution to a value: ${spray.version}
at 
com.typesafe.config.impl.ConfigSubstitution.resolve(ConfigSubstitution.java:199)
at 
com.typesafe.config.impl.ConfigSubstitution.resolveSubstitutions(ConfigSubstitution.java:240)
at 
com.typesafe.config.impl.SubstitutionResolver.resolve(SubstitutionResolver.java:89)
at 
com.typesafe.config.impl.SimpleConfigObject$1.modifyChildMayThrow(SimpleConfigObject.java:290)
at 
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:227)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:270)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:22)
at 
com.typesafe.config.impl.SubstitutionResolver.resolve(SubstitutionResolver.java:89)
at 
com.typesafe.config.impl.SimpleConfigObject$1.modifyChildMayThrow(SimpleConfigObject.java:290)
at 
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:227)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:270)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:22)
at 
com.typesafe.config.impl.SubstitutionResolver.resolve(SubstitutionResolver.java:89)
at 
com.typesafe.config.impl.SimpleConfigObject$1.modifyChildMayThrow(SimpleConfigObject.java:290)
at 
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:227)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:270)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:22)
at 
com.typesafe.config.impl.SubstitutionResolver.resolve(SubstitutionResolver.java:89)
at 
com.typesafe.config.impl.SimpleConfigObject$1.modifyChildMayThrow(SimpleConfigObject.java:290)
at 
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:227)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:270)
at 
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:22)
at 
com.typesafe.config.impl.SubstitutionResolver.resolve(SubstitutionResolver.java:89)
at 
com.typesafe.config.impl.SubstitutionResolver.resolveWithExternalExceptions(SubstitutionResolver.java:132)
at com.typesafe.config.impl.SimpleConfig.resolve(SimpleConfig.java:61)
at com.typesafe.config.impl.SimpleConfig.resolve(SimpleConfig.java:56)
at com.typesafe.config.impl.SimpleConfig.resolve(SimpleConfig.java:34)
at com.typesafe.config.impl.ConfigImpl$4.call(ConfigImpl.java:473)
at com.typesafe.config.impl.ConfigImpl$4.call(ConfigImpl.java:467)
at 
com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:50)
at com.typesafe.config.impl.ConfigImpl.computeCachedConfig(ConfigImpl.java:78)
at com.typesafe.config.impl.ConfigImpl.defaultReference(ConfigImpl.java:467)
at com.typesafe.config.ConfigFactory.defaultReference(ConfigFactory.java:295)
at com.typesafe.config.ConfigFactory.load(ConfigFactory.java:162)
at com.typesafe.config.ConfigFactory.load(ConfigFactory.java:113)
at com.typesafe.config.ConfigFactory.load(ConfigFactory.java:73)
at com.typesafe.config.ConfigFactory.loadDefaultConfig(ConfigFactory.java:182)
at com.typesafe.config.ConfigFactory.access$000(ConfigFactory.java:31)
at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:250)
at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:247)
at 
com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:50)
at 

[akka-user] Scheduling long term processes in cluster

[Filippo De Luca]

Hi Guys,
I have a task to schedule a long term task on the cluster. I am thinking to 
model this task as an Actor that got deployed remotely. What is the best 
approach to do that? 
I want to have a way to control the amount of concurrent process I run in 
the cluster. 

Also the Actor that run the process, run it in a Future, and it only 
monitor it by receiving update on the progress from the future. Should I 
use a child actor instead? The idea is that, the actor should be query-able 
to ask the progress status.

Any help will be very welcome.


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