Hi Jimmy,
please see inline.
On 26/08/14 10:44, Jimmy Lin wrote:
> Hi,
> after creating(ClientManager.connectToServer) and
> closing(Session.close) tyrus endpoint multiple times, we found out
> there are many Grizzly(1) (2) and Selector thread left over in our VM.
>
> Basically every time when our application detected session's state is
> close(abnormally), we will first called session.close (attempt to
> clean up everything) and then create new endpoint.
>
> is it the best practice to clean up Grizzly worker threads in Grizzly
> container/socket?
once the session is closed, it should not be necessary to invoke
session.close() method - it won't do much in that case, underlying
grizzly transport should be already closed.
> (basically assuming session.close will do all the magic, but
> apparently somehow Grizzly threads still around)
>
>
> thanks
Can you please produce minimal reproducible testcase? You can use echo
sample as a starting point (it might be easier if you don't have maven
project).
From what I know, this should not happen (if you are not using shared
container feature [1]) - are you sure you are not "leaking" sessions to
somewhere, keeping them open? Also, if you are trying to implement
persistent client connection - have you considered using Tyrus
ReconnectHandler [2]?
Thanks,
Pavel
[1]
https://tyrus.java.net/apidocs/1.8.2/org/glassfish/tyrus/client/ClientProperties.html#SHARED_CONTAINER
[2]
https://tyrus.java.net/apidocs/1.8.2/org/glassfish/tyrus/client/ClientProperties.html#RECONNECT_HANDLER