Hi Julien,

Thanks for your response.

I just wanted to confirm that we're talking about the same issue, because
the link you included to DIRMINA-610 seems to be all about backporting
IoBuffer.getString() performance enhancements, which seems unrelated.

Kind Regards,
John Fallows.

On Sun, Jul 27, 2008 at 11:42 PM, Julien Vermillard
<[EMAIL PROTECTED]>wrote:

> hi,
> I hunted the same bug this weekend ;) I'll commit a fix today.
> the issue is here https://issues.apache.org/jira/browse/DIRMINA-610
>
> You're right the whole flushnow method is a bit strange, it need some
> more inspection.
>
> Julien
>
> On Sat, 26 Jul 2008 14:45:16 -0700
> "John Fallows" <[EMAIL PROTECTED]> wrote:
>
> > Folks,
> >
> > First of all, before going any further, many thanks to the MINA team
> > for delivering such a useful toolkit for Java NIO development.  We
> > have had tremendous success with it to date. :-)
> >
> > However, we recently encountered an issue with
> > AbstractPollingIoProcessor.flushNow(T session, long currentTime) in
> > version 2.0-M2.  On Linux, large writes seem to flush and then stall
> > for a while before letting more writes through.  Further inspection
> > of this method revealed a fix specific to Java on Linux for large
> > files as follows:
> >
> >                } else if (message instanceof FileRegion) {
> >                    localWrittenBytes = writeFile(
> >                            session, req, hasFragmentation,
> >                            maxWrittenBytes - writtenBytes,
> >                            currentTime);
> >
> > *                    // Fix for Java bug on Linux
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103988
> >                    // If there's still data to be written in the
> > FileRegion, return 0 indicating that we need
> >                    // to pause until writing may resume.
> >                    if (localWrittenBytes > 0 && ((FileRegion)
> > message).getRemainingBytes() > 0) {
> >                        writtenBytes += localWrittenBytes;
> >                        setInterestedInWrite(session, true);
> >                        return false;
> >                    }
> > *               } else {
> >
> > Looking at the Java BugDB, it seems to be a general issue with large
> > writes, so a large IoBuffer would also have the same issue with Java
> > on Linux.  We added the following code to test the theory:
> >
> >                if (message instanceof IoBuffer) {
> >                    localWrittenBytes = writeBuffer(
> >                            session, req, hasFragmentation,
> >                            maxWrittenBytes - writtenBytes,
> >                            currentTime);
> >
> > *                    if (localWrittenBytes > 0 && ((IoBuffer)
> > message).hasRemaining()) {
> >                        writtenBytes += localWrittenBytes;
> >                        setInterestedInWrite(session, true);
> >                        return false;
> >                    }
> > *
> >                } else if (message instanceof FileRegion) {
> >
> > ...and it resolved the problem!  Full speed writes were back in
> > action again for large IoBuffers on Linux!
> >
> > This seems like a change that might be good to get into 2.0-M3.  If
> > you like, I can file an issue and attach the patch.
> >
> > Kind Regards,
> > John Fallows.
>



-- 
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.943.2436
800 W. El Camino Real, Ste 180 | Mountain View, CA 94040, USA

Reply via email to