Re: Does anyone object to me applying patch for SSHD-448 ?

2015-05-06 Thread Guillaume Nodet
My original idea was to deprecate the stop methods which imho have been
superseded by the the Closable interface.
More importantly, I don't understand why sessions are not tracked.
When closing the client or server, it will close the IoService, which in
turn should close IoSession, and last, closing all ssh sessions.

2015-05-06 14:27 GMT+02:00 Lyor Goldstein :

> https://issues.apache.org/jira/browse/SSHD-448
>


RE: Does anyone object to me applying patch for SSHD-448 ?

2015-05-06 Thread Lyor Goldstein
I don’t think that's the case - the code is a bit convoluted, but IMO what 
happens is that when one closes the server only the listen socket on which it 
accepts incoming messages is closed. This means that current sessions are still 
allowed to go forward (which is strange since the ExecutorService(s) should 
also be closed - perhaps we should also investigate why this does not happen).

-Original Message-
From: Guillaume Nodet [mailto:gno...@apache.org] 
Sent: Wednesday, May 6, 2015 16:31
To: dev@mina.apache.org
Subject: Re: Does anyone object to me applying patch for SSHD-448 ?

My original idea was to deprecate the stop methods which imho have been 
superseded by the the Closable interface.
More importantly, I don't understand why sessions are not tracked.
When closing the client or server, it will close the IoService, which in turn 
should close IoSession, and last, closing all ssh sessions.

2015-05-06 14:27 GMT+02:00 Lyor Goldstein :

> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
> _jira_browse_SSHD-2D448&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVM
> NtXt-uEs&r=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo&m=gWo5SxQId8HTF
> RXM7nghjRRke9diZ6W7yKpY-IO1CkM&s=5AcMuE90DUT9Tbg_B9MVIFTI5dyLlq3f-1YwZ
> EJSqkU&e=
>


Re: Does anyone object to me applying patch for SSHD-448 ?

2015-05-06 Thread Guillaume Nodet
When closing the Nio2Service for example, all sessions (Nio2Session) will
be closed through Nio2Service#getInnerCloseable().
When a Nio2Session is closed, Nio2Session#doCloseImmediately will be called
at some point, which will call handler.sessionClosed() which will close the
AbstractSession.


2015-05-06 15:45 GMT+02:00 Lyor Goldstein :

> I don’t think that's the case - the code is a bit convoluted, but IMO what
> happens is that when one closes the server only the listen socket on which
> it accepts incoming messages is closed. This means that current sessions
> are still allowed to go forward (which is strange since the
> ExecutorService(s) should also be closed - perhaps we should also
> investigate why this does not happen).
>
> -Original Message-
> From: Guillaume Nodet [mailto:gno...@apache.org]
> Sent: Wednesday, May 6, 2015 16:31
> To: dev@mina.apache.org
> Subject: Re: Does anyone object to me applying patch for SSHD-448 ?
>
> My original idea was to deprecate the stop methods which imho have been
> superseded by the the Closable interface.
> More importantly, I don't understand why sessions are not tracked.
> When closing the client or server, it will close the IoService, which in
> turn should close IoSession, and last, closing all ssh sessions.
>
> 2015-05-06 14:27 GMT+02:00 Lyor Goldstein :
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
> > _jira_browse_SSHD-2D448&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVM
> > NtXt-uEs&r=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo&m=gWo5SxQId8HTF
> > RXM7nghjRRke9diZ6W7yKpY-IO1CkM&s=5AcMuE90DUT9Tbg_B9MVIFTI5dyLlq3f-1YwZ
> > EJSqkU&e=
> >
>


RE: Does anyone object to me applying patch for SSHD-448 ?

2015-05-06 Thread Lyor Goldstein
I am not 100% sure - at least of version 0.14 I am using it in some code I 
wrote and when I close the server side, my Putty remains connected and 
responsive. I will check this again...

-Original Message-
From: Guillaume Nodet [mailto:gno...@apache.org] 
Sent: Wednesday, May 6, 2015 16:55
To: dev@mina.apache.org
Subject: Re: Does anyone object to me applying patch for SSHD-448 ?

When closing the Nio2Service for example, all sessions (Nio2Session) will be 
closed through Nio2Service#getInnerCloseable().
When a Nio2Session is closed, Nio2Session#doCloseImmediately will be called at 
some point, which will call handler.sessionClosed() which will close the 
AbstractSession.


2015-05-06 15:45 GMT+02:00 Lyor Goldstein :

> I don’t think that's the case - the code is a bit convoluted, but IMO 
> what happens is that when one closes the server only the listen socket 
> on which it accepts incoming messages is closed. This means that 
> current sessions are still allowed to go forward (which is strange 
> since the
> ExecutorService(s) should also be closed - perhaps we should also 
> investigate why this does not happen).
>
> -Original Message-
> From: Guillaume Nodet [mailto:gno...@apache.org]
> Sent: Wednesday, May 6, 2015 16:31
> To: dev@mina.apache.org
> Subject: Re: Does anyone object to me applying patch for SSHD-448 ?
>
> My original idea was to deprecate the stop methods which imho have 
> been superseded by the the Closable interface.
> More importantly, I don't understand why sessions are not tracked.
> When closing the client or server, it will close the IoService, which 
> in turn should close IoSession, and last, closing all ssh sessions.
>
> 2015-05-06 14:27 GMT+02:00 Lyor Goldstein :
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.o
> > rg 
> > _jira_browse_SSHD-2D448&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-Yih
> > VM 
> > NtXt-uEs&r=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo&m=gWo5SxQId8H
> > TF 
> > RXM7nghjRRke9diZ6W7yKpY-IO1CkM&s=5AcMuE90DUT9Tbg_B9MVIFTI5dyLlq3f-1Y
> > wZ
> > EJSqkU&e=
> >
>


RE: Does anyone object to me applying patch for SSHD-448 ?

2015-05-07 Thread Lyor Goldstein
Seems you are right - stopping the server does close the connections - my 
mistake, I will close the issue...

-Original Message-
From: Lyor Goldstein [mailto:lgoldst...@vmware.com] 
Sent: Wednesday, May 6, 2015 17:04
To: dev@mina.apache.org
Subject: RE: Does anyone object to me applying patch for SSHD-448 ?

I am not 100% sure - at least of version 0.14 I am using it in some code I 
wrote and when I close the server side, my Putty remains connected and 
responsive. I will check this again...

-Original Message-
From: Guillaume Nodet [mailto:gno...@apache.org] 
Sent: Wednesday, May 6, 2015 16:55
To: dev@mina.apache.org
Subject: Re: Does anyone object to me applying patch for SSHD-448 ?

When closing the Nio2Service for example, all sessions (Nio2Session) will be 
closed through Nio2Service#getInnerCloseable().
When a Nio2Session is closed, Nio2Session#doCloseImmediately will be called at 
some point, which will call handler.sessionClosed() which will close the 
AbstractSession.


2015-05-06 15:45 GMT+02:00 Lyor Goldstein :

> I don’t think that's the case - the code is a bit convoluted, but IMO 
> what happens is that when one closes the server only the listen socket 
> on which it accepts incoming messages is closed. This means that 
> current sessions are still allowed to go forward (which is strange 
> since the
> ExecutorService(s) should also be closed - perhaps we should also 
> investigate why this does not happen).
>
> -Original Message-
> From: Guillaume Nodet [mailto:gno...@apache.org]
> Sent: Wednesday, May 6, 2015 16:31
> To: dev@mina.apache.org
> Subject: Re: Does anyone object to me applying patch for SSHD-448 ?
>
> My original idea was to deprecate the stop methods which imho have 
> been superseded by the the Closable interface.
> More importantly, I don't understand why sessions are not tracked.
> When closing the client or server, it will close the IoService, which 
> in turn should close IoSession, and last, closing all ssh sessions.
>
> 2015-05-06 14:27 GMT+02:00 Lyor Goldstein :
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.o
> > rg 
> > _jira_browse_SSHD-2D448&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-Yih
> > VM 
> > NtXt-uEs&r=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo&m=gWo5SxQId8H
> > TF 
> > RXM7nghjRRke9diZ6W7yKpY-IO1CkM&s=5AcMuE90DUT9Tbg_B9MVIFTI5dyLlq3f-1Y
> > wZ
> > EJSqkU&e=
> >
>