Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Jetty 9.2.13 DefaultServlet static file download error ; HP Nonstop (Tandem) Operating system

Dear Simone& Joakim,

I would like to explain the issue in more detail. There are two issues;

1.DefaultServlet does not respect the outputBufferSize (32k) when using NIO

When serving static files, Jetty tries to send the whole file in one message to TCPIP. This causes a problem on HP NonStop as the maximum size can be only 52K. Normal application responses are broken into 32K  pieces.

By commenting out code where the buffer is writing through GatheringByteChannel in ​public boolean flush(ByteBuffer... buffers) method in org.eclipse.jetty.io.ChannelEndPoint​.Java class the defaultServlet also successfully served large files properly.

@Override
    public boolean flush(ByteBuffer... buffers) throws IOException
    {
        int flushed=0;
        try
        {
            if (buffers.length==1)
                flushed=_channel.write(buffers[0]);
            //else if (buffers.length>1 && _channel instanceof GatheringByteChannel) //commented this line
             //   flushed= (int)((GatheringByteChannel)_channel).write(buffers,0,buffers.length); // and this line
            else
            {
                for (ByteBuffer b : buffers)
                {
                    if (b.hasRemaining())
                    {
                        int l=_channel.write(b);
                        if (l>0)
                            flushed+=l;
                        if (b.hasRemaining())
                            break;
                    }
                }
            }
            ...
        }
        ...
    }
 
I do not know why the code the way it is. This never happened on Jetty using BIO. It shows up with NIO on Jetty 8 and Jetty 9. This must be a bug; why should outbuffersize not be followed ?
 
2.Woff and Woff2 files are not being downloaded by defaultServlet (only on the NonStop)

Before the above change, AwesomeFont woff, woof2 and ttf files could not come down as they are larger than 52K.
After the above change all files of all sorts larger than 52K successfully come, including awesomefont ttf file.
However, woff and woff2 files do not. For some reason, the browsers disconnect the connection. Jetty sees a remote disconnect error.


Since the TTF file comes down, the application does not get impacted and everything works. But there is something here that needs to be fixed.

The errno:4022 is the NonStop error when defaultServlet tries to do IO more than 52K, Nonstop manual explained the cause due to "The specified socket was already bound to an address or the address_len was incorrect"
The errno:4120 is the error when browser disconnects the connection during woff file download, cause due to "The peer process reset the connection before the operation completed"

Summary

We have a working setup in spite of the two issues after we made the code change in jetty.io. But I would like a proper fix.

Regards
Sakthi



On Tue, Dec 15, 2015 at 1:46 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
Simone has a good point.
And this was also pointed out on the stackoverflow question at


If you have HP support channels, you should ask them what the "Invalid function argument (errno: 4022)" means on HP NonStop OS.
Or report a bug with their JVM implementation.


Joakim Erdfelt / joakim@xxxxxxxxxxx

On Mon, Dec 14, 2015 at 11:13 AM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:
Hi,

On Mon, Dec 14, 2015 at 4:37 PM, Sakthivel.P <p.stivel@xxxxxxxxx> wrote:
> Caused by: java.io.IOException: Invalid function argument (errno:4022)
>     at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) ~[na:1.7.0_65]
>     at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51)
> ~[na:1.7.0_65]
>     at sun.nio.ch.IOUtil.write(IOUtil.java:148) ~[na:1.7.0_65]
>     at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:537)
> ~[na:1.7.0_65]
>     at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:172)
> ~[jetty-io-9.2.13.v20150730.jar:9.2.13.v20150730]

This is the real problem: the Non-Stop JVM has a bug, probably when
calling into native code.

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top