Closed arekfirus closed 1 year ago
@arekfirus - do you think your finding could be the cause for failing tests:
TCPNIOTransportTest.testMultiBind:139 » Bind Address already in use
...
TCPNIOTransportTest.testMultiBind:161 Server connection should be closed!
...
HttpResponseParseTest.testSimpleHeaders:71->doHttpResponseTest:181 » Bind Addr...
?
@pzygielo , my knowledge of Grizzly is quite limited but I think these problems are not correlated. The problems which you have mentioned are related to binding to network address. The shutdown
method closes all network listeners correctly, so this two things should have nothing in common. At least at the first sight.
The shutdown
method leaves the HttpServer
in a strange state when it does accept no incoming connections (because the listeners are closed) but beside of that, everything still works and resources are not released. I am not sure if it was intentional.
I faced a problem of OOM appearing during tests after the upgrade of Grizzly and after the investigation I found that strange behavior.
Thanks for the details, @arekfirus.
I have found a strange behavior of Grizzly's
HttpServer
class. Once it is shutdown (usingshutdown
method notshutdownNow
) not all resources are released.The problem started to appear in 2.4.0 version and it is still present in 3.x. The problem was not present in 2.3.x. Please see attached project showing the behavior. grizzly_http_server_shutdown.tar.gz
I think the situation is caused by commenting the invocation of the
shutdownNow
method once all listeners are closed: https://github.com/javaee/grizzly/blob/master/modules/http-server/src/main/java/org/glassfish/grizzly/http/server/HttpServer.java#L388To work around the problem, invocation of
shutdownNow
needs to be done manually (for example when the future, returned by the shutdown method, finishes).The situation is the most problematic in tests when many instances of
HttpServer
can be created and destroyed in single JVM. In such cases it leads to memory leak.