2009/1/8 Rajith Attapattu <rajit...@gmail.com>: > While applying the thread abstraction patch to the MINA code, I noticed that > we also have MINA related classes copied from the Apache Directory project. > For example MultiThreadSocketConnector and ExistingSocketConnector > I believe any plan to reduce MINA coupling should takes these classes into > account as well.
MultiThreadSocketConnector and ExistingSocketConnector are not copied from MINA. I wrote them, they are in the mina package as they need access to package private classes. Does the mina project have classes with these names? MultiThread is old and not used but provided dedicated io threads for read and write. This was done to get round the mina write bias. ExistingSocketConnector allows the client code to communicate over a socket that was already established. Any IO work we do should at least maintain this functionality, The MultiIO is most likely going to be made redundant by any IO work. Anyway, good to see M4 is looking good. I haven't had time to check it out but I'm not exactly in a work place till the 19th :) Cheers Martin > Btw, Rob I believe you had some success with the experiments you did with > your own NIO impl for the java broker. > Any plans to introduce these into trunk? > Also do we have a plan to phase out MINA in the future or do we first want > to try out their newer versions (after achieving some level of abstraction > in our IO layer) and see if there are improvements? > > Regards, > > Rajith > > On Thu, Jan 8, 2009 at 9:49 AM, Robert Godfrey <rob.j.godf...@gmail.com>wrote: > >> > >> > Just going through various JIRAs relating to MINA work on the Java side. >> > >> > Can I take a quick temperature for whether we should be considering >> (without >> > opening a complex I/O thread!) upgrading MINA or whether we reckon that >> any >> > I/O work would take us away from it ? >> >> Last time I looked it required not insignificant amounts of work to >> get the broker to work properly with later version of MINA, in part >> because of dependencies our code had on how MINA allocated and re-used >> ByteBuffers. >> >> This points to our fundamental problem which is our overly tight >> coupling on (a particular version of) MINA. Relaxing that coupling to >> allow for an upgrade would be a prelude to any work on the I/O layer >> in general I think... So If the proposal was phrased as: >> >> Should we reduce the coupling between our code and MINA such that it >> is possible for us to upgrade MINA, then my answer would be yes :-) >> >> Hope that helps, >> Rob >> > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > -- Martin Ritchie
