Menu
I'm currently in the process of making a pretty large Akka based Java application and I'm running into a couple issues that bug me to no end.
My current package layout looks kinda like this:
My Mobile class serving as the supervisor of the actors inside the actors package.
Since I don't want to create a new set of Actors for every HttpClient and Account, I pass those around in message objects, which are stored in the messages package, together with the endpoint ActorRef that receives the final result. This does however create a very cluttered messages package with a different message for each actor. Eg. MobileForActor1, Actor1ForMobile, MobileForActor2 etc. Now my question is, is there a Convention to use for this sort of stuff that deals with this problem and is my structure (Mobile->Actor1->Mobile->Actor2->etc.) the way Akka wants it to be or do I have to just sort of waterfall the messages (Mobile->Actor1->Actor2->etc.)?
Right now I'm sending a ConnectMessage to my Mobile actor which then sends it to Actor1, Actor1 processes it and sends a new message back to Mobile, Mobile sends that response then to Actor2 and the cycle continues with a new message being created based on the old message. Eg. new Message2(message1.foo, message1.bar, message1.baz, newComputatedResult, newComputatedResult2, etc);
Is this good practice or should I include the old instance (which may contain info that isn't useful anymore) and include the new stuff? Eg. new Message2(message1, newComputatedResult, newComputatedResult2, etc);
Or should I do something completely different?
I thought about using TypedActors but those require the use of a waterfall pattern and I don't know how I would pass on the ActorRef of the listener that wants to receive the final result.
I hope I made myself understandable enough because English is not my maiden languages and that the question is clear to everyone.
I'm a beginning Akka developer and love the idea but since the documentation doesn't cover this very well, I figured this would be the best place to ask. Thanks for reading!
947
Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
For variables, the Java naming convention is to always start with a lowercase letter and then capitalize the first letter of every subsequent word. Variables in Java are not allowed to contain white space, so variables made from compound words are to be written with a lower camel case syntax.
Methods should be verbs in lowerCamelCase or a multi-word name that begins with a verb in lowercase; that is, with the first letter lowercase and the first letters of subsequent words in uppercase. Local variables, instance variables, and class variables are also written in lowerCamelCase .
What is an Actor in Akka? An actor is essentially nothing more than an object that receives messages and takes actions to handle them. It is decoupled from the source of the message and its only responsibility is to properly recognize the type of message it has received and take action accordingly.
I will venture a few comments in response to this because I've dealt with the same issues in my learning curve of Akka. I think you're asking for some rules of thumb so mine are contained herein.
First, creating actors is incredibly cheap; they are very lightweight. So, why not create one for each HttpClient and Account and give them suitable names derived from their identity? This also avoids you having to pass them around as much, probably, decluttering your code.
Second, keep your message names short, focused and starting with a verb. Each message should tell the actor to do something so you want the name to reflect that by using a verb.
Third, sets of messages go with the actor. I usually declare them in the actor class's companion object so that using them is like ActorClass.MessageName unless it is within ActorClass and then it is just MessageName.
Fourth, append a counter to the name of an actor. I often just combine a counter (use AtomicInteger) with the name of the type (Car-1, Car-2, etc.).
If the hierarchy is important to you, I would recommend only appending the parent actor to the name. Something like Phone-1-in-Car-7 meaning Phone-1 is contained within Car-7. You can then assemble the hierarchy both programmatically and manually by following the parent links.
I think "Message" in ConnectMessage is redundant. Just make the message name be "Connect" or even better "ConnectToThing" (whatever Thing is, if that's relevant).
I wouldn't compound your message names too much like you're suggesting with Message2. Use the minimal amount of information to be useful to whomever is going to read those names. I think the lack of response to this may have resulted from this part of your question. I found it confusing as a lot of detail is missing.
Hope this helps.
149
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
