On Sat, Apr 19, 2014 at 10:38 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 4/19/14 9:13 AM, Alon Bar-Lev a écrit : >> Hi, >> >> The mission of async is to avoid having threads at all, or at least O(1). >> >> As you have underline internal/private low level channels for socket >> processing, and public high level channels to communicate with >> application, there should be a mechanism for library to request wake >> up for these low level channels. >> >> Another option is to avoid using sockets at all within the >> implementation and require application to manage the sockets and pipe >> socket data into the library. >> >> I understand this is conceptional change than what we have now, but >> this what will enable scale without abusing system threads or have >> nondeterministic behaviour in high load. > > There are a few important things you have to know about async and threads : > - the extra cost for dealing with async connection is around 30%. That > all but free > - a standard system can easily deal with a few thousands of threads > > Now, unless you define what is "high load", I don't really see what kind > of advantage we can get with an async implementation. > > FTR, when MINA was initially created, it was because there was a need > for a system supporting potentially ten of thousands of connections. Is > that what you are targetting ?
Yes, using work threads that are derived per # of CPUs, no more. I am far from the pure "Java" world... but if async IO is 30% insufficient, maybe it worth to use libssh (C) and communicate with it using single socket from java, delegating IO outside of java. > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
