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.
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 <[email protected]>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/
