Just to be clear, my class: com.test.common.LoginRequest is formed of 4
strings and an actorRef
Thanks all
2016-09-09 16:34 GMT+02:00 silvio poma <silviopom...@gmail.com>:
> Right now one of the biggest and strange problem is that when arrive a
> message from the Actor A in the node 1 to the actor B in the node 2 the
> node 2 is immediately disassociated from the cluster. The message that the
> actor A sends to actor B is our custom class that we are serializing using
> kryo (as u suggested).
>
> This is our config file:
>
> akka.extensions = ["com.romix.akka.serialization.kryo.
> KryoSerializationExtension$"]
>
> akka.actor.kryo {
>
> reference-enabled = true
>
>
> implicit-registration-enabled = true
>
> implicit-registration-logging = false
>
>
> buffer-size = 4096
>
>
> max-buffer-size = 1073741824
>
>
> serializer-pool-size = 16
>
>
> kryo-trace = false
>
>
> kryo-reference-map = true
>
> mappings {
> "com.test.common.LoginRequest" = 20
>
>
> }
>
>
> classes = [
> "com.test.common.LoginRequest"
>
> ]
> }
>
> #akka.actor.serialize-messages = on
>
> akka.actor.serializers {
> java = "akka.serialization.JavaSerializer"
> kryo = "com.romix.akka.serialization.kryo.KryoSerializer"
> }
>
> akka.actor.serialization-bindings {
>
> "com.test.common.LoginRequest" = kryo
> }
>
> Il giorno venerdì 9 settembre 2016 15:32:32 UTC+2, Guido Medina ha scritto:
>>
>> What problems are you facing?
>> I'm in my second project with Java 8 + Akka so maybe I can help.
>>
>> To integrate the akka-kryo extension all you need is the dependency and
>> few lines at the configuration you are using, no code changes are needed,
>> here is an example:
>>
>> akka {
>> // Log4j2 extension
>> loggers = ["de.heikoseeberger.akkalog4j.Log4jLogger"]
>> logging-filter = "de.heikoseeberger.akkalog4j.Log4jLoggingFilter"
>>
>> // akka-kryo extension
>> extensions = ["com.romix.akka.serialization
>> .kryo.KryoSerializationExtension$"]
>>
>> actor {
>> provider = "akka.cluster.ClusterActorRefProvider"
>> serializers.java = "com.romix.akka.serialization.kryo.KryoSerializer"
>>
>> serialization-bindings {
>> // Classes that don't implement serializable list here one by one
>> // to bind them to the Java serializer which you changed to Kryo.
>> "io.vertx.core.json.JsonObject" = java
>> }
>>
>> // I don't like to have too many threads so for non-blocking stuff I
>> think N x CPU is enough where N = 1..4
>> default-dispatcher {
>> type = Dispatcher
>> executor = "fork-join-executor"
>>
>> fork-join-executor {
>> parallelism-min = 4
>> parallelism-factor = 1
>> parallelism-max = 8
>> }
>> }
>>
>> kryo {
>> kryo-reference-map = false
>> idstrategy = "automatic"
>> use-manifests = true
>> buffer-size = 1024
>> type = "nograph"
>>
>> // To avoid serializing the class name list your remote message
>> classes here:
>> classes = [
>> "com.company.class_1",
>>
>> "io.vertx.core.json.JsonObject",
>>
>> "java.util.ArrayList"
>> ]
>> }
>> }
>>
>> // My current remote configuration, enough threads (not too many) for a
>> cluster of up to 12 nodes
>> remote {
>> log-remote-lifecycle-events = off
>>
>> netty.tcp {
>> port = 0
>>
>> server-socket-worker-pool {
>> pool-size-min = 4
>> pool-size-factor = 1
>> pool-size-max = 8
>> }
>>
>> client-socket-worker-pool {
>> pool-size-min = 4
>> pool-size-factor = 1
>> pool-size-max = 8
>> }
>> }
>>
>> default-remote-dispatcher {
>> type = Dispatcher
>> executor = "fork-join-executor"
>>
>> fork-join-executor {
>> parallelism-min = 4
>> parallelism-factor = 1
>> parallelism-max = 8
>> }
>> }
>> }
>>
>> cluster {
>> metrics.enabled = off
>> jmx.enabled = off
>> }
>> }
>>
>> HTH,
>>
>> Guido.
>>
>> On Friday, September 9, 2016 at 8:43:39 AM UTC+1, silvio poma wrote:
>>>
>>> Hi Guys, Thanks a lot everybody. Yours tips were very useful and we are
>>> working on it.
>>> We've already improved the router and the disptachers configuration
>>> achieving very good results.
>>> Now we are trying to leave the java serialization and pass to another
>>> one more efficient, but we are having some troubles in this field.
>>> Can some one point me any guides to follow? (Please notice that we are
>>> writing in Java and not in Scala)
>>> Thanks Guys,
>>> Silvio
>>>
>>> Il giorno mercoledì 7 settembre 2016 17:52:39 UTC+2, √ ha scritto:
>>>>
>>>> IMO Artery won't help much if using Java Serialization.
>>>> Java Serialization is notoriously slow.
>>>>
>>>> On Wed, Sep 7, 2016 at 5:50 PM, Guido Medina <oxy...@gmail.com> wrote:
>>>>
>>>>> Artery is at in milestone 3 (m3), you are welcome to use as I believe
>>>>> it is in an extremely good shape but I would pursue both,
>>>>> as it will only require you a day of work (as a newbie) in
>>>>> configuration and dependencies, no code changes will be required:
>>>>>
>>>>> http://search.maven.org/#artifactdetails%7Ccom.typesafe.
>>>>> akka%7Cakka-remote_2.11%7C2.4-ARTERY-M3%7Cjar
>>>>>
>>>>> As for dispatchers, be careful there, I didn't mean "one dispatcher
>>>>> per actor" but more like "one dispatcher per one or more types of actors"
>>>>>
>>>>> HTH,
>>>>>
>>>>> Guido.
>>>>>
>>>>>
>>>>> On Wednesday, September 7, 2016 at 4:37:13 PM UTC+1, silvio poma wrote:
>>>>>>
>>>>>> Dear Guido,
>>>>>> Thanks a lot for you answer.
>>>>>> We have already improved our concurrency model, using multiple
>>>>>> instances for each actor, that now work in parallel using multiple
>>>>>> dispatcher.
>>>>>> Now we have not so much time to release our product to the client.
>>>>>> What do you suggest to focus our efforts on?
>>>>>> Which of this two arguments can effectively improve the system
>>>>>> efficiency?
>>>>>>
>>>>>> - Passing from Remote to Artery?
>>>>>> - Remove Java serializer and use another one?
>>>>>>
>>>>>> Thanks,
>>>>>> Looking forward to hear you.
>>>>>> Silvio
>>>>>>
>>>>>>
>>>>>> Il giorno mercoledì 7 settembre 2016 11:16:08 UTC+2, Guido Medina ha
>>>>>> scritto:
>>>>>>>
>>>>>>> Messages can be slow when being sent remotely from node A to node B,
>>>>>>> current Akka remote will give you a top of 100k msg/sec best
>>>>>>> scenario and that depending on the message size,
>>>>>>> there is a new Akka remote (Akka artery which is a rewrite of Akka
>>>>>>> remote) on the way so that shouldn't discourage you.
>>>>>>>
>>>>>>> Serialization is important, make sure you are not using the default
>>>>>>> Java serialization, I suggest you to use Kryo for example.
>>>>>>>
>>>>>>> The fact that you are using actors doesn't really mean you are using
>>>>>>> concurrency right, books like "Java concurrency in Practice" still
>>>>>>> apply,
>>>>>>> you need to know how dispatchers work in Akka
>>>>>>> and how to spread your actors among dispatcher for specialized
>>>>>>> tasks, also, you need to learn how to create several instances of the
>>>>>>> same
>>>>>>> actor so that they act as workers,
>>>>>>> hence activating a proper level of concurrency.
>>>>>>>
>>>>>>> I think the main problem is that *-it is a common mistake by new
>>>>>>> Akka users-* is to try to just throw actors at the problem and
>>>>>>> expect that it will magically solve concurrency issues.
>>>>>>> You need to read the documentation and understand how actors,
>>>>>>> routers and dispatchers can work together and how to combine them.
>>>>>>>
>>>>>>> If you are simply sending messages to one actor in a node you still
>>>>>>> have a single threaded kind processor,
>>>>>>>
>>>>>>> I have tackled this kind of problem by creating several instances *-say
>>>>>>> N x CPUs depending on the problem they are solving-*,
>>>>>>> send such list to a remote node and there create a dumb round-robin
>>>>>>> router and use such router to send messages to such pool of actors,
>>>>>>> and then you will have some decent concurrency in that node, make
>>>>>>> sure you use more than one dispatcher or else everything will be
>>>>>>> executed
>>>>>>> by the same dispatcher,
>>>>>>> which translates to having a single thread pool executor doing
>>>>>>> everything.
>>>>>>>
>>>>>>> http://doc.akka.io/docs/akka/2.4.10/java/dispatchers.html
>>>>>>> http://doc.akka.io/docs/akka/2.4.10/java/routing.html
>>>>>>>
>>>>>>> HTH,
>>>>>>>
>>>>>>> Guido.
>>>>>>>
>>>>>>> On Monday, September 5, 2016 at 11:58:47 AM UTC+1, silvio poma wrote:
>>>>>>>>
>>>>>>>> Dear Konrad,
>>>>>>>> Thanks for your answer, our Actors didn't do anything that blocks
>>>>>>>> the system.
>>>>>>>> One possible cause for our performance problem is that in our
>>>>>>>> "cluster-metrics-adaptive-group" router have just one routees
>>>>>>>> associated to one actor (We have one actor for microsistem right now).
>>>>>>>> We
>>>>>>>> think to increase the number of actor for each microsistem and
>>>>>>>> consequencialy the routees lists, is this a possible solution?
>>>>>>>> If it is right to do so, there is a way to increase and decrease
>>>>>>>> the group without going directly inside the code, and leaves akka do
>>>>>>>> so ?
>>>>>>>> Thanks Silvio
>>>>>>>>
>>>>>>>> Il giorno lunedì 5 settembre 2016 11:26:58 UTC+2, Konrad Malawski
>>>>>>>> ha scritto:
>>>>>>>>>
>>>>>>>>> This is not really enough information to say where or what the
>>>>>>>>> bottlenecks are. If you need a full architecture overview that's a
>>>>>>>>> commercial thing we can offer.
>>>>>>>>>
>>>>>>>>> Having that said, you did not mention what HTTP server you're
>>>>>>>>> using.
>>>>>>>>> Actors are simply multiplexed onto threads, so if you're doing
>>>>>>>>> blocking in your actors you'll end up blocking the entire system -
>>>>>>>>> this
>>>>>>>>> could be one of the reasons you're seeing bad perf and no parallelism.
>>>>>>>>> Another reason could be that you do all inside one actor or
>>>>>>>>> synchronously in a thread, creating a bottleneck.
>>>>>>>>>
>>>>>>>>> Please explain a bit more on your setup and we could provide some
>>>>>>>>> more helpful hints.
>>>>>>>>>
>>>>>>>>> Please also refer to the documentation when in doubt :)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Konrad `ktoso` Malawski
>>>>>>>>> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>>>>>>>>>
>>>>>>>>> On 5 September 2016 at 11:22:26, silvio poma (silvio...@gmail.com)
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>> Working on a project for a big client that want to switch from a
>>>>>>>>> monolithic infrastructure to a microservice one we are getting stuck
>>>>>>>>> in a
>>>>>>>>> big doubt.
>>>>>>>>> We are making an infrastructure where each microservice are
>>>>>>>>> deployed in a different container on an ECS instance, than we have the
>>>>>>>>> first microservice that receive a message from the client via HTTP
>>>>>>>>> and this
>>>>>>>>> message triggers all the actors that start to send message one to each
>>>>>>>>> others.
>>>>>>>>> We've created an Akka-Cluster and each microservice is a node of
>>>>>>>>> the cluster. Every Actor send a message to a Router
>>>>>>>>> (cluster-metrics-adaptive-group) that has his routees.paths that
>>>>>>>>> points to the specific node.
>>>>>>>>> Testing the performances of our system we realize that everything
>>>>>>>>> is too slow and there is not any multithreading.
>>>>>>>>> How does multithreading work? Is our infrastructure too complex?
>>>>>>>>> Is there any best-practice we can implement to improve our system?
>>>>>>>>> Thanks all!
>>>>>>>>> Silvio
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>>>>>>>> urrent/additional/faq.html
>>>>>>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>>>>>>> p/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/c
>>>>> urrent/additional/faq.html
>>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>>> p/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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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 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.
