mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Beaulac <cabeau...@gmail.com>
Subject Re: [MINA 3.0] IoBuffer usage
Date Mon, 16 Jan 2012 13:56:06 GMT
Emmanuel, (all)

I'm working on this Camel ticket:
https://issues.apache.org/jira/browse/CAMEL-2624

I finished the initial cut of
https://issues.apache.org/jira/browse/CAMEL-3471 to create a mina2
component in Camel.

CAMEL-2624 adds the full async behavior for Mina2 endpoints in Camel.

Would it be possible to backport the IoBuffer reading and writing discussed
in this email thread from Mina3 to Mina2?
Following the depth of the stack trace through
AbstractIoSession.write(...), I'm a little concerned about the throughput.
My current code (mina-less) is supporting single TCP channels with 320+
Mb/s rates. I'm porting my code to use Mina with a Mina Google Protocol
Buffers codec I wrote. I know if this is a real problem soon when I finish
CAMEL-2624 and setup some throughput tests.

Regards,
Chad


On Tue, Dec 6, 2011 at 1:27 AM, Chad Beaulac <cabeaulac@gmail.com> wrote:

> Looks good Emmanuel.
>
> Sent from my iPhone
>
> On Dec 5, 2011, at 10:13 AM, Emmanuel Lecharny <elecharny@gmail.com>
> wrote:
>
> > On 12/5/11 3:50 PM, Julien Vermillard wrote:
> >> since it's a ConcurrentLinkedQueue it could be a perf killer to do a
> .size() from the oracle javadoc : ""Beware that, unlike in most
> collections, the size method is NOT a constant-time operation. Because of
> the asynchronous nature of these queues, determining the current number of
> elements requires a traversal of the elements.""
> > Damn right...
> >
> > What about using a read/write lock instead of a synchronized block ? The
> problem with the synchornized block on queue is that we must still protect
> the queue when it's being written with another synchronized block, when if
> we use a read/write lock, we can allow parallel writes in the queue, but
> once it comes to write in the channel, we acquire a write lock and the
> queue is now protected. Something like :
> >
> > private final ReadWriteLock lock = new ReentrantReadWriteLock();
> > private final Lock queueReadLock = lock.readLock();
> > private final Lock queueWriteLock= lock.writeLock();
> > ...
> > try {
> > queueWriteLock.lock();
> >
> >    do {
> >        WriteRequest wreq = queue.peek();
> >
> >        if (wreq == null) {
> >            break;
> >        }
> >        ...
> >    } while (!queue.isEmpty());
> > } finally {
> >    queueWriteLock.unlock();
> > }
> >
> > ...
> >
> >    public WriteRequest enqueueWriteRequest(Object message) {
> >        DefaultWriteRequest request = new DefaultWriteRequest(message);
> >
> >        try {
> > queueReadLock().lock()
> >            writeQueue.add(request);
> >        } finally {
> > queueReadLock.unlock();
> >        }
> >    }
> >
> > -- Regards, Cordialement, Emmanuel L├ęcharny www.iktek.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message