You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
use 'multimap' instead of 'map' to implement session pool
( session pool have more-than-one sessions per server )
pros:
maybe simple
performance: any clients can communicate same server completely simultaneously
cons:
resources: in high-load situation, many sockets will be created
support 'pipeline' properly in msgpack-rpc
( one client can send a request to a server while other clients wait response from
same server and same connection )
pros:
resource saving
cons:
hard-way?
performance: msgpack-rpc protocol doesn't support 'chunked' message.
while a client is sending/receiving a huge message, other clients
must wait it.
( But, in most cases, servers and proxies are running in same local network.
we can ignore this issue? Or, multiple proxies on one client PC avoid this issue? )
Thanks for the follow-up @y-oda-oni-juba! I think the first idea is better, because:
For the only drawback of the first idea, "in high-load situation, many sockets will be created", users can workaround this by adjusting socket pool size.
The second idea is a huge architecture change, which is almost rewriting the original msgpack-rpc code.
Could you start trying with the first idea, @gintenlabo?
Derived from discussion in jubatus/jubatus#507 and https://gist.github.com/kmaehashi/8516915
When using session pool feature of msgpack-rpc, only one connection per server is allowed at a time.
The text was updated successfully, but these errors were encountered: