Re: [akka-user] min-nr-of-members not working?

[Raymond Roestenburg]

Ok I'll have a look, even if I set all the confs to the same minimum of 2
worker nodes, the master starts up when there are no worker nodes yet.

On Mon, Jul 4, 2016 at 11:35 AM Patrik Nordwall 
wrote:

> The sample doesn't have those settings, but i added them for two roles and
> I could see from the MemberUp logging that it was working
> mån 4 juli 2016 kl. 11:08 skrev Raymond Roestenburg <
> raymond.roestenb...@gmail.com>:
>
>> That does not seem to solve the issue, I'll check out the
>> akka-sample-cluster-scala to see what you're doing differently there..
>>
>>
>> On Sunday, July 3, 2016 at 8:45:25 PM UTC+2, Raymond Roestenburg wrote:
>>>
>>> Thanks Patrik, I'll try that.
>>>
>>> On Friday, July 1, 2016 at 8:32:27 AM UTC+2, Patrik Nordwall wrote:

 I have verified that it works as expected with
 the akka-sample-cluster-scala.

 I think the problem is that you have not defined the same min-nr-of-members
 in all config files. seed.config only contains seed.min-nr-of-members

 /Patrik

 On Thu, Jun 30, 2016 at 2:47 PM, Raymond Roestenburg <
 raymond.r...@gmail.com> wrote:

> (Copy from gitter)
>
> Hey guys, I don’t think 'min-nr-of-members’ in cluster works anymore,
> I’ve got an example where I would expect the registerOnMemberUp to not get
> called until two ‘worker’ role nodes are up, but it gets called anyway.
> Example is here at
> https://github.com/RayRoestenburg/akka-in-action/tree/master/chapter-cluster
> .
>
> I you would like to try:
>
> run sbt assembly, start a 'seed' with
> java -DPORT=2551 -Dconfig.resource=/seed.conf -jar
> target/words-node.jar
> And a 'master’ with
> java -DPORT=2554 -Dconfig.resource=/master.conf -jar
> target/words-node.jar
> Since worker.min-nr-of-members = 2 is set, I would expect the master
> not to get up, but it does.
> (Am I doing something wrong?)
>
> Cheers,
> Ray
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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.
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [akka-user] min-nr-of-members not working?

[Patrik Nordwall]

The sample doesn't have those settings, but i added them for two roles and
I could see from the MemberUp logging that it was working
mån 4 juli 2016 kl. 11:08 skrev Raymond Roestenburg <
raymond.roestenb...@gmail.com>:

> That does not seem to solve the issue, I'll check out the
> akka-sample-cluster-scala to see what you're doing differently there..
>
>
> On Sunday, July 3, 2016 at 8:45:25 PM UTC+2, Raymond Roestenburg wrote:
>>
>> Thanks Patrik, I'll try that.
>>
>> On Friday, July 1, 2016 at 8:32:27 AM UTC+2, Patrik Nordwall wrote:
>>>
>>> I have verified that it works as expected with
>>> the akka-sample-cluster-scala.
>>>
>>> I think the problem is that you have not defined the same min-nr-of-members
>>> in all config files. seed.config only contains seed.min-nr-of-members
>>>
>>> /Patrik
>>>
>>> On Thu, Jun 30, 2016 at 2:47 PM, Raymond Roestenburg <
>>> raymond.r...@gmail.com> wrote:
>>>
 (Copy from gitter)

 Hey guys, I don’t think 'min-nr-of-members’ in cluster works anymore,
 I’ve got an example where I would expect the registerOnMemberUp to not get
 called until two ‘worker’ role nodes are up, but it gets called anyway.
 Example is here at
 https://github.com/RayRoestenburg/akka-in-action/tree/master/chapter-cluster
 .

 I you would like to try:

 run sbt assembly, start a 'seed' with
 java -DPORT=2551 -Dconfig.resource=/seed.conf -jar target/words-node.jar
 And a 'master’ with
 java -DPORT=2554 -Dconfig.resource=/master.conf -jar
 target/words-node.jar
 Since worker.min-nr-of-members = 2 is set, I would expect the master
 not to get up, but it does.
 (Am I doing something wrong?)

 Cheers,
 Ray

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

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Is it possible to increase the number of serialization threads?

[Eduardo Fernandes]

Yes, I definitely will give a try to Kryo serialization. Right know,
despite of using standard Java serialization, we're not sending class id's
over the wire since we have a morphological serialization on each class.
Nevertheless the Akka itself is doing that so Kryo could provide a good
enhancement on that. I'm pretty sure that we'll get a significant
performance improvement.

Regards.

On Mon, Jul 4, 2016 at 11:15 AM, Guido Medina  wrote:

> Thanks Patrik for clarifying the Artery part I had misunderstood, it is
> getting really close anyway which makes me *-and sure others-* happy.
>
> @Eduardo, the Kryo part will still apply, specially listing the classes as
> I did in my config example,
> I wouldn't worry much about the KryoQueueBuilder part, I would get it to
> work first and worry about that later.
>
> Regards,
>
> Guido.
>
> On Monday, July 4, 2016 at 6:56:25 AM UTC+1, Patrik Nordwall wrote:
>>
>>
>>
>> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes 
>> wrote:
>>
>>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in Java.
>>> We're using Java 8 but the transition to 2.4 is not direct since we've
>>> overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
>>> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>>>
>>
>> Updating to 2.4 is a good idea, since OSS version of 2.3 is end-of-life.
>> You find the migration guide here:
>> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>>
>> I would like to clarify one thing regarding the release of the new
>> remoting (Artery). We are still developing it and we are releasing
>> development milestones that you can try out. M3 to be released end of next
>> week according to the plan .
>> It will be merged back to 2.4 and released in a 2.4.x version, but that
>> will not happen next week.
>>
>> /Patrik
>>
>>
>>>
>>> Registering classes implicitly is not possible since we have many
>>> serialization asymmetries so I have to list the classes explicitly in
>>> configuration, as you've said.  I enabled kryo traces to print out
>>> automatically registered classed, which is very helpful.
>>>
>>> I'm working on it.
>>>
>>> Thanks again for you patience.
>>>
>>> /Eduardo
>>>
>>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina  wrote:
>>>
 Questions:

- Why not just replace 2.10 with 2.11? From the Java perspective it
should be transparent and irrelevant to your project *-if I
understood correctly, your project is in Java-*
- Are you using Java 8? If just why not just go Akka 2.4.x?

 Next week Akka 2.4.8+ (if sprint goes well I think) will get a new
 juice, akka-artery which will replace the current Netty basically giving
 you a much faster remote component.
 The automatic ID strategy is only available for akka-kryo 0.4.1+ which
 uses 2.11, automatic was the name we came up for default + incremental,
 basically to allow the developer to:

- Register classes explicitly, for the ones registered manual
performance will be better.
- Register classes automatically not listed.

 HTH,

 Guido.

 On Sunday, July 3, 2016 at 10:39:50 PM UTC+1, Eduardo Fernandes wrote:

> Hi All.
>
> I'm using akka-kryo-serialization_2.10 with incremental strategy. I'm
> using 2.10 for everything so maybe I should update in a near future.
>
> I'm getting the error below.
>
> Anyway, after tunning kryo to work with my project, I never will get
> more cpu's working in my bench so I'm afraid that I'll reach kryo limits
> quite soon.
>
> To fully adapt kryo to our project maybe I need to include it in a
> sprint. I have a considerable number of serializable classes.
>
> Thanks again for your time.
>
> -
>
> Serialization trace:
> callbacks
> (com.appgree.core.objectserver.providers.akka.client.ResponseImpl)
> response
> (com.appgree.core.objectserver.providers.akka.commands.CommandRequest)
> commands
> (com.appgree.core.objectserver.providers.akka.commands.CommandBulkRequest)
> at
> com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
> at
> com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
> at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
> at
> com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:106)
> at
> com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
> at com.esotericsoftware.kryo.Kryo.readObjectOrNull(Kryo.java:737)
> at
> com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:368)
> at
> 

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

[Guido Medina]

Thanks Patrik for clarifying the Artery part I had misunderstood, it is 
getting really close anyway which makes me *-and sure others-* happy.

@Eduardo, the Kryo part will still apply, specially listing the classes as 
I did in my config example,
I wouldn't worry much about the KryoQueueBuilder part, I would get it to 
work first and worry about that later.

Regards,

Guido.

On Monday, July 4, 2016 at 6:56:25 AM UTC+1, Patrik Nordwall wrote:
>
>
>
> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes  > wrote:
>
>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in Java. 
>> We're using Java 8 but the transition to 2.4 is not direct since we've 
>> overriden some behaviors in 2.3 which changed in 2.4 ( for ex. 
>> AllocationStrategy). I've tried to change to 2.4 and I got many errors. 
>>
>
> Updating to 2.4 is a good idea, since OSS version of 2.3 is end-of-life. 
> You find the migration guide here: 
> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>
> I would like to clarify one thing regarding the release of the new 
> remoting (Artery). We are still developing it and we are releasing 
> development milestones that you can try out. M3 to be released end of next 
> week according to the plan . 
> It will be merged back to 2.4 and released in a 2.4.x version, but that 
> will not happen next week.
>
> /Patrik
>  
>
>>
>> Registering classes implicitly is not possible since we have many 
>> serialization asymmetries so I have to list the classes explicitly in 
>> configuration, as you've said.  I enabled kryo traces to print out 
>> automatically registered classed, which is very helpful. 
>>
>> I'm working on it.
>>
>> Thanks again for you patience. 
>>
>> /Eduardo
>>
>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina > > wrote:
>>
>>> Questions:
>>>
>>>- Why not just replace 2.10 with 2.11? From the Java perspective it 
>>>should be transparent and irrelevant to your project *-if I 
>>>understood correctly, your project is in Java-*
>>>- Are you using Java 8? If just why not just go Akka 2.4.x?
>>>
>>> Next week Akka 2.4.8+ (if sprint goes well I think) will get a new 
>>> juice, akka-artery which will replace the current Netty basically giving 
>>> you a much faster remote component.
>>> The automatic ID strategy is only available for akka-kryo 0.4.1+ which 
>>> uses 2.11, automatic was the name we came up for default + incremental, 
>>> basically to allow the developer to:
>>>
>>>- Register classes explicitly, for the ones registered manual 
>>>performance will be better.
>>>- Register classes automatically not listed.
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Sunday, July 3, 2016 at 10:39:50 PM UTC+1, Eduardo Fernandes wrote:
>>>
 Hi All.

 I'm using akka-kryo-serialization_2.10 with incremental strategy. I'm 
 using 2.10 for everything so maybe I should update in a near future. 

 I'm getting the error below.

 Anyway, after tunning kryo to work with my project, I never will get 
 more cpu's working in my bench so I'm afraid that I'll reach kryo limits 
 quite soon. 

 To fully adapt kryo to our project maybe I need to include it in a 
 sprint. I have a considerable number of serializable classes.

 Thanks again for your time.

 -

 Serialization trace:
 callbacks 
 (com.appgree.core.objectserver.providers.akka.client.ResponseImpl)
 response 
 (com.appgree.core.objectserver.providers.akka.commands.CommandRequest)
 commands 
 (com.appgree.core.objectserver.providers.akka.commands.CommandBulkRequest)
 at 
 com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
 at 
 com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
 at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
 at 
 com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:106)
 at 
 com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
 at com.esotericsoftware.kryo.Kryo.readObjectOrNull(Kryo.java:737)
 at 
 com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:368)
 at 
 com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:289)
 at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
 at 
 com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:106)
 at 
 com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
 at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:660)
 at 
 com.romix.akka.serialization.kryo.KryoBasedSerializer.fromBinary(KryoSerializer.scala:397)
 at 
 

Re: [akka-user] min-nr-of-members not working?

[Raymond Roestenburg]

That does not seem to solve the issue, I'll check out the 
akka-sample-cluster-scala to see what you're doing differently there..

On Sunday, July 3, 2016 at 8:45:25 PM UTC+2, Raymond Roestenburg wrote:
>
> Thanks Patrik, I'll try that.
>
> On Friday, July 1, 2016 at 8:32:27 AM UTC+2, Patrik Nordwall wrote:
>>
>> I have verified that it works as expected with 
>> the akka-sample-cluster-scala.
>>
>> I think the problem is that you have not defined the same min-nr-of-members 
>> in all config files. seed.config only contains seed.min-nr-of-members
>>
>> /Patrik
>>
>> On Thu, Jun 30, 2016 at 2:47 PM, Raymond Roestenburg <
>> raymond.r...@gmail.com> wrote:
>>
>>> (Copy from gitter)
>>>
>>> Hey guys, I don’t think 'min-nr-of-members’ in cluster works anymore, 
>>> I’ve got an example where I would expect the registerOnMemberUp to not get 
>>> called until two ‘worker’ role nodes are up, but it gets called anyway. 
>>> Example is here at 
>>> https://github.com/RayRoestenburg/akka-in-action/tree/master/chapter-cluster
>>> .
>>>
>>> I you would like to try:
>>>
>>> run sbt assembly, start a 'seed' with
>>> java -DPORT=2551 -Dconfig.resource=/seed.conf -jar target/words-node.jar
>>> And a 'master’ with
>>> java -DPORT=2554 -Dconfig.resource=/master.conf -jar 
>>> target/words-node.jar
>>> Since worker.min-nr-of-members = 2 is set, I would expect the master not 
>>> to get up, but it does.
>>> (Am I doing something wrong?)
>>>
>>> Cheers,
>>> Ray
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to 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] Is it possible to increase the number of serialization threads?

[Eduardo Fernandes]

Ok. In our case the ack is per message... anyway I could expect a very good
improvement in number of transactions upgrading to Artery. We don't need
the factor 30x you have. If we have a factor 2 or 3 it would be very
welcome.

Thanks for the info. This numbers could help me to push it into a near
sprint.

Best regards Patrik.


On Mon, Jul 4, 2016 at 9:18 AM, Patrik Nordwall 
wrote:

>
>
> On Mon, Jul 4, 2016 at 9:13 AM, Eduardo Fernandes 
> wrote:
>
>> Wow!!! I have to try the new remoting!
>>
>> The measurement is quite basic: I have a pool of threads and I just call
>> the sends() and wait for the response and execute a new send. Nothing
>> particular. I made a simple test with the old remote and my numbers were
>> also around 25.000 msg/s, so we agree on that. On top of the old remote, on
>> my local machine (4 cores) I set the client and the server and I get around
>> 300.000 msg/s (really are 600.000 because we have cli->server and other
>> server->client response). So I could expect a very good enhancement if we
>> move to Artery.
>>
>> The limitation in my machine is CPU, not network, of course, because all
>> operations go through the loopback virtual card, which is a lot faster than
>> the real card. The CPU is high because of serialization.
>>
>> In your test of 700.000 does this include a response from the server (or
>> remote peer or whatever)?
>>
>
> No, that's one-way between two JVMs. Flow control is handled by one ack
> per batch of 1000 messages (several of these batches in flight).
>
>
>>
>> Thanks.
>>
>>
>> On Mon, Jul 4, 2016 at 9:03 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> Then I question how you measure this in your benchmark. With old
>>> (current) remoting I have observed max throughput of 25.000 msg/s (one way)
>>> using this test:
>>> https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala
>>>
>>> With new remoting (Artery) that test performs around 700.000 msg/s on my
>>> local machine.
>>>
>>>
>>> On Mon, Jul 4, 2016 at 8:54 AM, Eduardo Fernandes 
>>> wrote:
>>>
 Yes... 1.000.000 messages over the network (1.000.000 sent and
 1.000.000 of ack's with the operation state, in this case a single echo).
 Sorry, I was not precise on that. We call it transaction becase we make a
 kind of commit in ram but in this case it is not relevant.

 On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall <
 patrik.nordw...@gmail.com> wrote:

> Are you talking about 1.000.000 (500.000) messages/s over the network
> or what is your definition of transaction?
>
> On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes 
> wrote:
>
>> Many thanks Patrik. I'll share it with our dev team. I've read it
>> when we have indeed to change our code a bit. If we can distribute the
>> serialization across the processors I'm pretty sure we could achieve 
>> around
>> 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
>> node. Right now I have around 500.000 with 2 actors but increasing the
>> number of actors is not increasing the numbers as we should expect. The
>> network bandwidth is not the problem and I have around 48% of CPU in idle
>> state.
>>
>> Regards and thanks again for the info.
>>
>> On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes >> > wrote:
>>>
 Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
 Java. We're using Java 8 but the transition to 2.4 is not direct since
 we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
 AllocationStrategy). I've tried to change to 2.4 and I got many errors.

>>>
>>> Updating to 2.4 is a good idea, since OSS version of 2.3 is
>>> end-of-life. You find the migration guide here:
>>> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>>>
>>> I would like to clarify one thing regarding the release of the new
>>> remoting (Artery). We are still developing it and we are releasing
>>> development milestones that you can try out. M3 to be released end of 
>>> next
>>> week according to the plan
>>> . It will be merged
>>> back to 2.4 and released in a 2.4.x version, but that will not happen 
>>> next
>>> week.
>>>
>>> /Patrik
>>>
>>>

 Registering classes implicitly is not possible since we have many
 serialization asymmetries so I have to list the classes explicitly in
 configuration, as you've said.  I enabled kryo traces to print out
 automatically registered classed, which is 

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

[Patrik Nordwall]

On Mon, Jul 4, 2016 at 9:13 AM, Eduardo Fernandes  wrote:

> Wow!!! I have to try the new remoting!
>
> The measurement is quite basic: I have a pool of threads and I just call
> the sends() and wait for the response and execute a new send. Nothing
> particular. I made a simple test with the old remote and my numbers were
> also around 25.000 msg/s, so we agree on that. On top of the old remote, on
> my local machine (4 cores) I set the client and the server and I get around
> 300.000 msg/s (really are 600.000 because we have cli->server and other
> server->client response). So I could expect a very good enhancement if we
> move to Artery.
>
> The limitation in my machine is CPU, not network, of course, because all
> operations go through the loopback virtual card, which is a lot faster than
> the real card. The CPU is high because of serialization.
>
> In your test of 700.000 does this include a response from the server (or
> remote peer or whatever)?
>

No, that's one-way between two JVMs. Flow control is handled by one ack per
batch of 1000 messages (several of these batches in flight).


>
> Thanks.
>
>
> On Mon, Jul 4, 2016 at 9:03 AM, Patrik Nordwall  > wrote:
>
>> Then I question how you measure this in your benchmark. With old
>> (current) remoting I have observed max throughput of 25.000 msg/s (one way)
>> using this test:
>> https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala
>>
>> With new remoting (Artery) that test performs around 700.000 msg/s on my
>> local machine.
>>
>>
>> On Mon, Jul 4, 2016 at 8:54 AM, Eduardo Fernandes 
>> wrote:
>>
>>> Yes... 1.000.000 messages over the network (1.000.000 sent and 1.000.000
>>> of ack's with the operation state, in this case a single echo). Sorry, I
>>> was not precise on that. We call it transaction becase we make a kind of
>>> commit in ram but in this case it is not relevant.
>>>
>>> On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall <
>>> patrik.nordw...@gmail.com> wrote:
>>>
 Are you talking about 1.000.000 (500.000) messages/s over the network
 or what is your definition of transaction?

 On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes 
 wrote:

> Many thanks Patrik. I'll share it with our dev team. I've read it when
> we have indeed to change our code a bit. If we can distribute the
> serialization across the processors I'm pretty sure we could achieve 
> around
> 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
> node. Right now I have around 500.000 with 2 actors but increasing the
> number of actors is not increasing the numbers as we should expect. The
> network bandwidth is not the problem and I have around 48% of CPU in idle
> state.
>
> Regards and thanks again for the info.
>
> On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes 
>> wrote:
>>
>>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
>>> Java. We're using Java 8 but the transition to 2.4 is not direct since
>>> we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
>>> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>>>
>>
>> Updating to 2.4 is a good idea, since OSS version of 2.3 is
>> end-of-life. You find the migration guide here:
>> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>>
>> I would like to clarify one thing regarding the release of the new
>> remoting (Artery). We are still developing it and we are releasing
>> development milestones that you can try out. M3 to be released end of 
>> next
>> week according to the plan
>> . It will be merged
>> back to 2.4 and released in a 2.4.x version, but that will not happen 
>> next
>> week.
>>
>> /Patrik
>>
>>
>>>
>>> Registering classes implicitly is not possible since we have many
>>> serialization asymmetries so I have to list the classes explicitly in
>>> configuration, as you've said.  I enabled kryo traces to print out
>>> automatically registered classed, which is very helpful.
>>>
>>> I'm working on it.
>>>
>>> Thanks again for you patience.
>>>
>>> /Eduardo
>>>
>>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina 
>>> wrote:
>>>
 Questions:

- Why not just replace 2.10 with 2.11? From the Java
perspective it should be transparent and irrelevant to your project 
 *-if
I understood correctly, your project is in Java-*
- Are you using Java 8? If just why not 

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

[Eduardo Fernandes]

Wow!!! I have to try the new remoting!

The measurement is quite basic: I have a pool of threads and I just call
the sends() and wait for the response and execute a new send. Nothing
particular. I made a simple test with the old remote and my numbers were
also around 25.000 msg/s, so we agree on that. On top of the old remote, on
my local machine (4 cores) I set the client and the server and I get around
300.000 msg/s (really are 600.000 because we have cli->server and other
server->client response). So I could expect a very good enhancement if we
move to Artery.

The limitation in my machine is CPU, not network, of course, because all
operations go through the loopback virtual card, which is a lot faster than
the real card. The CPU is high because of serialization.

In your test of 700.000 does this include a response from the server (or
remote peer or whatever)?

Thanks.


On Mon, Jul 4, 2016 at 9:03 AM, Patrik Nordwall 
wrote:

> Then I question how you measure this in your benchmark. With old (current)
> remoting I have observed max throughput of 25.000 msg/s (one way) using
> this test:
> https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala
>
> With new remoting (Artery) that test performs around 700.000 msg/s on my
> local machine.
>
>
> On Mon, Jul 4, 2016 at 8:54 AM, Eduardo Fernandes 
> wrote:
>
>> Yes... 1.000.000 messages over the network (1.000.000 sent and 1.000.000
>> of ack's with the operation state, in this case a single echo). Sorry, I
>> was not precise on that. We call it transaction becase we make a kind of
>> commit in ram but in this case it is not relevant.
>>
>> On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> Are you talking about 1.000.000 (500.000) messages/s over the network
>>> or what is your definition of transaction?
>>>
>>> On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes 
>>> wrote:
>>>
 Many thanks Patrik. I'll share it with our dev team. I've read it when
 we have indeed to change our code a bit. If we can distribute the
 serialization across the processors I'm pretty sure we could achieve around
 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
 node. Right now I have around 500.000 with 2 actors but increasing the
 number of actors is not increasing the numbers as we should expect. The
 network bandwidth is not the problem and I have around 48% of CPU in idle
 state.

 Regards and thanks again for the info.

 On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
 patrik.nordw...@gmail.com> wrote:

>
>
> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes 
> wrote:
>
>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
>> Java. We're using Java 8 but the transition to 2.4 is not direct since
>> we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
>> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>>
>
> Updating to 2.4 is a good idea, since OSS version of 2.3 is
> end-of-life. You find the migration guide here:
> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>
> I would like to clarify one thing regarding the release of the new
> remoting (Artery). We are still developing it and we are releasing
> development milestones that you can try out. M3 to be released end of next
> week according to the plan
> . It will be merged back
> to 2.4 and released in a 2.4.x version, but that will not happen next 
> week.
>
> /Patrik
>
>
>>
>> Registering classes implicitly is not possible since we have many
>> serialization asymmetries so I have to list the classes explicitly in
>> configuration, as you've said.  I enabled kryo traces to print out
>> automatically registered classed, which is very helpful.
>>
>> I'm working on it.
>>
>> Thanks again for you patience.
>>
>> /Eduardo
>>
>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina 
>> wrote:
>>
>>> Questions:
>>>
>>>- Why not just replace 2.10 with 2.11? From the Java perspective
>>>it should be transparent and irrelevant to your project *-if I
>>>understood correctly, your project is in Java-*
>>>- Are you using Java 8? If just why not just go Akka 2.4.x?
>>>
>>> Next week Akka 2.4.8+ (if sprint goes well I think) will get a new
>>> juice, akka-artery which will replace the current Netty basically giving
>>> you a much faster remote component.
>>> The automatic ID strategy is only available for akka-kryo 0.4.1+
>>> which uses 2.11, automatic was the name we came up for default +
>>> 

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

[Patrik Nordwall]

Then I question how you measure this in your benchmark. With old (current)
remoting I have observed max throughput of 25.000 msg/s (one way) using
this test:
https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala

With new remoting (Artery) that test performs around 700.000 msg/s on my
local machine.


On Mon, Jul 4, 2016 at 8:54 AM, Eduardo Fernandes  wrote:

> Yes... 1.000.000 messages over the network (1.000.000 sent and 1.000.000
> of ack's with the operation state, in this case a single echo). Sorry, I
> was not precise on that. We call it transaction becase we make a kind of
> commit in ram but in this case it is not relevant.
>
> On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall  > wrote:
>
>> Are you talking about 1.000.000 (500.000) messages/s over the network or
>> what is your definition of transaction?
>>
>> On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes 
>> wrote:
>>
>>> Many thanks Patrik. I'll share it with our dev team. I've read it when
>>> we have indeed to change our code a bit. If we can distribute the
>>> serialization across the processors I'm pretty sure we could achieve around
>>> 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
>>> node. Right now I have around 500.000 with 2 actors but increasing the
>>> number of actors is not increasing the numbers as we should expect. The
>>> network bandwidth is not the problem and I have around 48% of CPU in idle
>>> state.
>>>
>>> Regards and thanks again for the info.
>>>
>>> On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
>>> patrik.nordw...@gmail.com> wrote:
>>>


 On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes 
 wrote:

> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
> Java. We're using Java 8 but the transition to 2.4 is not direct since
> we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>

 Updating to 2.4 is a good idea, since OSS version of 2.3 is
 end-of-life. You find the migration guide here:
 http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html

 I would like to clarify one thing regarding the release of the new
 remoting (Artery). We are still developing it and we are releasing
 development milestones that you can try out. M3 to be released end of next
 week according to the plan
 . It will be merged back
 to 2.4 and released in a 2.4.x version, but that will not happen next week.

 /Patrik


>
> Registering classes implicitly is not possible since we have many
> serialization asymmetries so I have to list the classes explicitly in
> configuration, as you've said.  I enabled kryo traces to print out
> automatically registered classed, which is very helpful.
>
> I'm working on it.
>
> Thanks again for you patience.
>
> /Eduardo
>
> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina 
> wrote:
>
>> Questions:
>>
>>- Why not just replace 2.10 with 2.11? From the Java perspective
>>it should be transparent and irrelevant to your project *-if I
>>understood correctly, your project is in Java-*
>>- Are you using Java 8? If just why not just go Akka 2.4.x?
>>
>> Next week Akka 2.4.8+ (if sprint goes well I think) will get a new
>> juice, akka-artery which will replace the current Netty basically giving
>> you a much faster remote component.
>> The automatic ID strategy is only available for akka-kryo 0.4.1+
>> which uses 2.11, automatic was the name we came up for default +
>> incremental, basically to allow the developer to:
>>
>>- Register classes explicitly, for the ones registered manual
>>performance will be better.
>>- Register classes automatically not listed.
>>
>> HTH,
>>
>> Guido.
>>
>> On Sunday, July 3, 2016 at 10:39:50 PM UTC+1, Eduardo Fernandes wrote:
>>
>>> Hi All.
>>>
>>> I'm using akka-kryo-serialization_2.10 with incremental strategy.
>>> I'm using 2.10 for everything so maybe I should update in a near future.
>>>
>>> I'm getting the error below.
>>>
>>> Anyway, after tunning kryo to work with my project, I never will get
>>> more cpu's working in my bench so I'm afraid that I'll reach kryo limits
>>> quite soon.
>>>
>>> To fully adapt kryo to our project maybe I need to include it in a
>>> sprint. I have a considerable number of serializable classes.
>>>
>>> Thanks again for your time.
>>>
>>> -
>>>
>>> Serialization trace:
>>> callbacks
>>> 

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

[Eduardo Fernandes]

Yes... 1.000.000 messages over the network (1.000.000 sent and 1.000.000 of
ack's with the operation state, in this case a single echo). Sorry, I was
not precise on that. We call it transaction becase we make a kind of commit
in ram but in this case it is not relevant.

On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall 
wrote:

> Are you talking about 1.000.000 (500.000) messages/s over the network or
> what is your definition of transaction?
>
> On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes 
> wrote:
>
>> Many thanks Patrik. I'll share it with our dev team. I've read it when we
>> have indeed to change our code a bit. If we can distribute the
>> serialization across the processors I'm pretty sure we could achieve around
>> 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
>> node. Right now I have around 500.000 with 2 actors but increasing the
>> number of actors is not increasing the numbers as we should expect. The
>> network bandwidth is not the problem and I have around 48% of CPU in idle
>> state.
>>
>> Regards and thanks again for the info.
>>
>> On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes 
>>> wrote:
>>>
 Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
 Java. We're using Java 8 but the transition to 2.4 is not direct since
 we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
 AllocationStrategy). I've tried to change to 2.4 and I got many errors.

>>>
>>> Updating to 2.4 is a good idea, since OSS version of 2.3 is end-of-life.
>>> You find the migration guide here:
>>> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>>>
>>> I would like to clarify one thing regarding the release of the new
>>> remoting (Artery). We are still developing it and we are releasing
>>> development milestones that you can try out. M3 to be released end of next
>>> week according to the plan .
>>> It will be merged back to 2.4 and released in a 2.4.x version, but that
>>> will not happen next week.
>>>
>>> /Patrik
>>>
>>>

 Registering classes implicitly is not possible since we have many
 serialization asymmetries so I have to list the classes explicitly in
 configuration, as you've said.  I enabled kryo traces to print out
 automatically registered classed, which is very helpful.

 I'm working on it.

 Thanks again for you patience.

 /Eduardo

 On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina 
 wrote:

> Questions:
>
>- Why not just replace 2.10 with 2.11? From the Java perspective
>it should be transparent and irrelevant to your project *-if I
>understood correctly, your project is in Java-*
>- Are you using Java 8? If just why not just go Akka 2.4.x?
>
> Next week Akka 2.4.8+ (if sprint goes well I think) will get a new
> juice, akka-artery which will replace the current Netty basically giving
> you a much faster remote component.
> The automatic ID strategy is only available for akka-kryo 0.4.1+ which
> uses 2.11, automatic was the name we came up for default + incremental,
> basically to allow the developer to:
>
>- Register classes explicitly, for the ones registered manual
>performance will be better.
>- Register classes automatically not listed.
>
> HTH,
>
> Guido.
>
> On Sunday, July 3, 2016 at 10:39:50 PM UTC+1, Eduardo Fernandes wrote:
>
>> Hi All.
>>
>> I'm using akka-kryo-serialization_2.10 with incremental strategy. I'm
>> using 2.10 for everything so maybe I should update in a near future.
>>
>> I'm getting the error below.
>>
>> Anyway, after tunning kryo to work with my project, I never will get
>> more cpu's working in my bench so I'm afraid that I'll reach kryo limits
>> quite soon.
>>
>> To fully adapt kryo to our project maybe I need to include it in a
>> sprint. I have a considerable number of serializable classes.
>>
>> Thanks again for your time.
>>
>> -
>>
>> Serialization trace:
>> callbacks
>> (com.appgree.core.objectserver.providers.akka.client.ResponseImpl)
>> response
>> (com.appgree.core.objectserver.providers.akka.commands.CommandRequest)
>> commands
>> (com.appgree.core.objectserver.providers.akka.commands.CommandBulkRequest)
>> at
>> com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
>> at
>> com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
>> at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
>> at
>> 

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

[Eduardo Fernandes]

Many thanks Patrik. I'll share it with our dev team. I've read it when we
have indeed to change our code a bit. If we can distribute the
serialization across the processors I'm pretty sure we could achieve around
1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
node. Right now I have around 500.000 with 2 actors but increasing the
number of actors is not increasing the numbers as we should expect. The
network bandwidth is not the problem and I have around 48% of CPU in idle
state.

Regards and thanks again for the info.

On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall 
wrote:

>
>
> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes 
> wrote:
>
>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in Java.
>> We're using Java 8 but the transition to 2.4 is not direct since we've
>> overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
>> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>>
>
> Updating to 2.4 is a good idea, since OSS version of 2.3 is end-of-life.
> You find the migration guide here:
> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>
> I would like to clarify one thing regarding the release of the new
> remoting (Artery). We are still developing it and we are releasing
> development milestones that you can try out. M3 to be released end of next
> week according to the plan .
> It will be merged back to 2.4 and released in a 2.4.x version, but that
> will not happen next week.
>
> /Patrik
>
>
>>
>> Registering classes implicitly is not possible since we have many
>> serialization asymmetries so I have to list the classes explicitly in
>> configuration, as you've said.  I enabled kryo traces to print out
>> automatically registered classed, which is very helpful.
>>
>> I'm working on it.
>>
>> Thanks again for you patience.
>>
>> /Eduardo
>>
>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina  wrote:
>>
>>> Questions:
>>>
>>>- Why not just replace 2.10 with 2.11? From the Java perspective it
>>>should be transparent and irrelevant to your project *-if I
>>>understood correctly, your project is in Java-*
>>>- Are you using Java 8? If just why not just go Akka 2.4.x?
>>>
>>> Next week Akka 2.4.8+ (if sprint goes well I think) will get a new
>>> juice, akka-artery which will replace the current Netty basically giving
>>> you a much faster remote component.
>>> The automatic ID strategy is only available for akka-kryo 0.4.1+ which
>>> uses 2.11, automatic was the name we came up for default + incremental,
>>> basically to allow the developer to:
>>>
>>>- Register classes explicitly, for the ones registered manual
>>>performance will be better.
>>>- Register classes automatically not listed.
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Sunday, July 3, 2016 at 10:39:50 PM UTC+1, Eduardo Fernandes wrote:
>>>
 Hi All.

 I'm using akka-kryo-serialization_2.10 with incremental strategy. I'm
 using 2.10 for everything so maybe I should update in a near future.

 I'm getting the error below.

 Anyway, after tunning kryo to work with my project, I never will get
 more cpu's working in my bench so I'm afraid that I'll reach kryo limits
 quite soon.

 To fully adapt kryo to our project maybe I need to include it in a
 sprint. I have a considerable number of serializable classes.

 Thanks again for your time.

 -

 Serialization trace:
 callbacks
 (com.appgree.core.objectserver.providers.akka.client.ResponseImpl)
 response
 (com.appgree.core.objectserver.providers.akka.commands.CommandRequest)
 commands
 (com.appgree.core.objectserver.providers.akka.commands.CommandBulkRequest)
 at
 com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
 at
 com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
 at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
 at
 com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:106)
 at
 com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
 at com.esotericsoftware.kryo.Kryo.readObjectOrNull(Kryo.java:737)
 at
 com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:368)
 at
 com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.read(DefaultArraySerializers.java:289)
 at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
 at
 com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:106)
 at
 com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:528)
 at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:660)
 at

Re: [akka-user] How to find Oldest node in Akka Cluster Singleton

[Patrik Nordwall]

Normally you would use the ClusterSingletonProxy, but if you want to
subscribe to the membership events and sort them you can use
Member. ageOrdering

or
isOlderThan

.

/Patrik

On Sat, Jul 2, 2016 at 8:20 PM, Madabhattula Rajesh Kumar <
mrajaf...@gmail.com> wrote:

> Hi,
>
> In  akka cluster singleton how to find "Oldest" node details.
>
> Regards,
> Rajesh
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Akka and Lagom

[Patrik Nordwall]

Using Akka without Lagom is not a bad decision in any way, many have
successfully done that and more will continue to do so.

To make the answer to your question complete I would like to add that Lagom
is not only adding a high level, opinionated, API. It's also providing:

   - development environment
   
which
   hot-reloads your services when code changes
   - out-of-the-box (still optional) integration with Lightbend ConductR
   for production
   
   aspects


On Mon, Jul 4, 2016 at 1:24 AM, Tal Beno  wrote:

> Thank you. I totally understand that. And I guess my question has been
> answered between lines as well. So I will stand down.
>
> Just an/my opinion, but it may have been more beneficial for Akka
> developers to get that kind of "magic" (framework) as an extended layer of
> the agents model. E.g. having the Service construct as a special node in
> the actors system hierarchy. With a dedicated purposed interface/impl. Most
> projects I guess will not rely on "pure" microservice architecture and may
> have polyglot persistence as well. Injecting these ideas as an organic
> layer in Akka may have had its own benefit.
>
> I stand down. I appreciate the help. And will likely adopt Akka on its own
> without the upcoming Lagom Scala APIs.
> Thank you.
>
>
> On Sunday, July 3, 2016 at 3:32:39 PM UTC-4, Christopher Hunt wrote:
>>
>> Akka is a low level toolkit. Lagom is a higher level framework.
>> Frameworks are opinionated and tend to be strongly focused on developer
>> productivity. This is a goal of Lagom.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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.