Re: Connection Closure due to Fatal Stream with HTTP2

[Chirag Dewan]

Hi,

This is without load balancer actually. I am directly sending to Tomcat.

Update:

A part issue I found was to be 9.0.29. I observed that when request were
timed out on client (2seconds), the client would send a RST frame. And the
GoAway from Tomcat was perhaps a bug. In 9.0.36, RST frame is replied with
a RST from Tomcat.

Now the next part to troubleshoot is why after about an hour or so,
requests are timed out at Tomcat.

Could close to 100 HTTP2 connections per second cause this on Tomcat?

Thanks

On Sun, 14 Jun, 2020, 12:27 AM Michael Osipov,  wrote:

> Am 2020-06-13 um 08:42 schrieb Chirag Dewan:
> > Hi,
> >
> > We are observing that under high load, my clients start receiving a
> GoAway
> > frame with error:
> >
> > *Connection[{id}], Stream[{id}] an error occurred during processing that
> > was fatal to the connection.*
> >
> > Background : We have implemented our clients to close connections after
> > every 500-1000 requests (streams). This is a load balancer requirement
> that
> > we are working on and hence such a behavior. So with a throughput of
> around
> > 19k, almost 40 connections are closed and recreated every second.
> >
> > After we receive this frame, my clients start behaving erroneously.
> Before
> > this as well, my clients start sending RST_STREAM with canceled for each
> > request. Could this be due to the number of connections we open? Is it
> > related to the version of Tomcat? Or maybe my clients are misbehaving?
> >
> > Now since I only receive this under heavy load, I can't quite picture
> > enough reasons for this to happen.
> >
> > Any possible clues on where I should start looking?
> >
> > My Stack:
> > Server - Tomcat 9.0.29
> > Client - Jetty 9.x
>
> Does the same happen w/o the load balancer?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Connection Closure due to Fatal Stream with HTTP2

[Michael Osipov]

Am 2020-06-13 um 08:42 schrieb Chirag Dewan:

Hi,

We are observing that under high load, my clients start receiving a GoAway
frame with error:

*Connection[{id}], Stream[{id}] an error occurred during processing that
was fatal to the connection.*

Background : We have implemented our clients to close connections after
every 500-1000 requests (streams). This is a load balancer requirement that
we are working on and hence such a behavior. So with a throughput of around
19k, almost 40 connections are closed and recreated every second.

After we receive this frame, my clients start behaving erroneously. Before
this as well, my clients start sending RST_STREAM with canceled for each
request. Could this be due to the number of connections we open? Is it
related to the version of Tomcat? Or maybe my clients are misbehaving?

Now since I only receive this under heavy load, I can't quite picture
enough reasons for this to happen.

Any possible clues on where I should start looking?

My Stack:
Server - Tomcat 9.0.29
Client - Jetty 9.x


Does the same happen w/o the load balancer?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat rfc6265 Cookie Dates

[S V Pavankumar]

Hi,

I am checking the RFC6265 as we wanted to switch to the RFC6265 Cookie 
processor. One thing I have noticed is around, the way cookie expires date is 
written to the response.

As per the RFC the date should follow RFC1123 date format 
https://tools.ietf.org/html/rfc6265#section-4.1.1


expires-av= "Expires=" sane-cookie-date

 sane-cookie-date  = https://tools.ietf.org/html/rfc1123>-date, 
defined in [RFC2616], Section 
3.3.1>

Example date format tomcat is writing

Thu, 11-Jul-2019 22:43:23 GMT private static final String 
COOKIE_DATE_PATTERN = "EEE, dd-MMM- HH:mm:ss z"; (CookieProcessorBase.java)

What RFC says,


HTTP applications have historically allowed three different formats

   for the representation of date/time stamps:



  Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 
822, updated by RFC 
1123

  Sunday, 06-Nov-94 08:49:37 GMT ; RFC 
850, obsoleted by RFC 
1036

  Sun Nov  6 08:49:37 1994   ; ANSI C's asctime() format


HTTP-date= rfc1123-date | 
rfc850-date | asctime-date

   rfc1123-date = wkday "," SP date1 
SP time SP "GMT"

   rfc850-date  = weekday "," SP date2 
SP time SP "GMT"

   asctime-date = wkday SP date3 SP time SP 4DIGIT

date1= 2DIGIT SP month SP 4DIGIT

  ; day month year (e.g., 02 Jun 1982)

   date2= 2DIGIT "-" month "-" 2DIGIT

  ; day-month-year (e.g., 02-Jun-82)

Tomcat date is getting started with short wkday then following date2 (contains 
dashes) format instead of date1.  I see both the cookie processors of tomcat 
are following the same pattern. Can tomcat keep the behavior according to RFC 
in future updates ?

Thanks,
Pavan.