https://bz.apache.org/bugzilla/show_bug.cgi?id=57638
--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Konstantin Kolinko from comment #1)
> What version the stacktrace is from?
>
> > at java.nio.Buffer.limit(Buffer.java:275)
>
> The line matches Java 8u31 sources.
> The IAE is triggered by the following check:
>
> [[[
> public final Buffer limit(int newLimit) {
> if ((newLimit > capacity) || (newLimit < 0))
> throw new IllegalArgumentException();
> ]]]
>
> > org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:179)
>
> The above does not match Tomcat 7 sources. By method name I guess that is
> line 356.
The reference in comment #1 says Tomcat 8.0.17. I'm sorry I didn't set the
correct version. I was able to reproduce this in 7.0.56, 7.0.57, 7.0.50, 8.0.17
and 8.0.20 with varying stack traces. The one posted here appears to be from
Tomcat 8.0.17.
> [[[
> private int readSocket(byte[] buf, int pos, int n, boolean block)
> throws IOException {
> int nRead = 0;
> ByteBuffer readBuffer =
> socketWrapper.getSocket().getBufHandler().getReadBuffer();
> readBuffer.clear();
> readBuffer.limit(n);
> ]]]
>
> Apparently it tries to read n bytes from the Socket read buffer at once. The
> buffer is smaller that that thus the IAE.
That seems like a reasonable diagnosis, but I'm not familiar enough with how
these components interact to understand the root cause and most appropriate
fix.
I suspect this is a rare problem since most people probably stick to the
default packetSize (8192) with the AJP connector.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
