If app B's machine is turned off, what are you hoping to have app A do? Should it store the request to be processed later and tell the user to come back tomorrow for the answer? <kidding>Or should it send an email to someone to have machine B turned back on, putting the user's phone number in the message, and put up a dialog telling the user to wait until he gets a phone call?</kidding>
You could use an MSMQ channel. Then app A would survive app B's machine being powered off, regardless of whether it went off before the operation is queued up or while it was processing. It would (of course) just take until machine B comes back up before the operation would be completed. Someone was puking at having to use MSMQ in an earlier thread, but if you really need things to be very robust, it's an easier (and probably higher-quality) solution than "rolling your own" robustness mechanism. At 04:44 AM 7/20/2006, Ragnvald Barth wrote >Lets say the machine application B is running on is powered off. It would >then be impossible to make application B robust enough to keep running... >So, the problem must be solved in application A, but thanks anyway. > >Normally a failing asynchronous operation would cause an exception to be >thrown from EndOperation, not from BeginOperation as the case is here. I >am aware that I could create a workaround by catching and storing the >exception when BeginOperation is called, and wrap and throw from >EndOperation. But that would require me to create an implementation of >IAsyncResult so it is a quite extensive workaround. > >I have discovered a solution that works if the contract implementation >object is created as a callback contract by WCF: The >OperationContext.Current.Channel provides Closing, Closed and Faulted >events! > >I cant find any good solution when the contract is created by application >A. The same events should be accessible in the API somewhere. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
