Hi Jimmy,
"it is related to how the connection was dropped" means that this is
only observable when 1006 close code is signaled to the client endpoint?
ad second question - once Session is closed, it will remain closed
forever; reconnect will create new session.
thanks,
Pavel
On 26/08/14 17:45, Jimmy Lin wrote:
> hi Pavel,
> it is kind of hard to reproduce, kind of related to how the connection
> was dropped in the first place, but I will try again.
>
> I do have reconnecthandler (reconnect retry up to certain times)
>
> so somewhat related question..... will Session state ever change from
> close back to running? say due to reconnect handler logic?
> or session state will remain "running" until reconnect handler
> "exhausted" and return false?
>
>
> thanks
>
>
>
> On Tue, Aug 26, 2014 at 1:51 AM, Pavel Bucek <pavel.bucek_at_oracle.com
> <mailto:pavel.bucek_at_oracle.com>> wrote:
>
> 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
>
>