On 20/10/2015 14:31, Mark Thomas wrote: > On 20/10/2015 14:11, Rémy Maucherat wrote: >> 2015-10-20 14:14 GMT+02:00 Mark Thomas <ma...@apache.org>: >> >>>> The other thing I want to look at before RC1 is the current >>>> Gump/BuildBot failures. >>> >>> I'm going to start looking at these now. I also won't be surprised if >>> the refactoring triggers a couple of additional failures. The tc-native >>> 1.2.0 release is going to take a little while so that should give me the >>> time to look at the failures before tagging 9.0.0-RC1. >>> >>> +1 >> >> I'm having an issue with the HTTP/2 input design though: when body frames >> come in, they get read until it overflows the buffer. And it doesn't work >> in conjunction with non blocking obviously then (tested with the byte >> counter from the examples). >> >> IMO this is rather difficult to do since we cannot stop reading the >> connection (it would stall all streams) so the body frames have to go >> somewhere. So the "solution" is to grow the buffer in that case ? > > Essentially, yes. The buffer has to be as least as big as the current > window size. The default buffer size needs to be increased from 16k to > 64k to align with the HTTP/2 default initial window size.
I have committed an untested fix for this. >> Other topic: any ideas on my NIO2/chrome issue ? > > Sorry, not yet. Still looking at a Gump failure that looks to have been > triggered by an error in my refactoring. I found the root cause of the Gump failure. It was an error in the refactoring when I switched WebSocket from Servlet 3.1 non-blockin I/O to goting directly to Tomcat's I/O layer. I'll take a look at NIO2/Chrome next. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
