Messages can always be lost (akka has at-most-once as message delivery) so you should design accordingly, i.e. add some mechanism to resend messages that have not been acknowledged to achieve at-least-once where needed.
Anyway, it can be interesting to understand why the messages are dropped in this case. Is it always the first messages? How many server nodes do you have? It might take some time for the registered services to become known to all nodes. On the server side the cluster client receptionist is using distributed pub-sub for the registry of services, and that is eventually consistent, i.e. it may take a while until the information is spread to all nodes. Regards, Patrik On Tue, Aug 4, 2015 at 1:01 PM, Arpit Rajpurohit <[email protected] > wrote: > I am using Cluster Client , I am sending 75000 messages in span of 5 mins > using this,but cluster client is dropping some 300 messages. Its spray,akka > set up. Running on single 4core,8GB Ram machine. > > > By dropping messages I mean, its not going to receivingActor. > > > Following is the ClusterClient code- > > clusterClient = > Project.system.actorOf(ClusterClient.props(clusterMembers.values().asScala.toSet,Duration.create(10, > TimeUnit.SECONDS))) > > > def sendClusterMessage(target: String, message: Any, delay: Int = 0, > localAffinity: Boolean = false) (implicit system: ActorSystem) = { > delay match { > case 0 => > clusterClient ! ClusterClient.Send(String.format("/user/%s", target), > message, localAffinity = localAffinity) > } > } > > Following are the conf details- > > akka { > loglevel = "INFO" > loggers = ["akka.event.slf4j.Slf4jLogger"] > log-dead-letters-during-shutdown = off > log-dead-letters = 0 > stdout-loglevel = "INFO" > log-config-on-start = off > daemonic = off > jvm-exit-on-fatal-error = on > actor { > provider = "akka.cluster.ClusterActorRefProvider" > unstarted-push-timeout = 100s > default-mailbox { > mailbox-type = "akka.dispatch.SingleConsumerOnlyUnboundedMailbox" > mailbox-push-timeout-time = 2s > } > default-dispatcher { > type = Dispatcher > executor = "fork-join-executor" > fork-join-executor { > parallelism-min = 16 > parallelism-factor = 4.0 > parallelism-max = 64 > } > throughput = 1 > } > } > > Buffer is not full when its dropping messages. So not a case dropping old > messages. I have developed the retry logic as well in the receivingActor. > So taking the case of > > Does ClusterClient drop messages when running on a single machine? What > can be the possible causes? Is ClusterClient not able to develop a > connection with the receivingActor, when this can happen? > > -- > >>>>>>>>>> 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. > -- 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 [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.
