You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Marnie McCormack <ma...@googlemail.com> on 2009/01/08 15:15:06 UTC
[Java] MINA
All,
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 ?
Thanks,
Marnie
Re: [Java] MINA
Posted by Aidan Skinner <ai...@gmail.com>.
On Thu, Jan 8, 2009 at 3:09 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> 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?
I think improving our IO abstraction (and decoupling things
generally[1]) for and then seeing where we stand is the way to go.
- Aidan
[1] See http://qpid.apache.org/java-broker-modularisation.html for a
bit more discussion on this
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: [Java] MINA
Posted by Robert Godfrey <ro...@gmail.com>.
2009/1/8 Rajith Attapattu <ra...@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.
They are part of the coupling to which I was referring. Basically we
have worked round bugs or performance issues in MINA by putting our
own versions of their classes first in our classpath. Obviously if
the MINA code changes (as you might expect when upgrading) then this
causes us grief.
> 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?
I think this is exactly the sort of thread drift Marnie was worried about :-)
-- Rob
>
> Regards,
>
> Rajith
>
Re: [Java] MINA
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jan 8, 2009 at 1:41 PM, Martin Ritchie <ri...@apache.org> wrote:
> 2009/1/8 Rajith Attapattu <ra...@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?
I did not say they were copied from MINA :)
I said they were copied from Apache Directory project.
I thoughts so due to the following attributes present in the
MultiThreadSocketConnector class.
Appologies if I have made a mistake.
/**
* {@link IoConnector} for socket transport (TCP/IP).
*
* @author The Apache Directory Project (mina-dev@directory.apache.org)
* @version $Rev: 619823 $, $Date: 2008-02-08 10:09:37 +0000 (Fri, 08 Feb
2008) $
*/
Regards,
Rajith
Re: [Java] MINA
Posted by Martin Ritchie <ri...@apache.org>.
2009/1/8 Rajith Attapattu <ra...@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 <ro...@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
Re: [Java] MINA
Posted by Rajith Attapattu <ra...@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.
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 <ro...@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/
Re: [Java] MINA
Posted by Robert Godfrey <ro...@gmail.com>.
>
> 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