RFR: 8300268 : ServerImpl allows too many idle connections when using sun.net.httpserver.maxIdleConnections [v3]
Daniel Fuchs
dfuchs at openjdk.org
Wed Feb 8 11:53:49 UTC 2023
On Wed, 8 Feb 2023 11:45:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> addressed comments
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 968:
>
>> 966: boolean close = false;
>> 967:
>> 968: idleConnectionLock.lock();
>
> I am wondering if this new lock is needed to deal with this change. The `idleConnections` is already a `Collections.synchronizedSet`, so maybe we could just use it here as follows:
>
>
> boolean close = false;
>
> synchronized(idleConnections) {
> if (idleConnections.size() >= MAX_IDLE_CONNECTIONS) {
> // closing the connection here could block
> // instead set boolean and close outside of synchronized block
> close = true;
> } else {
> c.idleStartTime = System.currentTimeMillis();
> c.setState(State.IDLE);
> idleConnections.add(c);
> }
> }
>
> if (close) {
> c.close();
> allConnections.remove(c);
> }
>
>
> The reason I propose using `synchronization` on the existing collection is because, that's the "lock" we use in various other places while dealing with the `idleConnections` set. So using `synchronized` here would provide consistency when handling the `idleConnections` set. Furthermore, with the introduction of this new `idleConnectionLock`, this method is the sole place we use it and other parts of the code (like the idle timeout task) would then use a different "monitor" while dealing with the `idleConnections` set and could potentially lead to some odd issues, I think.
Good point, and good catch!
-------------
PR: https://git.openjdk.org/jdk/pull/12413
More information about the net-dev
mailing list