On 24/09/2021 19:21, Christopher Schultz wrote:
Mark,
Sorry for the top-post but this is quite a long patch and it will be
easier to find my comments up here.
No problem. Makes sense.
When generating the String value for the request identifier, you could use:
private String requestId =
Long.toHexString(requestIdGenerator.getAndIncrement());
This would produce smaller strings, use slightly less CPU, and then
nobody cares whether the value is - or +.
Excellent. I like it. I'll make the change. We might need those extra
3,000,000 years before failover ;)
Should the new request-id be generated during recycle() or during
another time? Is there a method which is always called to re-commission
a Request object? If so, I think it would make more sense to leave the
requestId alone in recycle() and allocate the new request-id in that
other method.
Not sure. I'll take a look.
In cases where there are use-after-recycle errors in an application,
having the old request-id might be helpful in debugging.
I think that could go either way. The ID changing as soon as recycle is
called might make use after recycle easier to spot.
The more I think about this, the more I think changing ID on recycle is
the way to go but I am prepared to be convinced otherwise.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
