I'm half capacity today due to long hours, revert the division...
On Monday, February 1, 2016 at 7:57:58 PM UTC, Guido Medina wrote:
>
> If that is the case I think that design can be improved, I don't know
> Scala but I can explain my solution, assuming that number channels are a
> constant you can do the following:
>
> public int hashOfSenderToRecipient(ActorRef sender, ActorRef recipient) {
> return sender.hashCode() * 31 + recipient.hashCode();
> }
>
> public Channel channelOfSenderToRecipient(ActorRef sender, ActorRef
> recipient, List<Channel> channels) {
> return channels.get(channels.size() % hashOfSenderToRecipient(sender,
> recipient));
> }
>
> There; assume Channel is a Netty channel, ordering problem solved, now a
> question, what to assume when sender = noSender() ?
> How to resolve the noSender() bottleneck unless some metadata is set just
> for the sake of calculating the right hash.
>
> Guido.
>
> On Monday, February 1, 2016 at 6:08:49 PM UTC, Michael Frank wrote:
>>
>> note this is based on my understanding of the akka remoting
>> implementation (akka devs correct me if i'm wrong)...
>>
>> the drawback of using akka remoting is that is uses a single channel (a
>> single TCP connection) for all communication. this reduces concurrency
>> between remoting peers, and introduces the potential for head-of-line
>> blocking if a peer sends large message payloads or lots of messages. the
>> advantage of this design is that there are stronger message ordering
>> guarantees than if multiple channels were open between remoting peers.
>>
>> for control plane operations (infrequent, small messages, low
>> concurrency), i think remoting is an excellent choice. for data plane
>> operations (high message throughput, variable message payloads, high
>> concurrency) i think you're better off with akka http, spray, or any of the
>> RPC frameworks like thrift.
>>
>> -Michael
>>
>> On 01/31/16 00:27, Amir Karimi wrote:
>>
>> Hi,
>>
>> We are coding in Scala and we decided to use akka-remoting for our
>> microservices communication instead of JSON APIs. It's very concise and
>> simple and you don't have to deal with manual JSON serialization until you
>> need backward compatibility. Then you have to put aside default java
>> serializer and use something like JSON. It's OK but I don't see many people
>> use json serializer or alike for akka-remoting. Instead they tend to use
>> akka-http, Spray, etc. and build a standard JSON API using a web framework.
>>
>> I think using the akka-remoting serialization would be more concise and
>> simpler than other methods because you just work with case classes which is
>> very pleasant. What is your experiences? What do you advice?
>>
>> Thanks
>> --
>> >>>>>>>>>> Read the docs: <http://akka.io/docs/>http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives:
>> <https://groups.google.com/group/akka-user>
>> 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 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
