[akka-user] Re: Akka-Http [Version 10.0.5] OptionalHeaderValueByName & HeaderValueByName does not work for valid Content-Type values

[Wolfgang Friedl]

You are right, it is confusing :)

After a while I found this in the documenation 
http://doc.akka.io/docs/akka-http/10.0.4/scala/http/common/http-model.html#http-model,
 
but for me it does not make sense that valid Content-Types are 
filtered-away and "customized" Content-Types show up.

If this is an valid behaviour it should at least be documenated in the API 
of the according functions. 


Am Dienstag, 4. April 2017 23:29:13 UTC+2 schrieb Kyrylo Stokoz:
>
> ContentType, contentLength and some other headers are available on 
> httpentity and not part of standard headers in akka http, see headers 
> section in 
> http://doc.akka.io/docs/akka-http/current/scala/http/common/http-model.html 
> This was confusing for me in the beginning as well.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 [Version 10.0.5] OptionalHeaderValueByName & HeaderValueByName does not work for valid Content-Type values

[Kyrylo Stokoz]

ContentType, contentLength and some other headers are available on httpentity 
and not part of standard headers in akka http, see headers section in 
http://doc.akka.io/docs/akka-http/current/scala/http/common/http-model.html 
This was confusing for me in the beginning as well.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] Seed node shutdown/restart and Cluster rejoin

[Patrik Nordwall]

Lightbend ConductR
 has a
similar feature.

On Tue, Apr 4, 2017 at 9:47 AM, 'Michal Borowiecki' via Akka User List <
akka-user@googlegroups.com> wrote:

> Hi Unmesh,
> If you configure multiple seed nodes, then only at least one of the has to
> be up for new (or restarted) members to join.
> In our deployment we have a pretty static membership (we don't add nodes
> dynamically), so we set all nodes to be seed nodes, no harm in that.
>
> Hope that helps,
> Michal
>
>
>
> On 04/04/17 02:38, Unmesh Joshi wrote:
>
> Hi,
>
> As of now, if seed node is shutdown by SIGINT (or doing Crtl-C), it leaves
> the cluster gracefully. This means it is removed from the membership list
> on all the other nodes in the cluster. If such a seed node is restarted,
> there is not way for it to re-join the cluster, unless there is another
> seed node up and running. If we can have a periodic snapshot of group
> membership list stored on all the nodes, it can attempt to rejoin the
> cluster using the snapshot, without needing another seed node.
> Looks like Serf has this feature.. https://github.com/
> hashicorp/serf/pull/87
> Is there any way to do this in Akka cluster?
>
> Thanks,
> Unmesh
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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.
>
>
> --
>  Michal Borowiecki
> Senior Software Engineer L4
> T: +44 208 742 1600 <+44%2020%208742%201600>
>
>
> +44 203 249 8448 <+44%2020%203249%208448>
>
>
>
> E: michal.borowie...@openbet.com
> W: www.openbet.com
> OpenBet Ltd
>
> Chiswick Park Building 9
>
> 566 Chiswick High Rd
>
> London
>
> W4 5XT
>
> UK
> 
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmas...@openbet.com and delete it from your system as well as any
> copies. The content of e-mails as well as traffic data may be monitored by
> OpenBet for employment and security purposes. To protect the environment
> please do not print this e-mail unless necessary. OpenBet Ltd. Registered
> Office: Chiswick Park Building 9, 566 Chiswick High Road, London, W4 5XT,
> United Kingdom. A company registered in England and Wales. Registered no.
> 3134634. VAT no. GB927523612
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Understanding 'Leader can currently not perform its duties' message

[Patrik Nordwall]

I'm pretty sure that is not the case. If you create a minimized
example/reproducer I will take a look. I prefer that you base it on the
SimpleClusterApp example:
scala:
https://github.com/akka/akka-samples/blob/master/akka-sample-cluster-scala/src/main/scala/sample/cluster/simple/SimpleClusterApp.scala
or java:
https://github.com/akka/akka-samples/blob/master/akka-sample-cluster-java/src/main/java/sample/cluster/simple/SimpleClusterApp.java


On Tue, Apr 4, 2017 at 1:48 PM, Unmesh Joshi  wrote:

> It looks like logic of identifying new incarnation based on ip/port and
> downing previous incarnation of actorsystem happens only on seed nodes and
> not on members. So if I crash seed node and restart it again, the
> membership list will have the new incarnation of the seed in its membership
> list, but it wont down the old incarnation.
>
> On Tuesday, 4 April 2017 16:09:49 UTC+5:30, Patrik Nordwall wrote:
>>
>> No, there is no majority decision here. Perhaps you don't join the right
>> node. You should have both in seed-nodes and in same order. It should be
>> clear from info level logging what is going on.
>> tis 4 apr. 2017 kl. 12:26 skrev Unmesh Joshi :
>>
>>> Curiously, my observation is that if instead of two, I have four node
>>> cluster and crash/restart a node with same host/port, I do not get this
>>> warning. I get this only on two node cluster, which made me think that
>>> there is majority needed to mark the new incarnation as 'seen' and then
>>> down the previous incarnation.
>>>
>>>
>>> On Tuesday, 4 April 2017 15:17:45 UTC+5:30, Patrik Nordwall wrote:
>>>
 One way of downing is to join again with same host:port. That will
 trigger downing of previous incarnation and when removal is done the new
 incarnation can join by trying to join again. The seed-nodes joining will
 retry the joining automatically.

 However, sooner or later you will need a real downing strategy.

 /Patrik

>>> tis 4 apr. 2017 kl. 10:31 skrev 'Michal Borowiecki' via Akka User List <
 akka...@googlegroups.com>:

>>> Indeed. This is the relevant bit of docs I believe (
> http://doc.akka.io/docs/akka/2.4.17/common/cluster.html#Membership):
>
> The node identifier internally also contains a UID that uniquely
> identifies this actor system instance at that hostname:port. Akka
> uses the UID to be able to reliably trigger remote death watch. This means
> that the same actor system can never join a cluster again once it's been
> removed from that cluster. To re-join an actor system with the same
> hostname:port to a cluster you have to stop the actor system and
> start a new one with the same hostname:portwhich will then receive a
> different  UID.
>
> After re-starting the node it will get a new UID and will be
> considered a new member.
>
> The unreachable member (the previous incarnation of your node) needs
> to be downed first for new members to be admitted by the leader.
>
> Cheers,
>
> Michal
>

> On 04/04/17 08:58, Viktor Klang wrote:
>
 No, it needs to be Downed.
>
>
> On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi 
> wrote:
>
>> Hi,
>>
>> If I restart the crashed node on same host and port, it should be
>> reachable now and consensus should be reached isnt it?
>>
>> Thanks,
>> Unmesh
>>
>> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:
>>>
>>> Hi Unmesh,
>>>
>>> AFAIK, the crashed node has to be downed (whether manually or
>>> automatically) for the cluster to reach convergence.
>>>
>>> Only once there are no unreachable nodes observed by any member can
>>> the leader resume it's duties and allow the new member (your re-started
>>> instance) to join.
>>>
>>> For testing & dev, you can use auto-downing. For production you need
>>> to choose a more resilient approach I'm afraid, as out of the box
>>> auto-downing doesn't provide a way to address the split-brain-problem 
>>> which
>>> most likely would bite you in a real life environment sooner or later.
>>>
>>> Cheers,
>>>
>>> Michal
>>>
>>> On 04/04/17 08:31, Unmesh Joshi wrote:
>>>
>>> Is it possibly because in a two node cluster, there can never be
>>> majority ( > 50%) nodes agreeing on membership to mark a node as 'seen'?
>>>
>>> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:

 Hi,

 I have a two node cluster in a cluster. If I crash one of the nodes
 (*10.131.22.26:3552 ), *and bring it up
 again, I start getting following messages from other nodes.  Now that 
 the
 node is reachable and there are only two nodes in the cluster, why 
 should
 it give following message with seen=false for 1*0.131.22.26:3552
 

[akka-user] Akka-Http [Version 10.0.5] OptionalHeaderValueByName & HeaderValueByName does not work for valid Content-Type values

[Wolfgang Friedl]

Hi!

For testing purpose I started an http-endpoint which looks like this ...I 
removed some code to make it simple

object WebServer extends HttpApp {
  def route: Route =
path("publishvalid") {
  optionalHeaderValueByName("Content-Type") { header =>
println("Content-Type is "+header)
post {
  complete("")
  }
}
  }
}


The server I use to check if the client I worte is setting the expected 
content-type which is "application/json". Unfortunatly the type was never 
set, at least Content-Type was always none.
Thats why I started to use Postman to test my little WebServer where I made 
the following observation.

While seeting the content-type to application-json my server was telling me 
the content-type was not found.  If I used one which is not defined the 
content-type was available. See the logs below
Code hier eingeben...2017-04-04 14:12:59,894 INFO  ActorSystemImpl - Server 
online at http://127.0.0.1:8111/
/// Conente Type in postman was set to application/json
Content-Type is None
/// Conente Type in postman was set to bla bla
Content-Type is Some(bla bla)
2017-04-04 14:13:15,762 WARN  ActorSystemImpl - Illegal request header: 
Illegal 'content-type' header: Invalid input 'b', expected WSP, CRLF or '/' 
(line 1, column 5): bla bla
^

For me it seems optionalHeaderValueByName as well HeaderValueByName only 
returning the header if it is a user defined and not an existing. 
For me this is an unexpected behaviour.

Regards

Wolfgang

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Understanding 'Leader can currently not perform its duties' message

[Unmesh Joshi]

It looks like logic of identifying new incarnation based on ip/port and 
downing previous incarnation of actorsystem happens only on seed nodes and 
not on members. So if I crash seed node and restart it again, the 
membership list will have the new incarnation of the seed in its membership 
list, but it wont down the old incarnation.

On Tuesday, 4 April 2017 16:09:49 UTC+5:30, Patrik Nordwall wrote:
>
> No, there is no majority decision here. Perhaps you don't join the right 
> node. You should have both in seed-nodes and in same order. It should be 
> clear from info level logging what is going on.
> tis 4 apr. 2017 kl. 12:26 skrev Unmesh Joshi  >:
>
>> Curiously, my observation is that if instead of two, I have four node 
>> cluster and crash/restart a node with same host/port, I do not get this 
>> warning. I get this only on two node cluster, which made me think that 
>> there is majority needed to mark the new incarnation as 'seen' and then 
>> down the previous incarnation. 
>>
>>
>> On Tuesday, 4 April 2017 15:17:45 UTC+5:30, Patrik Nordwall wrote:
>>
>>> One way of downing is to join again with same host:port. That will 
>>> trigger downing of previous incarnation and when removal is done the new 
>>> incarnation can join by trying to join again. The seed-nodes joining will 
>>> retry the joining automatically.
>>>
>>> However, sooner or later you will need a real downing strategy.
>>>
>>> /Patrik
>>>
>> tis 4 apr. 2017 kl. 10:31 skrev 'Michal Borowiecki' via Akka User List <
>>> akka...@googlegroups.com>:
>>>
>> Indeed. This is the relevant bit of docs I believe (
 http://doc.akka.io/docs/akka/2.4.17/common/cluster.html#Membership):

 The node identifier internally also contains a UID that uniquely 
 identifies this actor system instance at that hostname:port. Akka uses 
 the UID to be able to reliably trigger remote death watch. This means that 
 the same actor system can never join a cluster again once it's been 
 removed 
 from that cluster. To re-join an actor system with the same 
 hostname:port to a cluster you have to stop the actor system and start 
 a new one with the same hostname:portwhich will then receive a 
 different  UID.

 After re-starting the node it will get a new UID and will be considered 
 a new member.

 The unreachable member (the previous incarnation of your node) needs to 
 be downed first for new members to be admitted by the leader.

 Cheers,

 Michal

>>>
 On 04/04/17 08:58, Viktor Klang wrote:

>>> No, it needs to be Downed.


 On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi  
 wrote:

> Hi, 
>
> If I restart the crashed node on same host and port, it should be 
> reachable now and consensus should be reached isnt it?
>
> Thanks,
> Unmesh
>
> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote: 
>>
>> Hi Unmesh,
>>
>> AFAIK, the crashed node has to be downed (whether manually or 
>> automatically) for the cluster to reach convergence.
>>
>> Only once there are no unreachable nodes observed by any member can 
>> the leader resume it's duties and allow the new member (your re-started 
>> instance) to join.
>>
>> For testing & dev, you can use auto-downing. For production you need 
>> to choose a more resilient approach I'm afraid, as out of the box 
>> auto-downing doesn't provide a way to address the split-brain-problem 
>> which 
>> most likely would bite you in a real life environment sooner or later.
>>
>> Cheers,
>>
>> Michal
>>
>> On 04/04/17 08:31, Unmesh Joshi wrote:
>>
>> Is it possibly because in a two node cluster, there can never be 
>> majority ( > 50%) nodes agreeing on membership to mark a node as 'seen'? 
>>
>> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote: 
>>>
>>> Hi,
>>>
>>> I have a two node cluster in a cluster. If I crash one of the nodes 
>>> (*10.131.22.26:3552 
>>> ), *and bring it up again, I start 
>>> getting following messages from other nodes.  Now that the node is 
>>> reachable and there are only two nodes in the cluster, why should it 
>>> give 
>>> following message with seen=false for 1*0.131.22.26:3552 
>>> ? *
>>> For members to be seen, is there any other configuration that needs 
>>> to be tuned?
>>>
>>>
>>> [INFO] [04/04/2017 12:38:49.623] 
>>> [csw-cluster-akka.actor.default-dispatcher-14] 
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform 
>>> its duties, reachability status: [akka.tcp://
>>> csw-cluster@10.131.22.26:41574 -> akka.tcp://
>>> csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] (1)], 
>>> memb

Re: [akka-user] Re: Understanding 'Leader can currently not perform its duties' message

[Patrik Nordwall]

No, there is no majority decision here. Perhaps you don't join the right
node. You should have both in seed-nodes and in same order. It should be
clear from info level logging what is going on.
tis 4 apr. 2017 kl. 12:26 skrev Unmesh Joshi :

> Curiously, my observation is that if instead of two, I have four node
> cluster and crash/restart a node with same host/port, I do not get this
> warning. I get this only on two node cluster, which made me think that
> there is majority needed to mark the new incarnation as 'seen' and then
> down the previous incarnation.
>
>
> On Tuesday, 4 April 2017 15:17:45 UTC+5:30, Patrik Nordwall wrote:
>
> One way of downing is to join again with same host:port. That will trigger
> downing of previous incarnation and when removal is done the new
> incarnation can join by trying to join again. The seed-nodes joining will
> retry the joining automatically.
>
> However, sooner or later you will need a real downing strategy.
>
> /Patrik
>
> tis 4 apr. 2017 kl. 10:31 skrev 'Michal Borowiecki' via Akka User List <
> akka...@googlegroups.com>:
>
> Indeed. This is the relevant bit of docs I believe (
> http://doc.akka.io/docs/akka/2.4.17/common/cluster.html#Membership):
>
> The node identifier internally also contains a UID that uniquely
> identifies this actor system instance at that hostname:port. Akka uses
> the UID to be able to reliably trigger remote death watch. This means that
> the same actor system can never join a cluster again once it's been removed
> from that cluster. To re-join an actor system with the same hostname:port to
> a cluster you have to stop the actor system and start a new one with the
> same hostname:portwhich will then receive a different  UID.
>
> After re-starting the node it will get a new UID and will be considered a
> new member.
>
> The unreachable member (the previous incarnation of your node) needs to be
> downed first for new members to be admitted by the leader.
>
> Cheers,
>
> Michal
>
>
> On 04/04/17 08:58, Viktor Klang wrote:
>
> No, it needs to be Downed.
>
>
> On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi  wrote:
>
> Hi,
>
> If I restart the crashed node on same host and port, it should be
> reachable now and consensus should be reached isnt it?
>
> Thanks,
> Unmesh
>
> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:
>
> Hi Unmesh,
>
> AFAIK, the crashed node has to be downed (whether manually or
> automatically) for the cluster to reach convergence.
>
> Only once there are no unreachable nodes observed by any member can the
> leader resume it's duties and allow the new member (your re-started
> instance) to join.
>
> For testing & dev, you can use auto-downing. For production you need to
> choose a more resilient approach I'm afraid, as out of the box auto-downing
> doesn't provide a way to address the split-brain-problem which most likely
> would bite you in a real life environment sooner or later.
>
> Cheers,
>
> Michal
>
> On 04/04/17 08:31, Unmesh Joshi wrote:
>
> Is it possibly because in a two node cluster, there can never be majority
> ( > 50%) nodes agreeing on membership to mark a node as 'seen'?
>
> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:
>
> Hi,
>
> I have a two node cluster in a cluster. If I crash one of the nodes 
> (*10.131.22.26:3552
> ), *and bring it up again, I start getting
> following messages from other nodes.  Now that the node is reachable and
> there are only two nodes in the cluster, why should it give following
> message with seen=false for 1*0.131.22.26:3552
> ? *
> For members to be seen, is there any other configuration that needs to be
> tuned?
>
>
> [INFO] [04/04/2017 12:38:49.623]
> [csw-cluster-akka.actor.default-dispatcher-14]
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
> (1)], member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up
> seen=false, akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:39:49.634]
> [csw-cluster-akka.actor.default-dispatcher-2]
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
> (1)], member status:* [akka.tcp://csw-cluster@10.131.22.26:3552
>  Up seen=false*, akka.tcp://
> csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:40:49.632]
> [csw-cluster-akka.actor.default-dispatcher-17]
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform

Re: [akka-user] Re: Understanding 'Leader can currently not perform its duties' message

[Unmesh Joshi]

Curiously, my observation is that if instead of two, I have four node 
cluster and crash/restart a node with same host/port, I do not get this 
warning. I get this only on two node cluster, which made me think that 
there is majority needed to mark the new incarnation as 'seen' and then 
down the previous incarnation. 

On Tuesday, 4 April 2017 15:17:45 UTC+5:30, Patrik Nordwall wrote:
>
> One way of downing is to join again with same host:port. That will trigger 
> downing of previous incarnation and when removal is done the new 
> incarnation can join by trying to join again. The seed-nodes joining will 
> retry the joining automatically.
>
> However, sooner or later you will need a real downing strategy.
>
> /Patrik
> tis 4 apr. 2017 kl. 10:31 skrev 'Michal Borowiecki' via Akka User List <
> akka...@googlegroups.com >:
>
>> Indeed. This is the relevant bit of docs I believe (
>> http://doc.akka.io/docs/akka/2.4.17/common/cluster.html#Membership):
>>
>> The node identifier internally also contains a UID that uniquely 
>> identifies this actor system instance at that hostname:port. Akka uses 
>> the UID to be able to reliably trigger remote death watch. This means that 
>> the same actor system can never join a cluster again once it's been removed 
>> from that cluster. To re-join an actor system with the same hostname:port
>>  to a cluster you have to stop the actor system and start a new one with 
>> the same hostname:portwhich will then receive a different  UID.
>>
>> After re-starting the node it will get a new UID and will be considered a 
>> new member.
>>
>> The unreachable member (the previous incarnation of your node) needs to 
>> be downed first for new members to be admitted by the leader.
>>
>> Cheers,
>>
>> Michal
>>
>> On 04/04/17 08:58, Viktor Klang wrote:
>>
>> No, it needs to be Downed.
>>
>> On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi > > wrote:
>>
>>> Hi, 
>>>
>>> If I restart the crashed node on same host and port, it should be 
>>> reachable now and consensus should be reached isnt it?
>>>
>>> Thanks,
>>> Unmesh
>>>
>>> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote: 

 Hi Unmesh,

 AFAIK, the crashed node has to be downed (whether manually or 
 automatically) for the cluster to reach convergence.

 Only once there are no unreachable nodes observed by any member can the 
 leader resume it's duties and allow the new member (your re-started 
 instance) to join.

 For testing & dev, you can use auto-downing. For production you need to 
 choose a more resilient approach I'm afraid, as out of the box 
 auto-downing 
 doesn't provide a way to address the split-brain-problem which most likely 
 would bite you in a real life environment sooner or later.

 Cheers,

 Michal

 On 04/04/17 08:31, Unmesh Joshi wrote:

 Is it possibly because in a two node cluster, there can never be 
 majority ( > 50%) nodes agreeing on membership to mark a node as 'seen'? 

 On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote: 
>
> Hi,
>
> I have a two node cluster in a cluster. If I crash one of the nodes 
> (*10.131.22.26:3552 
> ), *and bring it up again, I start getting 
> following messages from other nodes.  Now that the node is reachable and 
> there are only two nodes in the cluster, why should it give following 
> message with seen=false for 1*0.131.22.26:3552 
> ? *
> For members to be seen, is there any other configuration that needs to 
> be tuned?
>
>
> [INFO] [04/04/2017 12:38:49.623] 
> [csw-cluster-akka.actor.default-dispatcher-14] 
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform 
> its duties, reachability status: [akka.tcp://
> csw-cluster@10.131.22.26:41574 -> akka.tcp://
> csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] (1)], member 
> status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up seen=false, 
> akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:39:49.634] 
> [csw-cluster-akka.actor.default-dispatcher-2] 
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform 
> its duties, reachability status: [akka.tcp://
> csw-cluster@10.131.22.26:41574 -> akka.tcp://
> csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] (1)], member 
> status:* [akka.tcp://csw-cluster@10.131.22.26:3552 
>  Up seen=false*, akka.tcp://
> csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:40:49.632] 
> [csw-cluster-akka.actor.default-dispatcher-17] 
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>>

Re: [akka-user] Re: Understanding 'Leader can currently not perform its duties' message

[Patrik Nordwall]

One way of downing is to join again with same host:port. That will trigger
downing of previous incarnation and when removal is done the new
incarnation can join by trying to join again. The seed-nodes joining will
retry the joining automatically.

However, sooner or later you will need a real downing strategy.

/Patrik
tis 4 apr. 2017 kl. 10:31 skrev 'Michal Borowiecki' via Akka User List <
akka-user@googlegroups.com>:

> Indeed. This is the relevant bit of docs I believe (
> http://doc.akka.io/docs/akka/2.4.17/common/cluster.html#Membership):
>
> The node identifier internally also contains a UID that uniquely
> identifies this actor system instance at that hostname:port. Akka uses
> the UID to be able to reliably trigger remote death watch. This means that
> the same actor system can never join a cluster again once it's been removed
> from that cluster. To re-join an actor system with the same hostname:port to
> a cluster you have to stop the actor system and start a new one with the
> same hostname:portwhich will then receive a different  UID.
>
> After re-starting the node it will get a new UID and will be considered a
> new member.
>
> The unreachable member (the previous incarnation of your node) needs to be
> downed first for new members to be admitted by the leader.
>
> Cheers,
>
> Michal
>
> On 04/04/17 08:58, Viktor Klang wrote:
>
> No, it needs to be Downed.
>
> On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi 
> wrote:
>
> Hi,
>
> If I restart the crashed node on same host and port, it should be
> reachable now and consensus should be reached isnt it?
>
> Thanks,
> Unmesh
>
> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:
>
> Hi Unmesh,
>
> AFAIK, the crashed node has to be downed (whether manually or
> automatically) for the cluster to reach convergence.
>
> Only once there are no unreachable nodes observed by any member can the
> leader resume it's duties and allow the new member (your re-started
> instance) to join.
>
> For testing & dev, you can use auto-downing. For production you need to
> choose a more resilient approach I'm afraid, as out of the box auto-downing
> doesn't provide a way to address the split-brain-problem which most likely
> would bite you in a real life environment sooner or later.
>
> Cheers,
>
> Michal
>
> On 04/04/17 08:31, Unmesh Joshi wrote:
>
> Is it possibly because in a two node cluster, there can never be majority
> ( > 50%) nodes agreeing on membership to mark a node as 'seen'?
>
> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:
>
> Hi,
>
> I have a two node cluster in a cluster. If I crash one of the nodes 
> (*10.131.22.26:3552
> ), *and bring it up again, I start getting
> following messages from other nodes.  Now that the node is reachable and
> there are only two nodes in the cluster, why should it give following
> message with seen=false for 1*0.131.22.26:3552
> ? *
> For members to be seen, is there any other configuration that needs to be
> tuned?
>
>
> [INFO] [04/04/2017 12:38:49.623]
> [csw-cluster-akka.actor.default-dispatcher-14]
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
> (1)], member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up
> seen=false, akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:39:49.634]
> [csw-cluster-akka.actor.default-dispatcher-2]
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
> (1)], member status:* [akka.tcp://csw-cluster@10.131.22.26:3552
>  Up seen=false*, akka.tcp://
> csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:40:49.632]
> [csw-cluster-akka.actor.default-dispatcher-17]
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
> duties, reachability status: [akka.t
>
>
>
> Thanks,
> Unmesh
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options,

Re: [akka-user] [Akka/Java] Scala exception when updating maven dependencies

[Mark McShane]

I have tried that and it doesn't work, still getting the exception. 
Thanks for the reply though, here's how I edited the pom.xml:




On Tuesday, 4 April 2017 06:08:59 UTC+1, Patrik Nordwall wrote:
>
> You must use the same version for all Akka artifacts, e.g. 2.12_2.4.17 for 
> everything. Cluster-metrics exists for that version.
>
> Akka 2.4.x is released for Scala 2.11 and 2.12 but you have to pick one 
> and don't mix.
>
> /Patrik
> mån 3 apr. 2017 kl. 20:33 skrev Mark McShane  >:
>
>> I'm working on a project making use of various Akka modules in Java 
>> (akka-actor, akka-remote etc.). These modules were loaded in as 
>> dependencies through maven, each version being around Akka 2.10:3.9. I left 
>> the dependencies at these versions as I figured "If it ain't broke then 
>> don't fix it", and things are working as expected.
>>
>> I wanted to test some features from akka-cluster-metrics, but I'm have 
>> problems when I include the dependency in my pom.xml. I suspect the issue 
>> is some sort of problem with scala major versions. *I'm hoping that 
>> perhaps someone could give me some advice on how to fix my problem.*
>>
>> I'm getting the same exception (listed a bit below) regardless of the 
>> versions of each dependency. The format for the jars (see 
>> https://mvnrepository.com/) seems to be *akka-_2.> version>:*. At first I thought if I updated the old akka 
>> 2.10 jars to being akka 2.12, the problem would be resolved, but I still 
>> get the exception.
>>
>> The exception occurs consistently at the first place akka/scala is used 
>> in my application, this works fine prior to meddling with dependencies.
>> final ActorSystem system = ActorSystem.create("QuadraticSystem",
>> ConfigFactory.parseString("akka.remote.netty.tcp {" +
>> "\nhostname =\"" + analysisInfo[0] + "\"" +
>> "\nport=" + analysisInfo[1] +
>> "\n}").
>> withFallback(ConfigFactory.load("application.conf")));
>>
>> A cleaned up form of the exception:
>> Exception in thread "main" java.lang.VerifyError: Uninitialized object 
>> exists on backward branch 209
>> Exception Details:
>>   Location:
>> 
>> scala/collection/immutable/HashMap$HashTrieMap.split()Lscala/collection/immutable/Seq;
>>  
>> @249: goto
>>   Reason:
>> Error exists in the bytecode
>>   Bytecode:
>> 0x000: 2ab6 0057 04a0 001e b200 afb2 00b4 04bd
>> 0x010: 0002 5903 2a53 c000 b6b6 00ba b600 bec0
>> ...
>> Stackmap Table:
>> same_frame(@35)
>>
>> full_frame(@141,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#105]},{})
>> append_frame(@151,Object[#125],Object[#125])
>> at 
>> scala.collection.immutable.HashMap$.scala$collection$immutable$HashMap$$makeHashTrieMap(HashMap.scala:179)
>> at scala.collection.immutable.HashMap$HashMap1.updated0(HashMap.scala:211)
>> ...
>> at akka.actor.ActorSystem$Settings.(ActorSystem.scala:328)
>> at akka.actor.ActorSystemImpl.(ActorSystem.scala:683)
>> at akka.actor.ActorSystem$.apply(ActorSystem.scala:245)
>> at akka.actor.ActorSystem$.apply(ActorSystem.scala:288)
>> at akka.actor.ActorSystem$.apply(ActorSystem.scala:263)
>> at akka.actor.ActorSystem$.create(ActorSystem.scala:191)
>> at akka.actor.ActorSystem.create(ActorSystem.scala)
>> at uk.ac.qub.ccrcb.bioinf.ssc.CMDLauncher.main(CMDLauncher.java:38) > above code segment>
>>
>> For the record, my existing (working) pom.xml contains the following 
>> relevant dependencies:
>> akka-actor, akka-remote (both 2.10_2.3.9), typesafe config 1.2.1, 
>> scala-library 2.10.4.
>>
>> When I tried to update each dependency to 2.12, each is at:
>> akka-actor, akka-remote, akka-cluster-metrics (all at 2.12_2.4.17), 
>> typesafe config 1.3.1, scala-library 2.12.1.
>>
>> The earliest jar I can get cluster-metrics for is 2.11 (major version of 
>> scala still incompatible, afaik). Any configuration of versions I have 
>> tried result in this same exception. For reference, 
>> I'm using a Macbook Pro running macOs Sierra 10.12.3. My java version is 
>> the 'latest' I could get from the oracle site (although I'm confused as 
>> there seems to be inconsistency between the versions of java listed, I can 
>> only find one jdk myself).
>>
>>
>> 
>>
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-u

Re: [akka-user] Re: Understanding 'Leader can currently not perform its duties' message

['Michal Borowiecki' via Akka User List]

Indeed. This is the relevant bit of docs I believe 
(http://doc.akka.io/docs/akka/2.4.17/common/cluster.html#Membership):


The node identifier internally also contains a UID that uniquely 
identifies this actor system instance at thathostname:port. Akka uses 
the UID to be able to reliably trigger remote death watch. This means 
that the same actor system can never join a cluster again once it's 
been removed from that cluster. To re-join an actor system with the 
samehostname:portto a cluster you have to stop the actor system and 
start a new one with the samehostname:portwhich will then receive a 
differentUID.
After re-starting the node it will get a new UID and will be considered 
a new member.


The unreachable member (the previous incarnation of your node) needs to 
be downed first for new members to be admitted by the leader.


Cheers,

Michal


On 04/04/17 08:58, Viktor Klang wrote:

No, it needs to be Downed.

On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi > wrote:


Hi,

If I restart the crashed node on same host and port, it should be
reachable now and consensus should be reached isnt it?

Thanks,
Unmesh

On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:

Hi Unmesh,

AFAIK, the crashed node has to be downed (whether manually or
automatically) for the cluster to reach convergence.

Only once there are no unreachable nodes observed by any
member can the leader resume it's duties and allow the new
member (your re-started instance) to join.

For testing & dev, you can use auto-downing. For production
you need to choose a more resilient approach I'm afraid, as
out of the box auto-downing doesn't provide a way to address
the split-brain-problem which most likely would bite you in a
real life environment sooner or later.

Cheers,

Michal


On 04/04/17 08:31, Unmesh Joshi wrote:

Is it possibly because in a two node cluster, there can never
be majority ( > 50%) nodes agreeing on membership to mark a
node as 'seen'?

On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:

Hi,

I have a two node cluster in a cluster. If I crash one of
the nodes (*10.131.22.26:3552
), *and bring it up again, I
start getting following messages from other nodes.  Now
that the node is reachable and there are only two nodes
in the cluster, why should it give following message with
seen=false for 1*0.131.22.26:3552
? *
For members to be seen, is there any other configuration
that needs to be tuned?


[INFO] [04/04/2017 12:38:49.623]
[csw-cluster-akka.actor.default-dispatcher-14]
[akka.cluster.Cluster(akka://csw-cluster)] Cluster
Node [akka.tcp://csw-cluster@10.131.22.26:41574
] - Leader can
currently not perform its duties, reachability
status: [akka.tcp://csw-cluster@10.131.22.26:41574
 ->
akka.tcp://csw-cluster@10.131.22.26:3552
: Unreachable
[Unreachable] (1)], member status:
[akka.tcp://csw-cluster@10.131.22.26:3552
 Up seen=false,
akka.tcp://csw-cluster@10.131.22.26:41574
 Up seen=true]
[INFO] [04/04/2017 12:39:49.634]
[csw-cluster-akka.actor.default-dispatcher-2]
[akka.cluster.Cluster(akka://csw-cluster)] Cluster
Node [akka.tcp://csw-cluster@10.131.22.26:41574
] - Leader can
currently not perform its duties, reachability
status: [akka.tcp://csw-cluster@10.131.22.26:41574
 ->
akka.tcp://csw-cluster@10.131.22.26:3552
: Unreachable
[Unreachable] (1)], member
status:*[akka.tcp://csw-cluster@10.131.22.26:3552
 Up
seen=false*,
akka.tcp://csw-cluster@10.131.22.26:41574
 Up seen=true]
[INFO] [04/04/2017 12:40:49.632]
[csw-cluster-akka.actor.default-dispatcher-17]
[akka.cluster.Cluster(akka://csw-cluster)] Cluster
Node [akka.tcp://csw-cluster@10.131.22.26:41574

Re: [akka-user] Cluster Singleton Migration

[Michał Borowiecki]

I've created PRs for docs:

https://github.com/akka/akka/pull/22674 (java)

https://github.com/akka/akka/pull/22675 (scala)

Cheers,

Michal


On 04/04/17 06:12, Patrik Nordwall wrote:
This is correct. Is this a suggestion for documentation improvement? 
PR is welcome.


/Patrik
mån 3 apr. 2017 kl. 18:59 skrev Justin du coeur >:


Hmm.  Could be.  I suspect they'd welcome a PR to that effect...

On Mon, Apr 3, 2017 at 11:56 AM, Mushtaq Ahmed
mailto:mushta...@gmail.com>> wrote:

Thanks, that makes sense. But maybe the documentation of
cluster-singleton is a bit misleading and should be reworded.


On Monday, April 3, 2017 at 9:04:30 PM UTC+5:30, Arno Haase wrote:

When you kill a JVM running a cluster node, it becomes
'unreachable'.
The other nodes in the cluster have no way of knowing
whether this is
permanent or temporary (e.g. network congestion).

In order for a singleton to be started on another node,
the node it was
running on must be moved to state "down" (see Akka
documentation on
cluster). That can be tricky (see "split brain"), and an
Akka cluster
does (and can) not do that automatically.

In order to run an Akka cluster, you need some sort of
downing strategy
that decides when to move nodes from 'unreachable' to
'down'. Lightbend
has a commercial package containing (among other things)
code to support
this.

Hope this helps

- Arno

Am 03.04.2017 um 17:19 schrieb Mushtaq Ahmed:
> Hello!
>
> Doc on cluster singleton
>



> mention that even in case of JVM crash, singletons will
be successfully
> started on other nodes:
>
> "The cluster failure detector will notice when oldest
node becomes
> unreachable due to things like JVM crash, hard shut
down, or network
> failure. Then a new oldest node will take over and a new
singleton actor
> is created. For these failure scenarios there will not
be a graceful
> hand-over, but more than one active singletons is
prevented by all
> reasonable means. Some corner cases are eventually
resolved by
> configurable timeouts."
>
> But when I kill the JVM process hosting singleton, I do
not see that
> singleton is started in the nodes in the cluster. Am I
missing
> something? Only messages I see for past 10 mins are:
>
> [WARN] [04/03/2017 20:47:58.120] [New I/O boss #9]
> [NettyTransport(akka://csw-cluster)] Remote connection
to null failed
> with java.net.ConnectException: Connection refused:
/192.168.1.2:3552 
>
> [WARN] [04/03/2017 20:47:58.120]
> [csw-cluster-akka.remote.default-remote-dispatcher-6]
>

[akka.tcp://csw-cluster@192.168.1.2:54527/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fcsw-cluster%40192.168.1.2%3A3552-96

]

> Association with remote system
[akka.tcp://csw-cluster@192.168.1.2:3552
]
> has failed, address is now gated for [5000] ms. Reason:
[Association
> failed with [akka.tcp://csw-cluster@192.168.1.2:3552
]] Caused by:
> [Connection refused: /192.168.1.2:3552
]
>
> We are using 2.5.0-RC2.
>
> Thanks,
> Mushtaq
>
> --
>>> Read the docs: http://akka.io/docs/
>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> Search the archives:
https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to
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

[akka-user] At-least-once delivery guarantee chat server

[Alexander Lukyanchikov]

Hi everyone,

we are using Akka in production for notification mechanism (which is very 
close to chat server by semantics), but it is written in a very 
conservative way at the moment. It uses cache as a storage for relations, 
MQ middleware as a communication channel between the nodes.

I'm looking for more efficient, preferably Akka-native way to solve the 
problem. In documentation, I've found a wonderful built-in mechanism for 
that - DistributedPubSub 
. It 
looks amazing, but unfortunately we need at-least-once delivery guarantee.

There is a brief note at the bottom:

If you are looking for at-least-once delivery guarantee, we recommend Kafka 
> Akka Streams integration .



I'm not sure I understand. Does it mean to not use Akka Cluster 
capabilities at all, and instead do something like that -





- each user connects to the Akka node via websocket
- user subscribes to a number of topics
- each Akka node writes user's messages to the common Kafka topic (I guess 
there is no way to create topic per user, because there are hundred 
thousands of them)
- each Akka node continuously reads common topic and delivers messages for 
for subscribed actors

Also, is it the only recommended way, or we can somehow use 
DistributedPubSub/ClusterSharing with Akka Persistence module to have 
at-least-once delivery guarantee?

Thank you,
Alex

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Understanding 'Leader can currently not perform its duties' message

[Viktor Klang]

No, it needs to be Downed.

On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi  wrote:

> Hi,
>
> If I restart the crashed node on same host and port, it should be
> reachable now and consensus should be reached isnt it?
>
> Thanks,
> Unmesh
>
> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:
>>
>> Hi Unmesh,
>>
>> AFAIK, the crashed node has to be downed (whether manually or
>> automatically) for the cluster to reach convergence.
>>
>> Only once there are no unreachable nodes observed by any member can the
>> leader resume it's duties and allow the new member (your re-started
>> instance) to join.
>>
>> For testing & dev, you can use auto-downing. For production you need to
>> choose a more resilient approach I'm afraid, as out of the box auto-downing
>> doesn't provide a way to address the split-brain-problem which most likely
>> would bite you in a real life environment sooner or later.
>>
>> Cheers,
>>
>> Michal
>>
>> On 04/04/17 08:31, Unmesh Joshi wrote:
>>
>> Is it possibly because in a two node cluster, there can never be majority
>> ( > 50%) nodes agreeing on membership to mark a node as 'seen'?
>>
>> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:
>>>
>>> Hi,
>>>
>>> I have a two node cluster in a cluster. If I crash one of the nodes 
>>> (*10.131.22.26:3552
>>> ), *and bring it up again, I start getting
>>> following messages from other nodes.  Now that the node is reachable and
>>> there are only two nodes in the cluster, why should it give following
>>> message with seen=false for 1*0.131.22.26:3552
>>> ? *
>>> For members to be seen, is there any other configuration that needs to
>>> be tuned?
>>>
>>>
>>> [INFO] [04/04/2017 12:38:49.623] 
>>> [csw-cluster-akka.actor.default-dispatcher-14]
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
>>> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
>>> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
>>> (1)], member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up
>>> seen=false, akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
>>> [INFO] [04/04/2017 12:39:49.634] 
>>> [csw-cluster-akka.actor.default-dispatcher-2]
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
>>> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
>>> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
>>> (1)], member status:* [akka.tcp://csw-cluster@10.131.22.26:3552
>>>  Up seen=false*, akka.tcp://
>>> csw-cluster@10.131.22.26:41574 Up seen=true]
>>> [INFO] [04/04/2017 12:40:49.632] 
>>> [csw-cluster-akka.actor.default-dispatcher-17]
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
>>> duties, reachability status: [akka.t
>>>
>>>
>>>
>>> Thanks,
>>> Unmesh
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to 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.
>>
>>
>> --
>>  Michal Borowiecki
>> Senior Software Engineer L4
>> T: +44 208 742 1600 <+44%2020%208742%201600>
>>
>>
>> +44 203 249 8448 <+44%2020%203249%208448>
>>
>>
>>
>> E: michal.b...@openbet.com
>> W: www.openbet.com
>> OpenBet Ltd
>>
>> Chiswick Park Building 9
>>
>> 566 Chiswick High Rd
>>
>> London
>>
>> W4 5XT
>>
>> UK
>> 
>> This message is confidential and intended only for the addressee. If you
>> have received this message in error, please immediately notify the
>> ...@openbet.com and delete it from your system as well as any copies.
>> The content of e-mails as well as traffic data may be monitored by OpenBet
>> for employment and security purposes. To protect the environment please do
>> not print this e-mail unless necessary. OpenBet Ltd. Registered Office:
>> Chiswick Park Building 9, 566 Chiswick High Road, London, W4 5XT, United
>> Kingdom. A company registered in England and Wales. Registered no. 3134634.
>> VAT no. GB927523612
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archiv

[akka-user] At-least-once delivery guarantee chat server

[Alexander Lukyanchikov]

Hi everyone,

we are using Akka in production for notification mechanism (which is very 
close to chat server by semantics), but it is written in a very 
conservative way at the moment. It uses cache as a storage for relations, 
MQ middleware as a communication channel between the nodes.

I'm looking for more efficient, preferably Akka-native way to solve the 
problem. In documentation, I've found a wonderful built-in mechanism for 
that - DistributedPubSub 
. It 
looks amazing, but unfortunately we need at-least-once delivery guarantee.

There is a brief note at the bottom:

If you are looking for at-least-once delivery guarantee, we recommend Kafka 
> Akka Streams integration .



I'm not sure I understand. Does it mean to not use Akka Cluster 
capabilities at all, and instead do something like that -





Is Kafka the only recommended way, or we can somehow use 
DistributedPubSub/ClusterSharing with Akka Persistence module to have 
at-least-once delivery guarantee?

Thank you,
Alex

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Understanding 'Leader can currently not perform its duties' message

[Unmesh Joshi]

Hi,

If I restart the crashed node on same host and port, it should be reachable 
now and consensus should be reached isnt it?

Thanks,
Unmesh

On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:
>
> Hi Unmesh,
>
> AFAIK, the crashed node has to be downed (whether manually or 
> automatically) for the cluster to reach convergence.
>
> Only once there are no unreachable nodes observed by any member can the 
> leader resume it's duties and allow the new member (your re-started 
> instance) to join.
>
> For testing & dev, you can use auto-downing. For production you need to 
> choose a more resilient approach I'm afraid, as out of the box auto-downing 
> doesn't provide a way to address the split-brain-problem which most likely 
> would bite you in a real life environment sooner or later.
>
> Cheers,
>
> Michal
>
> On 04/04/17 08:31, Unmesh Joshi wrote:
>
> Is it possibly because in a two node cluster, there can never be majority 
> ( > 50%) nodes agreeing on membership to mark a node as 'seen'? 
>
> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote: 
>>
>> Hi,
>>
>> I have a two node cluster in a cluster. If I crash one of the nodes 
>> (*10.131.22.26:3552 
>> ), *and bring it up again, I start getting 
>> following messages from other nodes.  Now that the node is reachable and 
>> there are only two nodes in the cluster, why should it give following 
>> message with seen=false for 1*0.131.22.26:3552 
>> ? *
>> For members to be seen, is there any other configuration that needs to be 
>> tuned?
>>
>>
>> [INFO] [04/04/2017 12:38:49.623] 
>> [csw-cluster-akka.actor.default-dispatcher-14] 
>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its 
>> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574 
>> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] 
>> (1)], member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up 
>> seen=false, akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
>> [INFO] [04/04/2017 12:39:49.634] 
>> [csw-cluster-akka.actor.default-dispatcher-2] 
>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its 
>> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574 
>> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] 
>> (1)], member status:* [akka.tcp://csw-cluster@10.131.22.26:3552 
>>  Up seen=false*, akka.tcp://
>> csw-cluster@10.131.22.26:41574 Up seen=true]
>> [INFO] [04/04/2017 12:40:49.632] 
>> [csw-cluster-akka.actor.default-dispatcher-17] 
>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its 
>> duties, reachability status: [akka.t
>>
>>
>>
>> Thanks,
>> Unmesh 
>>
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to 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.
>
>
> -- 
>  Michal Borowiecki 
> Senior Software Engineer L4 
> T: +44 208 742 1600 
>
>
> +44 203 249 8448 
>
>
>   
> E: michal.b...@openbet.com  
> W: www.openbet.com 
> OpenBet Ltd 
>
> Chiswick Park Building 9 
>
> 566 Chiswick High Rd 
>
> London 
>
> W4 5XT 
>
> UK 
>  
> This message is confidential and intended only for the addressee. If you 
> have received this message in error, please immediately notify the 
> ...@openbet.com  and delete it from your system as well as 
> any copies. The content of e-mails as well as traffic data may be monitored 
> by OpenBet for employment and security purposes. To protect the environment 
> please do not print this e-mail unless necessary. OpenBet Ltd. Registered 
> Office: Chiswick Park Building 9, 566 Chiswick High Road, London, W4 5XT, 
> United Kingdom. A company registered in England and Wales. Registered no. 
> 3134634. VAT no. GB927523612 
>

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

Re: [akka-user] Seed node shutdown/restart and Cluster rejoin

['Michal Borowiecki' via Akka User List]

Hi Unmesh,

If you configure multiple seed nodes, then only at least one of the has 
to be up for new (or restarted) members to join.
In our deployment we have a pretty static membership (we don't add nodes 
dynamically), so we set all nodes to be seed nodes, no harm in that.


Hope that helps,
Michal


On 04/04/17 02:38, Unmesh Joshi wrote:

Hi,

As of now, if seed node is shutdown by SIGINT (or doing Crtl-C), it 
leaves the cluster gracefully. This means it is removed from the 
membership list on all the other nodes in the cluster. If such a seed 
node is restarted, there is not way for it to re-join the cluster, 
unless there is another seed node up and running. If we can have a 
periodic snapshot of group membership list stored on all the nodes, it 
can attempt to rejoin the cluster using the snapshot, without needing 
another seed node.
Looks like Serf has this 
feature.. https://github.com/hashicorp/serf/pull/87

Is there any way to do this in Akka cluster?

Thanks,
Unmesh
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
http://doc.akka.io/docs/akka/current/additional/faq.html

>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to 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.


--
Signature
 Michal Borowiecki
Senior Software Engineer L4
T:  +44 208 742 1600


+44 203 249 8448



E:  michal.borowie...@openbet.com
W:  www.openbet.com 


OpenBet Ltd

Chiswick Park Building 9

566 Chiswick High Rd

London

W4 5XT

UK




This message is confidential and intended only for the addressee. If you 
have received this message in error, please immediately notify the 
postmas...@openbet.com  and delete it 
from your system as well as any copies. The content of e-mails as well 
as traffic data may be monitored by OpenBet for employment and security 
purposes. To protect the environment please do not print this e-mail 
unless necessary. OpenBet Ltd. Registered Office: Chiswick Park Building 
9, 566 Chiswick High Road, London, W4 5XT, United Kingdom. A company 
registered in England and Wales. Registered no. 3134634. VAT no. 
GB927523612


--

 Read the docs: http://akka.io/docs/
 Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Understanding 'Leader can currently not perform its duties' message

['Michal Borowiecki' via Akka User List]

Hi Unmesh,

AFAIK, the crashed node has to be downed (whether manually or 
automatically) for the cluster to reach convergence.


Only once there are no unreachable nodes observed by any member can the 
leader resume it's duties and allow the new member (your re-started 
instance) to join.


For testing & dev, you can use auto-downing. For production you need to 
choose a more resilient approach I'm afraid, as out of the box 
auto-downing doesn't provide a way to address the split-brain-problem 
which most likely would bite you in a real life environment sooner or later.


Cheers,

Michal


On 04/04/17 08:31, Unmesh Joshi wrote:
Is it possibly because in a two node cluster, there can never be 
majority ( > 50%) nodes agreeing on membership to mark a node as 'seen'?


On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:

Hi,

I have a two node cluster in a cluster. If I crash one of the
nodes (*10.131.22.26:3552 ), *and bring
it up again, I start getting following messages from other nodes.
 Now that the node is reachable and there are only two nodes in
the cluster, why should it give following message with seen=false
for 1*0.131.22.26:3552 ? *
For members to be seen, is there any other configuration that
needs to be tuned?


[INFO] [04/04/2017 12:38:49.623]
[csw-cluster-akka.actor.default-dispatcher-14]
[akka.cluster.Cluster(akka://csw-cluster)] Cluster Node
[akka.tcp://csw-cluster@10.131.22.26:41574
] - Leader can
currently not perform its duties, reachability status:
[akka.tcp://csw-cluster@10.131.22.26:41574
 ->
akka.tcp://csw-cluster@10.131.22.26:3552
: Unreachable
[Unreachable] (1)], member status:
[akka.tcp://csw-cluster@10.131.22.26:3552
 Up seen=false,
akka.tcp://csw-cluster@10.131.22.26:41574
 Up seen=true]
[INFO] [04/04/2017 12:39:49.634]
[csw-cluster-akka.actor.default-dispatcher-2]
[akka.cluster.Cluster(akka://csw-cluster)] Cluster Node
[akka.tcp://csw-cluster@10.131.22.26:41574
] - Leader can
currently not perform its duties, reachability status:
[akka.tcp://csw-cluster@10.131.22.26:41574
 ->
akka.tcp://csw-cluster@10.131.22.26:3552
: Unreachable
[Unreachable] (1)], member
status:*[akka.tcp://csw-cluster@10.131.22.26:3552
 Up seen=false*,
akka.tcp://csw-cluster@10.131.22.26:41574
 Up seen=true]
[INFO] [04/04/2017 12:40:49.632]
[csw-cluster-akka.actor.default-dispatcher-17]
[akka.cluster.Cluster(akka://csw-cluster)] Cluster Node
[akka.tcp://csw-cluster@10.131.22.26:41574
] - Leader can
currently not perform its duties, reachability status: [akka.t



Thanks,
Unmesh

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

>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to 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.


--
Signature
 Michal Borowiecki
Senior Software Engineer L4
T:  +44 208 742 1600


+44 203 249 8448



E:  michal.borowie...@openbet.com
W:  www.openbet.com 


OpenBet Ltd

Chiswick Park Building 9

566 Chiswick High Rd

London

W4 5XT

UK




This message is confidential and intended only for the addressee. If you 
have received this message in error, please immediately notify the 
postmas...@openbet.com  and delete it 
from your system as well as any copies. The content of e-mails as well 
as traffic data may be monitored by OpenBet for employment and security 
purposes. To protect the environment please do not print this e-mail 
unless necessary. OpenBet Ltd. Registered Off

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

[Daniel Stoner]

Hi Kraythe,

Perhaps it helps to see a real world example that we've been working on - 
with a good number of routes involved.

This is from our AkkaHttpServer class. It's job is to inject all the routes 
(ordersV2, searchv3, searchTerms, persistence) which consist of around 6 
actual endpoints per injected class - into the right point in the hierarchy 
(Below the oAuth2 authenticator and any request/response loggers and 
whatnot that you may need).

We define index.html and healthcheck route in this class since they are one 
liners that live above oAuth2 security otherwise we would also inject them 
independently.

Route indexRoute = get(() -> route(pathSingleSlash(() -> 
getFromResource("web/index.html";
Route healthCheck = get(() -> path(PATH_HEALTH_CHECK, () -> 
extractRequestContext(healthCheckHandler::handle)));

Route apis = route(
indexRoute,
healthCheck,
oauth2Authentication(
accessTokenVerifier,
route(
ordersV2,
searchV3,
searchTerms,
persistence
)
)
);

return logRequestResult(
this::requestMethodAsInfo,
this::rejectionsAsInfo,
() -> handleExceptions(
exceptionHandlerLogAndReturnInternalError(),
() -> handleRejections(
rejectionHandlerLogAndReturnNotFound(),
() -> apis
)
)
);

Note the *handleExceptions *and *handleRejections* methods. Basically if 
your in the depths of a route (the bit supposed to handle the request) you 
have 3 options.

1) Handle the request and reply with a HttpResponse.
return HttpResponse.create().withStatus(StatusCodes.CREATED).addHeader(
RawHeader.create(HttpHeaders.LOCATION, location)
)
2) Reject the request with an explicit Rejection
return reject(Rejections.authorizationFailed());
3) Throw an exception directly
throw new MyCustomException("Something went dodgy here!")

Now how you transpose those rejections or exceptions into a HttpResponse is 
up to your generic rejection or exception handler right at the very top of 
your routes. I've included our 'ErrorHandlingDirectives' class which we 
simply extend (Instead of extending AllDirectives) wherever we need this:

public class ErrorHandlingDirectives extends AllDirectives {

private static final Logger LOG = 
LoggerFactory.getLogger(ErrorHandlingDirectives.class);

public LogEntry requestMethodAsInfo(HttpRequest request, HttpResponse 
response) {
String headers = toCensoredHeaderJson(request.getHeaders());

return LogEntry.create(
"Server has received a request\n"
+ request.method().name() + " " + 
request.getUri().toString() + "\n"
+ headers + "\n"
+ "Server responded with a response\n"
+ response.status() + "\n"
+ "Content-Type: " + 
response.entity().getContentType().toString() + "\n"
+ "Content-Length: " + 
response.entity().getContentLengthOption().orElse(-1),
InfoLevel());
}

public LogEntry rejectionsAsInfo(HttpRequest request, List 
rejections) {
String headers = toCensoredHeaderJson(request.getHeaders());

return LogEntry.create(
"Server has received a request\n"
+ request.method().name() + " " + 
request.getUri().toString() + "\n"
+ headers + "\n"
+ "Server responded with a rejection\n"
+ 
rejections.stream().map(Rejection::toString).collect(Collectors.joining("\n")),
InfoLevel());
}

public ExceptionHandler exceptionHandlerLogAndReturnInternalError() {
return ExceptionHandler
.newBuilder()
.matchAny(throwable -> extractRequest(request -> {
LOG.warn("Error on route: " + request.method().value() 
+ " " + request.getUri().toString() + " " + throwable.getMessage(), 
throwable);
return complete(StatusCodes.INTERNAL_SERVER_ERROR);
})
).build();
}

public String toCensoredHeaderJson(Iterable headers) {
return StreamSupport
.stream(headers.spliterator(), false)
.map(header -> {
if (header instanceof Authorization) {
return header.name() + ": CENSORED";
}
return header.name() + ": " + header.value();
})
.collect(Collectors.joining("\n"));
}

}


So - yes you 'can' write 1 big file with a bazillion routes in it - or you 
can do what most

[akka-user] Re: Understanding 'Leader can currently not perform its duties' message

[Unmesh Joshi]

Is it possibly because in a two node cluster, there can never be majority ( 
> 50%) nodes agreeing on membership to mark a node as 'seen'? 

On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:
>
> Hi,
>
> I have a two node cluster in a cluster. If I crash one of the nodes 
> (*10.131.22.26:3552 
> ), *and bring it up again, I start getting 
> following messages from other nodes.  Now that the node is reachable and 
> there are only two nodes in the cluster, why should it give following 
> message with seen=false for 1*0.131.22.26:3552 
> ? *
> For members to be seen, is there any other configuration that needs to be 
> tuned?
>
>
> [INFO] [04/04/2017 12:38:49.623] 
> [csw-cluster-akka.actor.default-dispatcher-14] 
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its 
> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574 
> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] 
> (1)], member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up 
> seen=false, akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:39:49.634] 
> [csw-cluster-akka.actor.default-dispatcher-2] 
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its 
> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574 
> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] 
> (1)], member status:* [akka.tcp://csw-cluster@10.131.22.26:3552 
>  Up seen=false*, akka.tcp://
> csw-cluster@10.131.22.26:41574 Up seen=true]
> [INFO] [04/04/2017 12:40:49.632] 
> [csw-cluster-akka.actor.default-dispatcher-17] 
> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its 
> duties, reachability status: [akka.t
>
>
>
> Thanks,
> Unmesh 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] Understanding 'Leader can currently not perform its duties' message

[Unmesh Joshi]

Hi,

I have a two node cluster in a cluster. If I crash one of the nodes 
(*10.131.22.26:3552), 
*and bring it up again, I start getting following messages from other 
nodes.  Now that the node is reachable and there are only two nodes in the 
cluster, why should it give following message with seen=false for 1
*0.131.22.26:3552? *
For members to be seen, is there any other configuration that needs to be 
tuned?


[INFO] [04/04/2017 12:38:49.623] 
[csw-cluster-akka.actor.default-dispatcher-14] 
[akka.cluster.Cluster(akka://csw-cluster)] Cluster Node 
[akka.tcp://csw-cluster@10.131.22.26:41574] - Leader can currently not 
perform its duties, reachability status: 
[akka.tcp://csw-cluster@10.131.22.26:41574 -> 
akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] (1)], 
member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up seen=false, 
akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
[INFO] [04/04/2017 12:39:49.634] 
[csw-cluster-akka.actor.default-dispatcher-2] 
[akka.cluster.Cluster(akka://csw-cluster)] Cluster Node 
[akka.tcp://csw-cluster@10.131.22.26:41574] - Leader can currently not 
perform its duties, reachability status: 
[akka.tcp://csw-cluster@10.131.22.26:41574 -> 
akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable] (1)], 
member status:* [akka.tcp://csw-cluster@10.131.22.26:3552 Up seen=false*, 
akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
[INFO] [04/04/2017 12:40:49.632] 
[csw-cluster-akka.actor.default-dispatcher-17] 
[akka.cluster.Cluster(akka://csw-cluster)] Cluster Node 
[akka.tcp://csw-cluster@10.131.22.26:41574] - Leader can currently not 
perform its duties, reachability status: [akka.t



Thanks,
Unmesh 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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.