Re: [akka-user] Re: node cannot automatically rejoin Cluster after seed node restarted

[Z Kevin]

Yes, you're right.
It works well if I make them both seed nodes. 
Thank you.

On Friday, 8 July 2016 19:37:49 UTC+8, Patrik Nordwall wrote:
>
> When you restart node A it will join itself and form a separate cluster, 
> since you have not configured node B in the list of seed nodes.
>
> You are not using any downing strategy 
> 
>  
> so node B will not remove node A.
>
> Cheers,
> Patrik
>
> On Fri, Jul 8, 2016 at 12:13 PM, 谌浏洋 > 
> wrote:
>
>> I had the same problem 
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "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: node cannot automatically rejoin Cluster after seed node restarted

[Z Kevin]

I'll do it your way. Thank you

On Friday, 8 July 2016 19:48:55 UTC+8, Guido Medina wrote:
>
> Your nodes will re-join if you keep at least 1 seed node up while 
> restarting other nodes, try having 2 seed nodes.
> In production don't ever relay on only 1 seed node, have at least 2.
>
> HTH,
>
> Guido.
>
> On Friday, July 8, 2016 at 12:37:49 PM UTC+1, Patrik Nordwall wrote:
>>
>> When you restart node A it will join itself and form a separate cluster, 
>> since you have not configured node B in the list of seed nodes.
>>
>> You are not using any downing strategy 
>> 
>>  
>> so node B will not remove node A.
>>
>> Cheers,
>> Patrik
>>
>> On Fri, Jul 8, 2016 at 12:13 PM, 谌浏洋  wrote:
>>
>>> I had the same problem 
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to 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
>>
>>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "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] How to unit test actors that are children of a cluster aware router actor?

[Alan Lewis]

Hi,

I've got an app with akka clusters and sharding, where 'single' or per-node 
instance routing actors with many "child" actors being responsible for most 
of the message processing. I've been tasked with adding unit tests for the 
messages received by the "child" actors. I have Scalatest and Testkit and a 
'working' test configuration. But I can't get (test) messages to, or 
responses from the "child" actor. I get nothing but message not delivered / 
dead-letter warnings. Can anyone suggest a way to achieve the desired 
outcome?

Please don't offer any StackOverflow style replies, like 'I wouldn't do it 
like that, ...'

Thanks in advance for helpful examples / tips or working suggestions.

Alan

 

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

[James Matlik]

Is there a tutorial on how to optimize materialization somewhere?  I've
designed some logic that, for a given request, will aggregate multiple
sources and stream the results back.

When streaming large amounts of data, this isn't an issue, but we now have
a use case that will request small chunks incrementally.  I would like to
minimize the materialization overhead, but don't really know the basic
patterns needed to do so.

I believe this issue is very similar to that of the short lived connections
performance issues the akka-http server is experiencing.

Thank you,
James

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

[Archit Kapoor]

Congratulations !

Sounds great. You guys are doing an amazing work. Will definitely give it a 
try. And I'm excited.


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

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

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

[Roland Kuhn]

Very impressive, congratulations!

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

[akka-user] ANNOUNCE: New Remoting Milestone 3

[Patrik Nordwall]

Dear hakkers,


We are pleased to announce the availability of the third development
milestone of the new Akka Remoting, codenamed Artery. It’s an early
development preview and we encourage you to try it out and give us
feedback, but it’s not intended for production usage yet.


The version number is 2.4-ARTERY-M3 with same artifacts as usual.


It is enabled with the following configuration:


akka.remote.artery {

 enabled = on

 # The hostname or ip clients should connect to.

 hostname = localhost

 # use 0 if you want a random available port

 port = 20200

}


The protocol part of the actor system address is artery, so you need to
change previous akka.tcp to artery in for example configuration of cluster
seed-nodes.


A summary of what is included in M3 compared to M2
::



   -

   compression of sender and recipient actor references in the message
   envelope header, explained below
   -

   performance improvements, results below
   -

   various bug fixes, all relevant remoting tests are now passing


The full list of changes since the last milestone is available under the
2.4-ARTERY-M3 
milestone on github for your reference.


The most exciting new feature in this milestone is the envelope header
compression. For small messages the sender and recipient Actor references
that are included in each remote message can be a large fraction of the
total payload since they are encoded as string representation of the full
ActorPath and the Actor’s UID. To reduce the message header size we have
developed a smart compression algorithm. The most commonly used sender and
recipient refs are detected by the recipient system and announced as a
compression table to the sender system. Then the sender can encode those
actor references as integers indexing the announced compression table. The
same thing is also done for serialization manifest strings. Overall
allowing us to save up to hundreds of bytes per message that would have
otherwise have be transferred over the wire (costing time and resources).


Another thing that some of you might find interesting is performance. We
have now measured the following between two m4.4xlarge EC2 instances (1
Gbit/s bandwidth) using the MaxThroughputSpec

and LatencySpec

:



   -

   630,239 messages/s with message payload of 100 bytes
   -

   8,245 messages/s with messages payload of 10,000 bytes
   -

   Round trip latency at a message rate of 10,000 messages/s: 50%ile: 155
   µs, 90%ile: 173 µs, 99%ile: 196 µs


We are using Aeron  as the underlying
transport and are implementing the layers on top using Akka Streams. You
find more details in the design document
.


The development branch is artery-dev
, in case you want to take a
look or contribute. Issues are labeled with t:remoting:artery

.


We are now taking a “summer break” from Artery development. We don’t only
need vacation, but we also have some other important areas to work on
before finalizing Artery. You find our  sprint plans at akka/akka-meta
. The goal is to complete Artery
in end of August and September and then release it in a 2.4.x version of
Akka as an optional transport.


Happy hakking!

-- 

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

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

[akka-user] ANNOUNCE: Akka 2.4.8 released!

[Konrad Malawski]

Dear hakkers,

we—the Akka committers—are proud to announce a new patch release of Akka 
2.4.

This release contains a number of fixes and improvements spread out across 
many of the Akka modules and the documentation. As usual, this version is a 
drop-in replacement for any previous 2.4.x series version and maintains 
binary compatibility according to the rules outlined here 
.

Some noteworthy changes in the 2.4.8 release are:

   - 
   
   HTTP Connection Pools don’t cache a resolved DNS address forever anymore 
   (which is useful for DNS based service location) (#20690 
   )
   - 
   
   HTTP Connection Pools can be configured to keep a “hot” number of 
   connections open eagerly, to decrease first-request-on-pool latency 
   significantly (20456 )
   - 
   
   Ported “Handling Blocking operations” document from an excellent 
   StackOverflow answer 
   

 
   (#20469 )
   - 
   
   Distributed Data now takes advantage of the WeaklyUp state (#18399 
   )
   

The full list of changes since the last milestone is available under the 
2.4.8  milestone on 
github for your reference.


Akka Team Blog


As already announced over various other channels earlier this week–we're 
re-launching the Akka Team Blog – “Let it Crash!” ! 
If you're interested in some top notch technical content straight from the 
team, we recommend to give it a look (and subscribe).


The content on the blog will be more 'lose', while we keep the news section 
of the page for... news. Please look forward to our new tech posts on the 
blog, and more upcoming release announcements on the news part of the site 
(on http://akka.io/news).


Credits

Thanks to the Community! For this release we had the help of 40 committers.

Especially we would like to thanks the various hakkers who helped migrate 
the Akka Streams internals to the new and awesome GraphStage in a great 
 collaborative 
 effort 
 over the last month. Thanks 
@Hawstein, @gosubpl, @RichardImaoka, @fagossa, @Zhxiaogg, @danxmoran and 
everyone contributing to this effort!

We also would like to give a special thanks to 4 of scalac 
‘s developers (Patryk, Michał, Piotr and Krzysztof) for 
collaborating with us more closely this month. While learning the ropes of 
Akka HTTP internals they were able to contribute some useful and 
challenging features–we’re hoping to see more of those in the future. 
Thanks a lot!


Credits:

commits added removed

  121292 176 Konrad Malawski

   71251  41 Hawstein

   5 314  41 Patrik Nordwall

   4  81  23 Endre Sándor Varga

   4 758  35 gosubpl

   3  97  10 Richard Imaoka

   3 317  46 Patryk Jażdżewski (scalac)

   3 603  78 Michal Sitko (scalac)

   2 692  12 Felix Satyaputra

   2 251 190 Kam Kasravi

   2 101  17 Johan Andrén

   2 121 115 Daniel Moran

   2 312   6 Alexander Golubev

   2 222   6 Piotr Krzemiński (scalac)

   2  18   4 Martynas Mickevicius

   1  22   1 kbrowder

   1  15   2 netcomm

   1  32  17 Chris Birchall

   1  21   0 Jan Ypma

   1  18   8 miaoqian

   1   2   2 Arnout Engelen

   1  32  27 monkey-mas

   1   6   0 Christian Hoffmeister

   1  63   0 Simão Martins

   1   6   6 Nafer Sanabria

   1 147   1 Krzysztof Wyczesany (scalac)

   1   5   5 Stefano Bonetti

   1 135  81 zhxiaog

   1  42   0 Robert Budźko

   1  47  18 Bernard Leach

   1  23   8 poojadshende

   1   2   1 Richard S. Imaoka

   1  38   6 Ben Barnard

   1  14   3 Tobias Pfeifer

   1 334  12 Fabian Gutierrez

   1   5   1 Kevin Deng

   1  21  21 Andrea Peruffo

   1  40  29 Michał Płachta

   1  31   1 Denis Rosca


Happy hakking!


-- The Akka Team





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

[akka-user] HelloAkka.java with gradle

[Neeraj Singh]

Hi,

I am new to Akka and Scala. I was trying out the HelloAkka.java program in 
eclipse.

The program is here 
https://github.com/typesafehub/activator-hello-akka-java8/blob/master/src/main/java/HelloAkka.java

Around the line 60 and 66, where we call Duration.create(), I get 
compilation error in gradle. Below is the compilation error

:compileJava

/Users/neerajsingh/hello-akka-java8/src/main/java/HelloAkka.java:61: error: 
unreported exception TimeoutException; must be caught or declared to be 
thrown

Greeting greeting1 = (Greeting) inbox.receive(Duration.create(5, 
TimeUnit.SECONDS));

 ^

/Users/neerajsingh/hello-akka-java8/src/main/java/HelloAkka.java:67: error: 
unreported exception TimeoutException; must be caught or declared to be 
thrown

Greeting greeting2 = (Greeting) inbox.receive(Duration.create(5, 
TimeUnit.SECONDS));

 ^

2 errors

:compileJava FAILED



Now, the same program works fine in my eclipse and activator. So, wondering 
what I am doing wrong in gradle build script


Meanwhile, when I handle the TimeoutException, gradle compile works fine. 
But wondering why this error, when the documentation doesn;t mention any 
such exceptions 
http://www.scala-lang.org/api/2.9.3/scala/concurrent/duration/Duration$.html

Here is my build script, which has been copied from the Hakka documentation 
http://doc.akka.io/docs/akka/snapshot/intro/getting-started.html

Using Akka with Gradle

Requires at least Gradle  1.4 Uses the Scala plugin 



   1. apply plugin: 'scala'
   2.  
   3. repositories {
   4.   mavenCentral()
   5. }
   6.  
   7. dependencies {
   8.   compile 'org.scala-lang:scala-library:2.11.8'
   9. }
   10.  
   11. tasks.withType(ScalaCompile) {
   12.   scalaCompileOptions.useAnt = false
   13. }
   14.  
   15. dependencies {
   16.   compile group: 'com.typesafe.akka', name: 'akka-actor_2.11', version: 
'2.4-SNAPSHOT'
   17.   compile group: 'org.scala-lang', name: 'scala-library', version: 
'2.11.8'
   18. }


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

[谌浏洋]

Thanks

On Friday, July 8, 2016 at 7:51:59 PM UTC+8, Guido Medina wrote:
>
> *Copy & paste from the other thread*
>
> Your nodes will re-join if you keep at least 1 seed node up while 
> restarting other nodes, try having 2 seed nodes.
> In production don't ever relay on only 1 seed node, have at least 2.
>
> HTH,
>
> Guido.
>
> On Friday, July 8, 2016 at 11:44:52 AM UTC+1, 谌浏洋 wrote:
>>
>> Sorry for my poor English
>>
>> I started two node A(seed) B, Both A and B can communication to each 
>> other.
>>
>> When I restart node A. node B cannot join A anymore. (No more Member 
>> Event be notified)
>>
>> B node console repeat print msg :
>>
>> [INFO] [07/08/2016 10:30:17.381] 
>> [system-akka.actor.default-dispatcher-22] 
>> [akka.cluster.Cluster(akka://system)] Cluster Node [akka.tcp://
>> system@127.0.0.1:57237] - Leader can currently not perform its duties, 
>> reachability status: [akka.tcp://system@127.0.0.1:57237 -> akka.tcp://
>> system@127.0.0.1:2551: Unreachable Unreachable 
>> ], member status: [akka.tcp://
>> system@127.0.0.1:2551 Up seen=false, akka.tcp://system@127.0.0.1:57237 
>> Up seen=true]
>>
>> Akka 2.4.7
>>
>> Please help me.
>>
>> Thanks
>>
>>
>> My node A configuration is
>>
>> akka {
>>   actor{
>> provider = "akka.cluster.ClusterActorRefProvider"
>> serializers {
>>   java = 
>> "org.appsugar.cluster.service.akka.serialization.ProtostuffSerialization"
>> }
>>   }
>>   remote {
>> log-remote-lifecycle-events = off
>> netty.tcp {
>>   hostname = "127.0.0.1"
>>   port = 2551
>> }
>>   }
>>
>>   cluster {
>> seed-nodes = ["akka.tcp://system@127.0.0.1:2551"]
>>   }
>> }
>> akka.cluster.metrics.enabled=off
>>
>> akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]
>>
>> akka.cluster.metrics.native-library-extract-folder=${user.dir}/target/native
>>
>> akka.actor.default-mailbox {
>>   mailbox-type = "akka.dispatch.SingleConsumerOnlyUnboundedMailbox"
>> }`
>>
>> Node B configuration as same as Node A, Just change port to 0
>>
>

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

[Guido Medina]

*Copy & paste from the other thread*

Your nodes will re-join if you keep at least 1 seed node up while 
restarting other nodes, try having 2 seed nodes.
In production don't ever relay on only 1 seed node, have at least 2.

HTH,

Guido.

On Friday, July 8, 2016 at 11:44:52 AM UTC+1, 谌浏洋 wrote:
>
> Sorry for my poor English
>
> I started two node A(seed) B, Both A and B can communication to each other.
>
> When I restart node A. node B cannot join A anymore. (No more Member Event 
> be notified)
>
> B node console repeat print msg :
>
> [INFO] [07/08/2016 10:30:17.381] [system-akka.actor.default-dispatcher-22] 
> [akka.cluster.Cluster(akka://system)] Cluster Node [akka.tcp://
> system@127.0.0.1:57237] - Leader can currently not perform its duties, 
> reachability status: [akka.tcp://system@127.0.0.1:57237 -> akka.tcp://
> system@127.0.0.1:2551: Unreachable Unreachable 
> ], member status: [akka.tcp://
> system@127.0.0.1:2551 Up seen=false, akka.tcp://system@127.0.0.1:57237 Up 
> seen=true]
>
> Akka 2.4.7
>
> Please help me.
>
> Thanks
>
>
> My node A configuration is
>
> akka {
>   actor{
> provider = "akka.cluster.ClusterActorRefProvider"
> serializers {
>   java = 
> "org.appsugar.cluster.service.akka.serialization.ProtostuffSerialization"
> }
>   }
>   remote {
> log-remote-lifecycle-events = off
> netty.tcp {
>   hostname = "127.0.0.1"
>   port = 2551
> }
>   }
>
>   cluster {
> seed-nodes = ["akka.tcp://system@127.0.0.1:2551"]
>   }
> }
> akka.cluster.metrics.enabled=off
>
> akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]
>
> akka.cluster.metrics.native-library-extract-folder=${user.dir}/target/native
>
> akka.actor.default-mailbox {
>   mailbox-type = "akka.dispatch.SingleConsumerOnlyUnboundedMailbox"
> }`
>
> Node B configuration as same as Node A, Just change port to 0
>

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

[Guido Medina]

You posted this question in another thread, please go there and look.

On Friday, July 8, 2016 at 11:44:52 AM UTC+1, 谌浏洋 wrote:
>
> Sorry for my poor English
>
> I started two node A(seed) B, Both A and B can communication to each other.
>
> When I restart node A. node B cannot join A anymore. (No more Member Event 
> be notified)
>
> B node console repeat print msg :
>
> [INFO] [07/08/2016 10:30:17.381] [system-akka.actor.default-dispatcher-22] 
> [akka.cluster.Cluster(akka://system)] Cluster Node [akka.tcp://
> system@127.0.0.1:57237] - Leader can currently not perform its duties, 
> reachability status: [akka.tcp://system@127.0.0.1:57237 -> akka.tcp://
> system@127.0.0.1:2551: Unreachable Unreachable 
> ], member status: [akka.tcp://
> system@127.0.0.1:2551 Up seen=false, akka.tcp://system@127.0.0.1:57237 Up 
> seen=true]
>
> Akka 2.4.7
>
> Please help me.
>
> Thanks
>
>
> My node A configuration is
>
> akka {
>   actor{
> provider = "akka.cluster.ClusterActorRefProvider"
> serializers {
>   java = 
> "org.appsugar.cluster.service.akka.serialization.ProtostuffSerialization"
> }
>   }
>   remote {
> log-remote-lifecycle-events = off
> netty.tcp {
>   hostname = "127.0.0.1"
>   port = 2551
> }
>   }
>
>   cluster {
> seed-nodes = ["akka.tcp://system@127.0.0.1:2551"]
>   }
> }
> akka.cluster.metrics.enabled=off
>
> akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]
>
> akka.cluster.metrics.native-library-extract-folder=${user.dir}/target/native
>
> akka.actor.default-mailbox {
>   mailbox-type = "akka.dispatch.SingleConsumerOnlyUnboundedMailbox"
> }`
>
> Node B configuration as same as Node A, Just change port to 0
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "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: node cannot automatically rejoin Cluster after seed node restarted

[Guido Medina]

Your nodes will re-join if you keep at least 1 seed node up while 
restarting other nodes, try having 2 seed nodes.
In production don't ever relay on only 1 seed node, have at least 2.

HTH,

Guido.

On Friday, July 8, 2016 at 12:37:49 PM UTC+1, Patrik Nordwall wrote:
>
> When you restart node A it will join itself and form a separate cluster, 
> since you have not configured node B in the list of seed nodes.
>
> You are not using any downing strategy 
> 
>  
> so node B will not remove node A.
>
> Cheers,
> Patrik
>
> On Fri, Jul 8, 2016 at 12:13 PM, 谌浏洋 > 
> wrote:
>
>> I had the same problem 
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "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: node cannot automatically rejoin Cluster after seed node restarted

[Patrik Nordwall]

When you restart node A it will join itself and form a separate cluster,
since you have not configured node B in the list of seed nodes.

You are not using any downing strategy

so node B will not remove node A.

Cheers,
Patrik

On Fri, Jul 8, 2016 at 12:13 PM, 谌浏洋  wrote:

> I had the same problem
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "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] How would you "connect" many independent graphs maintaining backpressure between them?

[Viktor Klang]

Considered Flow.throttle?

On Fri, Jul 8, 2016 at 11:23 AM, Jack Daniels  wrote:

> up vote
> down votefavorite
> 
>
> Hey guys! I continue learning akka-streams and have new question
> .
>
> *Variables:*
>
>- Single http client flow with throttling
>- Multiple other flows that want to use first flow simultaneously
>
> *Goal:*
>
> Single http flow is flow that makes requests to particular API that limits
> number of calls to it. Otherwise it bans me. Thus it's very important to
> maintain rate of request regardless of how many clients in my code use it.
>
> There are number of other flows that want to make requests to mentioned
> API but I'd like to have backpressure from http flow. Normally you connect
> whole thing to one graph and it works. But it my case I have multiple
> graphs.
>
> How would you solve it ?
>
> *My attempt to solve it:*
>
> I use Source.queue for http flow so that I can queue http requests and
> have throttling. Problem is that Future from SourceQueue.offer fails if I
> exceed number of requests. Thus somehow I need to "reoffer" when previously
> offered event completes. Thus modified Future from SourceQueue would
> backpressure other graphs (inside their mapAsync) that make http requests.
>
> Here is how I implemented it
>
> object Main {
>
>   implicit val system = ActorSystem("root")
>   implicit val executor = system.dispatcher
>   implicit val materializer = ActorMaterializer()
>
>   private val queueHttp = Source.queue[(String, Promise[String])](2, 
> OverflowStrategy.backpressure)
> .throttle(1, FiniteDuration(1000, MILLISECONDS), 1, ThrottleMode.Shaping)
> .mapAsync(4) {
>   case (text, promise) =>
> // Simulate delay of http request
> val delay = (Random.nextDouble() * 1000 / 2).toLong
> Thread.sleep(delay)
> Future.successful(text -> promise)
> }
> .toMat(Sink.foreach({
>   case (text, p) =>
> p.success(text)
> }))(Keep.left)
> .run
>
>   val futureDeque = new ConcurrentLinkedDeque[Future[String]]()
>
>   def sendRequest(value: String): Future[String] = {
>
> val p = Promise[String]()
> val offerFuture = queueHttp.offer(value -> p)
>
> def addToQueue(future: Future[String]): Future[String] = {
>   futureDeque.addLast(future)
>   future.onComplete {
> case _ => futureDeque.remove(future)
>   }
>   future
> }
>
> offerFuture.flatMap {
>   case QueueOfferResult.Enqueued =>
> addToQueue(p.future)
> }.recoverWith {
>   case ex =>
> val first = futureDeque.pollFirst()
> if (first != null)
>   addToQueue(first.flatMap(_ => sendRequest(value)))
> else
>   sendRequest(value)
> }
>   }
>
>   def main(args: Array[String]) {
>
> val allFutures = for (v <- 0 until 15)
>   yield {
> val res = sendRequest(s"Text $v")
> res.onSuccess {
>   case text =>
> println("> " + text)
> }
> res
>   }
>
> Future.sequence(allFutures).onComplete {
>   case Success(text) =>
> println(s">>> TOTAL: ${text.length} [in queue: 
> ${futureDeque.size()}]")
> system.terminate()
>   case Failure(ex) =>
> ex.printStackTrace()
> system.terminate()
> }
>
> Await.result(system.whenTerminated, Duration.Inf)
>   }}
>
> Disadvantage of this solution is that I have locking on
> ConcurrentLinkedDeque which is probably not that bad for rate of 1
> request per second but still.
>
> How would you solve this task?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

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

[akka-user] Re: node cannot automatically rejoin Cluster after seed node restarted

[谌浏洋]

I had the same problem 

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

[谌浏洋]

Sorry for my poor English

I started two node A(seed) B, Both A and B can communication to each other.

When I restart node A. node B cannot join A anymore. (No more Member Event 
be notified)

B node console repeat print msg :

[INFO] [07/08/2016 10:30:17.381] [system-akka.actor.default-dispatcher-22] 
[akka.cluster.Cluster(akka://system)] Cluster Node 
[akka.tcp://system@127.0.0.1:57237] - Leader can currently not perform its 
duties, reachability status: [akka.tcp://system@127.0.0.1:57237 -> 
akka.tcp://system@127.0.0.1:2551: Unreachable Unreachable 
], member status: 
[akka.tcp://system@127.0.0.1:2551 Up seen=false, 
akka.tcp://system@127.0.0.1:57237 Up seen=true]

Akka 2.4.7

Please help me.

Thanks


My node A configuration is

akka {
  actor{
provider = "akka.cluster.ClusterActorRefProvider"
serializers {
  java = 
"org.appsugar.cluster.service.akka.serialization.ProtostuffSerialization"
}
  }
  remote {
log-remote-lifecycle-events = off
netty.tcp {
  hostname = "127.0.0.1"
  port = 2551
}
  }

  cluster {
seed-nodes = ["akka.tcp://system@127.0.0.1:2551"]
  }
}
akka.cluster.metrics.enabled=off

akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]

akka.cluster.metrics.native-library-extract-folder=${user.dir}/target/native

akka.actor.default-mailbox {
  mailbox-type = "akka.dispatch.SingleConsumerOnlyUnboundedMailbox"
}`

Node B configuration as same as Node A, Just change port to 0

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "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] How would you "connect" many independent graphs maintaining backpressure between them?

[Jack Daniels]

up vote
down votefavorite 


Hey guys! I continue learning akka-streams and have new question 
.

*Variables:*

   - Single http client flow with throttling
   - Multiple other flows that want to use first flow simultaneously

*Goal:*

Single http flow is flow that makes requests to particular API that limits 
number of calls to it. Otherwise it bans me. Thus it's very important to 
maintain rate of request regardless of how many clients in my code use it.

There are number of other flows that want to make requests to mentioned API 
but I'd like to have backpressure from http flow. Normally you connect 
whole thing to one graph and it works. But it my case I have multiple 
graphs.

How would you solve it ?

*My attempt to solve it:*

I use Source.queue for http flow so that I can queue http requests and have 
throttling. Problem is that Future from SourceQueue.offer fails if I exceed 
number of requests. Thus somehow I need to "reoffer" when previously 
offered event completes. Thus modified Future from SourceQueue would 
backpressure other graphs (inside their mapAsync) that make http requests.

Here is how I implemented it

object Main {

  implicit val system = ActorSystem("root")
  implicit val executor = system.dispatcher
  implicit val materializer = ActorMaterializer()

  private val queueHttp = Source.queue[(String, Promise[String])](2, 
OverflowStrategy.backpressure)
.throttle(1, FiniteDuration(1000, MILLISECONDS), 1, ThrottleMode.Shaping)
.mapAsync(4) {
  case (text, promise) =>
// Simulate delay of http request
val delay = (Random.nextDouble() * 1000 / 2).toLong
Thread.sleep(delay)
Future.successful(text -> promise)
}
.toMat(Sink.foreach({
  case (text, p) =>
p.success(text)
}))(Keep.left)
.run

  val futureDeque = new ConcurrentLinkedDeque[Future[String]]()

  def sendRequest(value: String): Future[String] = {

val p = Promise[String]()
val offerFuture = queueHttp.offer(value -> p)

def addToQueue(future: Future[String]): Future[String] = {
  futureDeque.addLast(future)
  future.onComplete {
case _ => futureDeque.remove(future)
  }
  future
}

offerFuture.flatMap {
  case QueueOfferResult.Enqueued =>
addToQueue(p.future)
}.recoverWith {
  case ex =>
val first = futureDeque.pollFirst()
if (first != null)
  addToQueue(first.flatMap(_ => sendRequest(value)))
else
  sendRequest(value)
}
  }

  def main(args: Array[String]) {

val allFutures = for (v <- 0 until 15)
  yield {
val res = sendRequest(s"Text $v")
res.onSuccess {
  case text =>
println("> " + text)
}
res
  }

Future.sequence(allFutures).onComplete {
  case Success(text) =>
println(s">>> TOTAL: ${text.length} [in queue: ${futureDeque.size()}]")
system.terminate()
  case Failure(ex) =>
ex.printStackTrace()
system.terminate()
}

Await.result(system.whenTerminated, Duration.Inf)
  }}

Disadvantage of this solution is that I have locking on 
ConcurrentLinkedDeque which is probably not that bad for rate of 1 request 
per second but still.

How would you solve this task?

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