EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Clean shutdown

Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.
#19644
Posted: 04/02/2012 05:37:36
by Tim Frost (Standard support level)
Joined: 07/20/2007
Posts: 17

We are designing an application where a number of different clients on separate machines send messages to a service application in order to request and release a resource lock.

In testing, I have found that if a client application crashes, the process usually fails to terminate unless I have trapped the exception and de-activated the socket transport. Obviously, we hope that applications will not crash in production, but I would like to find a way of avoiding the need to manually terminate the app, as this annoys users even more than a crash!

Since the clients will often be multithreaded, it is not possible to de-activate the transport after sending each message, and this might have a performance penalty even if it was possible.

What's the best way of handling this issue?
#19646
Posted: 04/02/2012 05:57:13
by Eugene Mayevski (EldoS Corp.)

Quote
Tim Frost wrote:
In testing, I have found that if a client application crashes, the process usually fails to terminate unless I have trapped the exception and de-activated the socket transport.


I am not sure that I understood this. What process are you talking about?


Sincerely yours
Eugene Mayevski
#19649
Posted: 04/02/2012 06:41:46
by Tim Frost (Standard support level)
Joined: 07/20/2007
Posts: 17

I was not sufficiently precise. I find that when I terminate a client program normally after it has sent MsgConnect messages, the termination does not complete (and the process remains in the Windows process list) unless I first set the socket transport Active property to false. Otherwise the process has to be terminated with Process Explorer or Task Manager. If this is unexpected, then this is the real problem!

If the program crashes with an unhandled exception, it will not have gone through the close function, so will always hang.
#19651
Posted: 04/02/2012 07:00:44
by Eugene Mayevski (EldoS Corp.)

The transport runs secondary threads which need to be notified about the application being closed. This is done by the transport. You need to ensure that transport's destructor is called in one way or another. If you are sure that the destructor is executed and hangs (while trying to disable the transport), then we can work on this problem (it does happen sometimes and the workaround is to set NoUDPNotify property to true). If the destructor is not called sometimes, then you have to make it work always.


Sincerely yours
Eugene Mayevski
#19652
Posted: 04/02/2012 11:20:29
by Tim Frost (Standard support level)
Joined: 07/20/2007
Posts: 17

Thanks, ensuring that the destructor was called seems to have fixed it.
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 3340 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!