On Mon, Jun 30, 2014 at 12:49 PM, Guillaume Nodet <gno...@apache.org> wrote: > > For my curiosity, what kind of interface are you using for async ?
For now, I had no other choice than to use primitive multiple threads and feed Input/OutputStream in sync mode[1][2]. I am not native java... but I find the aio pattern inferior to event driven pattern, much more complex and error prone. Thanks! Alon [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/uutils/src/main/java/org/ovirt/engine/core/uutils/ssh/SSHDialog.java;hb=HEAD [2] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/uutils/src/main/java/org/ovirt/engine/core/uutils/ssh/SSHClient.java;hb=HEAD > > > 2014-06-29 11:02 GMT+02:00 Alon Bar-Lev <alon.bar...@gmail.com>: > > > Hi, > > > > Thank you for adding this, I can understand how it works, and it will > > provide a service for async that is written from scratch. I tried to > > evaluate the amount of changes that required in my simple case to use > > this interface and currently it is much too large, so I will not be > > able to actually use it in the near future. > > > > Thanks! > > Alon > > > > On Fri, Jun 6, 2014 at 9:48 AM, Guillaume Nodet <gno...@apache.org> wrote: > > > I've enhanced SSHD to be able to provide fully non-blocking io on both > > > client channels and server commands. > > > A client side example is shown at > > > > > > > > https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/ClientTest.java#L171 > > > A server side example: > > > > > > > > https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/util/AsyncEchoShellFactory.java > > > > > > I would appreciate any input ... > > > > > > > > > 2014-04-20 0:33 GMT+02:00 Alon Bar-Lev <alon.bar...@gmail.com>: > > > > > >> On Sun, Apr 20, 2014 at 1:19 AM, Guillaume Nodet <gno...@apache.org> > > >> wrote: > > >> > 2014-04-19 20:43 GMT+02:00 Alon Bar-Lev <alon.bar...@gmail.com>: > > >> > > > >> >> On Sat, Apr 19, 2014 at 9:15 PM, Guillaume Nodet <gno...@apache.org> > > >> >> wrote: > > >> >> > Sshd internally uses nio2 by default, which is not based on > > selectors, > > >> >> but > > >> >> > non blocking operations. > > >> >> > > > >> >> > On the client part of SSHD, things are mostly asynchronous already: > > >> >> > #1 SshClient#connect returns a future on which you can set a > > >> callback > > >> >> > and that you can use to retrieve the ClientSession asynchronously > > >> >> > #2 You need to use ClientSession#addXxxIdentity and then > > >> >> > ClientSession#auth which is also asynchronous > > >> >> > #3 You then create a channel, and actually operning the channel > > is > > >> >> also > > >> >> > asynchronous > > >> >> > #4 Closing channels is also asynchronous > > >> >> > > > >> >> > I think the only missing part is really the streams on the > > >> ClientChannel > > >> >> > which are using InputStream and OutputStream. > > >> >> > If we replace them with an AsynchronousByteChannel, I think we > > would > > >> be > > >> >> > fully async. > > >> >> > > >> >> Thank you for your response, Our definition of async is very > > >> different... > > >> >> :) > > >> >> > > >> >> I do not think this module is sufficient to what I target. I see the > > >> >> number of threads created within the library core and the logic that > > >> >> is out of reach. > > >> > > > >> > > > >> >> This ssh library is great, splitting it into two logic only and > > >> >> communication layers will enable to go fully async. The logic layer > > >> >> should not have any thread. A default implementation of communication > > >> >> layer can be provided, but is optional. The difference from the world > > >> >> I coming for is that Future handling is much more complex than having > > >> >> control queue. > > >> >> > > >> > > > >> > Not sure exactly what you're talking about here. > > >> > > > >> > Afaik, the only place where the ssh layer actually create a thread in > > >> when > > >> > creating > > >> > a client ChannelSession giving an InputStream which has to be read. > > This > > >> > thread creation can be easily avoided by using > > >> ClientChannel#getInvertedIn() > > >> > and writing to it. > > >> > > > >> > All other threads are communication threads only and are fully > > controlled > > >> > by > > >> > the IoService layer which is pluggable. Both mina and nio2 > > >> implementations > > >> > use a fixed number of threads. But you can rewrite it if you need. > > >> > > > >> > I'm all for improving sshd, but I fear i'm not really seeing your > > points > > >> > clearly. > > >> > > >> Thank you for the discussion, I truly appreciate that. > > >> > > >> Having a method for async input/output of data stream will be a good > > >> start within current implementation. > > >> > > >> Other than that it is a programming pattern discussion. I got the > > >> information I needed, thank you! > > >> > > >> >> > > >> >> Was just an idea, thank you for addressing. > > >> >> > > >> >> > > > >> >> > 2014-04-19 15:57 GMT+02:00 Alon Bar-Lev <alon.bar...@gmail.com>: > > >> >> > > > >> >> >> On Sat, Apr 19, 2014 at 3:52 PM, Jon V. <sybersn...@gmail.com> > > >> wrote: > > >> >> >> > > > >> >> >> > NIO controls and deals with the selectors. Async IO is a part of > > >> that > > >> >> but > > >> >> >> > is not the same thing. Async io means that if a write cannot be > > >> fully > > >> >> >> > flushed. It will not block until it can be. NIO provides us the > > >> >> events to > > >> >> >> > tell us that data is available in the socket. > > >> >> >> > > >> >> >> Async IO is the ability for a single thread to perform > > (multiplex) IO > > >> >> >> (connect, read, write, close etc..) for multiple file descriptors. > > >> >> >> > > >> >> >> As far as I know, without NIO you cannot achieve that in Java. > > >> >> >> > > >> >> >> There is no sense in read or write without blocking if you cannot > > >> wait > > >> >> >> (vs actively poll) for an event. > > >> >> >> > > >> >> >> > On Apr 19, 2014 4:56 AM, "Alon Bar-Lev" <alon.bar...@gmail.com> > > >> >> wrote: > > >> >> >> > > > >> >> >> > > On Sat, Apr 19, 2014 at 10:58 AM, Emmanuel Lécharny < > > >> >> >> elecha...@gmail.com> > > >> >> >> > > wrote: > > >> >> >> > > > Le 4/19/14 9:45 AM, Alon Bar-Lev a écrit : > > >> >> >> > > >> 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. > > >> >> >> > > > IO are already delegated outside on Java. Eveything IO > > related > > >> is > > >> >> >> > > > written in C and wrapped into Java class. > > >> >> >> > > > > > >> >> >> > > > The extra cost when using NIO is due to the management of > > >> >> SelectorKey > > >> >> >> > > > lists (with the various steps involved when dealing with > > those > > >> >> >> lists). > > >> >> >> > > > > > >> >> >> > > > All in all, when it comes to process IO, Java does not > > really > > >> add > > >> >> >> some > > >> >> >> > > > extra cost over a plain C implementation. It's not the same > > >> story > > >> >> >> when > > >> >> >> > > > using NIO, especially when dealing with many concurrent > > >> >> connections. > > >> >> >> > > > > > >> >> >> > > > > >> >> >> > > So I am confused... Java does not add cost to async IO, but > > NIO > > >> >> does? > > >> >> >> > > While NIO is the only interface to Java async IO? > > >> >> >> > > > > >> >> >> > > >> >> > > >> > >
