Hi Patrik,
Yes that was an idea and the Future passed would be of something
like
https://github.com/evolution-gaming/akka-tools/blob/master/src/main/scala/com/evolutiongaming/util/FutureSequentialForKey.scala#L17
In general the goal is to make sure large messages do not affect other
small mess
Are you thinking of adding mapAsync to the Artery lanes? It could be
interesting to look at a suggestion for that. Adding more async boundaries
will be worse for latency of normal messages, so it should not be the
default.
Also note that compression and serialization is CPU bound tasks so if you
t
I'm looking further in order to understand on how artery fixes it and truly
saying I'm not in favour of configurable number of inbound-lanes and
outbound-lanes.
Right now we have an issue with passing messages in cluster. Sometimes we
want to send large messages and make sure those are compress
That is correct, there is one writer and one reader per connection in the
stable remoting, so if serialization is slow/heavy that may be a bottleneck.
In the new remoting, "artery", we have made it possible to run multiple in
and outbound "lanes", but that functionality is not yet hardened enough
Hi guys,
Do I understand correctly that we have a single instance of
`EndpointReader` actor per connection ?
Thus deserialisation of remote messages being done sequentially, so we can
hit this bottleneck much faster then a network throughput limits?
--
>> Read the docs: http://ak
