You should be able to implement dispose in your plugin and do any housekeeping there. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/mod-managed-socket-binding-pro... Sent from the freeswitch-users mailing list archive at Nabble.com.

You're correct, it's not possible to work around this very easily via mod_managed. The issue is that there can be one or more outstanding calls (sessions or API calls) to your module, so the loading code loads up the new version, installs it for new calls, then waits for the reference count to hit zero before unloading the old one. And it doesn't have to be just one - as long as there's something using a module, that version will stay in memory regardless of how many newer versions are loaded. I'm open to suggestions on how mod_managed could do the loading differently. The native FreeSWITCH functions won't be of any help, as FS is unaware of the internal mod_managed module loading. As far as sorting out your situation right now: What I'd do is on module load, get a named mutex. If you get ownership, then you're the active version and can take over resources (socket bindings) and so on. Open a named pipe (System.IO.Pipes) and listen for messages. The next version of the module to load also gets the same named mutex, but it won't acquire ownership. So, it sends a message down the named pipe. The receiver of the message knows it's life is up, so it closes its ports and releases the mutex. The new version is waiting on this mutex. When it acquires the mutex, then it's the active version and opens all resources, and so on. That's not a very complete solution. For instance, 4 copies of the module could be in memory, and the mutex wait is not guaranteed to be fair. So a starting module should have some way of reading shared memory to determine if the current active version is newer than itself, and if so, not attempt to take ownership. Fortunately, I think mod_managed won't start loading a new version until it's finished loading a previous one. So, it's probably easy to sort out any race issues there. -Michael From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of babak yakhchali Sent: Thursday, October 14, 2010 2:40 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] mod_managed socket binding problem The problem is all of this functions (Dispose, Destructor ...) are called after the new instance of module is created, so on the creation of the new instance because still the old one is listening on for example port 9999 the new one can not bind to the port. I've found switch_loadable_module_function_table_t which seems to be where I should add my shut down routine but I can not find a way to do so thanx