Skip to main content

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

There are two articles related to this. community.microfocus.com/.../13734.how-can-idle-connections-be-forced-to-close-without-depending-on-whether-there-are-client-side-object-references-bound-to-a-connection.aspx and community.microfocus.com/.../13660.vbj-how-to-close-the-client-connection-programmatically.aspx

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

The old links are gone. Use this instead community.microfocus.com/.../13734.how-can-idle-connections-be-forced-to-close-without-depending-on-whether-there-are-client-side-object-references-bound-to-a-connection.aspx and community.microfocus.com/.../13660.vbj-how-to-close-the-client-connection-programmatically.aspx

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

Thank you

The application is in C#, so we can't use the C API (Except if we use only C and wrap it in C#, but we want to have a full managed solution ...).

I guess we have to assume this connection, except if I ping the server periodically and uses an idle timeout bigger than the ping interval (the application is not state less. So we can't only use some "idle timeout" to close the connection).

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

Since your application is C#, I'm assuming VisiBroker for .NET solution is deployed, which actually similar to VisiBroker for Java.

Anyway, what exactly is your requirement, may I ask? What do you mean by "application is not state less"? What are the concerns of having the connection being bound throughout the process runtime? If it is resource concern, VisiBroker client-side make use of connection pooling, that is, only one TCP connection to the same server and all client requests sending from different threads will only reuse this same connection.

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

Yes it is VisiBroker for Net.

The application is hosted by Excel. The user may login/logout or switch from server (using the CNS). When the user logout, he may keep Excel running. In that case, the TCP/IP connection stills alive until he left Excel. Same way, if he switch from server, Excel will keep one connection alive by ever used server.

If i just use an "idle timeout", the connection pool will perfectly work, and will re-establish a physical connection when needed. But, it that case, the code will have to run again a full initialization (about 40 seconds) because the application isn't stateless (many types, for which we need to get new references within the connection).

Anyway pinging the server, and setting an idle timeout higher than the ping period should work.

Thanks for your help

Hi,

Is there a way to force the socket to be closed ?

My client application is able to "logout". But once it is done, i have seen that the physical connexion stills alive.

Sébastien

Yes it is VisiBroker for Net.

The application is hosted by Excel. The user may login/logout or switch from server (using the CNS). When the user logout, he may keep Excel running. In that case, the TCP/IP connection stills alive until he left Excel. Same way, if he switch from server, Excel will keep one connection alive by ever used server.

If i just use an "idle timeout", the connection pool will perfectly work, and will re-establish a physical connection when needed. But, it that case, the code will have to run again a full initialization (about 40 seconds) because the application isn't stateless (many types, for which we need to get new references within the connection).

Anyway pinging the server, and setting an idle timeout higher than the ping period should work.

Thanks for your help

Terms & ConditionsAccessibility statement