On 19/01/2024 10:24, Rémy Maucherat wrote:
On Fri, Jan 19, 2024 at 11:08 AM Mark Thomas <ma...@apache.org> wrote:
On 19/01/2024 09:22, Rémy Maucherat wrote:
On Thu, Jan 18, 2024 at 8:18 PM <ma...@apache.org> wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 67638c17e7 Fix backport of BZ 66508 regression fix
67638c17e7 is described below
commit 67638c17e7c19a0280ccafa340183fb179af92f5
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Thu Jan 18 18:52:30 2024 +0000
Fix backport of BZ 66508 regression fix
I don't understand the differences introduced.
In SocketWrapperBase, the lock is not a ReentrantLock, but it still
cannot be anything else:
private final Lock lock = new ReentrantLock();
So couldn't the code be the same as in Tomcat 11 ? (with an extra
cast, but no need to check anything)
SocketWrapperBase.getLock() isn't final so it is possible for the
SocketWrapper implementation in a sub-class to override it and use a
different lock type.
I think ReentrantLock is the only realistic option here but I was aiming
to be extra careful to avoid breakage. We do have some users that
implement custom connectors so I couldn't be sure that a cast wouldn't
break in rare cases.
Oops. silly me, getLock can indeed return whatever. It would be really
odd, but it's possible.
Sorry for the noise ...
No problem. I almost went with the cast approach on the basis that
ReentrantLock was the only realistic option. It is good to have a check
on these sorts of things.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
