You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2015/10/16 12:26:41 UTC
Plan for 9.0.0.RC1
Hi,
As you may have noticed I have been busy with the Servlet 4.0 updates in
the last week or so, taking advantage of all the previous work on
connector refactoring and the HTTP/2 implementation.
9.0.x is now aligned with Servlet 4.0.b01 plus a couple of minor API
tweaks made post that release.
I think now is the time to give users a chance to use 9.0.x so we can
start gathering feedback on what works and what doesn't.
Therefore, I plan to tag 9.0.0.RC1 early next week and call a release
vote. Before I tag, there are a few things I want to finish off. They are:
- update server.xml to use new TLS configuration style
- start the 9.0.x migration guide
If anyone can think of anything they feel must be done before a
9.0.0.RC1 release then please speak up now.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by jean-frederic clere <jf...@gmail.com>.
On 10/22/2015 05:19 PM, Rémy Maucherat wrote:
> 2015-10-22 16:56 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> On 19/10/2015 13:38, Rémy Maucherat wrote:
>>> 2015-10-19 14:24 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>>>> Anything reproducible?
>>>
>>> Chrome mostly, Firefox is a bit nicer for me. I use JF's ApacheCon
>> example
>>> as well so that issues are easier to see:
>>> https://github.com/jfclere/h2_demos/tree/master/httpd
>>> Although APR works perfectly, NIO has some glitches and NIO2 doesn't
>> work.
>>> After debugging everything, I think the encryption layer is fine, the IO
>>> looks fine as well, and the HTTP2 code looks ok as well.
>>
>> First of all, I have to say that the sslImplementationName option on the
>> Connector is fantastic. To be able to switch from APR to NIO+OpenSSL
>> that easily is great.
>>
>> JF's HTTP/2 example web page is pretty good too.
>>
>
> Cool ! Yes, it's a good stress test which makes it easy to spot an issue.
>
>>
>> I've got things up and running on Windows (a good opportunity to test
>> the tcnative binaries) and I see what looks to be the same problem with
>> Chrome + NIO2 in that no images are displayed. Even a simple HTTP/2 page
>> fails.
>>
>
> That's what I get. Nice test since I had never tried the OpenSSL engine on
> Windows [and I don't think JF did either].
I have issue building 1.0.2c on my windows box for the moment...
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-22 16:56 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 19/10/2015 13:38, Rémy Maucherat wrote:
> > 2015-10-19 14:24 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> >> Anything reproducible?
> >
> > Chrome mostly, Firefox is a bit nicer for me. I use JF's ApacheCon
> example
> > as well so that issues are easier to see:
> > https://github.com/jfclere/h2_demos/tree/master/httpd
> > Although APR works perfectly, NIO has some glitches and NIO2 doesn't
> work.
> > After debugging everything, I think the encryption layer is fine, the IO
> > looks fine as well, and the HTTP2 code looks ok as well.
>
> First of all, I have to say that the sslImplementationName option on the
> Connector is fantastic. To be able to switch from APR to NIO+OpenSSL
> that easily is great.
>
> JF's HTTP/2 example web page is pretty good too.
>
Cool ! Yes, it's a good stress test which makes it easy to spot an issue.
>
> I've got things up and running on Windows (a good opportunity to test
> the tcnative binaries) and I see what looks to be the same problem with
> Chrome + NIO2 in that no images are displayed. Even a simple HTTP/2 page
> fails.
>
That's what I get. Nice test since I had never tried the OpenSSL engine on
Windows [and I don't think JF did either].
>
> I'm hoping that the recent handful of HTTP/2 fixes will have made the
> root cause easier to track down. I guess I'll find out soon enough.
>
> Ok, I hope you'll find something interesting.
Rémy
Re: Plan for 9.0.0.RC1
Posted by jean-frederic clere <jf...@gmail.com>.
On 10/23/2015 03:12 PM, Mark Thomas wrote:
> On 23/10/2015 12:26, Mark Thomas wrote:
>> On 23/10/2015 11:54, Rémy Maucherat wrote:
>>> 2015-10-23 10:12 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>>
>>>> I've made a little progress.
>>>>
>>>> I can see in Wireshark that the initial HTTP/2 connection preface is
>>>> sent followed by a SETTINGS frame are sent by Chrome.
>>>>
>>>> Debug logging in Tomcat shows that that data is never processed by the
>>>> Http2UpgradeHandler.
>>>>
>>>> My current thinking is that this data is getting lost somewhere in the
>>>> handshake process. I want to add more debug logging to Tomcat so I can
>>>> track all the bytes and match up what I see in Wireshark with what I see
>>>> in Tomcat.
>>>>
>>> I did spend some time debugging the handshake but found nothing
>>> interesting [it works and the state is as it should be after it]. Maybe
>>> you'll have better luck though.
>>
>> Not so far :(.
>>
>> I have is a bunch of theories all of which have been disproved as soon
>> as I add some more debug logging.
>>
>> The only positive is that I am filling in some gaps in the debug logging
>> for HTTP/2 as I go. Some of it might be over the top. We might want to
>> prune it once everything is stable.
>
> Found it.
>
> unwrap() only unwraps one TLS Record at a time. If there are multiple
> TLS records in the input buffer unwrap reads them all into the engine
> but only provides the decrypt for the first. Further calls to unwrap are
> required to decrypt the remaining records.
Cool. My demo is now working for all connectors.
>
> I have put in a work-around but I'm not sure it is in the right place.
> This feels like something that should be fixed at a lower level
> (tcnative?) so a call to unwrap unwarps as much as possible.
Well the work-around isn't too ugly I would keep it, the more stuff in
java the better.
Cheers
Jean-Frederic
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-23 15:12 GMT+02:00 Mark Thomas <ma...@apache.org>:
> Found it.
>
> unwrap() only unwraps one TLS Record at a time. If there are multiple
> TLS records in the input buffer unwrap reads them all into the engine
> but only provides the decrypt for the first. Further calls to unwrap are
> required to decrypt the remaining records.
>
> I have put in a work-around but I'm not sure it is in the right place.
> This feels like something that should be fixed at a lower level
> (tcnative?) so a call to unwrap unwarps as much as possible.
>
>
Awesome, thanks a lot for this finding ! Yes, looking at it I'd say there's
something which could be improved in the OpenSSL engine. I wonder what the
JSSE behavior is, since it seems to happen quite rarely (if at all) with
HTTP/1.1.
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 23/10/2015 12:26, Mark Thomas wrote:
> On 23/10/2015 11:54, Rémy Maucherat wrote:
>> 2015-10-23 10:12 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>>> I've made a little progress.
>>>
>>> I can see in Wireshark that the initial HTTP/2 connection preface is
>>> sent followed by a SETTINGS frame are sent by Chrome.
>>>
>>> Debug logging in Tomcat shows that that data is never processed by the
>>> Http2UpgradeHandler.
>>>
>>> My current thinking is that this data is getting lost somewhere in the
>>> handshake process. I want to add more debug logging to Tomcat so I can
>>> track all the bytes and match up what I see in Wireshark with what I see
>>> in Tomcat.
>>>
>> I did spend some time debugging the handshake but found nothing
>> interesting [it works and the state is as it should be after it]. Maybe
>> you'll have better luck though.
>
> Not so far :(.
>
> I have is a bunch of theories all of which have been disproved as soon
> as I add some more debug logging.
>
> The only positive is that I am filling in some gaps in the debug logging
> for HTTP/2 as I go. Some of it might be over the top. We might want to
> prune it once everything is stable.
Found it.
unwrap() only unwraps one TLS Record at a time. If there are multiple
TLS records in the input buffer unwrap reads them all into the engine
but only provides the decrypt for the first. Further calls to unwrap are
required to decrypt the remaining records.
I have put in a work-around but I'm not sure it is in the right place.
This feels like something that should be fixed at a lower level
(tcnative?) so a call to unwrap unwarps as much as possible.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 23/10/2015 11:54, Rémy Maucherat wrote:
> 2015-10-23 10:12 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> I've made a little progress.
>>
>> I can see in Wireshark that the initial HTTP/2 connection preface is
>> sent followed by a SETTINGS frame are sent by Chrome.
>>
>> Debug logging in Tomcat shows that that data is never processed by the
>> Http2UpgradeHandler.
>>
>> My current thinking is that this data is getting lost somewhere in the
>> handshake process. I want to add more debug logging to Tomcat so I can
>> track all the bytes and match up what I see in Wireshark with what I see
>> in Tomcat.
>>
> I did spend some time debugging the handshake but found nothing
> interesting [it works and the state is as it should be after it]. Maybe
> you'll have better luck though.
Not so far :(.
I have is a bunch of theories all of which have been disproved as soon
as I add some more debug logging.
The only positive is that I am filling in some gaps in the debug logging
for HTTP/2 as I go. Some of it might be over the top. We might want to
prune it once everything is stable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-23 10:12 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I've made a little progress.
>
> I can see in Wireshark that the initial HTTP/2 connection preface is
> sent followed by a SETTINGS frame are sent by Chrome.
>
> Debug logging in Tomcat shows that that data is never processed by the
> Http2UpgradeHandler.
>
> My current thinking is that this data is getting lost somewhere in the
> handshake process. I want to add more debug logging to Tomcat so I can
> track all the bytes and match up what I see in Wireshark with what I see
> in Tomcat.
>
> I did spend some time debugging the handshake but found nothing
interesting [it works and the state is as it should be after it]. Maybe
you'll have better luck though.
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 23/10/2015 08:39, Rémy Maucherat wrote:
> 2015-10-22 16:56 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> I've got things up and running on Windows (a good opportunity to test
>> the tcnative binaries) and I see what looks to be the same problem with
>> Chrome + NIO2 in that no images are displayed. Even a simple HTTP/2 page
>> fails.
>>
>
> If you don't find anything obvious, NIO works so that's good enough for
> this build.
I've made a little progress.
I can see in Wireshark that the initial HTTP/2 connection preface is
sent followed by a SETTINGS frame are sent by Chrome.
Debug logging in Tomcat shows that that data is never processed by the
Http2UpgradeHandler.
My current thinking is that this data is getting lost somewhere in the
handshake process. I want to add more debug logging to Tomcat so I can
track all the bytes and match up what I see in Wireshark with what I see
in Tomcat.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-22 16:56 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I've got things up and running on Windows (a good opportunity to test
> the tcnative binaries) and I see what looks to be the same problem with
> Chrome + NIO2 in that no images are displayed. Even a simple HTTP/2 page
> fails.
>
If you don't find anything obvious, NIO works so that's good enough for
this build.
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 19/10/2015 13:38, Rémy Maucherat wrote:
> 2015-10-19 14:24 GMT+02:00 Mark Thomas <ma...@apache.org>:
>> Anything reproducible?
>
> Chrome mostly, Firefox is a bit nicer for me. I use JF's ApacheCon example
> as well so that issues are easier to see:
> https://github.com/jfclere/h2_demos/tree/master/httpd
> Although APR works perfectly, NIO has some glitches and NIO2 doesn't work.
> After debugging everything, I think the encryption layer is fine, the IO
> looks fine as well, and the HTTP2 code looks ok as well.
First of all, I have to say that the sslImplementationName option on the
Connector is fantastic. To be able to switch from APR to NIO+OpenSSL
that easily is great.
JF's HTTP/2 example web page is pretty good too.
I've got things up and running on Windows (a good opportunity to test
the tcnative binaries) and I see what looks to be the same problem with
Chrome + NIO2 in that no images are displayed. Even a simple HTTP/2 page
fails.
I'm hoping that the recent handful of HTTP/2 fixes will have made the
root cause easier to track down. I guess I'll find out soon enough.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-19 14:24 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 19/10/2015 12:27, Rémy Maucherat wrote:
> > 2015-10-16 12:26 GMT+02:00 Mark Thomas <ma...@apache.org>:
> >
> >> I think now is the time to give users a chance to use 9.0.x so we can
> >> start gathering feedback on what works and what doesn't.
> >>
> > I'm still having problems with HTTP/2 and NIOx, mostly NIO2. Still no
> idea
> > why, I simply don't see anything wrong done by the server :(
>
> Anything reproducible?
>
Chrome mostly, Firefox is a bit nicer for me. I use JF's ApacheCon example
as well so that issues are easier to see:
https://github.com/jfclere/h2_demos/tree/master/httpd
Although APR works perfectly, NIO has some glitches and NIO2 doesn't work.
After debugging everything, I think the encryption layer is fine, the IO
looks fine as well, and the HTTP2 code looks ok as well.
>
> > Also, it's a bit difficult to release this build without a first Tomcat
> > Native build from trunk.
>
> Good point. I'll put a 1.2.0 release on my TODO list.
>
> Ok, go ahead for a first build IMO, there will be improvements later in
that branch [like the ability to do SSL without APR, hopefully].
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 19/10/2015 13:40, jean-frederic clere wrote:
> On 10/19/2015 02:24 PM, Mark Thomas wrote:
>> On 19/10/2015 12:27, Rémy Maucherat wrote:
>>> 2015-10-16 12:26 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>>
>>>> I think now is the time to give users a chance to use 9.0.x so we can
>>>> start gathering feedback on what works and what doesn't.
>>>>
>>> I'm still having problems with HTTP/2 and NIOx, mostly NIO2. Still no
>>> idea
>>> why, I simply don't see anything wrong done by the server :(
>>
>> Anything reproducible?
>>
>>> Also, it's a bit difficult to release this build without a first Tomcat
>>> Native build from trunk.
>>
>> Good point. I'll put a 1.2.0 release on my TODO list.
>
> Cool but note it requires a quite new openssl I would like to see how it
> can work without APR.
That sounds like a 2.0.0 to me.
If we remove APR from tc-native, doesn't that also mean removing support
for the APR/native connector? I'd be fine with that and just using
tc-native to support the OpenSSL engine for NIO & NIO2. That would
definitely make it a 2.0.0 thing.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by jean-frederic clere <jf...@gmail.com>.
On 10/19/2015 02:24 PM, Mark Thomas wrote:
> On 19/10/2015 12:27, Rémy Maucherat wrote:
>> 2015-10-16 12:26 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>>> I think now is the time to give users a chance to use 9.0.x so we can
>>> start gathering feedback on what works and what doesn't.
>>>
>> I'm still having problems with HTTP/2 and NIOx, mostly NIO2. Still no idea
>> why, I simply don't see anything wrong done by the server :(
>
> Anything reproducible?
>
>> Also, it's a bit difficult to release this build without a first Tomcat
>> Native build from trunk.
>
> Good point. I'll put a 1.2.0 release on my TODO list.
Cool but note it requires a quite new openssl I would like to see how it
can work without APR.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 19/10/2015 12:27, Rémy Maucherat wrote:
> 2015-10-16 12:26 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> I think now is the time to give users a chance to use 9.0.x so we can
>> start gathering feedback on what works and what doesn't.
>>
> I'm still having problems with HTTP/2 and NIOx, mostly NIO2. Still no idea
> why, I simply don't see anything wrong done by the server :(
Anything reproducible?
> Also, it's a bit difficult to release this build without a first Tomcat
> Native build from trunk.
Good point. I'll put a 1.2.0 release on my TODO list.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-16 12:26 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I think now is the time to give users a chance to use 9.0.x so we can
> start gathering feedback on what works and what doesn't.
>
> I'm still having problems with HTTP/2 and NIOx, mostly NIO2. Still no idea
why, I simply don't see anything wrong done by the server :(
Also, it's a bit difficult to release this build without a first Tomcat
Native build from trunk.
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 21/10/2015 15:31, Rémy Maucherat wrote:
> 2015-10-21 16:14 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> On 20/10/2015 15:30, Mark Thomas wrote:
>>
>>> 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.
>>
>> Sorry, I still haven't got to this. I was distracted by finding that the
>> non-blocking I/O examples were failing for HTTP/2.
>>
>> Having fixed those bugs, are your NIO2/Chrome issues any better?
>>
> Yes, it still looks the same. For some reason some timeouts occur although
> it looks fairly certain the server didn't receive anything or misprocessed
> some input [or output since it's fairly certain the encryption and IO work
> well enough for static files].
Drat. I thought those fixes might help. Oh well.
I plan to start the 1.2.0 tc-native release next and then look at this
while that vote runs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-21 16:14 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 20/10/2015 15:30, Mark Thomas wrote:
>
> > 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.
>
> Sorry, I still haven't got to this. I was distracted by finding that the
> non-blocking I/O examples were failing for HTTP/2.
>
> Having fixed those bugs, are your NIO2/Chrome issues any better?
>
> Yes, it still looks the same. For some reason some timeouts occur although
it looks fairly certain the server didn't receive anything or misprocessed
some input [or output since it's fairly certain the encryption and IO work
well enough for static files].
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 20/10/2015 15:30, Mark Thomas wrote:
> 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.
Sorry, I still haven't got to this. I was distracted by finding that the
non-blocking I/O examples were failing for HTTP/2.
Having fixed those bugs, are your NIO2/Chrome issues any better?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
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.
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Rémy Maucherat <re...@apache.org>.
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 ?
Other topic: any ideas on my NIO2/chrome issue ?
Rémy
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 19/10/2015 12:10, Mark Thomas wrote:
> On 16/10/2015 11:26, Mark Thomas wrote:
>> Hi,
>>
>> As you may have noticed I have been busy with the Servlet 4.0 updates in
>> the last week or so, taking advantage of all the previous work on
>> connector refactoring and the HTTP/2 implementation.
>>
>> 9.0.x is now aligned with Servlet 4.0.b01 plus a couple of minor API
>> tweaks made post that release.
>>
>> I think now is the time to give users a chance to use 9.0.x so we can
>> start gathering feedback on what works and what doesn't.
>>
>> Therefore, I plan to tag 9.0.0.RC1 early next week and call a release
>> vote. Before I tag, there are a few things I want to finish off. They are:
>> - update server.xml to use new TLS configuration style
>> - start the 9.0.x migration guide
>
> I've done these.
>
>> If anyone can think of anything they feel must be done before a
>> 9.0.0.RC1 release then please speak up now.
>
> A few things occurred to me over the weekend.
>
> There is a TODO for Async timeouts and HTTP/2. I'm planning on leaving
> that as a known TODO for the first RC. I think this will be easier to
> implement after I have completed some more refactoring and I'm not sure
> how long that refactoring will take.
This was easier that I thought it would be so this has been completed.
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for 9.0.0.RC1
Posted by Mark Thomas <ma...@apache.org>.
On 16/10/2015 11:26, Mark Thomas wrote:
> Hi,
>
> As you may have noticed I have been busy with the Servlet 4.0 updates in
> the last week or so, taking advantage of all the previous work on
> connector refactoring and the HTTP/2 implementation.
>
> 9.0.x is now aligned with Servlet 4.0.b01 plus a couple of minor API
> tweaks made post that release.
>
> I think now is the time to give users a chance to use 9.0.x so we can
> start gathering feedback on what works and what doesn't.
>
> Therefore, I plan to tag 9.0.0.RC1 early next week and call a release
> vote. Before I tag, there are a few things I want to finish off. They are:
> - update server.xml to use new TLS configuration style
> - start the 9.0.x migration guide
I've done these.
> If anyone can think of anything they feel must be done before a
> 9.0.0.RC1 release then please speak up now.
A things occurred to me over the weekend.
There is a TODO for Async timeouts and HTTP/2. I'm planning on leaving
that as a known TODO for the first RC. I think this will be easier to
implement after I have completed some more refactoring and I'm not sure
how long that refactoring will take.
The other thing I want to look at before RC1 is the current
Gump/BuildBot failures.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org