On 24/09/2021 20:27, Christopher Schultz wrote:
Mark,
On 9/24/21 14:39, Mark Thomas wrote:
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.
How about requestId = -1 on recycle (and create) but set it to a
definite value when it's "in service"?
Whilst I like the idea of being able to tell from the ID that the
request is recycled, at the back of my mind are some historical bugs
where we have two Processors (and hence 2 Requests) assigned to the same
connection at the same time. I think always having a unique ID for the
request is important for debugging that use case.
Your suggestion got me thinking though. It might be possible to ensure
that once the request has been recycled (and the new ID issued) that
subsequent calls to recycle before the start of the next request don't
trigger an increment in the ID.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
