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