[akka-user] Cluster failover: preloaded actors

[Eduardo Fernandes]

Hi All.

First of all many thanks for so efficient library. Very good job!

We're analyzing Akka to support a cluster of heavy objects (a single actor 
could have a couple of gigs in RAM). I'm wondering if I could use some kind 
of 'preloaded' in ram slave actor that could be used if the 'master actor' 
fails. It would be something like an updated View or something like that 
which gets the main role after a failure. The journal and snapshots are ok 
but I'm afraid that the recovering time could be minimized if I used the 
'slave' idea for heavy actors. After the backup object gets the main role a 
new 'slave' should be created from a normal snapshot and it would be 
prepared for the next failover cycle.

I've tried to find out in the docs something to help me with this without 
success.

Many thanks in advance for your help!


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

Re: [akka-user] Cluster failover: preloaded actors

[Eduardo Fernandes]

Many thanks Patrik for your post. Good shot.

We could consider sending commands simultaneously to two processors (the 
main and a standby) and in case of timeout talking to the first we could 
talk to the second. After the main recovering we could return to the 
original situation. Maybe we could create both actors in different clusters 
in different machines to avoid single point of failure in case of machine 
crash. 

Many thanks again for your time and for any comment.

Regards.


El martes, 18 de marzo de 2014 17:12:43 UTC+1, Patrik Nordwall escribió:


 I see what you are looking for, and it is not supported with current 
 tools. It would be something that is periodically replaying the event 
 stream like a view, but can then be changed into a normal writing processor.

 Have you thought about using an active standby? It would do the exact same 
 thing as the primary, but the output (external side effects) would be 
 ignored/filtered on the standby. It depends very much on your domain if 
 that is a good or bad idea.

 Regards,
 Patrik
  


 

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

Re: [akka-user] Cluster failover: preloaded actors

[Eduardo Fernandes]

Thanks for the new ticket!

This kind of behavior is extremely useful in some cases. In our case we're 
moving huge Redis/HBase structures to multiple java/scala maps and the 
result is thousand of times faster and simple and faster to implement. We 
think, after reading the docs, that Akka is a half step away of this.

Thanks again for your help and time!

El miércoles, 19 de marzo de 2014 09:30:15 UTC+1, Patrik Nordwall escribió:

 You're welcome. Anyway, I have created a ticket for the hot standby 
 processor: https://www.assembla.com/spaces/akka/tickets/3938
 That doesn't mean that we will implement it, but we will take it into 
 consideration.
 Thanks for the feedback.

 Cheers,
 Patrik


 On Tue, Mar 18, 2014 at 8:52 PM, Eduardo Fernandes 
 edu...@gmail.comjavascript:
  wrote:

 Many thanks Patrik for your post. Good shot.

 We could consider sending commands simultaneously to two processors (the 
 main and a standby) and in case of timeout talking to the first we could 
 talk to the second. After the main recovering we could return to the 
 original situation. Maybe we could create both actors in different clusters 
 in different machines to avoid single point of failure in case of machine 
 crash. 

 Many thanks again for your time and for any comment.

 Regards.


 El martes, 18 de marzo de 2014 17:12:43 UTC+1, Patrik Nordwall escribió:


 I see what you are looking for, and it is not supported with current 
 tools. It would be something that is periodically replaying the event 
 stream like a view, but can then be changed into a normal writing processor.

 Have you thought about using an active standby? It would do the exact 
 same thing as the primary, but the output (external side effects) would be 
 ignored/filtered on the standby. It depends very much on your domain if 
 that is a good or bad idea.

 Regards,
 Patrik
  


   -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to 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 javascript:.
 To post to this group, send email to akka...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Cluster/remote pipeline strategy

[Eduardo Fernandes]

Hi all.

We have a system where we've implemented a pipeline strategy as follows: 

1) If the number of messages pending for all actors to a remote host is 
more than N we flush the message queue to the net
2) If the total number of blocked threads waiting for reading is more then 
N we flush the message queue to the net
3) We flush the queue also after X milliseconds if we have some message in 
the queue

The idea is move our current architecture to Akka. Taking into 
consideration that the Akka cluster technology abstracts almost everything 
related to where the actors are and how many pending messages exist to a 
particular physical host, etc. my question is:

Is the internal Akka net pipeline more or less equivalent to our one or, in 
case of not, could I plug in something similar our current pipeline into 
Akka?

We've found that the three criteria aforementioned enabled us to adjust our 
current technology to a wide range of customer requirements.

I couldn't find the right way to go on after reading the docs Dispatchers, 
Routers, and mailboxes, (and also I'm a novice Akka user). 

Many thanks for your help and suggestions.

Best regards,

Eduardo.

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

Re: [akka-user] Cluster/remote pipeline strategy

[Eduardo Fernandes]

El jueves, 20 de marzo de 2014 09:44:28 UTC+1, Patrik Nordwall escribió:

 Hi Eduardo,


Many thanks for your time, Patrik.
 



 On Thu, Mar 20, 2014 at 12:04 AM, Eduardo Fernandes 
 edu...@gmail.comjavascript:
  wrote:

 Hi all.

 We have a system where we've implemented a pipeline strategy as follows: 

 The idea is move our current architecture to Akka. Taking into 
 consideration that the Akka cluster technology abstracts almost everything 
 related to where the actors are and how many pending messages exist to a 
 particular physical host, etc.


 That is not true. Akka cluster is essentially cluster membership, 
 including failure detection. Several tools, such as cluster aware routers, 
 are provided on top of this, but you have full control of where and how to 
 run the actors when you need that.


Gotcha. What I couldn't find is, for example, flush all mailboxes to actors 
in a particular host. The idea is to optimize the packets on the wire with 
a single shot with as many as pending commands as possible to a particular 
physical node. In fact I don't know exactly how to flush pending commands 
to the wire. I'm sure it is because I don't heavy enough knowledge about 
Akka yet.
 

  

 my question is:

 Is the internal Akka net pipeline more or less equivalent to our one or, 
 in case of not, could I plug in something similar our current pipeline into 
 Akka?

 We've found that the three criteria aforementioned enabled us to adjust 
 our current technology to a wide range of customer requirements.


 To give me a more clear picture, can you give some example of what this 
 solves.


We're calling Akka actors from a farm of tomcat's (hundreds) where each 
tomcat manages 5.000 - 9.000 concurrent users. To achieve this we have a 
competition criteria to flush the pending net packages (we, currently, 
manage byte arrays) which accumulates many pending user commands. As we 
need, in many cases, the response of the async cal, we need to block the 
thread waiting for the response. So the criteria to flush the packets to 
the wire is a combination of : total number of threads blocked, total 
volume of data pending to be sent and a max timeout. From our experience, 
if we have many many small packets (100 bytes) it is better to accumulate 
(typically up to 2-3 Kb) and then flush. If there are aprox 40 threads 
blocked we also flush to increase tomcat throughput. So, depending of the 
application scenario on or other criteria will apply with more or less 
relevance. Until now a good choice of the 'magic numbers' solves the 
problem with very good results. I'm wondering if this criteria applies to 
Akka or not. Maybe Akka solves this kind of problem automatically 
auto-adapting itself to the better combination.
 

  


 I couldn't find the right way to go on after reading the docs 
 Dispatchers, Routers, and mailboxes, (and also I'm a novice Akka user). 


 I'm not sure I understand what you are trying to do and why, but one 
 solution might be to pass the messages via an actor that is responsible for 
 the buffering and flushing. 


Maybe it is what we need. Is out there some example of this kind of actor 
doing both things (buffering and flushing to the wire) the pending packets? 
It sounds that is exactly what we want.

Thanks Patrik again for your time and for dedicating calories to understand 
so many different scenarios.

Best regards,

 


 Regards,
 Patrik
  

 Many thanks for your help and suggestions.

 Best regards,

 Eduardo.

  -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to 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 javascript:.
 To post to this group, send email to akka...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cluster/remote pipeline strategy

[Eduardo Fernandes]

Many thanks Patrik for the info!!
 
I'll check the links you mentioned. I think you're right, the frameworks 
could improve a lot our performance.

Best regards!!

El jueves, 20 de marzo de 2014 13:13:28 UTC+1, Patrik Nordwall escribió:




 On Thu, Mar 20, 2014 at 12:25 PM, Eduardo Fernandes 
 edu...@gmail.comjavascript:
  wrote:



 El jueves, 20 de marzo de 2014 09:44:28 UTC+1, Patrik Nordwall escribió:

 Hi Eduardo,


 Many thanks for your time, Patrik.
  



 On Thu, Mar 20, 2014 at 12:04 AM, Eduardo Fernandes edu...@gmail.comwrote:

 Hi all.

 We have a system where we've implemented a pipeline strategy as 
 follows: 

 The idea is move our current architecture to Akka. Taking into 
 consideration that the Akka cluster technology abstracts almost everything 
 related to where the actors are and how many pending messages exist to a 
 particular physical host, etc.
  

 That is not true. Akka cluster is essentially cluster membership, 
 including failure detection. Several tools, such as cluster aware routers, 
 are provided on top of this, but you have full control of where and how to 
 run the actors when you need that.


 Gotcha. What I couldn't find is, for example, flush all mailboxes to 
 actors in a particular host. The idea is to optimize the packets on the 
 wire with a single shot with as many as pending commands as possible to a 
 particular physical node. In fact I don't know exactly how to flush pending 
 commands to the wire. I'm sure it is because I don't heavy enough knowledge 
 about Akka yet.
  

  

 my question is:

 Is the internal Akka net pipeline more or less equivalent to our one 
 or, in case of not, could I plug in something similar our current pipeline 
 into Akka?

 We've found that the three criteria aforementioned enabled us to adjust 
 our current technology to a wide range of customer requirements.


 To give me a more clear picture, can you give some example of what this 
 solves.


 We're calling Akka actors from a farm of tomcat's (hundreds) where each 
 tomcat manages 5.000 - 9.000 concurrent users. To achieve this we have a 
 competition criteria to flush the pending net packages (we, currently, 
 manage byte arrays) which accumulates many pending user commands. As we 
 need, in many cases, the response of the async cal, we need to block the 
 thread waiting for the response. So the criteria to flush the packets to 
 the wire is a combination of : total number of threads blocked, total 
 volume of data pending to be sent and a max timeout.


 Sounds like you have a huge opportunity to improve the scalability of this 
 by using a non-blocking web framework/library, such as 
 Playhttp://www.playframework.com/or 
 Spray http://spray.io/.
  

 From our experience, if we have many many small packets (100 bytes) it is 
 better to accumulate (typically up to 2-3 Kb) and then flush. If there are 
 aprox 40 threads blocked we also flush to increase tomcat throughput. So, 
 depending of the application scenario on or other criteria will apply with 
 more or less relevance. Until now a good choice of the 'magic numbers' 
 solves the problem with very good results. I'm wondering if this criteria 
 applies to Akka or not. Maybe Akka solves this kind of problem 
 automatically auto-adapting itself to the better combination.


 When using akka remoting, the serialized representation of the messages 
 are sent without any batching.
  

  

  


 I couldn't find the right way to go on after reading the docs 
 Dispatchers, Routers, and mailboxes, (and also I'm a novice Akka user). 


 I'm not sure I understand what you are trying to do and why, but one 
 solution might be to pass the messages via an actor that is responsible for 
 the buffering and flushing. 


 Maybe it is what we need. Is out there some example of this kind of actor 
 doing both things (buffering and flushing to the wire) the pending packets? 
 It sounds that is exactly what we want.


 Take a look at the Buncher 
 examplehttp://doc.akka.io/docs/akka/2.3.0/scala/fsm.html#A_Simple_Example
 .
 It is using FSM, which doesn't exist in the Java7 API of Akka. in case you 
 are not using Scala or Java8 you can implement that with an ordinary actor 
 as well.

 If you want to go more low level and have full control you can use Akka 
 I/O http://doc.akka.io/docs/akka/2.3.0/scala/io.html instead of Akka 
 remoting.
  


 Thanks Patrik again for your time and for dedicating calories to 
 understand so many different scenarios.


 You're welcome.
 /Patrik
  


 Best regards,

  


 Regards,
 Patrik
  

  Many thanks for your help and suggestions.

 Best regards,

 Eduardo.

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

Re: [akka-user] Low performance in cluster + sharding with single actor

[Eduardo Fernandes]

Our current technology (what we want to replace) is using 3 different 
criteria when making automatic backpressure: number of blocked threads, 
timeout and queue size. The first one apply to ask patterns. The second one 
enable us to validate that the system is not blocking cpu due to pending 
tasks and the third one does the job if there is no too many queued 
elements. With a correct combination of the three parameters we could 
increase the throughput up to 40-45kCmd/s in my laptop, both client and 
server are monothread. The packet size through the net is adaptive in 
function of the concurrency and pressure.

Many thanks for your answer and for driving me to the right direction. I'll 
test the concepts and let you know.

 

El martes, 25 de marzo de 2014 11:16:28 UTC+1, Akka Team escribió:

 Hi Eduardo,

 The problem is that in your case no matter how large you choose your 
 buffer sizes, they will blow up because there is no backpressure between 
 the two actors. This is independent of remoting, you can blow up mailboxes 
 even locally. The issue with stash/unstash only comes into the picture 
 because the buffer grows out of bounds. Even if that issue would not exist, 
 eventually GC kicks in due to continuously increasing memory usage.

 -Endre


 On Tue, Mar 25, 2014 at 11:00 AM, Vitaliy V. Shopov 
 shopov@gmail.comjavascript:
  wrote:

 And what is your updated benchmark result?)


 2014-03-25 13:57 GMT+04:00 Eduardo Fernandes edu...@gmail.comjavascript:
 :

 Many thanks for your suggestions.

 I'll check the profiling and the settings below.

 Thanks again for your quick answer!


1.  
2. # Sets the send buffer size of the Sockets, 
3. # set to 0b for platform default
4.  send-buffer-size = 256000b 
5.  
6. # Sets the receive buffer size of the Sockets, 
7. # set to 0b for platform default
8.  receive-buffer-size = 256000b 


 El martes, 25 de marzo de 2014 09:46:28 UTC+1, Akka Team escribió:

 Hi Eduardo,


 On Tue, Mar 25, 2014 at 2:08 AM, Eduardo Fernandes edu...@gmail.comwrote:

 Hi all.

 I'm pretty sure this is because I don't have the correct configuration 
 on my side. Please find in the attached file a simple Eclipse Kepler 
 Maven 
 project with an echo actor. I'm using Akka 2.3.

 The basic configuration is 

   actor {
 provider = akka.cluster.ClusterActorRefProvider
 default-dispatcher {
   throughput = 1024
   fork-join-executor {
 parallelism-max = 4
   }
 }
 default-mailbox {
   mailbox-type = akka.dispatch.SingleConsumerOnlyUnboundedMai
 lbox
 }
   }

 Based on other thread in this group. After heating the JVM I got 
 around 11.000 msg per second.  A small and basic program with NIO give me 
 around 45.000 in the same machine, using the loopback interface.


 If you refer to the other localhost remoting benchmark thread, the 
 related ticket is here: https://www.assembla.com/
 spaces/akka/simple_planner#/ticket:3960

 You can check with a profiler and see if most of the time spent in 
 unstash/stash in EndpointWriter to verify that it is the same issue.

 If you properly backpressure messages between the two nodes there 
 should be no performance loss due to unstashing, you only need to increase 
 the tcp send buffer. The stash/unstash death spiral only pops up because 
 buffers are blowing up.
  


 I need to use a single actor due to processing requirements. I'm using 
 a simple sharding and a single frontend / backend topology (configured 
 using roles).

 Is it possible to flush the low level TCP channel based, for example, 
 in the volume of pending command to all actors belonging to a particular 
 host? Or is this already done based on some setting?


 Messages are pumped out to TCP as soon as possible, there is no 
 flushing involved.

 -Endre
  

  
 Many thanks for any help.

 Best regards,

 Eduardo.


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

 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam
  
  -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: 
 https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to the Google 
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to akka-user

[akka-user] Akka cluster failover: hot swaping

[Eduardo Fernandes]

Hi all.

I'm trying a hot swap between an active processor and a backup one, in line 
with the 
thishttps://www.assembla.com/spaces/akka/tickets/3938#/activity/ticket: 
ticket, 
to avoid delay while swapping huge actors. 

I'm thinking about manually sending my commands to two different actors in 
a active/passive fashion. In case of node failure I'd like to point out to 
the passive instance, avoiding startup delay. I'm thinking about having two 
sharding regions and then, after node failure and using a particular 
sharding strategy, point out to the node where the passive object is. Maybe 
the hotswap (as decribed 
herehttp://doc.akka.io/docs/akka/snapshot/java/untyped-actors.html#untypedactor-hotswap)
 
can be used to deviate the commands to passive actor. In the meanwhile the 
standard Akka persistence scheme is being used to re-initiate the original 
actor that could be used later after a new node failure. 

Do you think that this approach is feasible or maybe there is another 
simpler way to achieve this behavior? 

Many thanks for your help.

Eduardo.

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

[akka-user] [Cluster] Strange error with simultaneous messages

[Eduardo Fernandes]

Hi.

First of all, thanks for your time reading this.

I'm working with an Akka cluster and I don't understand a peculiar effect 
I'm observing. If I send 70 simultaneous messages (and for each message a 
callback resend the message again) everything works fine. But if I try the 
same with 100 simultaneous messages I'm getting messages like:

[INFO] [05/20/2014 23:38:07.469] 
[object-server-cluster-akka.actor.default-dispatcher-5] 
[Cluster(akka://object-server-cluster)] Cluster Node 
[akka.tcp://object-server-cluster@127.0.0.1:62912] - Welcome from 
[akka.tcp://object-server-cluster@127.0.0.1:12551]
[INFO] [05/20/2014 23:38:08.107] 
[object-server-cluster-akka.actor.default-dispatcher-5] 
[akka://object-server-cluster/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-1]
 
Message [akka.remote.transport.AssociationHandle$Disassociated] from 
Actor[akka://object-server-cluster/deadLetters] to 
Actor[akka://object-server-cluster/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-1#-2009383650]
 
was not delivered. [1] dead letters encountered. This logging can be turned 
off or adjusted with configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
[WARN] [05/20/2014 23:38:08.113] 
[object-server-cluster-akka.remote.default-remote-dispatcher-7] 
[akka.tcp://object-server-cluster@127.0.0.1:62912/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-0]
 
Association with remote system 
[akka.tcp://object-server-cluster@127.0.0.1:12551] has failed, address is 
now gated for [5000] ms. Reason is: [Disassociated].
[INFO] [05/20/2014 23:38:08.119] 
[object-server-cluster-akka.actor.default-dispatcher-4] 
[akka://object-server-cluster/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-1]
 
Message 
[akka.remote.transport.ActorTransportAdapter$DisassociateUnderlying] from 
Actor[akka://object-server-cluster/deadLetters] to 
Actor[akka://object-server-cluster/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-1#-2009383650]
 
was not delivered. [2] dead letters encountered. This logging can be turned 
off or adjusted with configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
[INFO] [05/20/2014 23:38:08.120] 
[object-server-cluster-akka.actor.default-dispatcher-3] 
[akka://object-server-cluster/deadLetters] Message 
[dw.core.objectserver.providers.akka.client.CommandRequest] from 
Actor[akka://object-server-cluster/user/pipelining-router#476466102] to 
Actor[akka://object-server-cluster/deadLetters] was not delivered. [3] dead 
letters encountered. This logging can be turned off or adjusted with 
configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.

( I've attached the error log for your convenience and my config files ). 
The processors are at backend side (process port 12551 and the log is 
related to the frontend process.

I'm sure it is related to configuration but I couldn't cut the right wire 
yet.

Many thanks for your help.

Regards,

Eduardo.



-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[INFO] [05/20/2014 23:38:07.469] 
[object-server-cluster-akka.actor.default-dispatcher-5] 
[Cluster(akka://object-server-cluster)] Cluster Node 
[akka.tcp://object-server-cluster@127.0.0.1:62912] - Welcome from 
[akka.tcp://object-server-cluster@127.0.0.1:12551]
[INFO] [05/20/2014 23:38:08.107] 
[object-server-cluster-akka.actor.default-dispatcher-5] 
[akka://object-server-cluster/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-1]
 Message [akka.remote.transport.AssociationHandle$Disassociated] from 
Actor[akka://object-server-cluster/deadLetters] to 
Actor[akka://object-server-cluster/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fobject-server-cluster%40127.0.0.1%3A12551-1#-2009383650]
 was not delivered. [1] dead letters encountered. This logging can be turned 
off or adjusted with configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
[WARN] [05/20/2014 23:38:08.113] 
[object-server-cluster-akka.remote.default-remote-dispatcher-7] 

[akka-user] Re: [Cluster] Strange error with simultaneous messages

[Eduardo Fernandes]

For sure... Akka version 2.3.2!

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

[akka-user] Cluster, sharding and roles

[Eduardo Fernandes]

Hi all.

Probably this is a silly question but I couldn't find any clear answer in 
the group or docs.

Suppose I have a cluster with 4 nodes with 2 roles (2 node instances per 
role). How could I create two shardings, each one sending messages to the 
nodes belonging to a particular role? The idea is add a new node with a 
particular role and let the cluster sharding distribute the work among all 
nodes belonging to that role. I suppose I could create two sharding 
regions, one per role, and assign the sharding to a role in some way?

I'm using Java and Akka 2.3.3.

Many thanks for your help.

Eduardo.


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

Re: [akka-user] Cluster, sharding and roles

[Eduardo Fernandes]

Many Thanks Patrik.

I'm afraid that if I manage the actors directly I'll lose all the cluster 
benefits, include spreading out the mapping objectId - physical node. I 
think that I can reduce the problem to a case where I could avoid the 
creation of new actors in a particular node in the cluster and then, after 
all actors are virtually inactive, turn the node down. 

I don't know where is the mapping of entryId - physical node. 

Could I override the distribution logical somehow so I could control in 
which physical node the actor will be instantiated in the cluster? That 
would be perfect. I'd overridden the mapping using the sharding policy with 
  AbstractShardAllocationStrategy inheriting 
from LeastShardAllocationStrategy but I couldn't find where adjust the way 
the cluster assign physical nodes to the particular sharding entry.

Many thanks, Patrik, for your help.

Regards.



El lunes, 2 de junio de 2014 10:24:34 UTC+2, Patrik Nordwall escribió:

 Hi Eduardo,

 The ClusterSharding extension supports configuration of one role to use a 
 subset of nodes, but that is not what you are looking for. Instead of using 
 the ClusterSharding extension you may start the actors yourself and thereby 
 specify the roles.
 See:
 ShardCoordinatorSupervisor.props
 ShardCoordinator.props
 ShardRegion.props

 Note that the ShardCoordinatorSupervisor is supposed be started with 
 a ClusterSingletonManager. See here: 
 https://github.com/akka/akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala#L360

 Cheers,
 Patrik


 

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

Re: [akka-user] Cluster, sharding and roles

[Eduardo Fernandes]

Many Thanks Patrik for your time!

I'll check the addresses and let you know. With this info I could,
theoretically, implements a smooth node shutdown.

Best regards!


On Mon, Jun 2, 2014 at 3:12 PM, Patrik Nordwall patrik.nordw...@gmail.com
wrote:




 On Mon, Jun 2, 2014 at 1:10 PM, Eduardo Fernandes edu...@gmail.com
 wrote:

 Many Thanks Patrik.

 I'm afraid that if I manage the actors directly I'll lose all the cluster
 benefits, include spreading out the mapping objectId - physical node.


 That would not change. The ClusterSharding extension is only creating
 exactly the same actors for you, in a convenient way. I understand that you
 think it is overwhelming to create these actors yourself, but it is
 possible (and the reason why the props methods are public).


 I think that I can reduce the problem to a case where I could avoid the
 creation of new actors in a particular node in the cluster and then, after
 all actors are virtually inactive, turn the node down.

 I don't know where is the mapping of entryId - physical node.

 Could I override the distribution logical somehow so I could control in
 which physical node the actor will be instantiated in the cluster? That
 would be perfect. I'd overridden the mapping using the sharding policy with
   AbstractShardAllocationStrategy inheriting
 from LeastShardAllocationStrategy but I couldn't find where adjust the way
 the cluster assign physical nodes to the particular sharding entry.


 Yes, that is done by the information returned by the
 AbstractShardAllocationStrategy. The passed in currentShardAllocations
 contains the ActorRefs of the ShardRegion actors, and you could use the
 addresses of these to decide which nodes to use. You must somehow correlate
 those addresses with the addresses of the cluster members if you want to
 use the cluster role information.

 The AbstractShardAllocationStrategy does not allocate locations for
 individual entries. That is always done on a group of entries, a.k.a.
 shard. You define the mapping between entry ids (messages) and shards in
 the MessageExtractor.

 /Patrik



 Many thanks, Patrik, for your help.

 Regards.



 El lunes, 2 de junio de 2014 10:24:34 UTC+2, Patrik Nordwall escribió:

 Hi Eduardo,

 The ClusterSharding extension supports configuration of one role to use
 a subset of nodes, but that is not what you are looking for. Instead of
 using the ClusterSharding extension you may start the actors yourself and
 thereby specify the roles.
 See:
 ShardCoordinatorSupervisor.props
 ShardCoordinator.props
 ShardRegion.props

 Note that the ShardCoordinatorSupervisor is supposed be started with
 a ClusterSingletonManager. See here: https://github.com/akka/
 akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/
 pattern/ClusterSharding.scala#L360

 Cheers,
 Patrik


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




 --

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  Reactive apps on the JVM
 Twitter: @patriknw

 http://typesafe.com/go-reactive-activator-contest

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

Re: [akka-user] Cluster, sharding and roles

[Eduardo Fernandes]

It worked perfectly!

Many thanks for your help!

Regards.



El lunes, 2 de junio de 2014 15:24:58 UTC+2, Eduardo Fernandes escribió:

 Many Thanks Patrik for your time!

 I'll check the addresses and let you know. With this info I could, 
 theoretically, implements a smooth node shutdown. 

 Best regards!



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

Re: [akka-user] Re: Cluster, sharding and roles

[Eduardo Fernandes]

Nice post!

I'll use your concepts to implement the progressive scaling down.

Many thanks for your info!


On Mon, Jun 2, 2014 at 10:49 PM, Luis Medina lu4...@gmail.com wrote:

 Hi Eduardo,

 I recently implemented my own version of a ShardAllocationStrategy and
 made use of the ShardRegion's addresses. I made a post about it here:
 https://groups.google.com/forum/#!topic/akka-user/7p_fkEFJqHw

 It doesn't solve your exact problem but maybe it will give you some ideas.
 Also, the code is in Java so if you're using Scala you might have to do a
 bit of translating.



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

[akka-user] Akka cluster: stopping actor doesn't remove sharding entry

[Eduardo Fernandes]

Hi.

First of all thanks for your time on this.

I'm using Akka version 2.3.4 (Java).

I've stopped an actor 

getContext().stop(getSelf());

and when I look at the rebalance() method in my AllocationStrategy I still 
see the entry in the sharding region corresponding to the stopped actor. 
I'm using a consistent hash scheme so the actor has a one to one 
correspondence to a particular sharding entry.

I expected that after the stop() method the cluster should remove the entry 
from the list. Is this the expected behaviour?

The problem is that if we created a lot of actors (corresponding to a 
particular sharding value) we got many useless (?) entries in the maps 
processed by the allocation strategy. I'm writing a start/stop routing for 
the cluster so I'd like to use the info in the sharding strategy to produce 
a list with only the active objects in the cluster.

The alternative is that I manage a list of active entries by myself, of 
course, using a kind of pub/sub actor.

Many thanks again for your help.

Edu.


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

Re: [akka-user] Akka cluster: stopping actor doesn't remove sharding entry

[Eduardo Fernandes]

Many thanks for your help Endre.

Completely understood from shard perspective. I'll check if the entry 
disappear if the actor is stopped (which is not the case for the sharding).

Regards.


El miércoles, 23 de julio de 2014 11:13:46 UTC+2, Akka Team escribió:

 Hi Eduardo,

 Shards are assumed to be a fixed and relatively few in numbers (like a few 
 hundreds). They are the unit of rebalancing and do not get removed even if 
 there are no active entries in them at a certain time. This is usually not 
 a problem if the number of shards are a few, but if you map all your 
 entries with shardId == entryId then obviously all entries will live on a 
 separate shard -- this use case is not optimized so far.

 -Endre

 

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

Re: [akka-user] Akka cluster: stopping actor doesn't remove sharding entry

[Eduardo Fernandes]

Ok. Entries are managed as expected. After looking at the code I understand 
what you mean.

Thanks a lot for your help.

Regards.




El miércoles, 23 de julio de 2014 15:41:00 UTC+2, Eduardo Fernandes 
escribió:

 Many thanks for your help Endre.

 Completely understood from shard perspective. I'll check if the entry 
 disappear if the actor is stopped (which is not the case for the sharding).

 Regards.


 

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

Re: [akka-user] Akka cluster: stopping actor doesn't remove sharding entry

[Eduardo Fernandes]

Yes, we are using passivation. Tx. 

There is a way of retrieve the entries id's from the shardings? 
There is a member called entries in the sharding region class but I don't know 
if I have access to it. 

Tx again. 



 El 24/07/2014, a las 10:19, Akka Team akka.offic...@gmail.com escribió:
 
 Hi Eduardo,
 
 Just to add more information, since the persistence support for sharding 
 allows persisted entries to be passivated (the actor is stopped to save 
 memory, but is restored from disk when needed) in which case the ShardRegion 
 - shardId association still needs to be maintained although no actors might 
 be running in that shard. In fact this table is persisted by the 
 ShardCoordinator so if the node hosting it fails it can be reliably restored 
 in a new node.
 
 -Endre
 
 
 On Thu, Jul 24, 2014 at 12:42 AM, Eduardo Fernandes edu...@gmail.com wrote:
 Ok. Entries are managed as expected. After looking at the code I understand 
 what you mean.
 
 Thanks a lot for your help.
 
 Regards.
 
 
 
 
 El miércoles, 23 de julio de 2014 15:41:00 UTC+2, Eduardo Fernandes escribió:
 Many thanks for your help Endre.
 
 Completely understood from shard perspective. I'll check if the entry 
 disappear if the actor is stopped (which is not the case for the sharding).
 
 Regards.
 
 -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam
 -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Akka User List group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/akka-user/ravs9P4Nz7A/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka cluster: stopping actor doesn't remove sharding entry

[Eduardo Fernandes]

Quite clear Endre, as always.

Many thanks again for your time!

Best regards from Spain.


On Thu, Jul 24, 2014 at 12:59 PM, Akka Team akka.offic...@gmail.com wrote:

 Hi Eduardo,

 There is no explicit table maintained for individual entries. Sharding
 maintains the table what ShardRegions are responsible for what ShardIds,
 but we don't have a list of all entities inside the ShardId -- since these
 relationships can be calculated by the IdExtractor and ShardResolver
 functions.

 I.e. if you want to send a message to a specific ID:
  - the shard ID is calculated using the ShardResolver function
  - using the internal tables we find out which ShardRegion hosts that
 ShardId
  - the message is forwarded to that ShardRegion
  - the ShardRegion forwards the message to the actor corresponding to the
 given Id (reactivating from disk if needed). This step does not need any
 tables

 -Endre

 -Endre


 On Thu, Jul 24, 2014 at 11:27 AM, Eduardo Fernandes edu...@gmail.com
 wrote:

 Yes, we are using passivation. Tx.

 There is a way of retrieve the entries id's from the shardings?
 There is a member called entries in the sharding region class but I don't
 know if I have access to it.

 Tx again.



 El 24/07/2014, a las 10:19, Akka Team akka.offic...@gmail.com escribió:

 Hi Eduardo,

 Just to add more information, since the persistence support for sharding
 allows persisted entries to be passivated (the actor is stopped to save
 memory, but is restored from disk when needed) in which case the
 ShardRegion - shardId association still needs to be maintained although no
 actors might be running in that shard. In fact this table is persisted by
 the ShardCoordinator so if the node hosting it fails it can be reliably
 restored in a new node.

 -Endre


 On Thu, Jul 24, 2014 at 12:42 AM, Eduardo Fernandes edu...@gmail.com
 wrote:

 Ok. Entries are managed as expected. After looking at the code I
 understand what you mean.

 Thanks a lot for your help.

 Regards.




 El miércoles, 23 de julio de 2014 15:41:00 UTC+2, Eduardo Fernandes
 escribió:

 Many thanks for your help Endre.

 Completely understood from shard perspective. I'll check if the entry
 disappear if the actor is stopped (which is not the case for the sharding).

 Regards.


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




 --
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups Akka User List group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/akka-user/ravs9P4Nz7A/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 akka-user+unsubscr...@googlegroups.com.

 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups Akka User List group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/akka-user/ravs9P4Nz7A/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user

[akka-user] AllocationStrategy rebalance() is stopping actors outside resharding list

[Eduardo Fernandes]

Hi.

We're using Akka 2.3.13 (Java Interface).

We have our own AllocationStrategy implementation and the idea is move 
several shards from one node to other.  We have a 2 nodes in the cluster 
and 1000 shards in total. When we start 7000 actors we have approximately 
3500 actors on each node inside 500 shards on each node (aprox). Everything 
normal and behaving like the user manual.

At some point in time we return in the rebalance() method around 300 shards 
to rebalance. What I'm observing is that some actors not belonging to a 
shard in the rebalancing set are being stopped, what is quite strange.

I can't find any public issue related to this. There is some known 
relocation bug?

Many thanks in advance.

/Eduardo

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

[akka-user] Akka cluster: Passivation + reshard

[Eduardo Fernandes]

Hi.

Suppose that we have all actors of a particular shard passivated. The next 
time an actor of that shard receive a message the new incarnation will be 
in the same physical node where the shard was before or the the logic of 
new shard is triggered again and the shard is created for example where 
there is less shards?

Obs: in my case the rebalancing logic is switched off so there is no 
automatic resharding. 

Thanks for your time.

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

Re: [akka-user] awaitTermination not working?

[Eduardo Fernandes]

Hum... it's look like an actor which uses an asynchronous DB persistor from 
an external library sometimes launches a thread. When the thread is running 
the shutdown() does nothing and the awaitTermination() doesn't block. If I 
stop the thread (I have to  say that in a not very documented way) the 
shutdown stops all Akka threads and the system appears to be released 
correctly (nevertheless in a single node configuration I don't see the 
typical shutdowing messages in the log).

Doing this the problem is solved. Thanks for your comments.

I still don't understand why the shutdown()/awaitTermination()  have no 
effect when those external threads are running. Probably when we migrate to 
2.4 the problem will just vanish.

Thanks again!


El viernes, 11 de marzo de 2016, 13:45:59 (UTC+1), Eduardo Fernandes 
escribió:
>
> Me too :(
>
> I'l prepare a minimum example. Typically when I do this the problem get 
> clear and I could fix my test code :)
>
> Regards.
>  
>
>

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

Re: [akka-user] awaitTermination not working?

[Eduardo Fernandes]

Hi Roland.

Thanks for your answer.

Sure, the problem was that I was not aware about that threads. I'm afraid
that I have to shutdown such threads at system shutdown because the library
shares threads among several actor instances. Anyway, problem solved!

Thanks again for your time very helpful suggestions.


On Mon, Mar 14, 2016 at 8:12 AM, Roland Kuhn  wrote:

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

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

[Eduardo Fernandes]

Hi group! Thanks for your time in advance.

I'm using Java version 2.3.13. In my JUnit tests and when I'm testing in 
single node the awaitTermination function after the traditional shutdown() 
is not awaiting for the actor system termination. In fact the actorsystem 
is not event starting to shutdown.

I found this 
and
 
this 

 but 
I didn't found a clear solution to my problem. For other tests in 
multi-node environment the awaiting function is working fine.

Any idea?

Many thanks again for your help.

/Eduardo


https://groups.google.com/forum/#!searchin/akka-user/awaitTermination/akka-user/kAbrnq9mTsM/YefmJmOw7bUJ

https://groups.google.com/forum/#!searchin/akka-user/awaitTermination/akka-user/9YCfjf2iuqc/edTwRBZJgUEJ

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

Re: [akka-user] awaitTermination not working?

[Eduardo Fernandes]

Hi. Thanks Patrik.

I am using shutdown() and then awaitTermination(). Both don't block and
return immediately. My previous test start two nodes and the the
awaitTermination()
blocks as expected and everything works fine. The only test which fails is
the one which works in single-node mode.

I've tried the TestKit and the behavior is exactly the same.

In other words, if I start a new node in the same test the function blocks
as expected.

Thanks again.


On Fri, Mar 11, 2016 at 1:33 PM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> You must use shutdown followed by awaitTermination.
> (note that awaitTermination is replaced by something else in 2.4.x, see
> deprecation)
>
> In TestKit there is a helper method to shutdown the actor system, await
> and verify.
>
> On Fri, Mar 11, 2016 at 1:22 PM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Hi.
>>
>> Hum... I think that is not the case. In fact the methods shutdown() and 
>> awaitTermination()
>> simply don't block at all and the next test says that the port 12551 is
>> already bound. If my previous test starts two nodes everything works find
>> and the awaitTermination() method waits for the node shutdown.
>>
>> The problem only appears when my test is single node.
>>
>> Thanks for your time.
>>
>> On Fri, Mar 11, 2016 at 1:14 PM, Akka Team <akka.offic...@gmail.com>
>> wrote:
>>
>>> Hi Eduardo,
>>>
>>> If you have an actor that is blocking indefinitely, the actor system
>>> termination will never complete, could this be the case? If it is you
>>> should be able to see that by getting a thread dump from the JVM and see
>>> one of your actor blocking one of the dispatcher threads.
>>>
>>> --
>>> Johan Andrén
>>> Akka Team, Lightbend Inc.
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Akka User List" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/akka-user/tkCnKcjj1tI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] <http://www.lightbend.com/>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/tkCnKcjj1tI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [akka-user] awaitTermination not working?

[Eduardo Fernandes]

Me too :(

I'l prepare a minimum example. Typically when I do this the problem get
clear and I could fix my test code :)

Regards.


On Fri, Mar 11, 2016 at 1:43 PM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> Please share minimized code of the problem. We use this all over the place
> so I'm pretty sure your code is not correct.
>
> On Fri, Mar 11, 2016 at 1:39 PM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Hi. Thanks Patrik.
>>
>> I am using shutdown() and then awaitTermination(). Both don't block and
>> return immediately. My previous test start two nodes and the the 
>> awaitTermination()
>> blocks as expected and everything works fine. The only test which fails is
>> the one which works in single-node mode.
>>
>> I've tried the TestKit and the behavior is exactly the same.
>>
>> In other words, if I start a new node in the same test the function
>> blocks as expected.
>>
>> Thanks again.
>>
>>
>> On Fri, Mar 11, 2016 at 1:33 PM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> You must use shutdown followed by awaitTermination.
>>> (note that awaitTermination is replaced by something else in 2.4.x, see
>>> deprecation)
>>>
>>> In TestKit there is a helper method to shutdown the actor system, await
>>> and verify.
>>>
>>> On Fri, Mar 11, 2016 at 1:22 PM, Eduardo Fernandes <edu...@gmail.com>
>>> wrote:
>>>
>>>> Hi.
>>>>
>>>> Hum... I think that is not the case. In fact the methods shutdown() and 
>>>> awaitTermination()
>>>> simply don't block at all and the next test says that the port 12551 is
>>>> already bound. If my previous test starts two nodes everything works find
>>>> and the awaitTermination() method waits for the node shutdown.
>>>>
>>>> The problem only appears when my test is single node.
>>>>
>>>> Thanks for your time.
>>>>
>>>> On Fri, Mar 11, 2016 at 1:14 PM, Akka Team <akka.offic...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Eduardo,
>>>>>
>>>>> If you have an actor that is blocking indefinitely, the actor system
>>>>> termination will never complete, could this be the case? If it is you
>>>>> should be able to see that by getting a thread dump from the JVM and see
>>>>> one of your actor blocking one of the dispatcher threads.
>>>>>
>>>>> --
>>>>> Johan Andrén
>>>>> Akka Team, Lightbend Inc.
>>>>>
>>>>> --
>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>> >>>>>>>>>> Check the FAQ:
>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>> >>>>>>>>>> Search the archives:
>>>>> https://groups.google.com/group/akka-user
>>>>> ---
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "Akka User List" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/akka-user/tkCnKcjj1tI/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> akka-user+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ:
>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>> >>>>>>>>>> Search the archives:
>>>> https://groups.google.com/group/akka-user
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Akka User List" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to akka-user+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>> For more options, v

Re: [akka-user] awaitTermination not working?

[Eduardo Fernandes]

Hi.

Hum... I think that is not the case. In fact the methods shutdown()
and awaitTermination()
simply don't block at all and the next test says that the port 12551 is
already bound. If my previous test starts two nodes everything works find
and the awaitTermination() method waits for the node shutdown.

The problem only appears when my test is single node.

Thanks for your time.

On Fri, Mar 11, 2016 at 1:14 PM, Akka Team  wrote:

> Hi Eduardo,
>
> If you have an actor that is blocking indefinitely, the actor system
> termination will never complete, could this be the case? If it is you
> should be able to see that by getting a thread dump from the JVM and see
> one of your actor blocking one of the dispatcher threads.
>
> --
> Johan Andrén
> Akka Team, Lightbend Inc.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/tkCnKcjj1tI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [akka-user] Akka cluster: Passivation + reshard

[Eduardo Fernandes]

Ok. I've tried to find it out in the group without success.

Many thanks for your time!



On Wed, Mar 9, 2016 at 10:36 AM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> I think this has been answered elsewhere, but anyway. Passivation of all
> entities does not mean that the shard goes away, so next message will
> trigger allocation of the entity actor where the shard is currently
> located. Rebalancing can change the current location.
>
> /Patrik
>
> On Mon, Feb 29, 2016 at 10:30 AM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Hi.
>>
>> Suppose that we have all actors of a particular shard passivated. The
>> next time an actor of that shard receive a message the new incarnation will
>> be in the same physical node where the shard was before or the the logic of
>> new shard is triggered again and the shard is created for example where
>> there is less shards?
>>
>> Obs: in my case the rebalancing logic is switched off so there is no
>> automatic resharding.
>>
>> Thanks for your time.
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to 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 <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] <http://www.lightbend.com/>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/u7qcXv_F2Oc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Eduardo Fernandes]

Hi.

If you have writeObject/readObject defined in your class the Java plain
serialization will invoke those methods. In my case all my internal members
and class references are also serialized using the very same technique. So
this is equivalent to technologies like kryo and similars since there is no
overhead if you serialize basic members. In other words the pre-compiles
classes you get from kryo are already made so there is no performance
enhancement in this case. The big advantage of kryo is that you don't have
to create the writeObject/readObject by yourself. In my particular case
I've already done that job and my serialization is optimized in particular
cases where I don't have to serialize all members depending of my semantic.
I've made some tests and doing this way is faster than kryo but you have to
burn some calories implementing a optimized serialization code.

Bests regards and thanks for your comment.


On Sat, Jul 2, 2016 at 9:27 PM, Viktor Klang <viktor.kl...@gmail.com> wrote:

> I'm not sure I understand why write/readObject special methods would
> necessarily be faster? Most of the waste of Java Serialization is its
> envelopes and using class names etc.
>
> On Sat, Jul 2, 2016 at 1:14 AM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Hi.
>>
>> I'm using Akka 2.3.13, Java edition.
>>
>> I'm making some performance tests and in the same machine with 8 cores I
>> see that the serialization process is my bottleneck.  I know that because
>> after an increment of actor cpu usage the throughput is exactly the same.
>>
>> My actor system talks to 2 other nodes so I see 2 cores dedicated to
>> serialization. Is is possible to increase the number of threads for
>> serialization?
>>
>> I'm using standard Java serialization but I have my own serialization
>> implementation in my write/readObject methods so I think that switching to
>> kryo or similar will not enhance too much the throughput.
>>
>> Many thanks for your help.
>>
>> /Eduardo
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> √
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/EVsIxMEDKeI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Eduardo Fernandes]

Hi Viktor.

I'm using basic (binary) serialization of basic Java types (int, String
(UTF), long, arrays of basic types, etc...).

The overhead is that depending of internal values there is no send to
serialize some members and other not. If you merge your functional logic
with the serialization you can make optimizations that a generic serializar
can't do. Example. Suppose that if a member A has a null value you don't
have to serialize other member B. Maybe the member B you don't have to
serialize could have a null value which is fast to serialize but it is even
faster you don't have even to serialize the null. This type of overhead is
only possible if the serializer knows about your functional logic.

Regards

On Sat, Jul 2, 2016 at 10:05 PM, Viktor Klang <viktor.kl...@gmail.com>
wrote:

> Hi Eduardo,
>
> Perhaps I misunderstood, what serialization format are you emitting in
> your readObject/writeObject?
> What overhead are you observing compared to using a custom Serializer?
>
> On Sat, Jul 2, 2016 at 10:02 PM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Hi.
>>
>> If you have writeObject/readObject defined in your class the Java plain
>> serialization will invoke those methods. In my case all my internal members
>> and class references are also serialized using the very same technique. So
>> this is equivalent to technologies like kryo and similars since there is no
>> overhead if you serialize basic members. In other words the pre-compiles
>> classes you get from kryo are already made so there is no performance
>> enhancement in this case. The big advantage of kryo is that you don't have
>> to create the writeObject/readObject by yourself. In my particular case
>> I've already done that job and my serialization is optimized in particular
>> cases where I don't have to serialize all members depending of my semantic.
>> I've made some tests and doing this way is faster than kryo but you have to
>> burn some calories implementing a optimized serialization code.
>>
>> Bests regards and thanks for your comment.
>>
>>
>> On Sat, Jul 2, 2016 at 9:27 PM, Viktor Klang <viktor.kl...@gmail.com>
>> wrote:
>>
>>> I'm not sure I understand why write/readObject special methods would
>>> necessarily be faster? Most of the waste of Java Serialization is its
>>> envelopes and using class names etc.
>>>
>>> On Sat, Jul 2, 2016 at 1:14 AM, Eduardo Fernandes <edu...@gmail.com>
>>> wrote:
>>>
>>>> Hi.
>>>>
>>>> I'm using Akka 2.3.13, Java edition.
>>>>
>>>> I'm making some performance tests and in the same machine with 8 cores
>>>> I see that the serialization process is my bottleneck.  I know that because
>>>> after an increment of actor cpu usage the throughput is exactly the same.
>>>>
>>>> My actor system talks to 2 other nodes so I see 2 cores dedicated to
>>>> serialization. Is is possible to increase the number of threads for
>>>> serialization?
>>>>
>>>> I'm using standard Java serialization but I have my own serialization
>>>> implementation in my write/readObject methods so I think that switching to
>>>> kryo or similar will not enhance too much the throughput.
>>>>
>>>> Many thanks for your help.
>>>>
>>>> /Eduardo
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ:
>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>> >>>>>>>>>> Search the archives:
>>>> https://groups.google.com/group/akka-user
>>>> ---
>>>> You received this message because you are subscribed to 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
>>&g

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

[Eduardo Fernandes]

Hi Guido.

After implementing your suggestions I'm realizing that maybe my particular
case is a bit peculiar, I'm interested in a benchmark involving 2 hosts.
I'm getting around 500.000 transactions per second (echo of array of 48
bytes), which is not a so bad number. Increasing the number of worker
threads is not improving my numbers. I have two actors in a shard region
talking to other two actors in other shard region (in other physical node).
It looks like Akka/netty, when talking to the second shard region, never
asks for more than one thread when connecting to the second shard region. I
think that Akka could use as many threads as actors in the first shard
region, below a max number. In my case, with a 8 cores machine, we could
expect that, for example, two threads could be used to serialize from host1
to host2 but I'm afraid that is not the case.

Thanks again for your time on this.

Regards.


On Sat, Jul 2, 2016 at 1:35 PM, Guido Medina <oxyg...@gmail.com> wrote:

> The following might also be helpful:
>
>
> akka.remote {
>
>   #log-remote-lifecycle-events = off
>
>   netty.tcp {
>
> #port = 0
>
> server-socket-worker-pool {
>   pool-size-min = 4
>   pool-size-factor = 1
>   pool-size-max = 8
> }
>
> client-socket-worker-pool {
>   pool-size-min = 4
>   pool-size-factor = 1
>   pool-size-max = 8
> }
>   }
> }
>
>
>
>
> On Saturday, July 2, 2016 at 12:31:12 PM UTC+1, Guido Medina wrote:
>>
>> Didn't read the serialization part, must be that I need my coffee, Kryo
>> is very well optimized, you don't know if is going to help until you test
>> it.
>> Kryo also also has a pool of serializers that are ready to be used and
>> can be improved if you declared the classes you are serializing.
>>
>> On Saturday, July 2, 2016 at 12:27:28 PM UTC+1, Guido Medina wrote:
>>>
>>> Try the following, these values work great,
>>> you can try higher but I don't think it is going to help because the
>>> most of the bottleneck is because of design,
>>> a problem related with how akka-remote is designed around Netty, but
>>> that will change soon: https://github.com/akka/akka-meta/issues/22
>>>
>>> akka.remote.default-remote-dispatcher {
>>>   type = Dispatcher
>>>   executor = "fork-join-executor"
>>>
>>>   fork-join-executor {
>>> parallelism-min = 4
>>> parallelism-factor = 1
>>> parallelism-max = 8
>>>   }
>>> }
>>>
>>> Also, what serialization are you using? Hopefully is the not default
>>> Java serialization, most people use Kryo serialization.
>>>
>>> Non-related but could help:
>>>
>>>- Set Akka version to "2.3.15" (next week 2.3.16 is probably going
>>>to be released)
>>>- Set Netty version to "3.10.6.Final" which will be part of next
>>>release.
>>>
>>> See https://github.com/netty/netty/issues?q=milestone%3A3.10.6.Final
>>> and https://github.com/akka/akka/pull/20857
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Saturday, July 2, 2016 at 12:14:24 AM UTC+1, Eduardo Fernandes wrote:
>>>>
>>>> Hi.
>>>>
>>>> I'm using Akka 2.3.13, Java edition.
>>>>
>>>> I'm making some performance tests and in the same machine with 8 cores
>>>> I see that the serialization process is my bottleneck.  I know that because
>>>> after an increment of actor cpu usage the throughput is exactly the same.
>>>>
>>>> My actor system talks to 2 other nodes so I see 2 cores dedicated to
>>>> serialization. Is is possible to increase the number of threads for
>>>> serialization?
>>>>
>>>> I'm using standard Java serialization but I have my own serialization
>>>> implementation in my write/readObject methods so I think that switching to
>>>> kryo or similar will not enhance too much the throughput.
>>>>
>>>> Many thanks for your help.
>>>>
>>>> /Eduardo
>>>>
>>>> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from

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

[Eduardo Fernandes]

Hi. 

Many thanks for your suggestions. 

I will try and let you know. 

Thanks again for your time. 

> El 2 jul 2016, a las 13:35, Guido Medina <oxyg...@gmail.com> escribió:
> 
> The following might also be helpful:
> 
> 
> akka.remote {
> 
>   #log-remote-lifecycle-events = off
> 
>   netty.tcp {
> 
> #port = 0
> 
> server-socket-worker-pool {
>   pool-size-min = 4
>   pool-size-factor = 1
>   pool-size-max = 8
> }
> 
> client-socket-worker-pool {
>   pool-size-min = 4
>   pool-size-factor = 1
>   pool-size-max = 8
> }
>   }
> }
> 
> 
> 
> 
>> On Saturday, July 2, 2016 at 12:31:12 PM UTC+1, Guido Medina wrote:
>> Didn't read the serialization part, must be that I need my coffee, Kryo is 
>> very well optimized, you don't know if is going to help until you test it.
>> Kryo also also has a pool of serializers that are ready to be used and can 
>> be improved if you declared the classes you are serializing.
>> 
>>> On Saturday, July 2, 2016 at 12:27:28 PM UTC+1, Guido Medina wrote:
>>> Try the following, these values work great,
>>> you can try higher but I don't think it is going to help because the most 
>>> of the bottleneck is because of design,
>>> a problem related with how akka-remote is designed around Netty, but that 
>>> will change soon: https://github.com/akka/akka-meta/issues/22
>>> 
>>> akka.remote.default-remote-dispatcher {
>>>   type = Dispatcher
>>>   executor = "fork-join-executor"
>>> 
>>>   fork-join-executor {
>>> parallelism-min = 4
>>> parallelism-factor = 1
>>> parallelism-max = 8
>>>   }
>>> }
>>> 
>>> Also, what serialization are you using? Hopefully is the not default Java 
>>> serialization, most people use Kryo serialization.
>>> 
>>> Non-related but could help:
>>> Set Akka version to "2.3.15" (next week 2.3.16 is probably going to be 
>>> released)
>>> Set Netty version to "3.10.6.Final" which will be part of next release.
>>> See https://github.com/netty/netty/issues?q=milestone%3A3.10.6.Final and 
>>> https://github.com/akka/akka/pull/20857
>>> 
>>> HTH,
>>> 
>>> Guido.
>>> 
>>>> On Saturday, July 2, 2016 at 12:14:24 AM UTC+1, Eduardo Fernandes wrote:
>>>> Hi.
>>>> 
>>>> I'm using Akka 2.3.13, Java edition.
>>>> 
>>>> I'm making some performance tests and in the same machine with 8 cores I 
>>>> see that the serialization process is my bottleneck.  I know that because 
>>>> after an increment of actor cpu usage the throughput is exactly the same. 
>>>> 
>>>> My actor system talks to 2 other nodes so I see 2 cores dedicated to 
>>>> serialization. Is is possible to increase the number of threads for 
>>>> serialization?
>>>> 
>>>> I'm using standard Java serialization but I have my own serialization 
>>>> implementation in my write/readObject methods so I think that switching to 
>>>> kryo or similar will not enhance too much the throughput. 
>>>> 
>>>> Many thanks for your help.
>>>> 
>>>> /Eduardo
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/EVsIxMEDKeI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

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

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

[Eduardo Fernandes]

Ups... sorry for misunderstanding your question.

My principal problem is not the overhead itself. My problem is that I can't
get more threads serializing objects to a node. Example: one client I have
30%, lets say. If I add other client talking to other actor instance in
parallel I would expect around 60% cpu usage in my server (I have 6 threads
minimum and I'm pretty sure that the configuration would enable that from
workers and netty perspective).  Nevertheless I get around 40% of my 8
cores machine working. If I put the actors in different processes I get the
60% I was expecting. When I say server I mean an actorsystem process (a
single java process).

Thanks again for your help.

On Sun, Jul 3, 2016 at 11:55 AM, Viktor Klang <viktor.kl...@gmail.com>
wrote:

> Hi Eduardo,
>
> I meant the overhead of the Java Serialization envelope.
>
> On Sat, Jul 2, 2016 at 10:12 PM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Hi Viktor.
>>
>> I'm using basic (binary) serialization of basic Java types (int, String
>> (UTF), long, arrays of basic types, etc...).
>>
>> The overhead is that depending of internal values there is no send to
>> serialize some members and other not. If you merge your functional logic
>> with the serialization you can make optimizations that a generic serializar
>> can't do. Example. Suppose that if a member A has a null value you don't
>> have to serialize other member B. Maybe the member B you don't have to
>> serialize could have a null value which is fast to serialize but it is even
>> faster you don't have even to serialize the null. This type of overhead is
>> only possible if the serializer knows about your functional logic.
>>
>> Regards
>>
>> On Sat, Jul 2, 2016 at 10:05 PM, Viktor Klang <viktor.kl...@gmail.com>
>> wrote:
>>
>>> Hi Eduardo,
>>>
>>> Perhaps I misunderstood, what serialization format are you emitting in
>>> your readObject/writeObject?
>>> What overhead are you observing compared to using a custom Serializer?
>>>
>>> On Sat, Jul 2, 2016 at 10:02 PM, Eduardo Fernandes <edu...@gmail.com>
>>> wrote:
>>>
>>>> Hi.
>>>>
>>>> If you have writeObject/readObject defined in your class the Java plain
>>>> serialization will invoke those methods. In my case all my internal members
>>>> and class references are also serialized using the very same technique. So
>>>> this is equivalent to technologies like kryo and similars since there is no
>>>> overhead if you serialize basic members. In other words the pre-compiles
>>>> classes you get from kryo are already made so there is no performance
>>>> enhancement in this case. The big advantage of kryo is that you don't have
>>>> to create the writeObject/readObject by yourself. In my particular case
>>>> I've already done that job and my serialization is optimized in particular
>>>> cases where I don't have to serialize all members depending of my semantic.
>>>> I've made some tests and doing this way is faster than kryo but you have to
>>>> burn some calories implementing a optimized serialization code.
>>>>
>>>> Bests regards and thanks for your comment.
>>>>
>>>>
>>>> On Sat, Jul 2, 2016 at 9:27 PM, Viktor Klang <viktor.kl...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'm not sure I understand why write/readObject special methods would
>>>>> necessarily be faster? Most of the waste of Java Serialization is its
>>>>> envelopes and using class names etc.
>>>>>
>>>>> On Sat, Jul 2, 2016 at 1:14 AM, Eduardo Fernandes <edu...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I'm using Akka 2.3.13, Java edition.
>>>>>>
>>>>>> I'm making some performance tests and in the same machine with 8
>>>>>> cores I see that the serialization process is my bottleneck.  I know that
>>>>>> because after an increment of actor cpu usage the throughput is exactly 
>>>>>> the
>>>>>> same.
>>>>>>
>>>>>> My actor system talks to 2 other nodes so I see 2 cores dedicated to
>>>>>> serialization. Is is possible to increase the number of threads for
>>>>>> serialization?
>>>>>>
>>>>>> I'm using standard Java serialization but I have my own serialization
>>>>>> implement

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

[Eduardo Fernandes]

Quite clean. Many thanks Guido! I'll try it out. I have to inventory my
classes so it will take a while. I hope I'll have some numbers this night.

Anyway, kryo will scale vertically, I suppose. Will kryo use more threads
than I'm using right now?

Thanks again for your help and knowledge.

On Sun, Jul 3, 2016 at 2:13 PM, Guido Medina <oxyg...@gmail.com> wrote:

> I meant to say *"anything that implements Serializable"*
> The classes list is important as Kryo won't write class names on the
> messages but IDs of the classes:
>
> classes = [
>   "com.mypackage.Class1",
>   "com.mypackage.Class2"
> ]
>
> Suffice to say every node of the cluster must have the same IDs so that's
> some sort of configuration you agree upon.
> I find convenient to have a package in a "common" jar project with all the
> classes that I'm going to share (Serialize-ables)
> and a "common.conf" with Akka configuration, as I can build my final
> configuration by putting together Akka configurations,
> even using place holders, like this:
>
> config = parseFile(new File(configPath)).withFallback(parseResources(
> "common.conf"))...resolve();
>
> You can use that fallback call as many times as you wish and it won't to
> resolve place holders until you don't call resolve()
>
> HTH,
>
> Guido.
>
>
> On Sunday, July 3, 2016 at 12:57:21 PM UTC+1, Guido Medina wrote:
>>
>> I have mimic-ed your configuration and corrected some errors, also added
>> Kryo if you want to give it a chance with the configuration I believe will
>> do best.
>> I default the "java" serializer to Kryo, that way, everything that
>> inherits "Serializable" will use Kryo, also, I list every class that I care
>> (performance wise) under Kryo list.
>>
>> Hope this give you better result, also, don't underestimate the the
>> default mailbox you have commented out:
>>
>> akka {
>>   extensions =
>> ["com.romix.akka.serialization.kryo.KryoSerializationExtension$"]
>>
>>   actor {
>> provider = "akka.cluster.ClusterActorRefProvider"
>> serializers.java = "com.romix.akka.serialization.kryo.KryoSerializer"
>> default-mailbox.mailbox-type =
>> "akka.dispatch.SingleConsumerOnlyUnboundedMailbox"
>>
>> default-dispatcher {
>>   type = Dispatcher
>>   executor = "fork-join-executor"
>>
>>   fork-join-executor {
>> parallelism-min = 4
>> parallelism-factor = 1
>> parallelism-max = 8
>>   }
>> }
>>
>> kryo {
>>   kryo-reference-map = false
>>   idstrategy = "automatic"
>>   use-manifests = true
>>   buffer-size = 1024
>>   type = "nograph"
>>
>>   classes = [
>> "com.mypackage.Class1",
>> "com.mypackage.Class2"
>>   ]
>> }
>>   }
>>
>>   remote {
>> log-remote-lifecycle-events = off
>>
>> netty.tcp {
>>
>>   server-socket-worker-pool {
>> pool-size-min = 4
>> pool-size-factor = 1
>>     pool-size-max = 8
>>   }
>>
>>   client-socket-worker-pool {
>> pool-size-min = 4
>> pool-size-factor = 1
>> pool-size-max = 8
>>   }
>> }
>>
>> default-remote-dispatcher {
>>   type = Dispatcher
>>   executor = "fork-join-executor"
>>
>>   fork-join-executor {
>> parallelism-min = 4
>> parallelism-factor = 1
>> parallelism-max = 8
>>   }
>> }
>>   }
>>
>>   cluster {
>> metrics.enabled = off
>> jmx.enabled = off
>>   }
>> }
>>
>>
>>
>> On Sunday, July 3, 2016 at 12:45:57 PM UTC+1, Eduardo Fernandes wrote:
>>>
>>> I'm using the configuration below, following Guido suggestions.
>>>
>>> Anyway, everything behaves like Akka/netty add more communication
>>> threads only if a add more endpoints. Adding more actores talking from host
>>> 1 to host 2 is not improving throughput, despite of the available idle
>>> cpu's.  Does this make sense?
>>>
>>> Of course if my processing were not only dedicated to echo back some
>>> characters the processing cpu would hide the serialization performance. It
>>> just for find the maximum throughput (net performance) of a couple of
>>> actorsystem's.
>>>
&g

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

[Eduardo Fernandes]

I'm using the configuration below, following Guido suggestions.

Anyway, everything behaves like Akka/netty add more communication threads
only if a add more endpoints. Adding more actores talking from host 1 to
host 2 is not improving throughput, despite of the available idle cpu's.
Does this make sense?

Of course if my processing were not only dedicated to echo back some
characters the processing cpu would hide the serialization performance. It
just for find the maximum throughput (net performance) of a couple of
actorsystem's.

My topology is (attached file). Each client process has 10.000 internal
sync clients and uses a single thread to dispatch messages. A single client
reaches around 450.000/s and two reaches around 525.000/s. Each client
talks to a particular actor in host 2 which talks to a particular actor in
host 3.

Again, many thanks for your help.

Best regards.


[image: Inline image 1]


Again, many thanks for your help.

  actor {
provider = "akka.cluster.ClusterActorRefProvider"
default-dispatcher {
  throughput = 1024
 fork-join-executor {
parallelism-min = 6
parallelism-factor = 1
parallelism-max = 8
  }
}

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

  }
  remote {
log-remote-lifecycle-events = off
netty.tcp {
  tcp-nodelay = on
  write-buffer-high-water-mark = 4000b
  write-buffer-low-water-mark = 0b
  send-buffer-size = 4000b
  receive-buffer-size = 4000b

 server-socket-worker-pool {
pool-size-min = 4
pool-size-factor = 1
pool-size-max = 8
 }

 client-socket-worker-pool {
pool-size-min = 4
pool-size-factor = 1
pool-size-max = 8
 }
}
  }


On Sun, Jul 3, 2016 at 1:05 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

> Doesn't the classical remoting perform serialization within the single
> actor responsible for each connection?
>
> Sent from my iPhone
>
> On 03 Jul 2016, at 12:57, Viktor Klang <viktor.kl...@gmail.com> wrote:
>
> Eduardo, are you sure that there aren't any synchronized-blocks or locks
> used? (i.e. is this a contention problem rather than a paralellization
> problem?)
>
> On Sun, Jul 3, 2016 at 12:28 PM, Eduardo Fernandes <edu...@gmail.com>
> wrote:
>
>> Ups... sorry for misunderstanding your question.
>>
>> My principal problem is not the overhead itself. My problem is that I
>> can't get more threads serializing objects to a node. Example: one client I
>> have 30%, lets say. If I add other client talking to other actor instance
>> in parallel I would expect around 60% cpu usage in my server (I have 6
>> threads minimum and I'm pretty sure that the configuration would enable
>> that from workers and netty perspective).  Nevertheless I get around 40% of
>> my 8 cores machine working. If I put the actors in different processes I
>> get the 60% I was expecting. When I say server I mean an actorsystem
>> process (a single java process).
>>
>> Thanks again for your help.
>>
>> On Sun, Jul 3, 2016 at 11:55 AM, Viktor Klang <viktor.kl...@gmail.com>
>> wrote:
>>
>>> Hi Eduardo,
>>>
>>> I meant the overhead of the Java Serialization envelope.
>>>
>>> On Sat, Jul 2, 2016 at 10:12 PM, Eduardo Fernandes <edu...@gmail.com>
>>> wrote:
>>>
>>>> Hi Viktor.
>>>>
>>>> I'm using basic (binary) serialization of basic Java types (int, String
>>>> (UTF), long, arrays of basic types, etc...).
>>>>
>>>> The overhead is that depending of internal values there is no send to
>>>> serialize some members and other not. If you merge your functional logic
>>>> with the serialization you can make optimizations that a generic serializar
>>>> can't do. Example. Suppose that if a member A has a null value you don't
>>>> have to serialize other member B. Maybe the member B you don't have to
>>>> serialize could have a null value which is fast to serialize but it is even
>>>> faster you don't have even to serialize the null. This type of overhead is
>>>> only possible if the serializer knows about your functional logic.
>>>>
>>>> Regards
>>>>
>>>> On Sat, Jul 2, 2016 at 10:05 PM, Viktor Klang <viktor.kl...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Eduardo,
>>>>>
>>>>> Perhaps I misunderstood, what serialization format are you emitting in
>>>>> your readObject/writeObject?
>>>>> What overhead are you observing compared to using a custom Serializer?
>>>>>
>>>>> On Sat, Jul 2, 2016 at 10:02 PM, Eduardo Fe

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

[Eduardo Fernandes]

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
com.romix.akka.serialization.kryo.KryoSerializer.fromBinary(KryoSerializer.scala:239)
at
akka.serialization.Serialization$$anonfun$deserialize$1.apply(Serialization.scala:104)
at scala.util.Try$.apply(Try.scala:161)
at akka.serialization.Serialization.deserialize(Serialization.scala:98)
at akka.remote.MessageSerializer$.deserialize(MessageSerializer.scala:23)
at
akka.remote.DefaultMessageDispatcher.payload$lzycompute$1(Endpoint.scala:58)
at akka.remote.DefaultMessageDispatcher.payload$1(Endpoint.scala:58)
at akka.remote.DefaultMessageDispatcher.dispatch(Endpoint.scala:76)
at
akka.remote.EndpointReader$$anonfun$receive$2.applyOrElse(Endpoint.scala:929)
at akka.actor.Actor$class.aroundReceive(Actor.scala:467)
at akka.remote.EndpointActor.aroundReceive(Endpoint.scala:405)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
at akka.actor.ActorCell.invoke(ActorCell.scala:487)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
at akka.dispatch.Mailbox.run(Mailbox.scala:220)
at
akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Caused by: java.lang.NullPointerException
at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)
at java.util.ArrayList.ensureCapacity(Unknown Source)
at
com.esotericsoftware.kryo.serializers.CollectionSerializer.read(CollectionSerializer.java:96)
at
com.esotericsoftware.kryo.serializers.CollectionSerializer.read(CollectionSerializer.java:22)
at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
at
com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:106)
... 32 more

On Sun, Jul 3, 2016 at 3:43 PM, Eduardo Fernandes <edu...@gmail.com> wrote:

> Ok. Thanks again.
>
> I'll give it a try. I have to adapt our code a bit.
>
> Thanks for your time on this.
>
> El 3 jul 2016, a las 15:14, Guido Medina <oxyg...@gmail.com> escribió:
>
> *Correction:*
>
>- Kryo offers a pool that you can use if you use Kryo directly, kind
>of the recommended way of using it.
>- Akka Kryo uses a similar model giving you the choice of using your
>own queue implementation for its internal pool of instances, each instance
>is an Akka serializer with its Kryo plus other things.
>
> You can see the relevant Akka Kryo code for the pool in this commit/diff:
> https://github.com/romix/akka-kryo-serialization/commit/045cd27dfd01c2c41ab7c64bf6e25a63b3fd8e42
>
> Guido.
>
> On Sunday, July 3, 2016 at 1:47:45 PM UTC+1, Guido Medina wrote:
>>
>> Kryo and Akka Kryo don't use any threads, the remote-dispatcher is the
>> one doing the work,
>> and Netty threads sending/receiving the bytes from/to Akka remote
>> dispatcher as far as I can tell.
>>
>>

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

[Eduardo Fernandes]

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.

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 <oxyg...@gmail.com> 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
>> com.romix.akka.serialization.kryo.KryoSerializer.fromBinary(KryoSerializer.scala:239)
>> at
>> akka.serialization.Serialization$$anonfun$deserialize$1.apply(Serialization.scala:104)
>> at scala.util.Try$.apply(Try.scala:161)
>> at akka.serialization.Serialization.deserialize(Serialization.scala:98)
>> at akka.remote.MessageSerializer$.deserialize(MessageSerializer.scala:23)
>> at
>> akka.remote.DefaultMessageDispatcher.payload$lzycompute$1(Endpoint.scala:58)
>> at akka.remote.DefaultMessageDispatcher.payload$1(Endpoint.scala:58)
>> at akka.remote.DefaultMessageDispatcher.dispatch(Endpoint.scala:76)
>> at
>> akka.remote.EndpointReader$$anonfun$receive$2.applyOrElse(Endpoint.scala:929)
>> at akka.actor.Actor$class.aroundReceive(Actor.scala:467)
>> at akka.remote.EndpointActor.aroundReceive(Endpoint.scala:405)
>> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
>> at akka.actor.ActorCell.invoke(ActorCell.scala:487)

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 <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 <edu...@gmail.com>
> 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 <edu...@gmail.com>
>>> 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 <edu...@gmail.com>
>>>>> 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
>>>>> <https://github.com/akka/akka-meta/issues/22>. 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.
>>>

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 <patrik.nordw...@gmail.com>
wrote:

>
>
> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes <edu...@gmail.com>
> 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 <https://github.com/akka/akka-meta/issues/22>.
> 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 <oxyg...@gmail.com> 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.serializer

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 <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 <edu...@gmail.com>
> 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 <edu...@gmail.com>
>>> 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 <https://github.com/akka/akka-meta/issues/22>.
>>> 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 <oxyg...@gmail.com>
>>>> 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.
>>>>>>
>>>>&

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 <patrik.nordw...@gmail.com>
wrote:

>
>
> On Mon, Jul 4, 2016 at 9:13 AM, Eduardo Fernandes <edu...@gmail.com>
> 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 <edu...@gmail.com>
>>> 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 <edu...@gmail.com>
>>>>> 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 <edu...@gmail.com
>>>>>>> > 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.
>>>>&

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 <oxyg...@gmail.com> 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 <edu...@gmail.com>
>> 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 <https://github.com/akka/akka-meta/issues/22>.
>> 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 <oxy...@gmail.com> 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:
&g

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

[Eduardo Fernandes]

Hi.

I'm using Akka 2.3.13, Java edition.

I'm making some performance tests and in the same machine with 8 cores I 
see that the serialization process is my bottleneck.  I know that because 
after an increment of actor cpu usage the throughput is exactly the same. 

My actor system talks to 2 other nodes so I see 2 cores dedicated to 
serialization. Is is possible to increase the number of threads for 
serialization?

I'm using standard Java serialization but I have my own serialization 
implementation in my write/readObject methods so I think that switching to 
kryo or similar will not enhance too much the throughput. 

Many thanks for your help.

/Eduardo

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

[Eduardo Fernandes]

Hi again.

I'm talking about multiple data-centers, so reducing the chattiness will be 
very welcome.

The logic unit question is a bit open yet from our side. We're considering 
different scenarios. I can talk to you more privately later.

Anyway, do you consider that numbers from 20.000 to 50.000 could arise from 
your test? Do you expect number from this size more or less? (some 
positivism will be welcome :) )

Regards.



El jueves, 29 de junio de 2017, 20:06:44 (UTC+2), Konrad Malawski escribió:
>
> Are those in different data centers or one?
> We’re also working on multi-dc features, which limit the chatty-ness 
> between datacenters, allowing for even greater scalability.
>
> The interesting question to ask if they are indeed one logical unit and 
> clustering them all indeed is the thing to do or not.
> I would be interested in understanding your use case in more detail, can 
> you talk about it openly or would you prefer to talk in private, 
> if so please ping me on kt...@lightbend.com , thanks!
>
> — Konrad
>
>
> On 30 June 2017 at 02:59:12, Eduardo Fernandes (edu...@gmail.com 
> ) wrote:
>
> Hi Konrad. Thanks for the quick answer. 
>
> We're managing from 20.000 up to 50.000 nodes with 8 to 16 Gigs of RAM. In 
> fact we could adapt the architecture depending of Akka capacity but the 
> upper limiter in a cluster could oblige us to develop a kind of 
> inter-cluster communication channel or similar. 
>
> Thanks again.
>
> El jueves, 29 de junio de 2017, 19:45:45 (UTC+2), Konrad Malawski 
> escribió: 
>>
>> We’re currently preparing for such large-scale scalability test on the 
>> new remoting.
>> How many nodes are you expecting more or less from memory per user 
>> estimates etc?
>>
>> — Konrad
>>
>>
>> On 30 June 2017 at 02:43:43, Eduardo Fernandes (edu...@gmail.com) wrote:
>>
>> Hi all. 
>>
>> I'm starting a new project and I'm wondering about what is the 
>> recommended max number of nodes in an Akka cluster. I've read numbers 
>> around 2400 in this test 
>> <https://www.lightbend.com/blog/running-a-2400-akka-nodes-cluster-on-google-compute-engine>
>>  but 
>> with the new Artery architecture, based on UDP, I suppose that such limit 
>> should change. 
>> If we manage standard machines on a cloud environment it would be nice to 
>> have an idea of about how many nodes we could manage in a single Akka 
>> cluster.
>>
>> Many thanks in advance for any help on this.
>>
>> Regards.
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com .
> To post to this group, send email to akka...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: [akka-user] Max number of cluster nodes

[Eduardo Fernandes]

Correct, I'm talking about JVM's. Today we use 2 JVM's per machine (for 
actor hot backup).

Thanks.


El jueves, 29 de junio de 2017, 21:18:13 (UTC+2), Patrik Nordwall escribió:
>
> Are we talking about the same thing. When we say nodes we mean JVMs 
> (ActorSystem instances) and typically you would run one or a few JVMs on 
> one machine (EC2/GCE instance).
>
> Do you mean nodes in that sense, or do you mean actors?
>
> On Thu, Jun 29, 2017 at 8:15 PM, Eduardo Fernandes <edu...@gmail.com 
> > wrote:
>
>> Hi again.
>>
>> I'm talking about multiple data-centers, so reducing the chattiness will 
>> be very welcome.
>>
>> The logic unit question is a bit open yet from our side. We're 
>> considering different scenarios. I can talk to you more privately later.
>>
>> Anyway, do you consider that numbers from 20.000 to 50.000 could arise 
>> from your test? Do you expect number from this size more or less? (some 
>> positivism will be welcome :) )
>>
>> Regards.
>>
>>
>>
>> El jueves, 29 de junio de 2017, 20:06:44 (UTC+2), Konrad Malawski 
>> escribió:
>>>
>>> Are those in different data centers or one?
>>> We’re also working on multi-dc features, which limit the chatty-ness 
>>> between datacenters, allowing for even greater scalability.
>>>
>>> The interesting question to ask if they are indeed one logical unit and 
>>> clustering them all indeed is the thing to do or not.
>>> I would be interested in understanding your use case in more detail, can 
>>> you talk about it openly or would you prefer to talk in private, 
>>> if so please ping me on kt...@lightbend.com, thanks!
>>>
>>> — Konrad
>>>
>>>
>>> On 30 June 2017 at 02:59:12, Eduardo Fernandes (edu...@gmail.com) wrote:
>>>
>>> Hi Konrad. Thanks for the quick answer. 
>>>
>>> We're managing from 20.000 up to 50.000 nodes with 8 to 16 Gigs of RAM. 
>>> In fact we could adapt the architecture depending of Akka capacity but the 
>>> upper limiter in a cluster could oblige us to develop a kind of 
>>> inter-cluster communication channel or similar. 
>>>
>>> Thanks again.
>>>
>>> El jueves, 29 de junio de 2017, 19:45:45 (UTC+2), Konrad Malawski 
>>> escribió: 
>>>>
>>>> We’re currently preparing for such large-scale scalability test on the 
>>>> new remoting.
>>>> How many nodes are you expecting more or less from memory per user 
>>>> estimates etc?
>>>>
>>>> — Konrad
>>>>
>>>>
>>>> On 30 June 2017 at 02:43:43, Eduardo Fernandes (edu...@gmail.com) 
>>>> wrote:
>>>>
>>>> Hi all. 
>>>>
>>>> I'm starting a new project and I'm wondering about what is the 
>>>> recommended max number of nodes in an Akka cluster. I've read numbers 
>>>> around 2400 in this test 
>>>> <https://www.lightbend.com/blog/running-a-2400-akka-nodes-cluster-on-google-compute-engine>
>>>>  but 
>>>> with the new Artery architecture, based on UDP, I suppose that such limit 
>>>> should change. 
>>>> If we manage standard machines on a cloud environment it would be nice 
>>>> to have an idea of about how many nodes we could manage in a single Akka 
>>>> cluster.
>>>>
>>>> Many thanks in advance for any help on this.
>>>>
>>>> Regards.
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ: 
>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>> >>>>>>>>>> Search the archives: 
>>>> https://groups.google.com/group/akka-user
>>>> ---
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Akka User List" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to akka-user+...@googlegroups.com.
>>>> To post to this group, send email to akka...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: 

[akka-user] Max number of cluster nodes

[Eduardo Fernandes]

Hi all.

I'm starting a new project and I'm wondering about what is the recommended 
max number of nodes in an Akka cluster. I've read numbers around 2400 in this 
test 

 but 
with the new Artery architecture, based on UDP, I suppose that such limit 
should change. 
If we manage standard machines on a cloud environment it would be nice to 
have an idea of about how many nodes we could manage in a single Akka 
cluster.

Many thanks in advance for any help on this.

Regards.

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

[Eduardo Fernandes]

Hi Konrad. Thanks for the quick answer.

We're managing from 20.000 up to 50.000 nodes with 8 to 16 Gigs of RAM. In 
fact we could adapt the architecture depending of Akka capacity but the 
upper limiter in a cluster could oblige us to develop a kind of 
inter-cluster communication channel or similar. 

Thanks again.

El jueves, 29 de junio de 2017, 19:45:45 (UTC+2), Konrad Malawski escribió:
>
> We’re currently preparing for such large-scale scalability test on the new 
> remoting.
> How many nodes are you expecting more or less from memory per user 
> estimates etc?
>
> — Konrad
>
>
> On 30 June 2017 at 02:43:43, Eduardo Fernandes (edu...@gmail.com 
> ) wrote:
>
> Hi all. 
>
> I'm starting a new project and I'm wondering about what is the recommended 
> max number of nodes in an Akka cluster. I've read numbers around 2400 in this 
> test 
> <https://www.lightbend.com/blog/running-a-2400-akka-nodes-cluster-on-google-compute-engine>
>  but 
> with the new Artery architecture, based on UDP, I suppose that such limit 
> should change. 
> If we manage standard machines on a cloud environment it would be nice to 
> have an idea of about how many nodes we could manage in a single Akka 
> cluster.
>
> Many thanks in advance for any help on this.
>
> Regards.
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com .
> To post to this group, send email to akka...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>

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

[akka-user] Cluster: Loosing messages when rebalancing

[Eduardo Fernandes]

Hi all.

I'm using Akka 2.3.13 [I know... a bit old :(  ] with Java.

A few times I'm loosing messages (in a very intensive concurrent 
environment).  In my case a message is sent to the actor just before the 
postStop() method is called, indicating that the kill action is sent to it 
due the rebalancing logic. 

By documentation the PoisonPill is sent and the the ShardRegion actor 
(proxy) stop sending messages until the shard is completely rebalanced. 
 Following my traces the unique case I have where I loose a message is when 
I'm sending the message using the shard region actor which is physically in 
the same process where the destine actor is. I have an unique id in my 
messages the actor prints it on reception. Other commands sen't to the same 
actor from other nodes after rebalancing work fine. 

I suppose the command would be queued and then sent automatically after 
rebalancing but I can't observe this.

Have I to do something programmatically to make this work?

Many thanks in advance for any help

/Eduardo

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

[Eduardo Fernandes]

Absolutely clear.

Many thanks for your reply.

I'll check the persistence feature.

Best regards.

El lunes, 25 de septiembre de 2017, 15:02:40 (UTC+2), 
johannes...@lightbend.com escribió:
>
> Hi Eduardo,
>
> cluster sharding has at-most-once delivery (as most of Akka) so losing 
> some messages is to be expected. Persistent actor can opt-in to 
> at-least-once delivery (see 
> http://doc.akka.io/docs/akka/current/scala/persistence.html#at-least-once-delivery),
>  
> for other actors, you need to make sure to confirm and resend messages 
> manually.
>
> Johannes
>
> On Friday, September 22, 2017 at 6:02:48 PM UTC+2, Eduardo Fernandes wrote:
>>
>> Hi all.
>>
>> I'm using Akka 2.3.13 [I know... a bit old :(  ] with Java.
>>
>> A few times I'm loosing messages (in a very intensive concurrent 
>> environment).  In my case a message is sent to the actor just before the 
>> postStop() method is called, indicating that the kill action is sent to it 
>> due the rebalancing logic. 
>>
>> By documentation the PoisonPill is sent and the the ShardRegion actor 
>> (proxy) stop sending messages until the shard is completely rebalanced. 
>>  Following my traces the unique case I have where I loose a message is when 
>> I'm sending the message using the shard region actor which is physically in 
>> the same process where the destine actor is. I have an unique id in my 
>> messages the actor prints it on reception. Other commands sen't to the same 
>> actor from other nodes after rebalancing work fine. 
>>
>> I suppose the command would be queued and then sent automatically after 
>> rebalancing but I can't observe this.
>>
>> Have I to do something programmatically to make this work?
>>
>> Many thanks in advance for any help
>>
>> /Eduardo
>>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] Mixing shard regions and proxy to shards regions in the same actor system

[Eduardo Fernandes]

Hi all. I had this working with java version 2.3.13 and after moving to 
2.5.6 it stop working. Let me explain the topology.

In configuration I have

akka.cluster.sharding {
role = "backend"
}

Ok then. If in a process (frontend) I use startProxy and in other process 
(backend) I use start in ClusterSharding everything looks ok. My problems 
start with I have a more than one ShardRegion in the game:

1) client: starts two proxies for shards (A and B)
2) one server start A and get proxy for B
3) other server starts B and proxy to A

What I'm observing is that the client talks to A via proxy. The actor in 
server receives the request but when tries to send a copy to the other 
server using the corresponding proxy to B it never reaches the other server.

I'm observing this in the log:

[29/10/17 21:18:55:996 CET]  WARN sharding.ShardRegion: Trying to register 
to coordinator at 
[Some(ActorSelection[Anchor(akka://object-server-cluster/), 
Path(/system/sharding/processor-actor-1Coordinator/singleton/coordinator)])], 
but no acknowledgement. Total [475] buffered messages.

My code to create the shard regions:

if (isLocal) {
ClusterSharding.get(clusterSystem).start(shardingName, 
Props.create(ProcessorActor.class, this), settings, new MessageExtractor(),
allocationStrategy, 
PoisonPill.getInstance());
} else {
Optional role = Optional.of(CLUSTER_ROLE_BACKEND);
ClusterSharding.get(clusterSystem).startProxy(shardingName, 
role, new MessageExtractor());
}

and isLocal is true for region A in server 1 and for region B in server 2, 
and false of the other shard region in each server, as you can imagine. 

Maybe this kind of user case is not supported in 2.5.6 anymore? I'm pretty 
sure that is not the case but I can't find the right way to instance the 
shads.

Many thanks in advance for any help on this.

Regards.

/Eduardo

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

[Eduardo Fernandes]

Fine!! It works like a charm!!

Many thanks Patrik for your time on this!!

I'm attaching the code fixed with your comments.

Many thanks for your time on this. It was not clear for me that the role 
was mandatory. I supposed that a non-role means any. My fault.

Happy Halloween and thanks again!


El martes, 31 de octubre de 2017, 10:53:57 (UTC+1), Patrik Nordwall 
escribió:
>
> In that example you are not using roles at all, which I think is necessary.
> You need 3 roles: 
>
>- backend-0 where you start region-0, and start proxy for region-1 
>with role backend-1
>- backend-1 where you start region-1, and start proxy for region-0 
>with role backend-0
>- frontend where you start proxy for region-0 with role backend-0, and 
>proxy for region-1 with role backend-1
>
> /Patrik
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 2.5.8 (Java Edition) Error initializing: java.lang.IllegalStateException: not yet initialized

[Eduardo Fernandes]

Thank you very much Patrik.

I'll check.

Best regards.


On Mon, Jan 8, 2018 at 8:53 AM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> Konrad is right. That is not the correct line numbers for GraphStage.scala
> in akka-stream 2.5.8 and not 2.5.6 either, so check what akka-stream
> dependency you actually have on the classpath.
>
> On Mon, Jan 8, 2018 at 7:50 AM, Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> Are you not accidentally mixing Akka versions?
>> What does your dependency file look like with regards to Akka
>> dependencies.
>>
>> Akka Streams and Actor etc should all be on the same version.
>>
>> --
>> Cheers,
>> Konrad 'ktoso <http://kto.so>' Malawski
>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>
>> On January 7, 2018 at 20:28:58, Eduardo Fernandes (edu...@gmail.com)
>> wrote:
>>
>> Hi all.
>>
>> First of all: have all a happy new year.
>>
>> I just jumped out from Akka 2.5.6 to 2.5.8. From that I'm getting the
>> following error when starting Akka:
>>
>> java.lang.IllegalStateException: not yet initialized: only setHandler is
>> allowed in GraphStageLogic constructor
>> at akka.stream.stage.GraphStageLogic.interpreter(GraphStage.scala:295)
>> at akka.stream.stage.GraphStageLogic$$anon$1.invoke(GraphStage.scala:960)
>> at akka.remote.artery.InboundControlJunction$$anon$2.attach(
>> Control.scala:129)
>> at akka.remote.artery.ArteryTransport.runInboundControlStream(A
>> rteryTransport.scala:704)
>> at akka.remote.artery.ArteryTransport.runInboundStreams(ArteryT
>> ransport.scala:686)
>> at akka.remote.artery.ArteryTransport.start(ArteryTransport.scala:455)
>> at akka.remote.RemoteActorRefProvider.init(RemoteActorRefProvid
>> er.scala:212)
>> at akka.cluster.ClusterActorRefProvider.init(ClusterActorRefPro
>> vider.scala:31)
>> at akka.actor.ActorSystemImpl.liftedTree2$1(ActorSystem.scala:797)
>> at akka.actor.ActorSystemImpl._start$lzycompute(ActorSystem.scala:794)
>> at akka.actor.ActorSystemImpl._start(ActorSystem.scala:794)
>> at akka.actor.ActorSystemImpl.start(ActorSystem.scala:810)
>> at akka.actor.ActorSystem$.apply(ActorSystem.scala:244)
>> at akka.actor.ActorSystem$.apply(ActorSystem.scala:287)
>> at akka.actor.ActorSystem$.apply(ActorSystem.scala:262)
>> at akka.actor.ActorSystem$.create(ActorSystem.scala:190)
>> at akka.actor.ActorSystem.create(ActorSystem.scala)
>>
>>
>> If I switch back to 2.5.6 or 2.5.5 and the error disappears.  I've tried
>> with 2.5.7 and the error is still there. Looks like some new behavior in
>> 2.5.7.
>>
>> I'm using Artery:
>>
>>   remote {
>> log-remote-lifecycle-events = off
>> artery {
>>   enabled = on
>>   canonical.hostname = 127.0.0.1
>>   canonical.port = 0
>> }
>>   }
>>
>> Many thanks in advance for your help!
>>
>>
>>
>>
>>
>>
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+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/c
>> urrent/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+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 2.5.8 (Java Edition) Error initializing: java.lang.IllegalStateException: not yet initialized

[Eduardo Fernandes]

 
Fixed. As you've said there was a mix in initialization. I was using 
persistence jdbc version 3.0.0 which loaded an old version of the stream 
jar. After changing to 3.1.0 the problem was fixed. 

Many thanks for you time Patrik.

Regards.

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

[Eduardo Fernandes]

https://ukutabs.com/o/oasis/wonderwall/?transpose=-2#point

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To 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.