[akka-user] Re: shutdown hook within Tomcat

[Guido Medina]

For Tomcat 7 and up it is very easy with Servlet 3.0 specification, 
basically you create create a listener and annotate it, then just add your 
shutdown code in the context destroyed method:

Explained with one example 
here: http://www.codejava.net/java-ee/servlet/weblistener-annotation-examples

-- 
  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] Re: Is there a way to broadcast to all sharded entities of a given type?

[Guido Medina]

Yeah, in Akka Cluster-Sharding you also have regions which I think you can 
use to broadcast messages to actors living in such region, a region will 
likely be spread between distinct nodes.
I use Akka Cluster roles because I have an admin node that keeps track of 
each supervisor's actor and a router by type to broadcast to them.

On Wednesday, June 3, 2015 at 2:57:45 PM UTC+1, Justin du coeur wrote:

 After 2+ years, I'm finally beginning the process of moving Querki from 
 single-node to properly clustered.  I believe Cluster Sharding is going to 
 be at the heart of that: Querki is mostly a big cloud of troupes, one for 
 each Space, and I believe that each of those troupes corresponds nicely to 
 a Shard Entity.

 I'm going through my code now, and figuring out how to evolve to using 
 Sharding, and the first question that comes up is: can I send a message to 
 all of these entities in some fashion?  This is mainly for monitoring -- 
 one message in my current SpaceManager (which I plan on replacing with the 
 Shard system) is GetSpaceStatus; this gets forwarded to all 
 currently-instantiated Spaces, so they can report back with a monitor 
 update.

 Is there a way to do this currently?  I'm not seeing anything obvious in 
 the sharding code, but I'm just starting on this...


-- 
  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: Is there a way to broadcast to all sharded entities of a given type?

[Guido Medina]

No so automated but I do this with specific supervisor actors that are 
subscribed to cluster events.

So I have broadcast routers that are kept updated, so when some event happens I 
just use the router.

-- 
  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: Is there a way to broadcast to all sharded entities of a given type?

[Guido Medina]

Cluster node has roles, and cluster events can keep your broadcast routers 
updated, so you could broadcast a message to a role.

-- 
  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] Re: Multiple dispatcher vs multiple actor system in one application

[Guido Medina]

But you need to read at least the first 3 parts of Java General 
documentation *-there is a Scala counterpart of course-*, since the answers 
are clearly there:

   - *Introduction:*
http://doc.akka.io/docs/akka/2.3.11/intro/index-java.html
   - *General:* http://doc.akka.io/docs/akka/2.3.11/general/index.html
   - *Actors:* http://doc.akka.io/docs/akka/2.3.11/java/index-actors.html

If you read these 3 parts *-you can skim thru the 1st one but it has some 
good concepts which you might not know-* I can assure you the answers to 
most of your questions will be there.

HTH.

http://doc.akka.io/docs/akka/2.3.11/general/index.html

On Tuesday, June 9, 2015 at 2:37:31 AM UTC+1, Maatary Okouya wrote:

 Hi, 

 I am wondering what would be the criteria to choose between having several 
 actor systems in one application over having multiple dispatcher ? 

 What are the consequence of multiple actor system vs multiple dispatcher ? 
 ( or advantage) 



-- 
  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] Re: shutdown hook within Tomcat

[Guido Medina]

Like you would reference any other singleton instance, as a static variable 
for example, ActorSystem is a heavy object so it is recommended to have 
just one per JVM anyway.

-- 
  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] Re: Multiple dispatcher vs multiple actor system in one application

[Guido Medina]

The documentation clearly says that ActorSystem is a heavy object and that 
should be treated as a Singleton instance per JVM, you can have as many 
dispatchers as you need to cover specialized tasks.

-- 
  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] Re: Integrating different Bounded Contexts

[Guido Medina]

I'm building a FX trading OMS and I have signals, strategies, accounts and 
orders, they all run on a different JVM and each have a distribution type 
like SINGLETON, SHARDED or ROUND_ROBIN, they communicate with each other 
because they are part of the Akka cluster, so each has a separate Actor 
System of course, the system was designed with scalability and 
microservices.

The power of Akka is the actor system and message passing, why would you 
want to add yet another messaging to redo what they do already?, a bit more 
of my workflow so that you can see how similar is my workflow with yours:

   - A trade capture comes from some source, each source is an actor 
   managing an alien connection (QuickFIX/J)
   - The signal if valid it is sent to the strategy router (ROUND_ROBIN)
   - The strategy decides how many orders it needs to build and each is 
   sent to the order components, each order component is an actor.
   - The order is receive and a persistor is created which is a child of 
   that order target which keeps the status being inserted, once the order is 
   completed (or failed), the persistor actor dies.

How does one cluster knows where another component is located? I have my 
cluster events which each time a microservice comes up, it informs all of 
the other microservices and each has its own ActorRef cache (located by 
type of component and ID which is an integer) so there isn't network cost 
when locating an actor and proxying between components is very minimal 
because there are no intermediaries to deliver my messages.

Hope this design helps you with yours, of course, I have spent a couple of 
months building all the business logic and my own sharding for my specific 
domain but so far I have no complains, I'm planning to add Hazelcast maybe, 
if I need some message resilience in the future, but that's a maybe.

-- 
  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] Java: Closing on context() at anonymous class

[Guido Medina]

Hi,

I have the following method which creates a FixInitiator which is part of 
another multi-threaded framework I have no control, the client is started 
inside an actor which its children are named and located by a generated 
UUID.

I have read that passing the context to another thread is not safe but when 
you look at the Scala code, the context is lazily initialized, if it was 
initialized already, doesn't that make this code OK?

The method fromApp(...) is re-actively called back from another thread when 
a FIX message comes into the system, so far this is working for me without 
any issues, but maybe it is because I have called context() already for 
this actor before I reach the anonymous class declaration at the preStart() 
method?

*Note:* The call to super.preStart() is because the actor is inheriting 
from another Abstract type of actor with some template methods pattern.
  
  @Override
  public void preStart() throws Exception {
initiator = new FixInitiator(entity, log, order) {
  @Override
  public void fromApp(Message message, SessionID sessionId) throws 
FieldNotFound {
if (message instanceof ExecutionReport) {
  final String uuid = message.getString(ClOrdID.FIELD);
  final OptionActorRef orderPersistor = *context**()*.child(uuid);
  if (orderPersistor.isDefined()) {
orderPersistor.get().tell(message, noSender());
  } else {
log.error(Order persistor for  + uuid +  doesn't exist or 
has expired);
  }
} else {
  unhandled(message);
}
  }
};
initiator.start();
super.preStart();
  }

-- 
  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] Re: Akka and DDD - Business Space to Solution Space for Bounded Context

[Guido Medina]

Is this a duplicate? I have spent sometime answering your other thread

-- 
  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] Re: Integrating different Bounded Contexts

[Guido Medina]

Some clarification on my previous posts:

   - *Akka cluster:* My cluster events was a typo, I meant that I use 
   Akka cluster and each microservice is subscribed to the cluster events so 
   every time one actor system comes up, it knows about the other actor 
   systems and a handshake with cache exchanges is initiated, that's only when 
   the cluster is changing because it might be expensive -sending 
   MapsInteger, ActorRef-
   - *Initial communication and how to inform other components:* Say you 
   have /orderManager, /someOtherService which are the main supervisors of 
   each microservice, you can pass messages to these main supervisors remotely 
   and then locally forward it to the intended destination, Akka 
   Remote/Cluster actor provider can help you with that, though I have a 
   bigger cache, I have caches for say order target ID 10 which lives at 
   /order/order_10 which is a friendly path for my system so I don't need to 
   talk to /order at all, I talk to /order only to inform about system changes 
   like, add/remove to/from your cache.
   - *Queues:* Remember each actor has a mailbox which is a queue, so if 
   you have actors processing a message at a time you can use 
   SingleConsumerOnlyMailbox which will give you a nice performance.
   - *Convention:* You can have a common dependency with all types of 
   messages you want to pass between components, that convention will help you 
   keep track of what you are passing, I have messages like 
   SupervisorCommandT, QueryRequestT, QueryResponseT, etc etc, or simply 
   Json, because I'm using Kryo I'm not worry about serialization, my messages 
   are very small anyway.

Sorry for my very long post, just trying to give you a full picture of the 
whole thing.

-- 
  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] Re: Integrating different Bounded Contexts

[Guido Medina]

No, I have a single cluster, each micro-service is an Akka system that is 
subscribed to cluster events and once a system is up, it sends a message to 
every other node saying, hey, I'm here, lets exchange information, call it, 
synchronizing their cache.

Risky?, Akka follow the let-it-crash philosophy which has been proven to be 
very safe in Erlang in the Telecom industry and Akka cluster uses gossip 
protocol so I'm relaying on an existing functionality to keep my systems 
updated.

If you are not going to send messages (remotely) between systems then why 
use Akka at all? It is like, oh, I like Akka but I don't want to use its 
messaging system. That being the case then people should be afraid of CAP 
theorems, CRDTs, eventual consistent data and just use the good old 
messaging systems like RabbitMQ and relational DBs, etc, but then, they are 
not that safe anyway.

I have my system running on a controlled environment and in production now 
for almost a month and I haven't lost a message, the bugs I have fixed have 
been related with my own code. Network failures are going to happen and in 
that case any system can fail so risk is only a relative word.

On Friday, June 5, 2015 at 12:21:36 PM UTC+1, wonderful world wrote:

 I have a BillingManager Bounded Context (DDD concept) whose job is to 
 charge the user for the orders they have placed. There is an OrderManager 
 that places the orders. They exist in two different Bounded Contexts. 

 As per the DDD, one Bounded Context should interact with another Bounded 
 Context via messages or events only. I'm trying to understand the right 
 pattern for the integration of these BCs. Is the right pattern (1) the 
 OrderManager and the BillingManager live in the same actor system and they 
 interact each other via pub-sub? (2) OrderManager and BillingManager exist 
 in two actor systems, and the OrderManager actor system TELL the Billing 
 Manager to process the order (3) introduce a Bus or Queue so the 
 OrderManager queue up the orders and the BillingManager poll the queue to 
 retrieve orders and process them?

 What would you suggest?



-- 
  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] Re: Comparing Akka with Quasar.

[Guido Medina]

I don't have an answer nor time to respond to a blog comparison, but if you 
google Akka vs Quasar you will find plenty of opinions and depending on 
what you want or need to hear you will make your decision, now, in a 
nutshell:

*Typesafe is a great, innovative and more matured company which hasn't 
being trying to re-invent the wheel* so if I were you I would go for their 
products' line.

Spark is built on top of Akka and Spark streaming might be what you need, 
you are the owner of your prototype, your code and you know the details of 
your data access patterns so I think you can answer that better than any of 
us by doing your homework and reading thru the products and the 
documentation, I can only point you into the right direction but I cannot 
digest the answers for you, the following link will give you everything you 
need to get you started and probably finish your project:

https://www.typesafe.com/community/other-projects/apache-spark


That link has definitions, examples, documentations and videos.

HTH.

-- 
  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] Re: How to instantiate an actor system from spring.

[Guido Medina]

If you are starting Spring within Tomcat I would recommend you to have the 
Spring programmatic-ally created and instantiated via @WebListener, then 
create your @Bean method returning your singleton ActorSystem, within your 
method you can tweak aspects like configuration, where to load it from, etc 
etc

On Tuesday, June 9, 2015 at 10:50:11 PM UTC+1, Maatary Okouya wrote:

 Hi, I do not wished to instantiate actor from the bean, but just an actor 
 system. 


 The only solution i see so far is to wrap, the actor system in an 
 ActorSystemBen and provide a getActorsystem method to it. The point is, 
 from this bean i can call  ActorSystem()  apply method. 


 Is there something more elegant or better ?


 Best, 

 M


-- 
  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 config file with a jar used as dependency

[Guido Medina]

The class loader effect, precedence, naming and how to load a custom 
configuration is very well explained at the end of the Akka documentation 
general section:

http://doc.akka.io/docs/akka/2.3.11/general/configuration.html

HTH

-- 
  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] Re: How to instantiate an actor system from spring.

[Guido Medina]

A better example:

  
@Configuration
public class SpringWebAppInitializer implements WebApplicationInitializer {

// Ugly but you don't have many options here, maybe a volatile?
// Just make sure you don't use this context before it is initialized,
// timing will be an issue, I have been there.
public static AnnotationConfigWebApplicationContext APPLICATION_CONTEXT 
= null;

@Override
public void onStartup(ServletContext container) throws ServletException 
{ 
APPLICATION_CONTEXT = new AnnotationConfigWebApplicationContext();
// Basically point to the same class that is also a web application 
initializer.
appContext.register(SpringWebAppInitializer.class);
}
 
@Bean
public ActorSystem actorSystem() { 
...
}
}

-- 
  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] Re: How to instantiate an actor system from spring.

[Guido Medina]

Pay attention to the WebListener class and @Configuration annotation, my 
recommendation would be to use both on the same class, create a static 
spring context which is the one you will use later to locate the spring 
beans including the ActorSystem which will have a signature like:

@Bean
public ActorSystem actorSystem() {
   
}


*Source:*
 
http://www.codejava.net/frameworks/spring/bootstrapping-a-spring-web-mvc-application-programmatically

-- 
  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] Java/Akka API: Is it really necessary?

[Guido Medina]

Hi,

I have been using Akka now for three months now and one thing that got my 
attention in a very good way is the fact that you can use Scala methods and 
functions from Java, then I wonder:

   - Is it really necessary to have an Akka Java API for Java developers in 
   general?
   - I have not much experience with Java-to-Scala combination but I have 
   noticed the doc in Java say for example getContext() vs Scala context(), in 
   my project I'm using context(), self(), sender() just like you would do in 
   Scala and it just works.

Why bother maintaining a Java API that is most likely to be outdated or 
miss something the next day?
Even from the documentation point of view, it makes things more difficult 
to understand and slower to document.

I'm not saying to remove the ability to use Akka from Java but to force 
Java developers to use the same API even if it is Java convention breaking.
There is no point and not even in the Java world we appreciate to be so 
tied up with get... prefix so why bother?

*The last and probably the most important question here:* If you eliminate 
the Java API that is designed to be Java's convention friendly, would Akka 
miss any functionality for Java developers?
Maybe at the beginning from an acceptance point of view you wanted to be 
Java's friendly, guess what, it is more annoying to try to follow an 
obsolete convention than forcing us to evolve and move forward.

Maybe this is deeper than just Akka but Scala in general if it becomes more 
Java 8 friendly and for example pass a Java 8 lambda expression to a Scala 
method expecting a Scala trait *-or whatever is called-*
I don't really know which is why I would like to know your opinion about 
this.

-- 
  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] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

You can set context time out for actors, if they don't receive a message 
within some time passivate them, activate them at login, that way you don't 
have to lazy load when the player is active but at login which will 
basically happen asynchronously.

Now, Akka experts should tell us if setting context timeout for many active 
actors is a bad idea.

HTH,

Guido.

On Thursday, June 18, 2015 at 8:57:30 AM UTC+1, Amir Karimi wrote:

  Hi,

 I'm working on a simple MMO game as a side project which is like Travian 
 https://en.wikipedia.org/wiki/Travian. I've decided to use Akka as the 
 game back-end, so I would like to share my design with you. Your 
 suggestions and feedbacks are very appreciated.

 Each of the following entities are modeled as an actor:
 - Player
 - Village
 - Building of a village
 - etc.

 Villages have some resources which are constantly decreasing or increasing 
 based on multiple factors like buildings level, village population, etc. 
 (Clearly, I'm not going to change the resource values periodically but I 
 save the last resource value, its time and the coefficient of increase or 
 decrease.)

 Each player may have multiple villages. As villages can be conquered by 
 other players, each village has an state for it's owner player (e.g. 
 playerId or playerActorRef) and also a player has a list of his/her own 
 villages (village actors or IDs).

 Each village may contains multiple buildings. As buildings won't be moved 
 and owned by other villages, they will be created as village actor 
 children. So the buildings will communicate with their village through 
 `context.parent`.

 For persisting the game world state I'm going to use Akka persistence 
 module.

 This is the fundamental of my design although I have several concerns:

- I'm not sure if players profile information should be stored into 
the database or into the player actors (as states). 
- According to 80/20 rule, I except 80% of the players to be much less 
active than the others but their corresponding actors are still resident 
 in 
the memory even if they have no activity at all. What are the best 
practices to reduce the RAM usage for those? 
- How can I show the statics and other information in the admin panel? 
For example I want to be able to search among players and get their 
information. I know I can use actorSelection with wildcard but what about 
data pagination? I'm not going to load all players information.
 
 First of all please let me know if this is a good idea to use actors for 
 such project. I'm not sure if this approach will make things more complex 
 or simpler.

 Thanks a lot,
 Amir
  

-- 
  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] Re: Java: Single consumer dispatch to router vs Future

[Guido Medina]

Assume the following is the default mailbox:

akka.actor.default-mailbox.mailbox-type = 
akka.dispatch.SingleConsumerOnlyUnboundedMailbox



On Thursday, June 25, 2015 at 2:20:01 PM UTC+1, Guido Medina wrote:

 Hi,

 I have an scenario where all messages come to a single main actor and such 
 actor in my previous version was processing each message in a Future, 
 realistically speaking I wouldn't expect to be processing more than CPUs 
 messages concurrently, but I need the main actor to dispatch such messages 
 ASAP to a processor, so I have a very simple round robin router that has 
 all the created processor actors.

 Do you think that will scale better than using Futures if, say, I have a 
 high burst of messages?

 Here is a fragment of my main actor:

   ...
   ...

   private final Router strategyProcessors;

   public StrategySupervisor() {
 strategyProcessors = new Router(new RoundRobinRoutingLogic(), 
 IntStream.range(0, Runtime.getRuntime().availableProcessors()).
   mapToObj(i - new ActorRefRoutee(context().actorOf(Props.create(new 
 StrategyProcessorCreator(this).
   collect(Collectors.toList())
 );
   }

   @Override
   protected ChildActorCreatorInteger, Strategy, StrategySupervisor, 
 StrategyProcessor creator(Strategy strategy) {
 return new StrategyProcessorCreator(this);
   }

   // Called by onReceive(...), part of a template pattern.
   @Override
   protected void processMessage(Object message) {
 if (message instanceof FixSignal) {
   strategyProcessors.route(message, noSender());
 } else {
   unhandled(message);
 }
   }

   ...
   ...



-- 
  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] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

You can activate an actor if not present, as long as you send the message 
to its supervisor, so you have to keep say, supervisors per zone? and each 
supervisor will try to send/forward the message to such child and if not 
present create it.

This is an example in Java where I do the same thing for account, the 
accounts actors are not eagerly created but on demand, the following method 
is inside the supervisor actor class:

private void applyToAccount(Currency currency, BalanceOperation operation) {
final ActorContext context = context();
context.child(currency.code).
  getOrElse(new AbstractFunction0ActorRef() {
@Override
public ActorRef apply() {
  return context.actorOf(balancePersistorProps(currency), currency.
code);
}
  }).tell(operation, noSender());
  }

HTH,

Guido.

On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote:

 I think It's not enough. There are events which will happen when the user 
 is not logged in. For example an attack on a village (which its owner is 
 inactive) or occupation of that village also generates a message to the 
 owner player actor (which is not resident) as well. So I can't activate 
 them just at login times.

 On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote:

 You can set context time out for actors, if they don't receive a message 
 within some time passivate them, activate them at login, that way you don't 
 have to lazy load when the player is active but at login which will 
 basically happen asynchronously.

 Now, Akka experts should tell us if setting context timeout for many 
 active actors is a bad idea.

 HTH,

 Guido.

 On Thursday, June 18, 2015 at 8:57:30 AM UTC+1, Amir Karimi wrote:

  Hi,

 I'm working on a simple MMO game as a side project which is like Travian 
 https://en.wikipedia.org/wiki/Travian. I've decided to use Akka as 
 the game back-end, so I would like to share my design with you. Your 
 suggestions and feedbacks are very appreciated.

 Each of the following entities are modeled as an actor:
 - Player
 - Village
 - Building of a village
 - etc.

 Villages have some resources which are constantly decreasing or 
 increasing based on multiple factors like buildings level, village 
 population, etc. (Clearly, I'm not going to change the resource values 
 periodically but I save the last resource value, its time and the 
 coefficient of increase or decrease.)

 Each player may have multiple villages. As villages can be conquered by 
 other players, each village has an state for it's owner player (e.g. 
 playerId or playerActorRef) and also a player has a list of his/her own 
 villages (village actors or IDs).

 Each village may contains multiple buildings. As buildings won't be 
 moved and owned by other villages, they will be created as village actor 
 children. So the buildings will communicate with their village through 
 `context.parent`.

 For persisting the game world state I'm going to use Akka persistence 
 module.

 This is the fundamental of my design although I have several concerns:

- I'm not sure if players profile information should be stored into 
the database or into the player actors (as states). 
- According to 80/20 rule, I except 80% of the players to be much 
less active than the others but their corresponding actors are still 
resident in the memory even if they have no activity at all. What are 
 the 
best practices to reduce the RAM usage for those? 
- How can I show the statics and other information in the admin 
panel? For example I want to be able to search among players and get 
 their 
information. I know I can use actorSelection with wildcard but what 
 about 
data pagination? I'm not going to load all players information.
 
 First of all please let me know if this is a good idea to use actors for 
 such project. I'm not sure if this approach will make things more complex 
 or simpler.

 Thanks a lot,
 Amir
  


-- 
  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: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

Say you don't have zones or any sort of grouping, you need at least one 
supervisor, I wouldn't recommend you to make all your players top level 
actors where their parent is /user, you need a fast way to locate a 
player and context().child(...) is such way IMHO, sharding with persistent 
actor is another way which was mentioned but it adds more complexity to 
your design, you don't need to de-activate actors though, maybe you just 
lazy load them with the method I gave you but again, you need one 
supervisor, you will be surprise how many millions of actors you can hold 
in memory, do you have millions of players?

If so then you are rich and we are talking of distributed gaming and stuff 
:D

On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote:

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason why I decided to use Akka is to make things simpler. For 
 example I believe Akka would help me to handle the game entity states in a 
 very simple and concise way. But it introduces new concerns about RAM 
 usage. It can be handled with the help of Akka persistence and supervisors 
 although it's not as simple as I thought.

 On 06/19/2015 11:40 AM, Guido Medina wrote:
  
 You can activate an actor if not present, as long as you send the message 
 to its supervisor, so you have to keep say, supervisors per zone? and each 
 supervisor will try to send/forward the message to such child and if not 
 present create it. 

  This is an example in Java where I do the same thing for account, the 
 accounts actors are not eagerly created but on demand, the following method 
 is inside the supervisor actor class:

   private void applyToAccount(Currency currency, BalanceOperation 
 operation) {
 final ActorContext context = context();
 context.child(currency.code).
   getOrElse(new AbstractFunction0ActorRef() {
 @Override
 public ActorRef apply() {
   return context.actorOf(balancePersistorProps(currency), currency
 .code);
 }
   }).tell(operation, noSender());
   }
  
  HTH,

  Guido.

 On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote: 

  I think It's not enough. There are events which will happen when the 
 user is not logged in. For example an attack on a village (which its owner 
 is inactive) or occupation of that village also generates a message to the 
 owner player actor (which is not resident) as well. So I can't activate 
 them just at login times.
  
 On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote: 

 You can set context time out for actors, if they don't receive a message 
 within some time passivate them, activate them at login, that way you don't 
 have to lazy load when the player is active but at login which will 
 basically happen asynchronously. 

  Now, Akka experts should tell us if setting context timeout for many 
 active actors is a bad idea.

  HTH,

  Guido.

 On Thursday, June 18, 2015 at 8:57:30 AM UTC+1, Amir Karimi wrote: 

  Hi,

 I'm working on a simple MMO game as a side project which is like 
 Travian https://en.wikipedia.org/wiki/Travian. I've decided to use 
 Akka as the game back-end, so I would like to share my design with you. 
 Your suggestions and feedbacks are very appreciated.

 Each of the following entities are modeled as an actor:
 - Player
 - Village
 - Building of a village
 - etc.

 Villages have some resources which are constantly decreasing or 
 increasing based on multiple factors like buildings level, village 
 population, etc. (Clearly, I'm not going to change the resource values 
 periodically but I save the last resource value, its time and the 
 coefficient of increase or decrease.)

 Each player may have multiple villages. As villages can be conquered by 
 other players, each village has an state for it's owner player (e.g. 
 playerId or playerActorRef) and also a player has a list of his/her own 
 villages (village actors or IDs).

 Each village may contains multiple buildings. As buildings won't be 
 moved and owned by other villages, they will be created as village actor 
 children. So the buildings will communicate with their village through 
 `context.parent`.

 For persisting the game world state I'm going to use Akka persistence 
 module.

 This is the fundamental of my design although I have several concerns:

- I'm not sure if players profile information should be stored into 
the database or into the player actors (as states). 
- According to 80/20 rule, I except 80% of the players to be much 
less active than the others but their corresponding actors are still 
resident in the memory even if they have no activity at all. What are 
 the 
best practices to reduce the RAM usage for those? 
- How can I show

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

Trust me you don't want to do concurrency by yourself even if you are an 
expert at it, asynchronous design is the way to go, with Akka that concern 
is easy enough and you will be able to focus only on the business logic and 
produce results, the last thing I'm going to Advice you is to not 
underestimate the documentation, specially the first 3 parts, I had to 
learn Akka in few weeks and that helped me the most to the point that I had 
no question but only the tricky ones.

On Friday, June 19, 2015 at 2:06:48 PM UTC+1, Amir Karimi wrote:

 These technologies and architectures are so appealing to me but I'm still 
 in doubt  whether I should follow these interesting approaches or just make 
 a traditional software (with a monolithic database-driven model). Although 
 this is a side project, it's very important to me. I should get it done.

 Anyway, thanks a lot Guido for your kind advices. 

 On 06/19/2015 05:19 PM, Guido Medina wrote:
  
 And don't worry about performance, assuming each shard has a pattern of 
 Single Consumer - Multiple Producer, make sure the inbox type for shards 
 and players is SingleConsumerOnlyMailbox which is a the fastest Akka 
 mailbox atm.

 On Friday, June 19, 2015 at 1:43:46 PM UTC+1, Guido Medina wrote: 

 If your number of shards is high enough and your hashcode is smart enough 
 coalitions should be very minimal, I think you should have stats of how 
 many players you have per shard and how busy shards get, and between 
 restarts *-maintenance time-*, redo your numbers and hashcode formulas, 
 otherwise you will have to do what hash maps implementations do when there 
 are to many coalitions which is to redistribute all the shards, up to you 
 which one you go for, I would say, pick a high number of shards like 1024, 
 then you will have avg of 50 players per shard.

 On Friday, June 19, 2015 at 1:26:51 PM UTC+1, Amir Karimi wrote: 

 Yes that would be easy and scalable!  Just out of curiosity, what if a 
 zone get too active? In another world how can we have asymmetric zones so 
 that we can balance zones pressure by moving active players between them.

 The first thing that comes to mind is that players shouldn't have any idea 
 about the zone their live in. Whenever we need to find out a player zone we 
 send a message to all zones asking about the player and wait for the 
 response from the zone in which the player actor lives. The problem is that 
 the player may have been moved to another zone in the middle of the finding 
 process :(

 It seems like the cellular mobile network. How can they find the BTS to 
 which my phone is connected?

 On 06/19/2015 04:31 PM, Guido Medina wrote:
  
 Do you have player IDs? design your application to have zones divided by a 
 number -preferably a power of 2-, say, 64, now you have 64 evenly 
 distributed shards so to send a message to player ID = 1001 then you just 
 need to 1001 mod shards, no look up needed, it is just a convention you are 
 using.

 On Friday, June 19, 2015 at 12:37:43 PM UTC+1, Amir Karimi wrote: 

 Yes it would be very nice. But I have no idea how to find a player zone. 
 Suppose player A want to attack player B. First we need to find out the 
 player B zone (to find it's supervisor). Right? Then we need an actor which 
 knows about the players zone. That would be the bottleneck again.

 On 06/19/2015 04:00 PM, Guido Medina wrote:
  
 Nvm, that would run into the same problem, instead, eagerly load the 
 player's zone -a supervisor for a bunch of players- and then lazily load 
 the player per zone, that will keep your actors distributed and also will 
 prepare your code to use these zones as shards when the game grows.

 On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote: 

 You could even have the concept of lazily load the zone and each zone 
 lazily load the players.

 On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote: 

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor. 

  There is another detail though, for the sake of concurrent delivery 
 under high load, you would be receiving all messages at that one 
 supervisor, do you think that will scale well? say you have 1000 attacks, 
 you will have to forward one at a time, so the concept of zone -think of it 
 as a shard or hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote: 

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

Nvm, that would run into the same problem, instead, eagerly load the 
player's zone -a supervisor for a bunch of players- and then lazily load 
the player per zone, that will keep your actors distributed and also will 
prepare your code to use these zones as shards when the game grows.

On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote:

 You could even have the concept of lazily load the zone and each zone 
 lazily load the players.

 On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor.

 There is another detail though, for the sake of concurrent delivery under 
 high load, you would be receiving all messages at that one supervisor, do 
 you think that will scale well? say you have 1000 attacks, you will have to 
 forward one at a time, so the concept of zone -think of it as a shard or 
 hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote:

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K 
 at max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote: 

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason why I decided to use Akka is to make things simpler. For 
 example I believe Akka would help me to handle the game entity states in a 
 very simple and concise way. But it introduces new concerns about RAM 
 usage. It can be handled with the help of Akka persistence and supervisors 
 although it's not as simple as I thought.

 On 06/19/2015 11:40 AM, Guido Medina wrote:
  
 You can activate an actor if not present, as long as you send the 
 message to its supervisor, so you have to keep say, supervisors per zone? 
 and each supervisor will try to send/forward the message to such child and 
 if not present create it. 

  This is an example in Java where I do the same thing for account, the 
 accounts actors are not eagerly created but on demand, the following 
 method 
 is inside the supervisor actor class:

   private void applyToAccount(Currency currency, BalanceOperation 
 operation) {
 final ActorContext context = context();
 context.child(currency.code).
   getOrElse(new AbstractFunction0ActorRef() {
 @Override
 public ActorRef apply() {
   return context.actorOf(balancePersistorProps(currency), 
 currency.code);
 }
   }).tell(operation, noSender());
   }
  
  HTH,

  Guido.

 On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote: 

  I think It's not enough. There are events which will happen when the 
 user is not logged in. For example an attack on a village (which its 
 owner 
 is inactive) or occupation of that village also generates a message to 
 the 
 owner player actor (which is not resident) as well. So I can't activate 
 them just at login times.
  
 On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote: 

 You can set context time out for actors, if they don't receive a 
 message within some time passivate them, activate them at login, that 
 way 
 you don't have to lazy load when the player is active but at login which 
 will basically happen asynchronously. 

  Now, Akka experts should tell us if setting context timeout for 
 many active actors is a bad idea.

  HTH,

  Guido.

 On Thursday, June 18, 2015 at 8

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

If your number of shards is high enough and your hashcode is smart enough 
coalitions should be very minimal, I think you should have stats of how 
many players you have per shard and how busy shards get, and between 
restarts *-maintenance time-*, redo your numbers and hashcode formulas, 
otherwise you will have to do what hash maps implementations do when there 
are to many coalitions which is to redistribute all the shards, up to you 
which one you go for, I would say, pick a high number of shards like 1024, 
then you will have avg of 50 players per shard.

On Friday, June 19, 2015 at 1:26:51 PM UTC+1, Amir Karimi wrote:

 Yes that would be easy and scalable!  Just out of curiosity, what if a 
 zone get too active? In another world how can we have asymmetric zones so 
 that we can balance zones pressure by moving active players between them.

 The first thing that comes to mind is that players shouldn't have any idea 
 about the zone their live in. Whenever we need to find out a player zone we 
 send a message to all zones asking about the player and wait for the 
 response from the zone in which the player actor lives. The problem is that 
 the player may have been moved to another zone in the middle of the finding 
 process :(

 It seems like the cellular mobile network. How can they find the BTS to 
 which my phone is connected?

 On 06/19/2015 04:31 PM, Guido Medina wrote:
  
 Do you have player IDs? design your application to have zones divided by a 
 number -preferably a power of 2-, say, 64, now you have 64 evenly 
 distributed shards so to send a message to player ID = 1001 then you just 
 need to 1001 mod shards, no look up needed, it is just a convention you are 
 using.

 On Friday, June 19, 2015 at 12:37:43 PM UTC+1, Amir Karimi wrote: 

 Yes it would be very nice. But I have no idea how to find a player zone. 
 Suppose player A want to attack player B. First we need to find out the 
 player B zone (to find it's supervisor). Right? Then we need an actor which 
 knows about the players zone. That would be the bottleneck again.

 On 06/19/2015 04:00 PM, Guido Medina wrote:
  
 Nvm, that would run into the same problem, instead, eagerly load the 
 player's zone -a supervisor for a bunch of players- and then lazily load 
 the player per zone, that will keep your actors distributed and also will 
 prepare your code to use these zones as shards when the game grows.

 On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote: 

 You could even have the concept of lazily load the zone and each zone 
 lazily load the players.

 On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote: 

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor. 

  There is another detail though, for the sake of concurrent delivery 
 under high load, you would be receiving all messages at that one 
 supervisor, do you think that will scale well? say you have 1000 attacks, 
 you will have to forward one at a time, so the concept of zone -think of it 
 as a shard or hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote: 

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K at 
 max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote: 

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

And don't worry about performance, assuming each shard has a pattern of 
Single Consumer - Multiple Producer, make sure the inbox type for shards 
and players is SingleConsumerOnlyMailbox which is a the fastest Akka 
mailbox atm.

On Friday, June 19, 2015 at 1:43:46 PM UTC+1, Guido Medina wrote:

 If your number of shards is high enough and your hashcode is smart enough 
 coalitions should be very minimal, I think you should have stats of how 
 many players you have per shard and how busy shards get, and between 
 restarts *-maintenance time-*, redo your numbers and hashcode formulas, 
 otherwise you will have to do what hash maps implementations do when there 
 are to many coalitions which is to redistribute all the shards, up to you 
 which one you go for, I would say, pick a high number of shards like 1024, 
 then you will have avg of 50 players per shard.

 On Friday, June 19, 2015 at 1:26:51 PM UTC+1, Amir Karimi wrote:

 Yes that would be easy and scalable!  Just out of curiosity, what if a 
 zone get too active? In another world how can we have asymmetric zones so 
 that we can balance zones pressure by moving active players between them.

 The first thing that comes to mind is that players shouldn't have any 
 idea about the zone their live in. Whenever we need to find out a player 
 zone we send a message to all zones asking about the player and wait for 
 the response from the zone in which the player actor lives. The problem is 
 that the player may have been moved to another zone in the middle of the 
 finding process :(

 It seems like the cellular mobile network. How can they find the BTS to 
 which my phone is connected?

 On 06/19/2015 04:31 PM, Guido Medina wrote:
  
 Do you have player IDs? design your application to have zones divided by 
 a number -preferably a power of 2-, say, 64, now you have 64 evenly 
 distributed shards so to send a message to player ID = 1001 then you just 
 need to 1001 mod shards, no look up needed, it is just a convention you are 
 using.

 On Friday, June 19, 2015 at 12:37:43 PM UTC+1, Amir Karimi wrote: 

 Yes it would be very nice. But I have no idea how to find a player zone. 
 Suppose player A want to attack player B. First we need to find out the 
 player B zone (to find it's supervisor). Right? Then we need an actor which 
 knows about the players zone. That would be the bottleneck again.

 On 06/19/2015 04:00 PM, Guido Medina wrote:
  
 Nvm, that would run into the same problem, instead, eagerly load the 
 player's zone -a supervisor for a bunch of players- and then lazily load 
 the player per zone, that will keep your actors distributed and also will 
 prepare your code to use these zones as shards when the game grows.

 On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote: 

 You could even have the concept of lazily load the zone and each zone 
 lazily load the players.

 On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote: 

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor. 

  There is another detail though, for the sake of concurrent delivery 
 under high load, you would be receiving all messages at that one 
 supervisor, do you think that will scale well? say you have 1000 attacks, 
 you will have to forward one at a time, so the concept of zone -think of it 
 as a shard or hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote: 

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K at 
 max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

50K is like zero for current and modern hardware, so, I would say, load 
them lazily from your players' supervisor and don't expire them until you 
start seeing a problem, expiring them would require you only to set context 
time out at preStart() and then handle the timeout message which would be 
to just send a poison pill to your actor.

There is another detail though, for the sake of concurrent delivery under 
high load, you would be receiving all messages at that one supervisor, do 
you think that will scale well? say you have 1000 attacks, you will have to 
forward one at a time, so the concept of zone -think of it as a shard or 
hash- is not a bad idea, a way to minimize coalition.

On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote:

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K at 
 max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote: 

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason why I decided to use Akka is to make things simpler. For 
 example I believe Akka would help me to handle the game entity states in a 
 very simple and concise way. But it introduces new concerns about RAM 
 usage. It can be handled with the help of Akka persistence and supervisors 
 although it's not as simple as I thought.

 On 06/19/2015 11:40 AM, Guido Medina wrote:
  
 You can activate an actor if not present, as long as you send the message 
 to its supervisor, so you have to keep say, supervisors per zone? and each 
 supervisor will try to send/forward the message to such child and if not 
 present create it. 

  This is an example in Java where I do the same thing for account, the 
 accounts actors are not eagerly created but on demand, the following method 
 is inside the supervisor actor class:

   private void applyToAccount(Currency currency, BalanceOperation 
 operation) {
 final ActorContext context = context();
 context.child(currency.code).
   getOrElse(new AbstractFunction0ActorRef() {
 @Override
 public ActorRef apply() {
   return context.actorOf(balancePersistorProps(currency), 
 currency.code);
 }
   }).tell(operation, noSender());
   }
  
  HTH,

  Guido.

 On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote: 

  I think It's not enough. There are events which will happen when the 
 user is not logged in. For example an attack on a village (which its owner 
 is inactive) or occupation of that village also generates a message to the 
 owner player actor (which is not resident) as well. So I can't activate 
 them just at login times.
  
 On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote: 

 You can set context time out for actors, if they don't receive a 
 message within some time passivate them, activate them at login, that way 
 you don't have to lazy load when the player is active but at login which 
 will basically happen asynchronously. 

  Now, Akka experts should tell us if setting context timeout for many 
 active actors is a bad idea.

  HTH,

  Guido.

 On Thursday, June 18, 2015 at 8:57:30 AM UTC+1, Amir Karimi wrote: 

  Hi,

 I'm working on a simple MMO game as a side project which is like 
 Travian https://en.wikipedia.org/wiki/Travian. I've decided to use 
 Akka as the game back-end, so I would like to share my design with you. 
 Your suggestions and feedbacks are very appreciated.

 Each of the following entities are modeled as an actor:
 - Player
 - Village
 - Building of a village
 - etc.

 Villages have some resources which are constantly decreasing or 
 increasing based on multiple factors like buildings

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

Another option, if you don't have player ID but a sort of ID as string, 
say, attach player oxygen8, get the hash of that string and apply the 
same formula, so you have 64 shards, so the supervisor of that player is 
oxygen8.hashCode() % 64

On Friday, June 19, 2015 at 1:01:00 PM UTC+1, Guido Medina wrote:

 Do you have player IDs? design your application to have zones divided by a 
 number -preferably a power of 2-, say, 64, now you have 64 evenly 
 distributed shards so to send a message to player ID = 1001 then you just 
 need to 1001 mod shards, no look up needed, it is just a convention you are 
 using.

 On Friday, June 19, 2015 at 12:37:43 PM UTC+1, Amir Karimi wrote:

 Yes it would be very nice. But I have no idea how to find a player zone. 
 Suppose player A want to attack player B. First we need to find out the 
 player B zone (to find it's supervisor). Right? Then we need an actor which 
 knows about the players zone. That would be the bottleneck again.

 On 06/19/2015 04:00 PM, Guido Medina wrote:
  
 Nvm, that would run into the same problem, instead, eagerly load the 
 player's zone -a supervisor for a bunch of players- and then lazily load 
 the player per zone, that will keep your actors distributed and also will 
 prepare your code to use these zones as shards when the game grows.

 On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote: 

 You could even have the concept of lazily load the zone and each zone 
 lazily load the players.

 On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote: 

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor. 

  There is another detail though, for the sake of concurrent delivery 
 under high load, you would be receiving all messages at that one 
 supervisor, do you think that will scale well? say you have 1000 attacks, 
 you will have to forward one at a time, so the concept of zone -think of it 
 as a shard or hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote: 

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K at 
 max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote: 

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason why I decided to use Akka is to make things simpler. For 
 example I believe Akka would help me to handle the game entity states in a 
 very simple and concise way. But it introduces new concerns about RAM 
 usage. It can be handled with the help of Akka persistence and supervisors 
 although it's not as simple as I thought.

 On 06/19/2015 11:40 AM, Guido Medina wrote:
  
 You can activate an actor if not present, as long as you send the message 
 to its supervisor, so you have to keep say, supervisors per zone? and each 
 supervisor will try to send/forward the message to such child and if not 
 present create it. 

  This is an example in Java where I do the same thing for account, the 
 accounts actors are not eagerly created but on demand, the following method 
 is inside the supervisor actor class:

   private void applyToAccount(Currency currency, BalanceOperation 
 operation) {
 final ActorContext context = context();
 context.child(currency.code).
   getOrElse(new AbstractFunction0ActorRef() {
 @Override
 public ActorRef apply

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

You could even have the concept of lazily load the zone and each zone 
lazily load the players.

On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor.

 There is another detail though, for the sake of concurrent delivery under 
 high load, you would be receiving all messages at that one supervisor, do 
 you think that will scale well? say you have 1000 attacks, you will have to 
 forward one at a time, so the concept of zone -think of it as a shard or 
 hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote:

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K at 
 max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote: 

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason why I decided to use Akka is to make things simpler. For 
 example I believe Akka would help me to handle the game entity states in a 
 very simple and concise way. But it introduces new concerns about RAM 
 usage. It can be handled with the help of Akka persistence and supervisors 
 although it's not as simple as I thought.

 On 06/19/2015 11:40 AM, Guido Medina wrote:
  
 You can activate an actor if not present, as long as you send the 
 message to its supervisor, so you have to keep say, supervisors per zone? 
 and each supervisor will try to send/forward the message to such child and 
 if not present create it. 

  This is an example in Java where I do the same thing for account, the 
 accounts actors are not eagerly created but on demand, the following method 
 is inside the supervisor actor class:

   private void applyToAccount(Currency currency, BalanceOperation 
 operation) {
 final ActorContext context = context();
 context.child(currency.code).
   getOrElse(new AbstractFunction0ActorRef() {
 @Override
 public ActorRef apply() {
   return context.actorOf(balancePersistorProps(currency), 
 currency.code);
 }
   }).tell(operation, noSender());
   }
  
  HTH,

  Guido.

 On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote: 

  I think It's not enough. There are events which will happen when the 
 user is not logged in. For example an attack on a village (which its owner 
 is inactive) or occupation of that village also generates a message to the 
 owner player actor (which is not resident) as well. So I can't activate 
 them just at login times.
  
 On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote: 

 You can set context time out for actors, if they don't receive a 
 message within some time passivate them, activate them at login, that way 
 you don't have to lazy load when the player is active but at login which 
 will basically happen asynchronously. 

  Now, Akka experts should tell us if setting context timeout for many 
 active actors is a bad idea.

  HTH,

  Guido.

 On Thursday, June 18, 2015 at 8:57:30 AM UTC+1, Amir Karimi wrote: 

  Hi,

 I'm working on a simple MMO game as a side project which is like 
 Travian https://en.wikipedia.org/wiki/Travian. I've decided to use 
 Akka as the game back-end, so I would like to share my design with you. 
 Your suggestions and feedbacks are very appreciated.

 Each of the following entities are modeled as an actor

Re: [akka-user] Re: Modeling a simple MMO game entities as actors? Is it OK?

[Guido Medina]

Do you have player IDs? design your application to have zones divided by a 
number -preferably a power of 2-, say, 64, now you have 64 evenly 
distributed shards so to send a message to player ID = 1001 then you just 
need to 1001 mod shards, no look up needed, it is just a convention you are 
using.

On Friday, June 19, 2015 at 12:37:43 PM UTC+1, Amir Karimi wrote:

 Yes it would be very nice. But I have no idea how to find a player zone. 
 Suppose player A want to attack player B. First we need to find out the 
 player B zone (to find it's supervisor). Right? Then we need an actor which 
 knows about the players zone. That would be the bottleneck again.

 On 06/19/2015 04:00 PM, Guido Medina wrote:
  
 Nvm, that would run into the same problem, instead, eagerly load the 
 player's zone -a supervisor for a bunch of players- and then lazily load 
 the player per zone, that will keep your actors distributed and also will 
 prepare your code to use these zones as shards when the game grows.

 On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote: 

 You could even have the concept of lazily load the zone and each zone 
 lazily load the players.

 On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote: 

 50K is like zero for current and modern hardware, so, I would say, load 
 them lazily from your players' supervisor and don't expire them until you 
 start seeing a problem, expiring them would require you only to set context 
 time out at preStart() and then handle the timeout message which would be 
 to just send a poison pill to your actor. 

  There is another detail though, for the sake of concurrent delivery 
 under high load, you would be receiving all messages at that one 
 supervisor, do you think that will scale well? say you have 1000 attacks, 
 you will have to forward one at a time, so the concept of zone -think of it 
 as a shard or hash- is not a bad idea, a way to minimize coalition.

 On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote: 

  You're absolutely right. I need at least one supervisor (or maybe two; 
 one for players and one for villages as they are top level actors). This 
 way I can deactivate and lazy load them as you said.

 And yes I don't have millions of players :D but I hope some day I'll ;)

 But seriously, as I won't have millions of users (I'm planning for 50K at 
 max) what about keeping all actors in memory? It will make everything 
 easier and faster.

 On 06/19/2015 03:05 PM, Guido Medina wrote:
  
 Say you don't have zones or any sort of grouping, you need at least one 
 supervisor, I wouldn't recommend you to make all your players top level 
 actors where their parent is /user, you need a fast way to locate a 
 player and context().child(...) is such way IMHO, sharding with persistent 
 actor is another way which was mentioned but it adds more complexity to 
 your design, you don't need to de-activate actors though, maybe you just 
 lazy load them with the method I gave you but again, you need one 
 supervisor, you will be surprise how many millions of actors you can hold 
 in memory, do you have millions of players? 

  If so then you are rich and we are talking of distributed gaming and 
 stuff :D

 On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote: 

  Thanks Guido, this is good idea but as I'm not going to make this game 
 distributed (at least in the near future) I feel this approach increases 
 the complexity and I don't know what would I get instead of this 
 complexity? (except for RAM usage optimization)

 The reason why I decided to use Akka is to make things simpler. For 
 example I believe Akka would help me to handle the game entity states in a 
 very simple and concise way. But it introduces new concerns about RAM 
 usage. It can be handled with the help of Akka persistence and supervisors 
 although it's not as simple as I thought.

 On 06/19/2015 11:40 AM, Guido Medina wrote:
  
 You can activate an actor if not present, as long as you send the message 
 to its supervisor, so you have to keep say, supervisors per zone? and each 
 supervisor will try to send/forward the message to such child and if not 
 present create it. 

  This is an example in Java where I do the same thing for account, the 
 accounts actors are not eagerly created but on demand, the following method 
 is inside the supervisor actor class:

   private void applyToAccount(Currency currency, BalanceOperation 
 operation) {
 final ActorContext context = context();
 context.child(currency.code).
   getOrElse(new AbstractFunction0ActorRef() {
 @Override
 public ActorRef apply() {
   return context.actorOf(balancePersistorProps(currency), currency
 .code);
 }
   }).tell(operation, noSender());
   }
  
  HTH,

  Guido.

 On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote: 

  I think It's not enough. There are events which will happen when the 
 user is not logged

[akka-user] Re: Spray Client (i.e. AKKA) within Tomcat, cause Threading issue

[Guido Medina]

Did you shutdown ActorSystem at some post context destroyed class? You can 
add that to the same class of the previous question but just shutting down 
spring context and at the @Bean annotation state what shutdown method 
ActorSystem uses:

@Bean(destroyMethod=shutdown)

-- 
  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] Spray Client (i.e. AKKA) within Tomcat, cause Threading issue

[Guido Medina]

Yeah, I'm helping you because I have been in your shoes where legacy code 
cannot be just deleted, I'll guess you are the new guy that can't change 
things drastically...

The problem you are facing is complex and simple at the same time, you have 
Tomcat as container and Spring as DI so questions:

   - What do you need Tomcat for?
   - What do you need Spring for?
   - Spray client in Scala on top of Tomcat, why?
   - And finally, what are you using Akka for?

Now you need to think of the life cycle which Servlet 3.0 has one you can 
use:

*Context created method:* start your Spring context.
*Context destroyed method:* stop your Spring context.

When you stop Spring, it will stop all beans running in it if they have 
defined a destroy method, the destroy method needs to be declared for beans 
that need some sort of resources clean up like data sources, actor systems, 
thread pools, etc etc.

HTH

On Wednesday, June 10, 2015 at 6:23:47 PM UTC+1, Brian Topping wrote:

 I'm going to guess you don't find solutions because this is about the 
 point of discovery that most people dump these mixed environments. Probably 
 not what you want to hear, but not saying anything is just as bad.

 It's death by a thousand cuts. It all works in the large, but the cost of 
 these smaller issues doesn't necessarily have the payback you might 
 initially imagine. Since you're one of a likely small group of people doing 
 these things, there's simply a lot fewer people that can help you, 
 including running it in large deployments that resolve corner cases before 
 you get your own code into critical production requirements.

 It's a tale of caution, that's all.

 On Jun 10, 2015, at 10:11 AM, Maatary Okouya maatar...@gmail.com 
 javascript: wrote:

 I am using spray client i.e. akka within a Tomcat webApp.

 While I do properly destroy the actor system on tomcat shutdown via 
 spring, i'm nevertheless still facing this threading issue.

 I found that this issue was already reported few years ago Tomcat 
 complaints when re-deploying servlet with akka inside 
 https://www.assembla.com/spaces/akka/tickets/2672#/activity/ticket:, 
 but could not find the solution for it

 I'm using the default spray-client configuration.

 here is the error that i get when i stop tomcat. (Sorry for the amount of 
 information but i try to give as much clue as possible)

 10-Jun-2015 12:54:22.516 WARNING [localhost-startStop-1] 
 org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
 web application [ROOT] appears to have started a thread named 
 [PoolPartyConnector-ActorSystem-scheduler-1] but has failed to stop it. 
 This is very likely to create a memory leak.

 Stack trace of thread: java.lang.Thread.sleep(Native Method) 
 akka.actor.LightArrayRevolverScheduler.waitNanos(Scheduler.scala:226) 
 akka.actor.LightArrayRevolverScheduler$$anon$8.nextTick(Scheduler.scala:405) 
 akka.actor.LightArrayRevolverScheduler$$anon$8.run(Scheduler.scala:375) 
 java.lang.Thread.run(Thread.java:745)

 10-Jun-2015 12:54:22.516 WARNING [localhost-startStop-1] 
 org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
 web application [ROOT] appears to have started a thread named 
 [PoolPartyConnector-ActorSystem-akka.actor.default-dispatcher-2] but has 
 failed to stop it. This is very likely to create a memory leak. Stack trace 
 of thread: sun.misc.Unsafe.park(Native Method) 
 scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2075) 
 scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) 
 scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

 10-Jun-2015 12:54:22.516 WARNING [localhost-startStop-1] 
 org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
 web application [ROOT] appears to have started a thread named 
 [PoolPartyConnector-ActorSystem-akka.actor.default-dispatcher-3] but has 
 failed to stop it. This is very likely to create a memory leak. Stack trace 
 of thread: 
 akka.actor.dungeon.DeathWatch$class.watchingContains(DeathWatch.scala:73) 
 akka.actor.dungeon.DeathWatch$class.watchedActorTerminated(DeathWatch.scala:54)
  
 akka.actor.ActorCell.watchedActorTerminated(ActorCell.scala:369) 
 akka.actor.ActorCell.invokeAll$1(ActorCell.scala:455) 
 akka.actor.ActorCell.systemInvoke(ActorCell.scala:478) 
 akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:263) 
 akka.dispatch.Mailbox.processMailbox(Mailbox.scala:241) 
 akka.dispatch.Mailbox.run(Mailbox.scala:220) 
 akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
  
 scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) 
 scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
  
 scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) 
 scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

 10-Jun-2015 12:54:22.517 WARNING 

[akka-user] Re: Akka 2.4 milestones, RC and final release ETAs?

[Guido Medina]

Hi Patrik,

Fair enough, I know there is lot of work to be done which makes it harder 
to estimate hence the question.

Do you happen to know anything about the Akka remote direction/status? 
AFAIK it is been replaced/rewritten with Akka I/O

Best regards,

Guido.

On Saturday, June 13, 2015 at 8:03:42 PM UTC+1, Guido Medina wrote:

 Hi,

 Just wondering what are the ETAs on Akka 2.4-M2, RCs and final?

 Best regards,

 Guido.


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

[akka-user] Re: Integrating different Bounded Contexts

[Guido Medina]

On Monday, June 15, 2015 at 1:57:23 PM UTC+1, Carsten Saathoff wrote:

 Am Samstag, 6. Juni 2015 00:24:16 UTC+2 schrieb Guido Medina:

 No, I have a single cluster, each micro-service is an Akka system that is 
 subscribed to cluster events and once a system is up, it sends a message to 
 every other node saying, hey, I'm here, lets exchange information, call it, 
 synchronizing their cache.


 The draw back here is that having microservices within a single akka 
 cluster results in strong coupling between the services. All nodes need to 
 share at least the message classes that are used within an exchange. Of 
 course one could configure the serializer to work around that with 
 protobuf, e.g., but using REST APIs or message queues in between basically 
 result in higher decoupling of the microservices for less effort. And that 
 is usually something that you want. One often mentioned advantage of 
 microservice architectures is independence of the technology stack, which 
 is something that is sacrificed if we use Akka Cluster as the microservice 
 platform.


Yes, I use a common project for things like that, but you can always 
fallback to Json and send/receive byte[] messages using Json with Jackson 
Smiley for an even faster performance, that's what I used do when I used 
RMQ, Hazelcast and JMS in general.
Each project is different, I'm the only developer on my company at the 
moment so cost wise it was very easy for me to create a template Main class 
that starts the micro-service and join the cluster, create the deployables 
and have a friendly start/stop via standard JVM execution inside IntelliJ 
so for me, that type of semi-automatic cluster came handy for me and 
friendly of development is very valuable, I hate such development 
environments that to test/run something you have to follow 1000 steps, 
maybe I'm lazy :(

 

 If you are not going to send messages (remotely) between systems then why 
 use Akka at all? It is like, oh, I like Akka but I don't want to use its 
 messaging system. That being the case then people should be afraid of CAP 
 theorems, CRDTs, eventual consistent data and just use the good old 
 messaging systems like RabbitMQ and relational DBs, etc, but then, they are 
 not that safe anyway.


 Akka has other advantages than sending messages remotely. I would even 
 argue that there are much better approaches to sending messages around 
 remotely than using Akka. But, how do you guarantee message delivery? Do 
 you handle that in your application? Is that an issue at all in your 
 application? What do you do if one microservice is not available, i.e., how 
 do you ensure resilience?


 I don't, if I can't deliver a message in time in the industry my 
application is built for I can't retry, I just fail-fast and report the 
error though it has never happened, there are pros and cons in the system I 
have built, like, adding nodes to the cluster will rebalance sharded 
components *-best efforts to keep order of supervisors associated with list 
of  actors, I have my own sharding based on IDs that is fed via Cluster 
events-* and load-balanced components so my application is not so much 
designed for resiliency *-for now, I will add Hazelcast on top of the Akka 
cluster, so each Akka node will also be a Hazelcast node-*

 

 I have my system running on a controlled environment and in production 
 now for almost a month and I haven't lost a message, the bugs I have fixed 
 have been related with my own code. Network failures are going to happen 
 and in that case any system can fail so risk is only a relative word.


 My personal experience with Akka Cluster is that sending around large 
 amounts of messages between nodes will result in an unstable cluster. This 
 was also discussed in different threads on this mailing list. The messages 
 between nodes always go over the default TCP connection between different 
 actor systems. If that connection is occupied with application messages, it 
 means that system messages will take longer until received often rendering 
 the cluster instable. IIRC it was even a suggestion by the Akka team to use 
 a dedicated connection channel (e.g. HTTP or TCP via akka-io) to send 
 around large volumes of application messages.


My main problem is not with Akka cluster, I think that has been improved a 
lot, at least from version 2.3.11 and on, my main problem is with Akka 
remote that for such a great toolkit like Akka, I consider Akka remote 
extremely slow but I'm not giving up my hope on it, I can't, time is not on 
my side so I'll have to work around it somehow.


 Akka Cluster is great technology, specifically features like cluster 
 sharding and the cluster singleton are extremely useful. But when it comes 
 to communicating between microservices, I usually use HTTP or queues like 
 RabbitMQ and Kafka, as they are technology independent, allow for loose 
 coupling of the microservices, and provide for additional features

Re: [akka-user] Re: Akka 2.4 milestones, RC and final release ETAs?

[Guido Medina]

Hi Hepin,

I explored a bit the code on github and noticed you don't have default 
setting for Netty server/client pools like Akka remote, are these also 
needed for Netty 4.1.x?
Are you more comfortable with Netty 4.1.X.Beta than 4.0.X.Final? I think 
the issues you might be facing are because you jumped 2 versions straight 
and I know API changed from 4.0.x to 4.1.x
I'm sure you are doing that for a good reason, Netty guys tend improve by a 
considerable factor the performance between versions.

Best regards,

Guido.

On Monday, June 15, 2015 at 2:02:59 PM UTC+1, 何品 wrote:

 Hi,the code on github is what we used in the last production,and the code 
 is more like a POC,but we use it in production and works well.

 after I knew that akka is going to implement the akka remoting via akka 
 stream and akka io.I reimplement it and split it to akka-io-netty and then 
 implement the transport based on the io extension.

 in the new way I did not use the bootstrap and user event trigger and 
 mainly implemented all the command what akka io tcp have,and I tried to 
 implement the domain socket too. 
 and it is more like an POC too,but we are using the new implement now.

 as the akka remoting is going to using akka stream and the akka stream 
 it's self is based on the akka io extension,so I think this would be the 
 right direction.

 one problem of the current SPI is that you don't know when to do a 
 flushwrite don't auto flush in netty4,and you have to using a tick to do 
 the flush or trigger a flush every time you do write akk writeAndFlush.And 
 the current SPI is a little complicate too.


 在 2015年6月15日星期一 UTC+8下午6:51:06，Guido Medina写道：

 Hi Hepin,

 Thanks for your response, what does that mean exactly?
 Is it your extension going a workaround for Akka remote or are you 
 actually talking about the new Akka remote?

 Best regards,

 Guido.

 On Monday, June 15, 2015 at 11:02:39 AM UTC+1, Patrik Nordwall wrote:

 2.4-M2 should be out this week or early next week.

 We don't have an ETA of 2.4-RC yet, but we are working hard on making it 
 happen as soon as possible. It might be possible in August, but I can't 
 promise anything.

 /Patrik

 On Mon, Jun 15, 2015 at 7:12 AM, 何品 hepi...@gmail.com wrote:

 I have build a new one via io extension,and maybe opensource when it is 
 more complete.
 the code there is deprecated.
 and I will try to build the io extension via akka stream too.

 ```

 import java.net.InetSocketAddress

 import akka.actor.{ Actor, ActorLogging, Props }
 import akka.io.IO
 import qgame.akka.extension.netty.transport.tcp.Tcp
 import qgame.akka.extension.netty.transport.{ Bind, Bound, Connected }

 /**
  * Created by kerr.
  */
 class ServerActor extends Actor with ActorLogging {

   override def receive: Receive = {
 case Bound(address) =
   log.debug(bound :[{}], address)
 case Connected(remoteAddress, localAddress) =
   val connector = sender()
   log.debug(connected,remote :[{}],local :[{}],connector :[{}], 
 remoteAddress, localAddress, connector)
   context.actorOf(Props.create(classOf[ConnectionHandler], connector, 
 remoteAddress, localAddress))

   }

   @throws[Exception](classOf[Exception])
   override def preStart(): Unit = {
 import context.system
 val manager = IO(Tcp)
 manager ! Bind(self, new InetSocketAddress(9000))
 super.preStart()
   }
 }

 ```
 在 2015年6月14日星期日 UTC+8上午4:07:05，Guido Medina写道：

 Also, I would like to know what's the status of the new Akka remote 
 using Akka I/O, I was trying to use the Netty 4 implementation from Hepin:
 https://github.com/hepin1989/akka-remote-transport-netty4

 But I just realized it was deprecated in favor of the new Akka I/O.

 Best regards,

 Guido.

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

Re: [akka-user] The all roles developer with IntelliJ, Java and Maven

[Guido Medina]

I heard Maven next gen is coming with Gradle like? *-old Play conf style-* 
where you can mix and match XML with free style POM definition, I haven't 
got the opportunity to work with very big teams where each sub-project is a 
piece of something and eventually everything becomes a nightmare so for 
now, for the projects I have worked I tend to use simplistic setups and try 
to pattern-ize everything.

As example, I have this utility class to create actor systems with its 
corresponding supervisor actor which inherits from a mega super class with 
several template methods to do all the things, then the specific things to 
implement at very minimal.

The other thing of course is Scala, which is nice, with Java 8 now things 
are less verbose for Java developers but I can see the trends moving 
towards Scala, though I would mix them both nicely, for small teams 
productivity isn't more than finding the perfect development environment 
where a developer can focus on what he/she is hired to do: deliver business 
logic well implemented so that is what I have tried and maybe *-too early 
to tell though it is in production-* succeeded.

I find in particular Maven app assembler an awesome plugin, it gives the 
developer a way to provide execution scripts to admins, then admins can do 
whatever they want, docker or supervisord, etc etc.

Next phase of the project after basic system is build is monitoring, and 
because money is not the real problem I think it will be about time to buy 
something like ConductR or something, let's see what is out there when the 
time comes.

I want to reach the climax of the project so that I can focus more on Akka 
and Scala and at the same time contribute here and there.

Best regards,

Guido.

On Tuesday, June 16, 2015 at 9:59:53 PM UTC+1, Brian Topping wrote:

 Congrats Guido, sounds like you've done a great job. When the customer is 
 happy... :-)

 So that you know, there are a few of us using Scala with Maven. As someone 
 who once suffered through Ant, I prefer the encapsulation of 
 functional/procedural code in plugins. As you may know, the SBT plugin for 
 IntelliJ needs to do a build with a special SBT plugin inserted in order 
 to extract the build configuration, like Ant builds of yore, there's no way 
 to reliably extract SBT configuration across versions without doing things 
 this way. There's nothing wrong with that and it works, but my mind also 
 thinks in this declarative way now about builds, so I tend towards Maven, 
 XML and all.

 What I do is commit to starting one new project every year in SBT to see 
 if I can make it stick. There are some projects coming along like ScalaJS 
 that probably won't have a Maven plugin for a long time since there's 
 nobody to support it. That will be the kind of thing that will probably tip 
 the scales for me. Like Scala and Akka, SBT has been coming along nicely 
 and now that the heavy lifting patterns are established, there's time and 
 experience to make it a more enjoyable and productive environment.

 If you're interested in a nice template for Scala, you might want to check 
 out https://github.com/hseeberger/reactive-flows/. Heiko has done an 
 stellar job of assembling all the best widgets for a clustered app with 
 Akka-HTTP, including showing how to test with it. I've been banging on it 
 to try to make the app more modular and in line with DDD patterns since 
 it's already CQRS/ES friendly. If you get some free time, check it out!

 best, Brian

 On Jun 16, 2015, at 1:14 PM, Guido Medina oxy...@gmail.com javascript: 
 wrote:

 Hi,

 This is not exactly a question, more like a discussion and sharing some of 
 my experiences lately, most of it for medium+ size companies might not make 
 much sense but for overloaded small teams with one or two developers doing 
 everything, here is my *-as short as I can describe it-* story:

 I was hired to continue developing a system, but such system was doing 
 anything and the premise was to use X asynchronous framework *-won't say 
 the name-* to build a high available and scalable system initially 
 with several Maven projects and Eclipse.

 Everything looked perfect until I discovered the project was a green-field 
 project with thousands of lines and it was not working so I decided to 
 scratch it, first I had to convince management that Akka was the way to go 
 and to do that I had 3 weeks to build a prototype that could deliver the 
 basic functionalities so I had to make quick decisions and learn Akka while 
 going:

- *Development environment:* No doubt, IntelliJ, I was willing to buy 
it myself if they wouldn't, I'm not too fond of SBT so I'm doing 
 everything 
with Maven, my project is written in Java 8 but it has already the Scala 
compiler so I can add Scala code if I want to, also IntelliJ Scala plugin 
is good to look at API source code and stuff.
- *Project structure:* Maven parent project with modules, a common 
module for shared

Re: [akka-user] The all roles developer with IntelliJ, Java and Maven

[Guido Medina]

Nice, you know projects from time to time deprecate things out, depending 
on how things play out and time surely it will be worth to take a look at 
new/easier ways to do things, for me it was a hell of a journey because I 
had to learn Akka in 3 weeks with spoonful of salt and steroids included.

One of the experiences I cannot stress enough to Akka's new comers how 
important and useful are the first 3 parts of the documentation: General, 
Actors and Configuration have lots of useful information to kick start any 
project and further, specially if you keep it simple, nice work on these 
parts of the documentation.

On Tuesday, June 16, 2015 at 10:34:30 PM UTC+1, Konrad Malawski wrote:

 Awesome email, thanks the kudos and for spending the time to write it up, 
 Guido!

 Allow me to swiftly chime in on one of the touched upon topics :-)

 I find in particular Maven app assembler an awesome plugin, it gives the 
 developer a way to provide execution scripts to admins, then admins can do 
 whatever they want, docker or supervisord, etc etc.

 We've got your covered on that in sbt as well: 
 https://github.com/sbt/sbt-native-packager :-)

 -- 
 Cheers,
 Konrad 'ktoso’ Malawski
 Akka http://akka.io @ Typesafe http://typesafe.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 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] Re: The all roles developer with IntelliJ, Java and Maven

[Guido Medina]

Streams of thoughts are what evolve us ;-)
Yeah, I had to do some old school tricks to get the project to stage it is 
atm, but things will change, the company mindset is changing very fast, I 
have my good effects on management that nothing is impossible, we are 
hiring another person more UI oriented so if anyone Java 8 or Scala is 
interested on a very peculiar system that I started for the Financial 
Industry in Dublin, Ireland, just let me know, I need a partner :D

My background is similar to your, I'm the backend multi-thread async guy, I 
hate UI...

Thanks for sharing, it is always good to know others experiences, specially 
small teams.

Best regards,

Guido.

On Tuesday, June 16, 2015 at 10:48:23 PM UTC+1, Giovanni Alberto 
Caporaletti wrote:

 I'll tell you my story as you did with yours, as a sort of knowledge 
 exchange.

 I work in a -for the time being!- small startup that has to cover every 
 possible technical aspect there is out there, from x64 assembly to machine 
 learning to web development, and I'm the only backend guy (but this will 
 hopefully change soon), I currently work 12 hours/day, on saturdays, I do 
 devops, release management, development, planning, mentoring for younger 
 guys and a lot of other stuff. I have to manage a prototype inherited from 
 someone else and manage its evolution to a mature system while at the same 
 time keeping the first small production systems alive and well. I sometimes 
 even touch frontend code (that I hate with all my guts). I'm even taking 
 online courses meanwhile.  What's my point? I simply don't want to find 
 myself in the position of having to explain to the management my 
 technical choices. It's simply not what I want to do. I want to fail on my 
 own if I must, but as someone -maybe joel spolsky? I don't remember- once 
 said: never work for someone who has never written a line of code.

 That said, I think that, especially when you're alone, the only tool that 
 helps you is the tool you're familiar with. Time is essential. Sbt is a 
 PAIN if you don't know it, while if you know it you can customize your 
 builds to degrees maven users cannot even think of. The same applies to 
 scala. The compiler is unbearably slow for someone used to 
 java/intellij/eclipse (I come from there). You have to rely less on the IDE 
 and learn to trust the compiler errors, I even disable automatic 
 auto-completion because it's so slow, but anyway, once you go the scala 
 way, if you know the tools, if you know the language, if you know a bit of 
 theory (functional etc) and the idioms, a new world unravels in front of 
 you, trust me.

 What I really think? On small/greenfield projects, process, automation and 
 delivery tools are the most important thing, whatever build tool, framework 
 and language you use. Software engineering and development changes 
 radically when you have time and money. In the last two months I set up 
 trello, slack, jenkins, gitlab, openldap, artifactory, a private docker 
 registry (PAIN), ansible scripts, continuous integration environments, 
 automated build, packaging and release of each and every component. I used 
 akka-http on a small component and I intend to use it on a bigger one, I 
 wrote a number of python scripts, shell scripts, etc etc. Using sbt native 
 packager, for example I now have reproducible builds that create docker 
 containers and one-click releases, builds and deployments.
 See it this way: once you have the infrastructure in place, changing your 
 projects structure is like changing your code when you have 100% test 
 coverage. If you structure the code well and all your process is automated, 
 it's incredibly easy to change the build tools, so my suggestion is not to 
 focus on those at the beginning.

 If you want to introduce scala into your projects, start with tests. You 
 could have separate sbt projects with end-to-end and performance (gatling) 
 tests written in scala, to try it out. Sbt is not necessarily slower than 
 maven as you seem to think, you just need to leave it open, it's only the 
 bootstrap that's slow. On the contray, on a number of occasions I had to 
 write custom maven plugins or patch already existing maven plugins because 
 of the limitations of the xml-based approach. Maven is so much easier to 
 get up and running as long as the plugins you have cover all your needs. I 
 have never used it with scala and I don't know the latest versions anyway. 
 Are you able to split pom.xml in more than one file now? I like to have 
 small, organized files for the build as well, I wouldn't use maven even 
 only for the huge spammy-xml-ish pom files. I like the idea that the build 
 is a project itself and not just a descriptor or the project.

 Sorry for the stream of thoughts and for going off topic...!



 On another note: is there anyone in this group who works in Singapore? If 
 there is, can you contact me? thanks

 On Tuesday, 16 June 2015 22:14:53 UTC+2, Guido Medina

[akka-user] The all roles developer with IntelliJ, Java and Maven

[Guido Medina]

Hi,

This is not exactly a question, more like a discussion and sharing some of 
my experiences lately, most of it for medium+ size companies might not make 
much sense but for overloaded small teams with one or two developers doing 
everything, here is my *-as short as I can describe it-* story:

I was hired to continue developing a system, but such system was doing 
anything and the premise was to use X asynchronous framework *-won't say 
the name-* to build a high available and scalable system initially 
with several Maven projects and Eclipse.

Everything looked perfect until I discovered the project was a green-field 
project with thousands of lines and it was not working so I decided to 
scratch it, first I had to convince management that Akka was the way to go 
and to do that I had 3 weeks to build a prototype that could deliver the 
basic functionalities so I had to make quick decisions and learn Akka while 
going:

   - *Development environment:* No doubt, IntelliJ, I was willing to buy it 
   myself if they wouldn't, I'm not too fond of SBT so I'm doing everything 
   with Maven, my project is written in Java 8 but it has already the Scala 
   compiler so I can add Scala code if I want to, also IntelliJ Scala plugin 
   is good to look at API source code and stuff.
   - *Project structure:* Maven parent project with modules, a common 
   module for shared data structures, utilities and messages, a very minimal 
   number of dependencies, for example I was using Jackson Json but there were 
   like 4 jars so I switched to a lighter and smaller Jar - Gson.
   - *Execution:* Each module is just a Java main with an ActorSystem, 
   common.conf from common module dictates general config that are included 
   into each module_name.conf
   - *Akka cluster/remote:* The project was designed from the beginning 
   with location transparency and scale-ability in mind.
   - *Execution inside IntelliJ:* Easy because each module is just a Java 
   main.
   - *Maven profiles:* Help me create deployment options for different 
   environments like dev, test, uat, etc.
   - *Maven runners:* There is a mirror project which has the same 
   structure as the main project but it only acts as script builder and 
   application assembler to create easy executables using Maven app assembler, 
   due to all problems I have heard, I preferred not to use shaded nor fat 
   jars, instead something else generates the script (module_name.sh, 
   module_name.bat) for me so all I have to do is pass such scripts to IT 
   admin: http://www.mojohaus.org/appassembler/appassembler-maven-plugin/
   - *Location transparency and caches:* I have a sort of a address book 
   per module, each module instance subscribe to relevant cluster events and 
   when it does it knows *-by convention-* what supervisor it needs to send 
   a message to initiate the handshake, say a module named strategy comes 
   up, that module has the role strategy so I know at that node 
   address/user/strategy is a supervisor running, so I send my actor ref, once 
   it gets it, it sends to me his actor refs cache -children- and then I have 
   a local cache with addresses, so if I need to locate some account ID, I 
   just look up by Integer in my cache and I get an ActorRef, or I could look 
   for a round robin router because some components are load balanced so each 
   other supervisor keeps a round robin router updated.
   - *Dispatchers and mail boxes:* It wasn't easy to come up with a good 
   design initially, I was using the default dispatcher, now I have the 
   default dispatcher modified, a dispatcher for blocking operations, Netty 
   server and client pools customized, Kryo serialization 
   and SingleConsumerOnlyUnboundedMailbox, this is the aspect most of us will 
   spend most time, be ready for the inevitable consequences here, you will 
   play with these hundreds of times.


*Why did I make such decisions?*

   - Time wasn't in my favor, I wanted to use something that just works, 
   and location transparency + cluster + local caches is doing a nice job for 
   me.


*What problems am I facing now?*

   - Only few, now I have to build the UI of a system that it is running in 
   production making real transactions but I'm waiting on Akka HTTP's docs for 
   Java, yeah I know Scala is there but remember, time, Scala is on my list 
   and it is going to happen because I say so :D but not yet.
   - Akka remote is not behaving excellently but I expect that to improve, 
   fortunately my project required max time of 5ms and my system is doing from 
   1ms to 4ms with a caveat, first few messages take 50ms and eventually 
*-sooner 
   rather than later-* it goes down to within parameters.

*Moving forward:*

   - There were desperate moments because the old project took the company 
   1 year plus the money spent and nothing was delivered so I was on a very 
   bad position, I didn't know this at the interview but I moved forward, now 
   

[akka-user] Re: Java/Akka API: Is it really necessary?

[Guido Medina]

Hi Roland,

Thanks for the response, I guess from Scala/Java perspective you are right, 
now I think that is arguable from the Akka perspective, I think Akka is in 
a corner case where you should have the liberty to dictate what's the safe 
way of using Akka which gives you the license and/or liberty to settle on 
for example, Scala Futures and so on, at the end of the day your decision 
to settle on one style or the other is very justify in order to protect the 
Akka API consumer from concurrency pitfalls and mutability issues.

But again, time will tell and I think it will tell towards Scala rather 
than old Java style.

Best regards,

Guido.

On Saturday, June 6, 2015 at 7:41:09 PM UTC+1, Guido Medina wrote:

 Hi,

 I have been using Akka now for three months now and one thing that got my 
 attention in a very good way is the fact that you can use Scala methods and 
 functions from Java, then I wonder:

- Is it really necessary to have an Akka Java API for Java developers 
in general?
- I have not much experience with Java-to-Scala combination but I have 
noticed the doc in Java say for example getContext() vs Scala context(), 
 in 
my project I'm using context(), self(), sender() just like you would do in 
Scala and it just works.

 Why bother maintaining a Java API that is most likely to be outdated or 
 miss something the next day?
 Even from the documentation point of view, it makes things more difficult 
 to understand and slower to document.

 I'm not saying to remove the ability to use Akka from Java but to force 
 Java developers to use the same API even if it is Java convention breaking.
 There is no point and not even in the Java world we appreciate to be so 
 tied up with get... prefix so why bother?

 *The last and probably the most important question here:* If you 
 eliminate the Java API that is designed to be Java's convention friendly, 
 would Akka miss any functionality for Java developers?
 Maybe at the beginning from an acceptance point of view you wanted to be 
 Java's friendly, guess what, it is more annoying to try to follow an 
 obsolete convention than forcing us to evolve and move forward.

 Maybe this is deeper than just Akka but Scala in general if it becomes 
 more Java 8 friendly and for example pass a Java 8 lambda expression to a 
 Scala method expecting a Scala trait *-or whatever is called-*
 I don't really know which is why I would like to know your opinion about 
 this.


-- 
  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] Re: The all roles developer with IntelliJ, Java and Maven

[Guido Medina]

I'm still in the process of learning Scala, remember atm the project is 
written in Java 8, to be more provider dependent we are thinking to use 
Akka HTTP/Streams combined with AngularJS for such purpose.

About SBT, I'm not denying it is better than Maven but there was a strong 
time constrain so I had to deliver something with the tools at hand ;-)

On Wednesday, June 17, 2015 at 9:45:27 AM UTC+1, Anton Kulaga wrote:

 Why Maven? SBT is much better and flexible. Also, if you will decide to 
 add some scalajs code to frontend you will have to move to sbt anyway as 
 maven currently does not support scalajs

 On Tuesday, June 16, 2015 at 11:14:53 PM UTC+3, Guido Medina wrote:

 Hi,

 This is not exactly a question, more like a discussion and sharing some 
 of my experiences lately, most of it for medium+ size companies might not 
 make much sense but for overloaded small teams with one or two developers 
 doing everything, here is my *-as short as I can describe it-* story:

 I was hired to continue developing a system, but such system was doing 
 anything and the premise was to use X asynchronous framework *-won't say 
 the name-* to build a high available and scalable system initially 
 with several Maven projects and Eclipse.

 Everything looked perfect until I discovered the project was a 
 green-field project with thousands of lines and it was not working so I 
 decided to scratch it, first I had to convince management that Akka was the 
 way to go and to do that I had 3 weeks to build a prototype that could 
 deliver the basic functionalities so I had to make quick decisions and 
 learn Akka while going:

- *Development environment:* No doubt, IntelliJ, I was willing to buy 
it myself if they wouldn't, I'm not too fond of SBT so I'm doing 
 everything 
with Maven, my project is written in Java 8 but it has already the Scala 
compiler so I can add Scala code if I want to, also IntelliJ Scala plugin 
is good to look at API source code and stuff.
- *Project structure:* Maven parent project with modules, a common 
module for shared data structures, utilities and messages, a very minimal 
number of dependencies, for example I was using Jackson Json but there 
 were 
like 4 jars so I switched to a lighter and smaller Jar - Gson.
- *Execution:* Each module is just a Java main with an ActorSystem, 
common.conf from common module dictates general config that are included 
into each module_name.conf
- *Akka cluster/remote:* The project was designed from the beginning 
with location transparency and scale-ability in mind.
- *Execution inside IntelliJ:* Easy because each module is just a 
Java main.
- *Maven profiles:* Help me create deployment options for different 
environments like dev, test, uat, etc.
- *Maven runners:* There is a mirror project which has the same 
structure as the main project but it only acts as script builder and 
application assembler to create easy executables using Maven app 
 assembler, 
due to all problems I have heard, I preferred not to use shaded nor fat 
jars, instead something else generates the script (module_name.sh, 
module_name.bat) for me so all I have to do is pass such scripts to IT 
admin: http://www.mojohaus.org/appassembler/appassembler-maven-plugin/
- *Location transparency and caches:* I have a sort of a address book 
per module, each module instance subscribe to relevant cluster events and 
when it does it knows *-by convention-* what supervisor it needs to 
send a message to initiate the handshake, say a module named strategy 
comes up, that module has the role strategy so I know at that node 
address/user/strategy is a supervisor running, so I send my actor ref, 
 once 
it gets it, it sends to me his actor refs cache -children- and then I 
 have 
a local cache with addresses, so if I need to locate some account ID, I 
just look up by Integer in my cache and I get an ActorRef, or I could 
 look 
for a round robin router because some components are load balanced so 
 each 
other supervisor keeps a round robin router updated.
- *Dispatchers and mail boxes:* It wasn't easy to come up with a good 
design initially, I was using the default dispatcher, now I have the 
default dispatcher modified, a dispatcher for blocking operations, Netty 
server and client pools customized, Kryo serialization 
and SingleConsumerOnlyUnboundedMailbox, this is the aspect most of us 
 will 
spend most time, be ready for the inevitable consequences here, you will 
play with these hundreds of times.


 *Why did I make such decisions?*

- Time wasn't in my favor, I wanted to use something that just works, 
and location transparency + cluster + local caches is doing a nice job 
 for 
me.


 *What problems am I facing now?*

- Only few, now I have to build the UI of a system that it is running

[akka-user] Re: Java: Closing on context() at anonymous class

[Guido Medina]

Hi Roland,

I didn't say it but I thought about ThreadLocal problems, or a 
non-concurrent mutable map under each actor to hold their children 
*-Option[ActorRef]-*
I lack *-for now-* the Scala's concurrency knowledge to go any further, I'm 
about to learn Scala but a bit busy with something else.
I'll stick to your advise and send the message to self() and forward it to 
the child if exists.

And yes, you are right, I have been complicating myself with 
micro-optimizations because I'm loosing 2ms or more
sending messages within Akka nodes in the same cluster.

*-Akka Cluster/Remote with Kryo serialization, very small Java messages, 
one actor system per JVM and all in localhost-*

Which is why I have been trying my best with micro-optimizations of what I 
have control, 2ms is too high of a cost for our application.
I'm even setting the sender() to noSender() everywhere *-by design only in 
one or two places I need to know about it-*

I think I have everything correct including modified configuration of 
default dispatcher, remote dispatcher, netty client and server pools,
proper JVM args, dedicated dispatchers for blocking operations, etc etc.

I'm not sending many messages, my messages at most will have a burst of 4 
or 5 but when they come I need them to have the lowest latency as possible,
1st to 5th message take like 60ms, then go down to 20ms, then finally stays 
between 1ms and 3ms to 5ms, still too high

I have spent weeks researching on Akka remote but looks like nobody has 
gotten it right or it is an ultra secret not shared anywhere, tips are 
welcome.

Best regards,

Guido.


On Friday, June 5, 2015 at 6:28:39 PM UTC+1, Guido Medina wrote:

 Hi,

 I have the following method which creates a FixInitiator which is part of 
 another multi-threaded framework I have no control, the client is started 
 inside an actor which its children are named and located by a generated 
 UUID.

 I have read that passing the context to another thread is not safe but 
 when you look at the Scala code, the context is lazily initialized, if it 
 was initialized already, doesn't that make this code OK?

 The method fromApp(...) is re-actively called back from another thread 
 when a FIX message comes into the system, so far this is working for me 
 without any issues, but maybe it is because I have called context() already 
 for this actor before I reach the anonymous class declaration at the 
 preStart() method?

 *Note:* The call to super.preStart() is because the actor is inheriting 
 from another Abstract type of actor with some template methods pattern.
   
   @Override
   public void preStart() throws Exception {
 initiator = new FixInitiator(entity, log, order) {
   @Override
   public void fromApp(Message message, SessionID sessionId) throws 
 FieldNotFound {
 if (message instanceof ExecutionReport) {
   final String uuid = message.getString(ClOrdID.FIELD);
   final OptionActorRef orderPersistor = *context**()*.child(uuid
 );
   if (orderPersistor.isDefined()) {
 orderPersistor.get().tell(message, noSender());
   } else {
 log.error(Order persistor for  + uuid +  doesn't exist or 
 has expired);
   }
 } else {
   unhandled(message);
 }
   }
 };
 initiator.start();
 super.preStart();
   }



-- 
  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 2.4 milestones, RC and final release ETAs?

[Guido Medina]

Hi,

Just wondering what are the ETAs on Akka 2.4-M2, RCs and final?

Best regards,

Guido.

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

[akka-user] Re: Akka 2.4 milestones, RC and final release ETAs?

[Guido Medina]

Also, I would like to know what's the status of the new Akka remote using 
Akka I/O, I was trying to use the Netty 4 implementation from Hepin:
https://github.com/hepin1989/akka-remote-transport-netty4

But I just realized it was deprecated in favor of the new Akka I/O.

Best regards,

Guido.

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

Re: [akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

I'll send you the pull request in several minutes, also the signing for 
contribution.

On Tuesday, June 16, 2015 at 9:22:16 AM UTC+1, Patrik Nordwall wrote:

 I have created an issue so that someone (great community contribution) can 
 pick it up: https://github.com/akka/akka/issues/17738

 On Sun, Jun 7, 2015 at 12:12 PM, Akka Team akka.o...@gmail.com 
 javascript: wrote:

 Hi Guido,

 You cannot import the release-2.3-dev in newest IntelliJ, I filed them a 
 bug last week. Can you still make this a proper PR? You can build Akka 
 using sbt only, or you can still use the old sbt-idea plugin to make a 
 project that IDEA can read (that is what I use now until they fix the 
 import).

 -Endre

 On Mon, Jun 1, 2015 at 12:54 PM, Guido Medina oxy...@gmail.com 
 javascript: wrote:

 I modified the original to be correct, theoretically when your 
 AtomicLong reaches the *Long.MAX_VALUE* + 1 it will shift to 
 *Long.MIN_VALUE* making the mod (%) function return negative which will 
 make the application fail due to invalid list index 
 *-list.get(neg_index)-*

 In practice that is unlikely to happen but there might be some crazy lab 
 running DNA sequencing so in practice infinite is now reachable, could take 
 hours, days or weeks, but once it happen, original 
 *RoundRobinRountingLogic* will fail, perf tests concluded that at least 
 in Java 8 atomic adder + mod is faster than CAS, but the class needs to be 
 modified from this:

 final class RoundRobinRoutingLogic extends RoutingLogic {
   val next = new AtomicLong(0)


   override def select(message: Any, routees: immutable.IndexedSeq[Routee
 ]): Routee =
 if (routees.isEmpty) NoRoutee
 else routees((next.getAndIncrement % routees.size).asInstanceOf[Int
 ])

 }

 To this, not sure if it is going to compile, I'm not a Scala programmer, 
 not sure if the asInstanceOf is needed anymore, Integer or Long they 
 will eventually overflow and go to their MIN_VALUE so why bother with a 
 Long?

 It looks to me Long was put there with fear of reaching MAX_VALUE 
 causing a failure, well, it won't fail because overflows will just shift a 
 bit, but it will fail because mod(%) will return negative 
 *-list.get(neg_index)-*, so here is the original with Math.abs and 
 AtomicInteger instead:

 final class RoundRobinRoutingLogic extends RoutingLogic {
   val next = new AtomicInteger(0)


   override def select(message: Any, routees: immutable.IndexedSeq[Routee
 ]): Routee =
 if (routees.isEmpty) NoRoutee
 else routees(Math.abs(next.getAndIncrement % routees.size).
 asInstanceOf[Int])

 }


 *JMH perf tested results:*

 BenchmarkMode  Cnt  Score  Error  Units
 CASvsMOD.intCAS_1   thrpt5   76444721.566 ±   813686.931  ops/s
 CASvsMOD.intCAS_4   thrpt5   73853879.600 ±   689854.722  ops/s
 CASvsMOD.intCAS_8   thrpt5   76352315.163 ±  2300065.091  ops/s
 CASvsMOD.intMOD_1   thrpt5  131541916.778 ±  3400828.887  ops/s
 CASvsMOD.intMOD_4   thrpt5   96787272.406 ±  1540417.674  ops/s
 CASvsMOD.intMOD_8   thrpt5   96954428.161 ±  1007965.370  ops/s
 CASvsMOD.longMOD_1  thrpt5  129730846.046 ± 23522696.956  ops/s
 CASvsMOD.longMOD_4  thrpt5   96930440.731 ±  1549403.070  ops/s
 CASvsMOD.longMOD_8  thrpt5   96882920.242 ±  1342011.843  ops/s


 JMH perf source code:

 import org.openjdk.jmh.annotations.*;
 import org.openjdk.jmh.runner.Runner;
 import org.openjdk.jmh.runner.RunnerException;
 import org.openjdk.jmh.runner.options.Options;
 import org.openjdk.jmh.runner.options.OptionsBuilder;


 import java.io.IOException;
 import java.util.concurrent.atomic.AtomicInteger;
 import java.util.concurrent.atomic.AtomicLong;


 @State(Scope.Benchmark)
 public class CASvsMOD {


   private final AtomicInteger nextInt = new AtomicInteger();
   private final AtomicLong nextLong = new AtomicLong();


   private int nextInt(int routees) {
 return nextInt.accumulateAndGet(1, (index, increment) - ++index  
 routees ? index : 0);
   }


   @Benchmark
   public void intCAS_1() {
 nextInt(1);
   }


   @Benchmark
   public void intCAS_4() {
 nextInt(4);
   }


   @Benchmark
   public void intCAS_8() {
 nextInt(8);
   }


   private int nextIntWithMod(int routees) {
 return Math.abs(nextInt.incrementAndGet() % routees);
   }


   @Benchmark
   public void intMOD_1() {
 nextIntWithMod(1);
   }


   @Benchmark
   public void intMOD_4() {
 nextIntWithMod(4);
   }


   @Benchmark
   public void intMOD_8() {
 nextIntWithMod(8);
   }


   private long nextLong(int routees) {
 return Math.abs(nextLong.incrementAndGet() % routees);
   }


   @Benchmark
   public void longMOD_1() {
 nextLong(1);
   }


   @Benchmark
   public void longMOD_4() {
 nextLong(4);
   }


   @Benchmark
   public void longMOD_8() {
 nextLong(8);
   }


   public static void main(String[] args) throws RunnerException, 
 IOException {
 final Options opt = new OptionsBuilder().
   include

[akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

In fact, I think my implementation should not only be faster but it is also 
safer due to the *-unlikely event?-* of reaching Long.MAX_VALUE, a side by 
side comparison:

   - Both implementations compare and set the value atomically, but mine 
   does it for an *AtomicInteger vs AtomicLong* which is cheaper.
   - My implementation does one increment of an integer and compare it 
   against the size and return either the new value if less or  equal than 
   size or zero, the original implementation always MOD a long value which 
   according to my research *-not a very extensive one-* moding cost  
   dividing cost  multiplying cost  incrementing cost

The other issue not strictly related with my implementation is that the 
static and singleton *NoRoutee* instance is a private member of 
*Router.scala* making it unusable for *RoutingLogic* extenders, and Akka 
does use equality *-if routee == NoRoutee then deadletters ! tell...-* which 
makes anyone's custom *RoutingLogic* implementation not able to behave like 
any other Akka provided RoutingLogic so I think it needs to be made public 
and mentioned in the documentation clarifying that returning it from a 
RoutingLogic will drop the message into the dead letters.

Best regards,

Guido.

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

[akka-user] Re: Strategies for detecting thread pool starvation in misbehaving Akka apps

[Guido Medina]

One approach I use after watching Akka days videos, was to just create 
small dispatchers for different types of tasks, say you have a set of 
actors that persist to a relational database, create these actors on your 
persistor-dispatcher for example, another example, say you have a single 
supervisor that its only jobs is to forward messages to another set of 
actors living in your own cache, for that a PinnedDispatcher is perfect 
since that supervisor only needs 1 thread for ever and it needs to be fast 
because the only thing it is doing is to forward messages, then there is 
the fine grained configuration of your remote-dispatcher, etc.

I mean, I don't think there will be a solve-all the problems approach, but 
pre-defining dispatchers ahead of time and have a shared conf file where 
every module of your system extends will help, set the standard on the 
project of what dispatcher should be used for what, that's at least how I 
have it at the moment and I don't have to worry about some insert SQL 
taking too long because such actor is running on a dispatcher where it 
doesn't matter how long it takes.

Hope that helps,

Guido.

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

[akka-user] Re: Strategies for detecting thread pool starvation in misbehaving Akka apps

[Guido Medina]

Following up on my previous post, say there is a careful thread management 
which interrupts a long running task, I have been there...if you are 
interrupting something you coded, then probably you will refactor your code 
so that it doesn't need to be interrupted which leads to another scenario, 
you are trying to interrupt an alien API, you know that changes of a bad 
designed API to be interrupted are from slim to none right?

That said, you will have no other choice than to isolate such calls to 
dedicated dispatchers, it all boils down to two things:

   1. Interruption in Java which most of the time you do not have control.
   2. Thread scheduler fairness which you also have no control.

So I strongly believe the best you can do is to isolate or divide and 
conquer

Hope that helps,

Guido.

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

[akka-user] Re: Strategies for detecting thread pool starvation in misbehaving Akka apps

[Guido Medina]

Another approach that may as well deal with accidental issues, is to avoid 
awaiting on messages, this is how I do, and again, it is working like a 
charm, say you have the following scenario:

   - Actor A running on persistor-dispatcher needs to insert a record on 
   the DB and send the identity of that record, or the whole inserted new 
   record to Actor B which needs it.
   - Actor B will at pre-start send a message to actor A requesting such 
   record without waiting, just fire-and-forget, include the sender in your 
   message.
   - Actor A will answer the message with its new inserted record.
   - Actor B will set context timeout for say, 1 minute and before it 
   receives the record from Actor A, it stash all messages coming to it.
   - Actor B if receives timeout message, deal with it with your own logic, 
   say, keep working until number of timeouts exceed a number, say, 5 times or 
   just kill the actor because something is wrong on Actor A.
   - Actor B eventually receives the record from Actor A and at that moment 
   it will unstash all messages and do the normal processing.

Think of it as long running state machine without blocking, you are just 
reacting to either the eventual message or a timeout, does that cover all 
scenarios?, No, but I think it is a good approach to avoid blocking and 
waiting.

-- 
  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] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

Will do that ;-)

-- 
  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] Re: Java: Yet another get or create actor question

[Guido Medina]

Many thanks, that Optional pattern will come very handy to me.

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

[akka-user] Re: Java: Yet another get or create actor question

[Guido Medina]

Is there any way to avoid the verbosity?, I try with a more functional 
approach which was OK for IntelliJ but not for the Java 8 compiler, here is 
the form that is working:

  private void applyToAccount(Currency currency, BalanceOperation operation) 
{
context().child(currency.code).
  getOrElse(new AbstractFunction0OptionActorRef() {
@Override
public OptionActorRef apply() {
  return Option.some(context().actorOf(balancePersistorProps(
currency), currency.code));
}
  }).
  get().forward(operation, context);
  }


But I was hoping the following would work, but Java 8 can't infer the type, 
strange IntelliJ recognizes it I guess the mix of Java and Scala drives it 
crazy:

  
private void applyToAccount(Currency currency, BalanceOperation operation) {
context().child(currency.code).
  getOrElse(() - Option.some(context().actorOf(balancePersistorProps(
currency), currency.code))).
  get().forward(operation, context);
  }


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.

[akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

I modified the original to be correct, theoretically when your AtomicLong 
reaches the *Long.MAX_VALUE* + 1 it will shift to *Long.MIN_VALUE* making 
the mod (%) function return negative which will make the application fail 
due to invalid list index *-list.get(neg_index)-*

In practice that is unlikely to happen but there might be some crazy lab 
running DNA sequencing so in practice infinite is now reachable, could take 
hours, days or weeks, but once it happen, original *RoundRobinRountingLogic* 
will fail, perf tests concluded that at least in Java 8 atomic adder + mod 
is faster than CAS, but the class needs to be modified from this:

final class RoundRobinRoutingLogic extends RoutingLogic {
  val next = new AtomicLong(0)


  override def select(message: Any, routees: immutable.IndexedSeq[Routee]): 
Routee =
if (routees.isEmpty) NoRoutee
else routees((next.getAndIncrement % routees.size).asInstanceOf[Int])

}

To this, not sure if it is going to compile, I'm not a Scala programmer, 
not sure if the asInstanceOf is needed anymore, Integer or Long they will 
eventually overflow and go to their MIN_VALUE so why bother with a Long?

It looks to me Long was put there with fear of reaching MAX_VALUE causing a 
failure, well, it won't fail because overflows will just shift a bit, but 
it will fail because mod(%) will return negative *-list.get(neg_index)-*, 
so here is the original with Math.abs and AtomicInteger instead:

final class RoundRobinRoutingLogic extends RoutingLogic {
  val next = new AtomicInteger(0)


  override def select(message: Any, routees: immutable.IndexedSeq[Routee]): 
Routee =
if (routees.isEmpty) NoRoutee
else routees(Math.abs(next.getAndIncrement % routees.size).asInstanceOf[
Int])

}


*JMH perf tested results:*

BenchmarkMode  Cnt  Score  Error  Units
CASvsMOD.intCAS_1   thrpt5   76444721.566 ±   813686.931  ops/s
CASvsMOD.intCAS_4   thrpt5   73853879.600 ±   689854.722  ops/s
CASvsMOD.intCAS_8   thrpt5   76352315.163 ±  2300065.091  ops/s
CASvsMOD.intMOD_1   thrpt5  131541916.778 ±  3400828.887  ops/s
CASvsMOD.intMOD_4   thrpt5   96787272.406 ±  1540417.674  ops/s
CASvsMOD.intMOD_8   thrpt5   96954428.161 ±  1007965.370  ops/s
CASvsMOD.longMOD_1  thrpt5  129730846.046 ± 23522696.956  ops/s
CASvsMOD.longMOD_4  thrpt5   96930440.731 ±  1549403.070  ops/s
CASvsMOD.longMOD_8  thrpt5   96882920.242 ±  1342011.843  ops/s


JMH perf source code:

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;


import java.io.IOException;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;


@State(Scope.Benchmark)
public class CASvsMOD {


  private final AtomicInteger nextInt = new AtomicInteger();
  private final AtomicLong nextLong = new AtomicLong();


  private int nextInt(int routees) {
return nextInt.accumulateAndGet(1, (index, increment) - ++index  
routees ? index : 0);
  }


  @Benchmark
  public void intCAS_1() {
nextInt(1);
  }


  @Benchmark
  public void intCAS_4() {
nextInt(4);
  }


  @Benchmark
  public void intCAS_8() {
nextInt(8);
  }


  private int nextIntWithMod(int routees) {
return Math.abs(nextInt.incrementAndGet() % routees);
  }


  @Benchmark
  public void intMOD_1() {
nextIntWithMod(1);
  }


  @Benchmark
  public void intMOD_4() {
nextIntWithMod(4);
  }


  @Benchmark
  public void intMOD_8() {
nextIntWithMod(8);
  }


  private long nextLong(int routees) {
return Math.abs(nextLong.incrementAndGet() % routees);
  }


  @Benchmark
  public void longMOD_1() {
nextLong(1);
  }


  @Benchmark
  public void longMOD_4() {
nextLong(4);
  }


  @Benchmark
  public void longMOD_8() {
nextLong(8);
  }


  public static void main(String[] args) throws RunnerException, IOException 
{
final Options opt = new OptionsBuilder().
  include(CASvsMOD.class.getSimpleName()).
  warmupIterations(5).
  measurementIterations(5).
  forks(1).
  build();
new Runner(opt).run();
  }
}


Why am I proposing code here?, well, I tried to import and compile Akka on 
IntelliJ *-I have latest IntelliJ with Scala plugin-*, but I gave up 
because several issues I didn't have the time nor patience to resolve like 
SBT, so this is the best I can do.

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

[akka-user] Re: Akka cluster with 1 seed node

[Guido Medina]

I probably confused the readers with my long explanation so I'll ask the 
question straight forward: If I have a cluster with one seed node, how do I 
make the cluster reconnect to that seed node if I restart it? Is there any 
resilient configuration I'm not aware of that can make the other nodes try 
to re-associate themselves with such restarted seed node?

-- 
  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] RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

Hi,

I have my own version of a RoundRobinRouting logic which I believe it is 
faster and less CPU intensive due to no mod math operation, here is my 
version in Java 8, it has though one small error because NoRoutee instance 
if private and I don't know much Scala, so here it is a copy/proposal :

public class CircularRoutingLogic implements RoutingLogic {

  final AtomicInteger next = new AtomicInteger(-1);

  @Override
  public Routee select(Object message, IndexedSeqRoutee routees) {
final int size = routees.size();

// null should be replaced by NoRoutee Akka/Scala instance.
return size == 0 ? null : routees.apply(next.accumulateAndGet(1, (index, 
increment) - ++index = size ? 0 : index));
  }
}

-- 
  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] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

There is one thing to clarify and two differences:

   - There are no locks in atomic operations, remember atomic operations 
   are based on CAS.
   - Incrementing an *AtomicInteger* will definitely be cheaper than 
   incrementing an *AtomicLong.*
   - Comparing the value and returning is definitely cheaper 
   than division/mod operation which is CPU intensive.
   - And last but least important and highly unlikely: No risk of 
   overflowing the counter because the value is always reset to zero.

Though you are right, I should JMH it, let me do that tonight:

Here is what the side-effect function looks like in Java 8:

/**
 * Atomically updates the current value with the results of
 * applying the given function to the current and given values,
 * returning the updated value. The function should be
 * side-effect-free, since it may be re-applied when attempted
 * updates fail due to contention among threads.  The function
 * is applied with the current value as its first argument,
 * and the given update as the second argument.
 *
 * @param x the update value
 * @param accumulatorFunction a side-effect-free function of two arguments
 * @return the updated value
 * @since 1.8
 */
public final int accumulateAndGet(int x,
  IntBinaryOperator accumulatorFunction) {
int prev, next;
do {
prev = get();
next = accumulatorFunction.applyAsInt(prev, x);
} while (!compareAndSet(prev, next));
return next;
}

-- 
  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] Re: Java: Closing on context() at anonymous class

[Guido Medina]

Isn't that *pure chance* the fact that I'm calling context() before that 
declaration *-at the constructor of the outer class-* and as a side effect 
the context is already initialized?, What if I extract the context as a 
final variable before the anonymous declaration?
Wouldn't that eliminate the pure chance to an already initialized context?

The reason for me doing that is because I want to maximize my parallelism 
and message delivery intermediaries by just passing the message to an actor 
that should exist, the self() actor I want to do only what it is meant to 
do,
which is why my actors are using SingleConsumerOnlyMailbox.

On Friday, June 5, 2015 at 6:28:39 PM UTC+1, Guido Medina wrote:

 Hi,

 I have the following method which creates a FixInitiator which is part of 
 another multi-threaded framework I have no control, the client is started 
 inside an actor which its children are named and located by a generated 
 UUID.

 I have read that passing the context to another thread is not safe but 
 when you look at the Scala code, the context is lazily initialized, if it 
 was initialized already, doesn't that make this code OK?

 The method fromApp(...) is re-actively called back from another thread 
 when a FIX message comes into the system, so far this is working for me 
 without any issues, but maybe it is because I have called context() already 
 for this actor before I reach the anonymous class declaration at the 
 preStart() method?

 *Note:* The call to super.preStart() is because the actor is inheriting 
 from another Abstract type of actor with some template methods pattern.
   
   @Override
   public void preStart() throws Exception {
 initiator = new FixInitiator(entity, log, order) {
   @Override
   public void fromApp(Message message, SessionID sessionId) throws 
 FieldNotFound {
 if (message instanceof ExecutionReport) {
   final String uuid = message.getString(ClOrdID.FIELD);
   final OptionActorRef orderPersistor = *context**()*.child(uuid
 );
   if (orderPersistor.isDefined()) {
 orderPersistor.get().tell(message, noSender());
   } else {
 log.error(Order persistor for  + uuid +  doesn't exist or 
 has expired);
   }
 } else {
   unhandled(message);
 }
   }
 };
 initiator.start();
 super.preStart();
   }



-- 
  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] Re: Java: Closing on context() at anonymous class

[Guido Medina]

What I meant if, would the incorrect use be kind of worked around if I do 
this instead?, Notice also I remove the unhandled call.

  @Override
  public void preStart() throws Exception {
final ActorContext context = context();
initiator = new FixInitiator(entity, log, order) {
  @Override
  public void fromApp(Message message, SessionID sessionId) throws 
FieldNotFound {
if (message instanceof ExecutionReport) {
  final String uuid = message.getString(ClOrdID.FIELD);
  final OptionActorRef orderPersistor = context.child(uuid);
  if (orderPersistor.isDefined()) {
orderPersistor.get().tell(message, noSender());
  } else {
log.error(Order persistor for  + uuid +  doesn't exist or 
has expired);
  }
} else {
  log.error(FIX message not recognized  + message);
}
  }
};
initiator.start();
super.preStart();
  }


-- 
  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] Re: Java: Closing on context() at anonymous class

[Guido Medina]

Hi Dr. Roland,

Sorry for being annoying over here :D

In Akka 2.3.11 self() for example is context.self() and context below, 
doesn't that make self() also dangerous to be send to another thread 
outside Akka?
It looks to me that these chances are also valid for self(), isn't all 
about calling context() early, by early I mean before you do anything at 
all?
That being the case, doesn't extracting a variable for context before using 
it makes it safe? Maybe it is not appropriate to do it,
then I guess the only safe bet is to extract self() to a variable but that 
looks to me is exactly as extracting context() to a variable, right?

implicit val context: ActorContext = {
val contextStack = ActorCell.contextStack.get
if ((contextStack.isEmpty) || (contextStack.head eq null))
  throw ActorInitializationException(
sYou cannot create an instance of [${getClass.getName}] explicitly 
using the constructor (new).  +
  You have to use one of the 'actorOf' factory methods to create a 
new actor. See the documentation.)
val c = contextStack.head
ActorCell.contextStack.set(null :: contextStack)
c
  }

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

[akka-user] Re: ANNOUNCE: Akka Streams HTTP 1.0-RC3

[Guido Medina]

Excellent news,

But I couldn't find the HTTP guide for Java, ETA?, unfortunately our 
project is using Akka/Java 8.

We are waiting on it to use right away :D

Best regards,

Guido.

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

[akka-user] question on getting mailbox confirmation

[Guido Medina]

Hi Shawn,

You need to handle such actors like a state machine, initial state will just 
stash incoming messages and when its ready unstash all messages, for that Akka 
has UntypedActorWithStah

HTH,

Guido.

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

[akka-user] Akka cluster with 1 seed node

[Guido Medina]

Dear Hakkers,

I have a system with micro-services and my custom cluster shard 
implementation *-a long story not to be told for now, glad to share my 
approach later-*, so I have N roles in the cluster and each role with one 
of the following types: *[singleton, evenly distributed, balanced]* where 
*evenly 
distributed* is what cluster sharding does with my own algorithm and 
*balanced* creates a circular cycler routing logic which is similar to 
round robin but dumber, it just keep cycling an atomic integer between 
routee 1..N *-I can share the code later if anyone wants it-*

So every time a micro-service comes up it subscribe to cluster events with 
initial cluster state and member up/removed and here I update a local cache *-a 
local cache per service of an address book where other actors of other 
roles are to avoid network look up-*

The problem I'm having is that because I'm using only one seed node *-a 
special micro-service that doesn't do any business logic, just coordination 
stuff-* and if I restart the seed node, other nodes don't try to rejoin it 
and now I have two clusters, one with the seed node and all of the other 
nodes, new nodes coming after this will just join the seed node cluster.

So I guess what I'm looking for is some sort of cluster seed node 
resilience configuration?

I have gone through the documentation over and over and done some googling 
for hours with no success,

Best regards,

Guido.

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

Re: [akka-user] Implementing a bounded mailbox using lmax disruptor

[Guido Medina]

Hi Igor,

I have modified your initial implementation because on my tests it was 
blocking the Akka system at shutdown so I simplified it for 
SingleConsumerOnlyBoundedMailbox, look at the Akka git hub ticket and at my 
forked branch:

https://github.com/akka/akka/issues/17558

Best regards and many thanks for sharing it,

Guido

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

[akka-user] PinnedDispatcher with SingleConsumerOnlyUnboundedMailbox behaviour

[Guido Medina]

*Quick question:* If my default mailbox is a 
*SingleConsumerOnlyUnboundedMailbox* and my dispatcher a *PinnedDispatcher*, 
does the thread pool *-in this case a single thread-* de-queue tasks from 
it or is it there an intermediary Java blocking queue?

I'm assuming dispatchers in Akka are not necessary a copy of Fork-Join and 
Thread Pool executors from Java which for *SingleConsumerOnlyUnboundedMailbox 
*and *PinnedDispatcher* would be a waste of performance, I'm assuming it is 
de-queuing tasks directly from the mailbox, are my assumptions correct?

Best regards,

Guido.

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

[akka-user] Re: PinnedDispatcher with SingleConsumerOnlyUnboundedMailbox behaviour

[Guido Medina]

Sorry I mixed oranges with apples here, I just looked deeper the code and 
no, my assumptions are *not* correct, the mailbox is one thing but the 
task-queue is a different story, it would be nice at the 
ThreadPoolExecutorConfigurator Scala class to have an option for single 
thread dispatchers *aka* PinnedDispatcher so that it is not a full blown 
blocking queue due to the fact there is only one thread executing tasks, 
I'm guessing there is one or more threads on the Akka system loop that 
can queue tasks into the PinnedDispatcher's queue which in this case it 
will always have a single task consumer -The PinnedDispatcher only thread-

-- 
  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: PinnedDispatcher with SingleConsumerOnlyUnboundedMailbox behaviour

[Guido Medina]

It would only require a quick  dirty hack, but I'm still in the process of
learning/developing a new project using Akka/Java 8 on a new job so time is
not much on my side *-you know, the first 6 months of every new job-*

There is no need to change the dispatcher but the Scala configurator should
provide one of your lovely queues which I know are extremely optimized
compared to ArrayBlockingQueue, LinkedBlocking and ConcurrentLinkedQueue
Java counter parts, right?

On Tue, May 26, 2015 at 5:54 PM, Viktor Klang viktor.kl...@gmail.com
wrote:

 Hi Guido,

 the good news is that the ExecutorService for the Dispatcher is pluggable
 so you can provide your own, optimized version.

 Would love to hear how much of a difference it could make (JMH bench would
 be superb).

 On Tue, May 26, 2015 at 6:35 PM, Guido Medina oxyg...@gmail.com wrote:

 In fact, even more could be done here, I'm assuming there is a reason why
 mailboxes in general are not just blocking queues from Java, designers'
 decision to provide a faster queue, so, why not reuse the same logic for
 dispatchers?

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




 --
 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/Q_sgvACG8Nw/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-user] Re: PinnedDispatcher with SingleConsumerOnlyUnboundedMailbox behaviour

[Guido Medina]

Sorry I replied directly to you, my mistake, pasting message here:

It would only require a quick  dirty hack, but I'm still in the process of 
learning/developing a new project using Akka/Java 8 on a new job so time is 
not much on my side *-you know, the first 6 months of every new job-*

There is no need to change the dispatcher but the Scala configurator should 
provide one of your lovely queues which I know are extremely optimized 
compared to ArrayBlockingQueue, LinkedBlocking and ConcurrentLinkedQueue 
Java counter parts, right?

-- 
  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] Re: PinnedDispatcher with SingleConsumerOnlyUnboundedMailbox behaviour

[Guido Medina]

In fact, even more could be done here, I'm assuming there is a reason why 
mailboxes in general are not just blocking queues from Java, designers' 
decision to provide a faster queue, so, why not reuse the same logic for 
dispatchers?

-- 
  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: How to survive long GC pause

[Guido Medina]

And more information about the application itself to see memory usage 
patterns.

On Monday, August 24, 2015 at 4:22:10 PM UTC+1, Guido Medina wrote:

 Hi Patrik,

 I'm quite sure his problem has anything to do with Akka but lack of proper 
 JVM parameters, that 32 seconds pause shown in his logs would be enough to 
 cause nodes de-association and connection failures/timeouts of Akka remote 
 (without mentioning Akka cluster and other extensions) hence I suggested to 
 switch to newest garbage collector, of course the ideal thing to do is for 
 OP to post JVM parameters and more information about the JVM in use to aid 
 better.

 Hope that helps,

 Guido.

 On Monday, August 24, 2015 at 2:41:53 PM UTC+1, Patrik Nordwall wrote:

 Note that there is no: akka.cluster.transport-failure-detector

 you probably mean: akka.remote.transport-failure-detector

 The Disassociated might be triggered by that failure detector and you can 
 try to increase 

 akka.remote.transport-failure-detector.acceptable-heartbeat-pause

 /Patrik

 On Fri, Aug 21, 2015 at 11:29 AM, Guido Medina oxy...@gmail.com wrote:

 Try the JVM option -XX:+UseG1GC, assuming you are using at least JVM 
 7uLatest where latest should be 79 or 80. The new GC algorithm doesn't stop 
 world, it works more often and can make your application a bit slower (on a 
 very hyper micro-level) but GC will now be consistent.


 On Friday, August 21, 2015 at 6:36:11 AM UTC+1, Ara Tatous wrote:

 I have a configuration of Akka cluster with 4 nodes. Let's call them 
 Engine and Warehouse.  

 In Engine:

  

 *Everything is normal*

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

  

  

 *We have GC pause here*

 2015-08-20T07:32:31.959-0700: [GC2015-08-20T07:32:31.960-0700: [ParNew 
 (promotion failed): 172544K-170208K(172544K), 0.8968931 
 secs]2015-08-20T07:32:32.857-0700: [CMS2015-08-20T07:32:39.682-0700: 
 [CMS-concurrent-sweep: 7.003/7.909 secs] [Times: user=8.78 sys=0.40, 
 real=7.91 secs] 

  (concurrent mode failure): 5760566K-2755481K(6099776K), 30.9310318 secs] 
 5924201K-2755481K(6272320K), [CMS Perm : 142090K-141971K(237016K)], 
 31.8286597 secs] [Times: user=32.22 sys=0.38, real=31.83 secs] 

  

 *We have almost 32 seconds GC pause. The following heartbeat request are 
 buffered and played right after GC pause in one single second!. All the 
 connection is being disassociated with other cluster members.*

  

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon

Re: [akka-user] Re: How to survive long GC pause

[Guido Medina]

Hi Patrik,

I'm quite sure his problem has anything to do with Akka but lack of proper 
JVM parameters, that 32 seconds pause shown in his logs would be enough to 
cause nodes de-association and connection failures/timeouts of Akka remote 
(without mentioning Akka cluster and other extensions) hence I suggested to 
switch to newest garbage collector, of course the ideal thing to do is for 
OP to post JVM parameters and more information about the JVM in use to aid 
better.

Hope that helps,

Guido.

On Monday, August 24, 2015 at 2:41:53 PM UTC+1, Patrik Nordwall wrote:

 Note that there is no: akka.cluster.transport-failure-detector

 you probably mean: akka.remote.transport-failure-detector

 The Disassociated might be triggered by that failure detector and you can 
 try to increase 

 akka.remote.transport-failure-detector.acceptable-heartbeat-pause

 /Patrik

 On Fri, Aug 21, 2015 at 11:29 AM, Guido Medina oxy...@gmail.com 
 javascript: wrote:

 Try the JVM option -XX:+UseG1GC, assuming you are using at least JVM 
 7uLatest where latest should be 79 or 80. The new GC algorithm doesn't stop 
 world, it works more often and can make your application a bit slower (on a 
 very hyper micro-level) but GC will now be consistent.


 On Friday, August 21, 2015 at 6:36:11 AM UTC+1, Ara Tatous wrote:

 I have a configuration of Akka cluster with 4 nodes. Let's call them 
 Engine and Warehouse.  

 In Engine:

  

 *Everything is normal*

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

  

  

 *We have GC pause here*

 2015-08-20T07:32:31.959-0700: [GC2015-08-20T07:32:31.960-0700: [ParNew 
 (promotion failed): 172544K-170208K(172544K), 0.8968931 
 secs]2015-08-20T07:32:32.857-0700: [CMS2015-08-20T07:32:39.682-0700: 
 [CMS-concurrent-sweep: 7.003/7.909 secs] [Times: user=8.78 sys=0.40, 
 real=7.91 secs] 

  (concurrent mode failure): 5760566K-2755481K(6099776K), 30.9310318 
 secs] 5924201K-2755481K(6272320K), [CMS Perm : 142090K-141971K(237016K)], 
 31.8286597 secs] [Times: user=32.22 sys=0.38, real=31.83 secs] 

  

 *We have almost 32 seconds GC pause. The following heartbeat request are 
 buffered and played right after GC pause in one single second!. All the 
 connection is being disassociated with other cluster members.*

  

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1

[akka-user] Re: How to survive long GC pause

[Guido Medina]

Try the JVM option -XX:+UseG1GC, assuming you are using at least JVM 
7uLatest where latest should be 79 or 80. The new GC algorithm doesn't stop 
world, it works more often and can make your application a bit slower (on a 
very hyper micro-level) but GC will now be consistent.

On Friday, August 21, 2015 at 6:36:11 AM UTC+1, Ara Tatous wrote:

 I have a configuration of Akka cluster with 4 nodes. Let's call them 
 Engine and Warehouse.  

 In Engine:

  

 *Everything is normal*

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

 [DEBUG] [08/20/2015 07:32:25.082] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-80] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:32:25.084] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-98] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat response from 
 [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

  

  

 *We have GC pause here*

 2015-08-20T07:32:31.959-0700: [GC2015-08-20T07:32:31.960-0700: [ParNew 
 (promotion failed): 172544K-170208K(172544K), 0.8968931 
 secs]2015-08-20T07:32:32.857-0700: [CMS2015-08-20T07:32:39.682-0700: 
 [CMS-concurrent-sweep: 7.003/7.909 secs] [Times: user=8.78 sys=0.40, 
 real=7.91 secs] 

  (concurrent mode failure): 5760566K-2755481K(6099776K), 30.9310318 secs] 
 5924201K-2755481K(6272320K), [CMS Perm : 142090K-141971K(237016K)], 
 31.8286597 secs] [Times: user=32.22 sys=0.38, real=31.83 secs] 

  

 *We have almost 32 seconds GC pause. The following heartbeat request are 
 buffered and played right after GC pause in one single second!. All the 
 connection is being disassociated with other cluster members.*

  

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2552]

 [DEBUG] [08/20/2015 07:33:03.794] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-23] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod2:2551]

 [DEBUG] [08/20/2015 07:33:03.808] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-81] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 
 Heartbeat to [akka.tcp://EngineWarehouseActorSystem@compprod1:2551]

 [DEBUG] [08/20/2015 07:33:03.808] 
 [EngineWarehouseActorSystem-akka.actor.default-dispatcher-81] 
 [akka.tcp://EngineWarehouseActorSystem@compprod2:2552/system/cluster/core/daemon/heartbeatSender]
  
 Cluster Node [akka.tcp://EngineWarehouseActorSystem@compprod2:2552] - 

[akka-user] Akka HTTP web-socket authentication session ID

[Guido Medina]

Hi,

I'm trying to implement the following workflow or checking if there is an 
example (preferably in Java) somewhere:

   1. Connect via web-socket, authenticate and receive a session ID 
   identifier.
   2. Using that session ID an actor is created which will handle all 
   subsequent requests coming from that user.
   3. That session ID can also subscribe to specific events which will make 
   the server send data back events to that session using the created actor.
   4. The actor of course has a session timeout so it will expire after few 
   minutes.


So my question is, what is the data structure that I need to wrap inside 
that actor in order to respond back to that session ID? A SourceT, T, I 
might not completely understood Akka HTTP and Streams documentation so I'm 
wondering if there is an example with such or similar scenario.

The examples I have seen so far are very straight forward, send request, 
handle request and return a Message, but I'm looking for a data structure 
that can continuously stream data back on the already established 
web-socket connection, maybe it is more obvious than what I think and I 
have just not seen it.

Best regards,

Guido.

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

[akka-user] Re: Akka config to include "common.conf" programmatically

[Guido Medina]

I tried using withFallback(...) which has different semantics and behavior, 
I need something that emulates include programmatically.

On Thursday, October 29, 2015 at 2:31:59 PM UTC, Guido Medina wrote:
>
> Hi,
>
> I have the following configuration which works fine but because we are 
> externalizing so that IT admins have full control of it, we need to be able 
> to mimic the *include "common"* section programmatically, here is the 
> configution:
>
> include "common"
>
> engine {
>   cluster.name = ${engine.cluster.name}
>
>
>   admin {
> hostname = ${admin.hostname}
> port = ${admin.port}
>   }
> }
>
>
> akka.cluster {
>   roles = ["account"]
>   seed-nodes = ["akka.tcp://"${engine.cluster.name}"@"${engine.admin.
> hostname}":"${engine.admin.port}]
> }
>
>
>
> common.conf is a big conf file with all common configuration for every 
> micro-service, what we want is to be able to load that configuration and 
> include "common" without to explicitly say that on the conf file header 
> section, here is our current common.conf file:
>
> akka {
>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>   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"
>   throughput = 2
>
>   fork-join-executor {
> parallelism-min = 4
> parallelism-factor = 1.0
> parallelism-max = 16
> task-peeking-mode = "FIFO"
>   }
> }
>
> kryo {
>   type = "nograph"
>   idstrategy = "default"
>   serializer-pool-size = 512
>   kryo-reference-map = false
> }
>   }
>
>   remote {
> log-remote-lifecycle-events = off
>
> netty.tcp {
>   port = 0
>
>   server-socket-worker-pool {
> pool-size-min = 8
> pool-size-factor = 1.0
> pool-size-max = 16
>   }
>
>
>   client-socket-worker-pool {
> pool-size-min = 8
> pool-size-factor = 1.0
> pool-size-max = 16
>   }
> }
>
> default-remote-dispatcher {
>   type = Dispatcher
>   executor = "fork-join-executor"
>
>   fork-join-executor {
> parallelism-min = 4
> parallelism-factor = 1.0
> parallelism-max = 16
> task-peeking-mode = "FIFO"
>   }
> }
>   }
>
>   cluster {
> auto-down-unreachable-after = 10s
> metrics.enabled = off
> jmx.enabled = off
>   }
> }
>
>
> engine.dispatcher {
>   type = Dispatcher
>   executor = "fork-join-executor"
>   throughput = 2
>
>   fork-join-executor {
> parallelism-min = 8
> parallelism-factor = 1.0
> parallelism-max = 16
> task-peeking-mode = "FIFO"
>   }
> }
>
>
> So far we are able to only:
>
> ConfigFactory.load("resource_name")
>
>
> where resource_name.conf has the include header section.
>
> Best regards,
>
> Guido.
>

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

[akka-user] Akka config to include "common.conf" programmatically

[Guido Medina]

Hi,

I have the following configuration which works fine but because we are 
externalizing so that IT admins have full control of it, we need to be able 
to mimic the *include "common"* section programmatically, here is the 
configution:

include "common"

engine {
  cluster.name = ${engine.cluster.name}


  admin {
hostname = ${admin.hostname}
port = ${admin.port}
  }
}


akka.cluster {
  roles = ["account"]
  seed-nodes = ["akka.tcp://"${engine.cluster.name}"@"${engine.admin.
hostname}":"${engine.admin.port}]
}



common.conf is a big conf file with all common configuration for every 
micro-service, what we want is to be able to load that configuration and 
include "common" without to explicitly say that on the conf file header 
section, here is our current common.conf file:

akka {
  loggers = ["akka.event.slf4j.Slf4jLogger"]
  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"
  throughput = 2

  fork-join-executor {
parallelism-min = 4
parallelism-factor = 1.0
parallelism-max = 16
task-peeking-mode = "FIFO"
  }
}

kryo {
  type = "nograph"
  idstrategy = "default"
  serializer-pool-size = 512
  kryo-reference-map = false
}
  }

  remote {
log-remote-lifecycle-events = off

netty.tcp {
  port = 0

  server-socket-worker-pool {
pool-size-min = 8
pool-size-factor = 1.0
pool-size-max = 16
  }


  client-socket-worker-pool {
pool-size-min = 8
pool-size-factor = 1.0
pool-size-max = 16
  }
}

default-remote-dispatcher {
  type = Dispatcher
  executor = "fork-join-executor"

  fork-join-executor {
parallelism-min = 4
parallelism-factor = 1.0
parallelism-max = 16
task-peeking-mode = "FIFO"
  }
}
  }

  cluster {
auto-down-unreachable-after = 10s
metrics.enabled = off
jmx.enabled = off
  }
}


engine.dispatcher {
  type = Dispatcher
  executor = "fork-join-executor"
  throughput = 2

  fork-join-executor {
parallelism-min = 8
parallelism-factor = 1.0
parallelism-max = 16
task-peeking-mode = "FIFO"
  }
}


So far we are able to only:

ConfigFactory.load("resource_name")


where resource_name.conf has the include header section.

Best regards,

Guido.

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

Re: [akka-user] Re: Akka config to include "common.conf" programmatically

[Guido Medina]

I tried renaming "common.conf" to "application.conf" but the thing is that 
I'm not making a fat jar so the side effect you were expecting is not 
happening, it would at been a nice trick though, it is not a big deal to 
add *include "common"*, common.jar is one dependency of the project, we 
avoided completely the need of shade or fat jar and instead rely on a 
script generator which creates the .sh executable for each micro-service, 
but each conf is embedded and we would like to pass the conf for each 
microservice as a parameter hence I was looking for a way to remove the 
include responsability and make it programmatically instead.

Thanks for the help though.

Regards,

Guido.

On Thursday, October 29, 2015 at 4:08:54 PM UTC, √ wrote:
>
> make the common.conf the application.conf and then load the externally 
> provided config with ConfigFactory.load?
>
> On Thu, Oct 29, 2015 at 5:03 PM, Guido Medina <oxy...@gmail.com 
> > wrote:
>
>> I tried using withFallback(...) which has different semantics and 
>> behavior, I need something that emulates include programmatically.
>>
>>
>> On Thursday, October 29, 2015 at 2:31:59 PM UTC, Guido Medina wrote:
>>>
>>> Hi,
>>>
>>> I have the following configuration which works fine but because we are 
>>> externalizing so that IT admins have full control of it, we need to be able 
>>> to mimic the *include "common"* section programmatically, here is the 
>>> configution:
>>>
>>> include "common"
>>>
>>> engine {
>>>   cluster.name = ${engine.cluster.name}
>>>
>>>
>>>   admin {
>>> hostname = ${admin.hostname}
>>> port = ${admin.port}
>>>   }
>>> }
>>>
>>>
>>> akka.cluster {
>>>   roles = ["account"]
>>>   seed-nodes = ["akka.tcp://"${engine.cluster.name}"@"${engine.admin.
>>> hostname}":"${engine.admin.port}]
>>> }
>>>
>>>
>>>
>>> common.conf is a big conf file with all common configuration for every 
>>> micro-service, what we want is to be able to load that configuration and 
>>> include "common" without to explicitly say that on the conf file header 
>>> section, here is our current common.conf file:
>>>
>>> akka {
>>>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>>>   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"
>>>   throughput = 2
>>>
>>>   fork-join-executor {
>>> parallelism-min = 4
>>> parallelism-factor = 1.0
>>> parallelism-max = 16
>>> task-peeking-mode = "FIFO"
>>>   }
>>> }
>>>
>>> kryo {
>>>   type = "nograph"
>>>   idstrategy = "default"
>>>   serializer-pool-size = 512
>>>   kryo-reference-map = false
>>> }
>>>   }
>>>
>>>   remote {
>>> log-remote-lifecycle-events = off
>>>
>>> netty.tcp {
>>>   port = 0
>>>
>>>   server-socket-worker-pool {
>>> pool-size-min = 8
>>> pool-size-factor = 1.0
>>> pool-size-max = 16
>>>   }
>>>
>>>
>>>   client-socket-worker-pool {
>>> pool-size-min = 8
>>> pool-size-factor = 1.0
>>> pool-size-max = 16
>>>   }
>>> }
>>>
>>> default-remote-dispatcher {
>>>   type = Dispatcher
>>>   executor = "fork-join-executor"
>>>
>>>   fork-join-executor {
>>> parallelism-min = 4
>>> parallelism-factor = 1.0
>>> parallelism-max = 16
>>> task-peeking-mode = "FIFO"
>>>   }
>>> }
>>>   }
>>>
>>>   cluster {
>>> auto-down-unreachable-after = 10s
>>> metr

Re: [akka-user] Re: deserializing ActorRef's after jvm restart, will it point to the correct actor?

[Guido Medina]

Ah, in a way the code I sent before is for a set of Actor systems connected 
between them all belonging to the same cluster, I'm not sure how Akka 
Cluster will perform with 1000 nodes, why so many nodes? Answering your 
question if a node leaves the cluster under any circumstances an event is 
generated on all other nodes so I remove that branch of actors from each 
node's cache, I only call once when a node comes up to locate the 
supervisor actor via selection remotely because that one is always on 
/user/$role where $role in ["account", "order", "signal", ..., "http"] etc

Also, children actors extend an abstract template class which basically 
notify the other remote supervisor of its life-cycle (created, destroyed), 
one node going down is an special action so child by child are not remove 
but their whole branch, because; they belong to a tree, a hierarchy of 
supervisors with children.

There are special supervisors that have no children, specially for 
round-robin supervisor, say, a supervisor that process stateless requests 
and each other node have a router reference to such category instead of a 
single reference to a supervisor so instead of sending a message to a 
supervisor I send a message to a round robin router.

Cheers,

Guido.

On Tuesday, November 10, 2015 at 12:27:02 PM UTC, Kostas kougios wrote:
>
> Hi Guido, mine is a similar use case. One difference is that I store the 
> actorrefs to files on disk as I am expecting to have a lot of them and 
> don't want to keep them into memory. I would expect to say have 1000 
> servers with 1000 actorrefs per server for 1 "index" of mine  (index = 
> database index as I am building a database). This means it is costly to do 
> batch updates of the actor refs. So what I ended doing so far is to 
> serialize the actor path (after injecting the real server RootAddress to 
> it). Then I resolveOne actorRef and I keep that ref into memory for 10 
> seconds and then resolveOne again. This means that my servers don't have to 
> communicate up/down and it works if servers crash/restarts too. The whole 
> trick is achived by replacing ActorRef with EndpointActorRef (a class of 
> mine) which does the actorPath manipulation and takes care of serializing 
> the actorPath instead of actorRef.
>
> Overall I might end up serializing actorPath for actors in the same jvm - 
> if the actor is inactive for a long time. This means actors might come and 
> go quite frequently even if the servers are up.
>
> What happens to your cache if a server crashes? Do the cache removes the 
> invalid actor refs somehow?
>
> Cheers
>
>
> On 09/11/15 23:26, Guido Medina wrote:
>
> Hi Kostas, 
>
> I have few micro-services and some supervisor actors which inherited from 
> an AbstractSupervisor template which uses local caches per microservices 
> with an optimistic approach, example with requirements:
>
> 1) There is a uniform pattern where each micro-service is an independent 
> category and also each category has the capability of being either a 
> round-robin supervisor only or a supervisor with children (sharding)
> 2) Each category informs other categories by using cluster events when a 
> supervisor comes up and/or any/of its children.
> 3) If a supervisor dies, also its children die which means that other 
> supervisors in other categories are informed hence the cache for that 
> supervisor is invalidated.
> 4) Each children has an Integer ID, say, category account and account 1, 
> 2, , 10 so I don't bother giving a path to children, I know a children 
> of account is ../acccount/$blah blah incarnation, so what I do to inform 
> caches of other microservices that Account ID X = ActorRef Y
>
> All this would suggest that cluster sharding is what I use but no, it is 
> very similar but I have my own implementation constrained more to a DDD.
>
> I probably confused you more than what I helped you, all I wanted to say 
> is that caching a key with a corresponding ActorRef is not a bad idea, of 
> course if one of your microservices goes down you need to invalidate caches 
> in order to avoid actor selection calls which I would discourage you to do, 
> instead (but not free since I had to put lot of work on contemplating 
> different scenarios), do an inventory of your events and try to react on 
> them.
>
> I particularly designed the application to build the caches using cluster 
> events and template pattern (preStart and postStop for some type of actors 
> would inform other caches)
>
> Having also an uniform hierarchy will help like supervisor -> children so 
> that you can add or invalidate a whole branch (I do that too with my 
> mini-framework)
>
> Hope all these crazy ideas can help you.
>
> Best regards,
&g

[akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

[Guido Medina]

I have actors such like *AccountProcessor* and *AccountPersistor*, 
AccountPersistor is a child of AccountProcessor and at its creation I pass 
a different dispatcher, assuming your code is in Scala here is better 
explained:

http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html

HTH,

Guido.

On Monday, November 9, 2015 at 10:23:38 PM UTC, Kostas kougios wrote:
>
> I have some code that will take some time to execute. This code runs in a 
> few steps with each step "blocking" for some time to store data into files.
>
> I am thinking in creating a new actor which can receive 1 message for each 
> step. Will the block part affect only that actor or will other actors be 
> affected (since threads are reused in the actorsystem)?
>

-- 
>>  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: deserializing ActorRef's after jvm restart, will it point to the correct actor?

[Guido Medina]

Each server is subscribed to cluster events and each event is received by 
the supervisor of that server; when I say server think a micro-service and 
when I say supervisor think a supervisor for the category of that 
micro-service like Account supervisor or Order supervisor, etc, each server 
event message is dealt with accordingly, other things happen of course, if 
a member comes up to the cluster it notifies other members saying, here is 
my ActorRef supervisor, so to that actor ref other node send their caches, 
the beauty of it is that actorref can be use as a Map key, so if a node 
goes down, I locate the key and remove the children keys, partial 
production and working Java 8 code:

import akka.actor.*;
import akka.cluster.Cluster;
import akka.cluster.ClusterEvent.MemberEvent;
import akka.cluster.ClusterEvent.MemberUp;
import akka.cluster.Member;
import akka.dispatch.Futures;
import akka.dispatch.OnComplete;
import akka.event.Logging;
import akka.event.LoggingAdapter;
import akka.pattern.Patterns;
import akka.routing.RoundRobinRoutingLogic;
import akka.routing.Router;
-- removed company imports;
import com.zaxxer.hikari.HikariDataSource;
import scala.concurrent.ExecutionContextExecutor;
import scala.concurrent.Future;

import javax.persistence.EntityManagerFactory;
import java.io.Serializable;
import java.util.*;
import java.util.concurrent.ConcurrentMap;

import static akka.actor.ActorRef.noSender;
import static akka.cluster.ClusterEvent.initialStateAsEvents;
-- removed company imports;

/**
 * @author Guido Medina, created on 17/03/15.
 */
public abstract class SupervisorAbstractActor<
  K extends Serializable,
  T extends GenericEntity<K, T>,
  S extends SupervisorAbstractActor<K, T, S, C>,
  C extends ChildAbstractActor<K, T, S, C>> extends DefaultAbstractActor {

  public static final String ENGINE_DISPATCHER = "engine.dispatcher";
  public static final String DEFAULT_DISPATCHER = 
"akka.actor.default-dispatcher";

  public final SupervisorKey key;
  public final HikariDataSource ds;
  public final EntityManagerFactory emf;
  public final LoggingAdapter log;

  final ConcurrentMap<SupervisorType, Router> routers = newConcurrentMap();
  final ComputingConcurrentMap<SupervisorType, 
ComputingConcurrentMap<SupervisorKey, ConcurrentMap<Integer, ActorRef>>>
actors = newComputingConcurrentMap(supervisorType -> 
newComputingConcurrentMap(supervisorKey -> newConcurrentMap()));

  public SupervisorAbstractActor(SupervisorType type) {
final ActorSystem system = context().system();
log = Logging.getLogger(system, this);
key = new SupervisorKey(type, self());
try {
  ds = createDataSource(system.settings().config());
  emf = createEntityManagerFactory(ds);
} catch (Exception e) {
  log.error("Error starting supervisor " + key, e);
  system.terminate();
  throw e;
}
Cluster.get(system).subscribe(key.supervisorRef, 
initialStateAsEvents(), MemberEvent.class);
  }

  protected abstract ChildActorCreator<K, T, S, C> creator(T entity);

  protected ActorRef createChildActor(ActorContext context, T entity) {
return 
context.actorOf(Props.create(creator(entity)).withDispatcher(DEFAULT_DISPATCHER));
  }

  @Override
  public SupervisorStrategy supervisorStrategy() {
return ALWAYS_RESUME_STRATEGY;
  }

  @Override
  public void postStop() {
emf.close();
ds.close();
  }

  private void createSupervisor(SupervisorCommand<ConcurrentMap<Integer, 
ActorRef>> command) {
actors.computeIfAbsent(command.key.type).compute(command.key, 
(supervisor, children) -> {
  if (children == null) {
if (command.key.type.distributionType.isRoundRobin) {
  routers.compute(command.key.type, (type, router) ->
(router == null ? new Router(new RoundRobinRoutingLogic()) : 
router).addRoutee(command.key.supervisorRef));
}
return command.value != null ? command.value : newConcurrentMap();
  } else {
if (command.value != null) {
  children.putAll(command.value);
}
return children;
  }
});
  }

  private void registerKey(Member member) {
final Set roles = member.getRoles();
if (!roles.isEmpty()) {
  final String role = roles.iterator().next();
  if (SupervisorType.findBy(role) != key.type) {
context().actorSelection(member.address() + "/user/" + role).
  tell(SupervisorCommand.registerKey(), key.supervisorRef);
  }
}
  }

  private void registerKey(SupervisorCommand 
supervisorCommand) {

createSupervisor(SupervisorCommand.createSupervisor(supervisorCommand.key, 
null));
final ConcurrentMap<Integer, ActorRef> cache = findCacheBy(key);
supervisorCommand.key.supervisorRef.
  tell(SupervisorCommand.createSupervisor(key, cache.isEmpty() ? null : 
cache), noSender());
  }

  private void removeSupervisor(Mem

Re: [akka-user] Re: Akka config to include "common.conf" programmatically

[Guido Medina]

Just to let you know guys that I was able to make this work like  charm 
using the following:

static.conf is a placeholder that need to be resolve later, it includes 
common.conf:

include "common.conf"


akka.remote.netty.tcp {
  hostname = ${engine.admin.hostname}
  port = ${engine.admin.port}
}


akka.cluster {
  roles = ["admin"]
  seed-nodes = ["akka.tcp://"${engine.cluster.name}"@"${engine.admin.
hostname}":"${engine.admin.port}]
}


And the code to do it, the key is to resolve once all resources are parsed 
in a single config, if you try to load, it will resolve, don't load, parse 
with all fallback you need and then finally resolve()

final Config config = ConfigFactory.parseFile(new File(args[0])).
withFallback(ConfigFactory.parseResources("static.conf")).resolve();


Thanks for the ideas,

Guido.

On Thursday, October 29, 2015 at 4:24:55 PM UTC, Guido Medina wrote:
>
> I tried renaming "common.conf" to "application.conf" but the thing is that 
> I'm not making a fat jar so the side effect you were expecting is not 
> happening, it would at been a nice trick though, it is not a big deal to 
> add *include "common"*, common.jar is one dependency of the project, we 
> avoided completely the need of shade or fat jar and instead rely on a 
> script generator which creates the .sh executable for each micro-service, 
> but each conf is embedded and we would like to pass the conf for each 
> microservice as a parameter hence I was looking for a way to remove the 
> include responsability and make it programmatically instead.
>
> Thanks for the help though.
>
> Regards,
>
> Guido.
>
> On Thursday, October 29, 2015 at 4:08:54 PM UTC, √ wrote:
>>
>> make the common.conf the application.conf and then load the externally 
>> provided config with ConfigFactory.load?
>>
>> On Thu, Oct 29, 2015 at 5:03 PM, Guido Medina <oxy...@gmail.com> wrote:
>>
>>> I tried using withFallback(...) which has different semantics and 
>>> behavior, I need something that emulates include programmatically.
>>>
>>>
>>> On Thursday, October 29, 2015 at 2:31:59 PM UTC, Guido Medina wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have the following configuration which works fine but because we are 
>>>> externalizing so that IT admins have full control of it, we need to be 
>>>> able 
>>>> to mimic the *include "common"* section programmatically, here is the 
>>>> configution:
>>>>
>>>> include "common"
>>>>
>>>> engine {
>>>>   cluster.name = ${engine.cluster.name}
>>>>
>>>>
>>>>   admin {
>>>> hostname = ${admin.hostname}
>>>> port = ${admin.port}
>>>>   }
>>>> }
>>>>
>>>>
>>>> akka.cluster {
>>>>   roles = ["account"]
>>>>   seed-nodes = ["akka.tcp://"${engine.cluster.name}"@"${engine.admin.
>>>> hostname}":"${engine.admin.port}]
>>>> }
>>>>
>>>>
>>>>
>>>> common.conf is a big conf file with all common configuration for every 
>>>> micro-service, what we want is to be able to load that configuration and 
>>>> include "common" without to explicitly say that on the conf file header 
>>>> section, here is our current common.conf file:
>>>>
>>>> akka {
>>>>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>>>>   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"
>>>>   throughput = 2
>>>>
>>>>   fork-join-executor {
>>>> parallelism-min = 4
>>>> parallelism-factor = 1.0
>>>> parallelism-max = 16
>>>> task-peeking-mode = "FIFO"
>>>>   }
>>>> }
>>>>
>>>> kryo {
>>>>   type = "nograph"
>>

[akka-user] Re: Akka sensible design choice for a stateless server

[Guido Medina]

I think you are looking at it from a very simplistic perspective without 
taking into account many details that happen behind the scene, people tend 
to use concurrent execution wrong where at the end of the day you still 
have a finite set of processors -and small amount- so concurrent IMHO or at 
least how concurrency is mostly used, it tends to overwhelm and exhaust 
resources instead of making things faster, Actors -using my own wording and 
not the documentation which is great and would had answered your concerns 
and more- are merely mailboxes, and thread pools will decide which mailbox 
is going to be processed next.

So if you think of Actors as an analogy of synchronous and blocking your 
analogy is completely wrong, it is serialized yes to avoid context 
switching, but as a single serialized unit of execution once it starts, but 
it is asynchronous because delivering the message to a mailbox and 
processing are two completely separated operation, I tend to recommend 
people to read the 1st two or three parts of Akka reference documentation:

http://doc.akka.io/docs/akka/2.4.0/scala.html

Akka is not the only framework that follows such asynchronous processing, 
look at Vert.x and Vert.x  Web for example, which is simpler and similar, 
though not as rich and limiting in serialization of their message passing.

Hope that helps,

Guido.

On Monday, November 9, 2015 at 9:02:08 PM UTC, Stuart Reynolds wrote:
>
> In a highly concurrent system, it seems to me that the major benefit of 
> using Akka is not in allowing concurrent computation (Futures work more 
> simply), but in ensuring correct execution of things that should not happen 
> concurrently (e.g. serializing access to state).
> (from reading this: Don't use Actors for concurrency 
> ).
>
> Is this a fair way to think about Akka?
>
> Suppose I build a stateless webserver, what benefits (if any) does Akka 
> provide in its implementation?
>
> For example, for Spray  HTTP servers, spray encourages 
> the use of Actors in routing requests. That is, a single actor exclusively 
> blocks the routing of other requests until either, the request completes or 
> a child actor is created to manage this. Why does Akka help here? It seems 
> to me that it encourages blocking for no benefit  -- since routing is 
> typically a stateless operation, what's the rationale in making this 
> operation an actor?
>
> Thanks,
> - Stuart
>

-- 
>>  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] Re: Akka sensible design choice for a stateless server

[Guido Medina]

The analogy of the JMM for Akka is also very interesting, it is an 
important aspect of Akka to be aware 
of http://doc.akka.io/docs/akka/2.4.0/general/jmm.html

On Monday, November 9, 2015 at 9:02:08 PM UTC, Stuart Reynolds wrote:
>
> In a highly concurrent system, it seems to me that the major benefit of 
> using Akka is not in allowing concurrent computation (Futures work more 
> simply), but in ensuring correct execution of things that should not happen 
> concurrently (e.g. serializing access to state).
> (from reading this: Don't use Actors for concurrency 
> ).
>
> Is this a fair way to think about Akka?
>
> Suppose I build a stateless webserver, what benefits (if any) does Akka 
> provide in its implementation?
>
> For example, for Spray  HTTP servers, spray encourages 
> the use of Actors in routing requests. That is, a single actor exclusively 
> blocks the routing of other requests until either, the request completes or 
> a child actor is created to manage this. Why does Akka help here? It seems 
> to me that it encourages blocking for no benefit  -- since routing is 
> typically a stateless operation, what's the rationale in making this 
> operation an actor?
>
> Thanks,
> - Stuart
>

-- 
>>  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: deserializing ActorRef's after jvm restart, will it point to the correct actor?

[Guido Medina]

Hi Kostas,

I have few micro-services and some supervisor actors which inherited from 
an AbstractSupervisor template which uses local caches per microservices 
with an optimistic approach, example with requirements:

1) There is a uniform pattern where each micro-service is an independent 
category and also each category has the capability of being either a 
round-robin supervisor only or a supervisor with children (sharding)
2) Each category informs other categories by using cluster events when a 
supervisor comes up and/or any/of its children.
3) If a supervisor dies, also its children die which means that other 
supervisors in other categories are informed hence the cache for that 
supervisor is invalidated.
4) Each children has an Integer ID, say, category account and account 1, 2, 
, 10 so I don't bother giving a path to children, I know a children of 
account is ../acccount/$blah blah incarnation, so what I do to inform 
caches of other microservices that Account ID X = ActorRef Y

All this would suggest that cluster sharding is what I use but no, it is 
very similar but I have my own implementation constrained more to a DDD.

I probably confused you more than what I helped you, all I wanted to say is 
that caching a key with a corresponding ActorRef is not a bad idea, of 
course if one of your microservices goes down you need to invalidate caches 
in order to avoid actor selection calls which I would discourage you to do, 
instead (but not free since I had to put lot of work on contemplating 
different scenarios), do an inventory of your events and try to react on 
them.

I particularly designed the application to build the caches using cluster 
events and template pattern (preStart and postStop for some type of actors 
would inform other caches)

Having also an uniform hierarchy will help like supervisor -> children so 
that you can add or invalidate a whole branch (I do that too with my 
mini-framework)

Hope all these crazy ideas can help you.

Best regards,

Guido.

On Friday, November 6, 2015 at 4:15:24 PM UTC, Kostas kougios wrote:
>
> Well, I refactored my code to cache actorpaths but indeed during creation 
> all actorpaths are local and when they are transmitted over the wire they 
> remain local => pointing to the wrong path.
>
> I've manually modified the address part of the path myself so that it 
> contains the host & port of the server. But the process seems awkward , am 
> I missing something?
>
>

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

[Guido Medina]

Hi Viktor,

Maybe you could abstract the transport API and create multiple 
implementations, with both Netty and Aeron, Aeron might not be as fast as 
you think, some performance benchmark on different transports and keep a 
updated score table to keep the user informed on what transport works best 
under specific scenarios like:

   - Many small messages (high frequency with low latency)
   - Standard amount of messages with standard size (amount of messages and 
   size TBD)
   - And for large messages.
   
So different transports and/or configuration of them might provide a better 
performance for different scenarios.

My main concern is that nobody seems to be concerned AFAIK with this 
subject nor aware on how slow the current remote transport is hence my post 
subject "Akka remote communication roadmap?", at least it is slow for my 
application and its configuration.

Best regards,

Guido.

On Wednesday, October 14, 2015 at 1:49:04 PM UTC+1, √ wrote:
>
> For extremely low latency we'd want to use a transport like Aeron.
>
> On Wed, Oct 14, 2015 at 1:34 PM, Guido Medina <oxy...@gmail.com 
> > wrote:
>
>> Very nice, I wasn't aware of it, IMHO it needs something like that as 
>> proper remote communication is the foundation for distributed 
>> micro-services, our application is a FOREX trading application and we might 
>> eventually move to high-frequency trading, it is in production and for what 
>> we do at the moment the times are within the OK parameters, but for high 
>> frequency trading it will be a show stopper, I do believe Akka remote, 
>> cluster and other remote related extensions will play a nice role in the 
>> future of financial services, or maybe I'm just too excited with Akka and 
>> getting ahead of myself, who knows ;-)
>>
>> Thank you very much for that info,
>>
>> Guido.
>>
>>
>> On Wednesday, October 14, 2015 at 12:27:46 PM UTC+1, Andrey Kuznetsov 
>> wrote:
>>>
>>> Did you see this? 
>>> https://github.com/typesafehub/netty-reactive-streams/blob/master/pom.xml
>>> I think it's a first step of migration to streams. It already depends on 
>>> Netty 4.
>>>
>>> On Wednesday, October 14, 2015 at 12:22:33 PM UTC+3, Guido Medina wrote:
>>>>
>>>> Hi,
>>>>
>>>> I created a similar post some time ago but the circumstances were a bit 
>>>> different, the project I'm working at the moment has the requirement of 
>>>> processing messages within 5ms, and I chose Akka remote to do this job, 
>>>> the 
>>>> project also requires to be distributed so again, Akka remote with 
>>>> clustering was the clear candidate, I have done lots of research and have 
>>>> done the following:
>>>>
>>>>- Properly configured Netty TCP client and server pools.
>>>>- Properly configured serialization using Kryo.
>>>>- I have created small, immutable and concise Java classes for 
>>>>sending messages between remote actors.
>>>>- I have configured properly Akka remote thread pools.
>>>>
>>>> And it doesn't matter what I do, I still get a high time with the 1st 
>>>> few messages, I cannot make my application send messages in less than 2ms 
>>>> to 5ms after initial warm up, sometimes it takes even more, I would be 
>>>> curious about low latency applications out there that use Akka remote, the 
>>>> state of Akka remote IMHO is "out-dated?"
>>>>
>>>> I think it needs more attention, I'm quite sure the community 
>>>> appreciates so many features you guys are releasing but I think remote 
>>>> communication is not only an important but crucial aspect of Akka.
>>>>
>>>> In my old post someone mentioned there would be an Akka remote 
>>>> rewritten using Akka streams, it has been some reasonable time now to 
>>>> start 
>>>> thinking about, Akka 2.4, Akka HTTP 1.0 are already released and still 
>>>> Akka 
>>>> remote is using Netty 3, a shorter time alternative would be to just 
>>>> migrate Akka remote to Netty 4 which someone has proven already it faster 
>>>> and consistent for Akka.
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Guido.
>>>>
>>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>

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

[Guido Medina]

If that was my expertise I would at definitely done something already, but 
the only thing I have done with Netty is a TCP server for a logger hardware 
for the utility industry, nothing that would require such level of details 
like someone with hands on NIO, Scala and Serialization altogether.

Also "Hepin" had written something and the relevant git URL I copied from 
another post, but that concluded with the statement that Akka remote was 
going to be replaced by Akka IO/streams, so not sure if this attempt is 
somehow in the right way:

>From Hepin: 

> I push the io side code here
> https://github.com/qgame/engine/tree/master/framework/akka-io-netty
>
> https://github.com/qgame/engine/tree/master/framework/akka-remote-transport-io-netty/
>

Original post 
https://groups.google.com/d/msg/akka-user/0p-1UWT3uas/OBl1C02xWWUJ

Best regards,

Guido. 

On Thursday, October 15, 2015 at 10:21:39 AM UTC+1, √ wrote:
>
> Hi Guido,
>
> Would you be interested in contributing towards this?
>
> On Thu, Oct 15, 2015 at 11:02 AM, Guido Medina <oxy...@gmail.com 
> > wrote:
>
>> Hi Viktor,
>>
>> Maybe you could abstract the transport API and create multiple 
>> implementations, with both Netty and Aeron, Aeron might not be as fast as 
>> you think, some performance benchmark on different transports and keep a 
>> updated score table to keep the user informed on what transport works best 
>> under specific scenarios like:
>>
>>- Many small messages (high frequency with low latency)
>>- Standard amount of messages with standard size (amount of messages 
>>and size TBD)
>>- And for large messages.
>>
>> So different transports and/or configuration of them might provide a 
>> better performance for different scenarios.
>>
>> My main concern is that nobody seems to be concerned AFAIK with this 
>> subject nor aware on how slow the current remote transport is hence my post 
>> subject "Akka remote communication roadmap?", at least it is slow for my 
>> application and its configuration.
>>
>> Best regards,
>>
>> Guido.
>>
>> On Wednesday, October 14, 2015 at 1:49:04 PM UTC+1, √ wrote:
>>>
>>> For extremely low latency we'd want to use a transport like Aeron.
>>>
>>> On Wed, Oct 14, 2015 at 1:34 PM, Guido Medina <oxy...@gmail.com> wrote:
>>>
>>>> Very nice, I wasn't aware of it, IMHO it needs something like that as 
>>>> proper remote communication is the foundation for distributed 
>>>> micro-services, our application is a FOREX trading application and we 
>>>> might 
>>>> eventually move to high-frequency trading, it is in production and for 
>>>> what 
>>>> we do at the moment the times are within the OK parameters, but for high 
>>>> frequency trading it will be a show stopper, I do believe Akka remote, 
>>>> cluster and other remote related extensions will play a nice role in the 
>>>> future of financial services, or maybe I'm just too excited with Akka and 
>>>> getting ahead of myself, who knows ;-)
>>>>
>>>> Thank you very much for that info,
>>>>
>>>> Guido.
>>>>
>>>>
>>>> On Wednesday, October 14, 2015 at 12:27:46 PM UTC+1, Andrey Kuznetsov 
>>>> wrote:
>>>>>
>>>>> Did you see this? 
>>>>> https://github.com/typesafehub/netty-reactive-streams/blob/master/pom.xml
>>>>> I think it's a first step of migration to streams. It already depends 
>>>>> on Netty 4.
>>>>>
>>>>> On Wednesday, October 14, 2015 at 12:22:33 PM UTC+3, Guido Medina 
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I created a similar post some time ago but the circumstances were a 
>>>>>> bit different, the project I'm working at the moment has the requirement 
>>>>>> of 
>>>>>> processing messages within 5ms, and I chose Akka remote to do this job, 
>>>>>> the 
>>>>>> project also requires to be distributed so again, Akka remote with 
>>>>>> clustering was the clear candidate, I have done lots of research and 
>>>>>> have 
>>>>>> done the following:
>>>>>>
>>>>>>- Properly configured Netty TCP client and server pools.
>>>>>>- Properly configured serialization using Kryo.
>>>>>>- I have created small, immutable and conci

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

[Guido Medina]

Git URL 
correction: https://github.com/hepin1989/akka-remote-transport-netty4

On Thursday, October 15, 2015 at 10:54:46 AM UTC+1, Guido Medina wrote:
>
> If that was my expertise I would at definitely done something already, but 
> the only thing I have done with Netty is a TCP server for a logger hardware 
> for the utility industry, nothing that would require such level of details 
> like someone with hands on NIO, Scala and Serialization altogether.
>
> Also "Hepin" had written something and the relevant git URL I copied from 
> another post, but that concluded with the statement that Akka remote was 
> going to be replaced by Akka IO/streams, so not sure if this attempt is 
> somehow in the right way:
>
> From Hepin: 
>
>> I push the io side code here
>> https://github.com/qgame/engine/tree/master/framework/akka-io-netty
>>
>> https://github.com/qgame/engine/tree/master/framework/akka-remote-transport-io-netty/
>>
>
> Original post 
> https://groups.google.com/d/msg/akka-user/0p-1UWT3uas/OBl1C02xWWUJ
>
> Best regards,
>
> Guido. 
>
> On Thursday, October 15, 2015 at 10:21:39 AM UTC+1, √ wrote:
>>
>> Hi Guido,
>>
>> Would you be interested in contributing towards this?
>>
>> On Thu, Oct 15, 2015 at 11:02 AM, Guido Medina <oxy...@gmail.com> wrote:
>>
>>> Hi Viktor,
>>>
>>> Maybe you could abstract the transport API and create multiple 
>>> implementations, with both Netty and Aeron, Aeron might not be as fast as 
>>> you think, some performance benchmark on different transports and keep a 
>>> updated score table to keep the user informed on what transport works best 
>>> under specific scenarios like:
>>>
>>>- Many small messages (high frequency with low latency)
>>>- Standard amount of messages with standard size (amount of messages 
>>>and size TBD)
>>>- And for large messages.
>>>
>>> So different transports and/or configuration of them might provide a 
>>> better performance for different scenarios.
>>>
>>> My main concern is that nobody seems to be concerned AFAIK with this 
>>> subject nor aware on how slow the current remote transport is hence my post 
>>> subject "Akka remote communication roadmap?", at least it is slow for my 
>>> application and its configuration.
>>>
>>> Best regards,
>>>
>>> Guido.
>>>
>>> On Wednesday, October 14, 2015 at 1:49:04 PM UTC+1, √ wrote:
>>>>
>>>> For extremely low latency we'd want to use a transport like Aeron.
>>>>
>>>> On Wed, Oct 14, 2015 at 1:34 PM, Guido Medina <oxy...@gmail.com> wrote:
>>>>
>>>>> Very nice, I wasn't aware of it, IMHO it needs something like that as 
>>>>> proper remote communication is the foundation for distributed 
>>>>> micro-services, our application is a FOREX trading application and we 
>>>>> might 
>>>>> eventually move to high-frequency trading, it is in production and for 
>>>>> what 
>>>>> we do at the moment the times are within the OK parameters, but for high 
>>>>> frequency trading it will be a show stopper, I do believe Akka remote, 
>>>>> cluster and other remote related extensions will play a nice role in the 
>>>>> future of financial services, or maybe I'm just too excited with Akka and 
>>>>> getting ahead of myself, who knows ;-)
>>>>>
>>>>> Thank you very much for that info,
>>>>>
>>>>> Guido.
>>>>>
>>>>>
>>>>> On Wednesday, October 14, 2015 at 12:27:46 PM UTC+1, Andrey Kuznetsov 
>>>>> wrote:
>>>>>>
>>>>>> Did you see this? 
>>>>>> https://github.com/typesafehub/netty-reactive-streams/blob/master/pom.xml
>>>>>> I think it's a first step of migration to streams. It already depends 
>>>>>> on Netty 4.
>>>>>>
>>>>>> On Wednesday, October 14, 2015 at 12:22:33 PM UTC+3, Guido Medina 
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I created a similar post some time ago but the circumstances were a 
>>>>>>> bit different, the project I'm working at the moment has the 
>>>>>>> requirement of 
>>>>>>> processing messages within 5ms, and I chose Akka remote to do this job, 
>&

[akka-user] Akka remote communication roadmap?

[Guido Medina]

Hi,

I created a similar post some time ago but the circumstances were a bit 
different, the project I'm working at the moment has the requirement of 
processing messages within 5ms, and I chose Akka remote to do this job, the 
project also requires to be distributed so again, Akka remote with 
clustering was the clear candidate, I have done lots of research and have 
done the following:

   - Properly configured Netty TCP client and server pools.
   - Properly configured serialization using Kryo.
   - I have created small, immutable and concise Java classes for sending 
   messages between remote actors.
   - I have configured properly Akka remote thread pools.

And it doesn't matter what I do, I still get a high time with the 1st few 
messages, I cannot make my application send messages in less than 2ms to 
5ms after initial warm up, sometimes it takes even more, I would be curious 
about low latency applications out there that use Akka remote, the state of 
Akka remote IMHO is "out-dated?"

I think it needs more attention, I'm quite sure the community appreciates 
so many features you guys are releasing but I think remote communication is 
not only an important but crucial aspect of Akka.

In my old post someone mentioned there would be an Akka remote rewritten 
using Akka streams, it has been some reasonable time now to start thinking 
about, Akka 2.4, Akka HTTP 1.0 are already released and still Akka remote 
is using Netty 3, a shorter time alternative would be to just migrate Akka 
remote to Netty 4 which someone has proven already it faster and consistent 
for Akka.


Best regards,

Guido.

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

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

[Guido Medina]

Very nice, I wasn't aware of it, IMHO it needs something like that as 
proper remote communication is the foundation for distributed 
micro-services, our application is a FOREX trading application and we might 
eventually move to high-frequency trading, it is in production and for what 
we do at the moment the times are within the OK parameters, but for high 
frequency trading it will be a show stopper, I do believe Akka remote, 
cluster and other remote related extensions will play a nice role in the 
future of financial services, or maybe I'm just too excited with Akka and 
getting ahead of myself, who knows ;-)

Thank you very much for that info,

Guido.

On Wednesday, October 14, 2015 at 12:27:46 PM UTC+1, Andrey Kuznetsov wrote:
>
> Did you see this? 
> https://github.com/typesafehub/netty-reactive-streams/blob/master/pom.xml
> I think it's a first step of migration to streams. It already depends on 
> Netty 4.
>
> On Wednesday, October 14, 2015 at 12:22:33 PM UTC+3, Guido Medina wrote:
>>
>> Hi,
>>
>> I created a similar post some time ago but the circumstances were a bit 
>> different, the project I'm working at the moment has the requirement of 
>> processing messages within 5ms, and I chose Akka remote to do this job, the 
>> project also requires to be distributed so again, Akka remote with 
>> clustering was the clear candidate, I have done lots of research and have 
>> done the following:
>>
>>- Properly configured Netty TCP client and server pools.
>>- Properly configured serialization using Kryo.
>>- I have created small, immutable and concise Java classes for 
>>sending messages between remote actors.
>>- I have configured properly Akka remote thread pools.
>>
>> And it doesn't matter what I do, I still get a high time with the 1st few 
>> messages, I cannot make my application send messages in less than 2ms to 
>> 5ms after initial warm up, sometimes it takes even more, I would be curious 
>> about low latency applications out there that use Akka remote, the state of 
>> Akka remote IMHO is "out-dated?"
>>
>> I think it needs more attention, I'm quite sure the community appreciates 
>> so many features you guys are releasing but I think remote communication is 
>> not only an important but crucial aspect of Akka.
>>
>> In my old post someone mentioned there would be an Akka remote rewritten 
>> using Akka streams, it has been some reasonable time now to start thinking 
>> about, Akka 2.4, Akka HTTP 1.0 are already released and still Akka remote 
>> is using Netty 3, a shorter time alternative would be to just migrate Akka 
>> remote to Netty 4 which someone has proven already it faster and consistent 
>> for Akka.
>>
>>
>> Best regards,
>>
>> Guido.
>>
>

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

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

[Guido Medina]

If I have to give up on Akka remote because it is slow, I'll just switch to 
something like Vert.x, not sure what's going on here or why it has such 
little importance when it is part of Akka selling speech: "Location 
transparency" or is it only an advertisement but not used much in practice 
because of its performance?

I think Akka remote performance is a very important aspect for Akka and 
should deserve a higher priority but hey, I'm only one Akka user maybe the 
other thousands think otherwise.

On Tuesday, October 20, 2015 at 8:02:40 AM UTC+1, 何品 wrote:
>
> I rewrite it with akka-io-netty ,it has the same api as the akka-io,and 
> then redo the transport based on it.but my company asked me to delete it 
> from the github.so sorry.and the link below is unmatained and we are not 
> using it in production any more.
> and I think for the really HT,you could do the things like:
> 1,reduce context switch
> 2,reduce gc pressure
> 3,quick serialization
> 4,don't using tcp
> 5,don't using akka remote directly
>
> If I was you ,I would start a dedicated endpoint for the exchange ,which 
> may be based on Aeron or Netty4 with UDT.only by using akka-stream and 
> netty4 will not make it works here I think,5 ms,need some special work.
>
>>

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

[Guido Medina]

Hi Roland,

Fair enough, I agree with all you have said, specially the non-negotiable 
points which are the foundation of the remote communication contracts 
ported from Erlang paradigms, our application can survive with the times it 
has at the moment.

I only needed to hear/know what you just said (awareness of the current 
state/situation), knowing that you guys are aware of its importance is a 
big relief, I'll do my best to catch up and try to help when I get there 
(That is the learning curve of Scala and Akka abstraction layers needed to 
help with it, no promises though)

Best regards,

Guido.

On Tuesday, October 20, 2015 at 11:13:44 AM UTC+1, rkuhn wrote:
>
> Guido, you are right that remote communication is key to what Akka is all 
> about. The main hindrance in terms of implementation improvements is that 
> there is a rather large complexity overhead incurred by
>
>- supporting bidirectional TCP usage
>- guaranteeing per-pair ordering with at-most-once semantics (*)
>- … across connection failures
>
> I’d very much like to dump as much of the baggage as possible to make 
> headway, but this will mean that we become (even) more opinionated in terms 
> of where Akka Cluster is applicable—I’d envision it to be targeted at 
> localized deployment within the same rack or data center so that we can go 
> beyond TCP. The (*) point is not negotiable, though.
>
> One thing that might not be widely known—despite there being no secret 
> about it—is that the Akka team at Typesafe is not actually that big, we 
> cannot do all things at once. We are right now in a position where we must 
> finish what we began, we cannot leave Streams & HTTP in this half-finished 
> state, with lots of performance and API improvements lying on the table. 
> And to make in particular Streams more widely applicable we also need to 
> work on getting more data sources and sinks integrated with it, either 
> directly or via Reactive Streams interfaces.
>
> This means that there is no wiggle room for us in the near term future to 
> tackle such a large new topic as re-envisioning the remoting 
> implementation. Such an effort could start small, though, and it could also 
> start outside of the core team. I’m absolutely ready to support any such 
> initiative, e.g. by making sure that the RemoteTransport interface is 
> high-level and accessible enough to make an alternative transport not only 
> possible but also successful.
>
> Ideas could be to use Aeron in terms of a communication model (e.g. by 
> switching off redeliveries since we don’t need them) or to research 
> QUIC—but a pure UDP transport would also be interesting to explore in order 
> to see which “connection-like” features we really need (which I guess to be 
> extremely little).
>
> This is surely not satisfying in the short term but as other people say: I 
> want a pony! (I actually want a time machine …)
>
> Regards,
>
> Roland
>
> 20 okt 2015 kl. 11:41 skrev Guido Medina <oxy...@gmail.com >:
>
> If I have to give up on Akka remote because it is slow, I'll just switch 
> to something like Vert.x, not sure what's going on here or why it has such 
> little importance when it is part of Akka selling speech: "Location 
> transparency" or is it only an advertisement but not used much in practice 
> because of its performance?
>
> I think Akka remote performance is a very important aspect for Akka and 
> should deserve a higher priority but hey, I'm only one Akka user maybe the 
> other thousands think otherwise.
>
> On Tuesday, October 20, 2015 at 8:02:40 AM UTC+1, 何品 wrote:
>>
>> I rewrite it with akka-io-netty ,it has the same api as the akka-io,and 
>> then redo the transport based on it.but my company asked me to delete it 
>> from the github.so sorry.and the link below is unmatained and we are not 
>> using it in production any more.
>> and I think for the really HT,you could do the things like:
>> 1,reduce context switch
>> 2,reduce gc pressure
>> 3,quick serialization
>> 4,don't using tcp
>> 5,don't using akka remote directly
>>
>> If I was you ,I would start a dedicated endpoint for the exchange ,which 
>> may be based on Aeron or Netty4 with UDT.only by using akka-stream and 
>> netty4 will not make it works here I think,5 ms,need some special work.
>>
>>>
> -- 
> >>>>>>>>>> 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

[akka-user] Re: ANNOUNCE: Akka 2.3.13 Released

[Guido Medina]

Hi Patrik,

That's great news, does the TCP no delay affect remote performance in 
anyway? If so is that change reflected at 2.4-RC1 or is it coming in the 
next 2.4 release?

Best regards,

Guido.

On Thursday, September 3, 2015 at 2:04:20 PM UTC+1, Patrik Nordwall wrote:
>
> Dear hAkkers,
>
>
> We—the Akka committers—are pleased to be able to announce the availability 
> of Akka 2.3.13. This is the 13th maintenance release of the 2.3 branch. 
> This release contains a few important fixes:
>
>
>- 
>
>backport ClusterClient failure detection improvement
>- 
>
>fix AbstractFSM.onTransition recursion
>- 
>
>set tcpNoDelay on Netty child channels
>- 
>
>a fix for a potential PermGen leak problem
>- 
>
>clear pending connections after quarantine
>
>
> Akka 2.3.13 is released for Scala 2.10 and 2.11. This release is backwards 
> binary compatible with all previous 2.3.x versions which means that the new 
> JARs are a drop-in replacement for the old one (but not the other way 
> around) as long as your build does not enable the inliner (Scala-only 
> restriction). Always make sure to use at least the latest version required 
> by any of your project’s dependencies.
> Migrating from Older Releases
>
> When migrating an existing project from Akka 2.2.x please have a look at 
> the migration guide 
> 
> .
> Additional Release Details
>
> The artifacts comprising this release have been published to 
> https://oss.sonatype.org/content/repositories/releases/ and also to Maven 
> Central. In addition, we adopted the sbt standard of encoding the Scala 
> binary version in the artifact name, i.e. the core actor package’s 
> artifactId is “akka-actor_2.10” or “akka-actor_2.11”, respectively.
>
> The complete list of closed tickets can be found in the 2.3.13 github 
> issues milestone 
> .
> Credits
>
> commits added removed
>5 231 134 Patrik Nordwall
>
>1   2   0 Luben Karavelov
>
>1   4   0 Konrad Malawski
>
>1 110   0 Endre Sándor Varga
>
>1   1   1 Ankush Khanna
>
>1   1   1 Rafał Sujak
>
> Happy hAkking!
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  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] Callable, Function or other Smart Messages?

[Guido Medina]

Hi Robert,

The problem with old Java domain objects IMHO is how to properly guard 
their state, for example, you might think of solutions like Loading caches 
using Guava or any other caching framework but that still doesn't free you 
from mutability problems, caching is one of the hardest problems to get 
right as you already know, now, I wouldn't be much scared of using one 
actor per domain object with context timeout, that right there would 
emulate existing caching solutions, it also ensures only 1 thread is 
modifying a domain object at a time and that messages sent to such domain 
object are handled by its actor (think of it as a thread safe and expiring 
DAO), the only thing I don't know is how scale-able is context timeout when 
applied to hundreds of thousands or millions of actors, say an actor will 
kill itself if hasn't been interrogated for, say; a minute.

I have been there so I kind of understand your pain, I have had to dealt 
with legacy code in Java, messaging, anemic pojos, very fat pojos, big 
data, json mapping and so other nightmares when you combine them together.

I think you have being trying a complex solution to simple problem, maybe a 
little of following properly the actor philosophy plus GoF might be just 
what you need, specially template pattern.

Hope that helps,

Guido.

On Thursday, August 27, 2015 at 7:54:35 PM UTC+1, kraythe wrote:
>
> Roland, 
>
> As is the case with 90% of software out of academia, there isnt much 
> purity of any pholosophy in the system. We have to deal with legacy code, 
> code implemented badly, code implemented by other teams and as a practical 
> matter of reality I cant advocate a complete refactor of an enormous system 
> to any particular strategy without having some sort of business ROI reason 
> to do so. So any changes made have to be incremental. The system stores the 
> objects in a hazelcast map and looks the data up in that map before 
> operating on it. Is it pure academic DDD ? Maybe not. Fairly close though. 
> Definitely its not MVC. The objects are intelligent and know how to do 
> things to themselves, not managed as pojos by external code. The MVC pojo 
> approach has major problems in my opinion, one I share with M. Fowler. The 
> anemic domain model is ... bad. 
>
> As a result I cant start up an actor per domain model. That would be 
> problematic because i don't know which objects will be needed and I would 
> have to constantly bring the actors up and down. The approach I have to 
> take is to use a generic CustomerActor that can look up, find and access 
> the actual customer objects from the cache and call the functionality in 
> the domain object. I can make the actor a nested class and make all of the 
> implementation of the methods private so it must be accessed through the 
> actor though. That is an interesting idea. 
>
> As for accessing mutliple objects, most use cases involve changing more 
> than one object at a time in a transactional manner. Should something go 
> wrong all needs to be rolled back. So a message "CancelAllOrders" and you 
> have to change the customer after all the orders are cancelled that all has 
> to be done in a transaction. There are probably some ways it could be 
> changed to be better but again ROI from management will be the limiting 
> factor. 
>
> -- Robert
>
>
> On Thursday, August 27, 2015 at 12:08:37 PM UTC-5, rkuhn wrote:
>>
>> Hi Robert!
>>
>> 27 aug 2015 kl. 16:01 skrev kraythe :
>>
>> Roland, 
>>
>> Sorry I got frustrated. Perhaps we I am just having problems 
>> communicating.
>>
>>
>> That might well be, thanks for being open!
>>
>>
>> Back to the issue at hand. Your code sample is fine, and I like how its 
>> implemented, but here is what I wonder. What is the difference between what 
>> you wrote and having a message that implements Callable? Only think you are 
>> doing is implementing a different interface (trait in this case).
>>
>>
>> The difference is that the message type is specific and descriptive, it 
>> is clear that this Actor only responds to operations on the particular 
>> domain entity type that it represents. An Actor that just executes any 
>> Callable it gets is no longer an Actor, it is just an Executor for 
>> arbitrary code.
>>
>> In this particular use pattern the primary class is the domain object 
>> with all its operations, these are tightly coupled together and form the 
>> business logic that you are expressing. The Actor that wraps one such 
>> domain object again is tightly coupled to this particular type of entity, 
>> it is not a generic DomainEntityActor but a CustomerActor. While 
>> generalizing the apply() method across all Operations allows elegant code 
>> for the main use-case it remains important that individual operation types 
>> can be handled differently or reinterpreted—the Actor needs to stay in 
>> control of what it executes and when. For example you might limit the 
>> update rate or limit certain 

[akka-user] Re: Are there any libraries that help me implementing a Micro-Service Archicteture with Akka?

[Guido Medina]

AFAIK nope, Akka micro kernel was deprecated, I think Akka completely moved 
to a "toolkit/framework" approach, I have a system running micro-services 
with some shared generic actors and a single configuration with seed nodes, 
all using the good old Java main method per micro-service, each 
micro-service runs on its own JVM and a common.jar is shared between the 
modules for shared messages Java classes.

I had to create my own shard and balancer mechanism for some type of 
micro-service all based on cluster events, DevOps created the executables 
using Ansible scripts to create supervisord micro-services and Maven 
app-assembler to generate the main executable by resolving the dependencies 
of such micro-service with release policies in place and uniform versions 
of each micro-service, when a version is rolled up it is done at Maven 
parent project so all micro-services roll a version.

There is two types of maintenance:

   - Add/remove node of a supervisor type to the cluster which doesn't 
   require the cluster to be restarted.
   - Upgrade to a version which due to JVM class loader implications and 
   serializable class versions we restart the cluster at this phase.

For  the 2nd type of maintenance we could had gone the Json route but in 
the end it gets messy and it is not as fast IMHO as native types using 
Kryo, it is a decision that can be made prior implementation but there will 
be always a trade of.

Hope that helps,

Guido.

On Friday, December 4, 2015 at 10:46:32 AM UTC, john@gmail.com wrote:
>
> Hi,
>
> If I have a  bare bone Akka cluster running on n nodes with a fixed 
> configuration.
> I am cosidering to build a system where one could deploy dynamically  
> akka-jars to this cluster.  
> These akka-jars should be  isolated as much as possible from each other. 
> (Maybe through different classloaders)
>
> Does the akka echo system offer any thing here.
> I skimmed through the 2.4 docs but couldn't find much on this subject?
>
> Many Greetings
> john
>

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

[akka-user] Re: Are there any libraries that help me implementing a Micro-Service Archicteture with Akka?

[Guido Medina]

*ConductR* is where we will be heading too in the future, when our project 
get to a 2nd or 3rd major version, as I'm the only developer it is too 
difficult for me to do everything and now would only be a hassle, but yes 
that's where I would like to go.

On Wednesday, December 9, 2015 at 1:44:34 PM UTC, Johan Andrén wrote:
>
> You didn't mention if you are looking for something free/OSS so not sure
> if this interests you, but there is ConductR from Typesafe that does 
> similiar
> things to what you describe.
>
> You can find more info here: http://conductr.typesafe.com/docs/1.0.x/Home
>
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
>
> On Friday, December 4, 2015 at 11:46:32 AM UTC+1, john@gmail.com 
> wrote:
>>
>> Hi,
>>
>> If I have a  bare bone Akka cluster running on n nodes with a fixed 
>> configuration.
>> I am cosidering to build a system where one could deploy dynamically  
>> akka-jars to this cluster.  
>> These akka-jars should be  isolated as much as possible from each other. 
>> (Maybe through different classloaders)
>>
>> Does the akka echo system offer any thing here.
>> I skimmed through the 2.4 docs but couldn't find much on this subject?
>>
>> Many Greetings
>> john
>>
>

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

Re: [akka-user] Aggregate counts in multi-jvm testing

[Guido Medina]

Or CRDT with any distributed data structure, I can mention a couple: Hazelcast, 
Riak, etc

Basically you want a distributed counter.

-- 
>>  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] Aggregate counts in multi-jvm testing

[Guido Medina]

I will need distributed data for my project in the future so it was good you 
mentioned it cause I didn't know akka had it.

-- 
>>  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: Deserialize ActorRef, again

[Guido Medina]

Hey Patrik, to confirm; out of the 6 I listed only leave "java" as I had it 
initially?

On Saturday, December 19, 2015 at 4:24:15 PM UTC, Patrik Nordwall wrote:
>
> Don't change the ones that are using protobuf, eg akka-cluster. They are 
> optimized, and proven to work well. Replacing anything that is using java 
> serialization is good.
> lör 19 dec. 2015 kl. 17:12 skrev Guido Medina <oxy...@gmail.com 
> >:
>
>> Hi, not with the intention of hijacking this thread but here is a 
>> question related question:
>>
>> If I decide to use only Kryo for all sort of serializations, has anyone 
>> done this? I mean to also serialize Akka inter-node messages with Kryo?
>>
>> *This is what I had before:*
>> serializers {
>>java = "com.romix.akka.serialization.kryo.KryoSerializer"
>> }
>>
>>
>> *And this is what I'm testing at the moment by changing every serializer 
>> declared at Akka actor, remote and cluster:*
>> serializers {
>>   java = "com.romix.akka.serialization.kryo.KryoSerializer"
>>   bytes = "com.romix.akka.serialization.kryo.KryoSerializer"
>>   akka-cluster = "com.romix.akka.serialization.kryo.KryoSerializer"
>>   akka-containers = "com.romix.akka.serialization.kryo.KryoSerializer"
>>   proto = "com.romix.akka.serialization.kryo.KryoSerializer"
>>   daemon-create = "com.romix.akka.serialization.kryo.KryoSerializer"
>> }
>>
>> *Any thoughts? Is there any of these types that Kryo serializer would do 
>> more harm than good?*
>>
>> Thanks a lot,
>>
>> Guido.
>>
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [akka-user] Re: Deserialize ActorRef, again

[Guido Medina]

Hi, not with the intention of hijacking this thread but here is a question 
related question:

If I decide to use only Kryo for all sort of serializations, has anyone 
done this? I mean to also serialize Akka inter-node messages with Kryo?

*This is what I had before:*
serializers {
   java = "com.romix.akka.serialization.kryo.KryoSerializer"
}


*And this is what I'm testing at the moment by changing every serializer 
declared at Akka actor, remote and cluster:*
serializers {
  java = "com.romix.akka.serialization.kryo.KryoSerializer"
  bytes = "com.romix.akka.serialization.kryo.KryoSerializer"
  akka-cluster = "com.romix.akka.serialization.kryo.KryoSerializer"
  akka-containers = "com.romix.akka.serialization.kryo.KryoSerializer"
  proto = "com.romix.akka.serialization.kryo.KryoSerializer"
  daemon-create = "com.romix.akka.serialization.kryo.KryoSerializer"
}

*Any thoughts? Is there any of these types that Kryo serializer would do 
more harm than good?*

Thanks a lot,

Guido.

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

Re: [akka-user] Log4j2 Async Logger

[Guido Medina]

Sorry for brevity writing from phone which I hate.

In a nutshell I would like your plugin akka-log4j to offer an extra class to 
log directly without an actor in between which is your current implementation, 
same applies for akka-slf4j.

That way Akka system has a registered logger and my actors will continue 
obtaining the logger instance from Akka system.

-- 
>>  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] Aggregate counts in multi-jvm testing

[Guido Medina]

I was planning to have Hazelcast start/stop with each ActorSystem 
programmatically, Hazelcast API is as friendly as akka's

But again if akka has its own in-memory grid then no need, also think if you 
only need a counter or other things from a toolkit like Hazelcast and if the 
things you will need can be accomplished with akka alone.

HTH,

Guido.

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

Re: [akka-user] Re: Deserialize ActorRef, again

[Guido Medina]

Why not Akka Kryo?

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