<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 16, 2011, at 9:43 AM, Tony Garnock-Jones wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><p>Stepping back from the immediate problem, the "real" solution is to have the JVM and .NET virtual machines grow up and behave like proper systems, complete with lifecycle events. Then, AMQP connections have a chance to clean up and disconnect on their own, without special action on the part of the programmer and without unduly delaying or preventing VM shutdown.<br></p></span></blockquote></div><br><div>If you use Spring, you get events like these. With Spring for Java, you can use the destroy-method attribute of the <bean /> element to invoke a method when the context is shutting down. I haven't used Spring with .Net, but I'd be surprised if there weren't a similar mechanism there.</div></body></html>