Lets suppose I have an .NET client application that connects to a WCF service, or perhaps a message queue. During the normal execution of the program it is possible that there might be connection losses or maybe the user has been forced to log off by the administrator, or the administrator sends a message to the app to change and login to another WCF server (e.g. some form of manual load balancing).
The client application would only know about this when any one of many low level methods ties to make a WCF call and it fails.
When such a thing happens I'd like the application and all its windows to somehow be disabled/hidden, for a dialog box / splash window to come up and do a reconnection, and once successful the windows get shown again.
How does one go about doing this? The problem I see is that the code which first finds out there is a problem is at the lowest level (i.e. maybe as a result of a button click on a dialog window that is on top of main windows). Sort of need the program to be inside out to handle it intuitively. Therefore I am assuming there are some patterns or frameworks that help with this?
Unfortunately there isn't a great way of doing this because the exceptions caused by it are going to start anyplace a WCF call can happen and go upward until something catches them. For the HTTP bindings you know when that will be because WCF only does anything when you make an explicit call, so you could catch any disconnect/timeout exceptions and deal with them appropriately.
For message queues or TCP bindings I think it might get a bit messier, but the tactic is the same. Anytime you're making a WCF call, you'll need to watch for the appropriate exceptions and then the application will have to call some function that can change the UI how you want.
I believe what you're looking for is called "exception handling". Exceptions are the way to get from the bottom to the top.
One of the possible solutions you may apply is you may call some kind of non-transactional method that will return minimal result in a fixed interval. Or if you can get the underlying socket object of the instantiated wcf client; the overhead of checking is not that huge. Though socket objects probably don't have some kind of event that is related to disconnection; you may check only if you try to communicate to the other end but I might be wrong about this.
Related
Hey i recently created a text message application in c# that sends messages back in forth in a console. I used NetworkCommsDotNet & NetworkCommsDotNet.Connections.
When i was researching about it i found a command NetworkComms.Shutdown() http://www.networkcomms.net/api/html/M_NetworkCommsDotNet_NetworkComms_Shutdown.htm
I'm also new to programming so i really didn't completely understand what they where saying and was still left wondering if I don't use this in my program, will it break something or mess up my router in any way?
ps - the program works and i had success with testing it between two computers on my home network.
I haven't used this, nor even know what it is, however i am good at reading documentation and believe what they tell me (for the most part)
Shutdown all connections, threads and execute OnCommsShutdown event.
Any packet handlers are left unchanged. If any network activity has
taken place this should be called on application close.
The reason why its telling you this, is that is most likely using unmanaged resources, and most likely wants to gracefully shut them down or clean them up. Since there is no open source for this project, we can only listen to what its telling you
In asp.net, there is app_offline.htm which let you shutdown website gracefully.I want to implemet similar function in client.
There is a flag to set to maintenance mode,if flag is on:
When user start the client, user will be prompted something like "system is under maintenance, try again after 30 mins".
Any new update/delete/add operations, similar message prompted.
Ongoing requests will be processed.
How to implement this?
Given the differences in application architecture, this is not something that is going to have a "one-size-fits-all" type solution that is going to work for everyone.
app_offline.html for web applications is truly a "sledgehammer" approach. The app is down, yes it is graceful but it is a 100% hard stop.
A primitive way of doing this within your application could be to have a service call that you make on a regular basis for "Is online" or similar. If it returns false, force quit your current form and show a splashpage.
But this is really going to depend on architecture.
You can put a condition when starting the client, but you if you want the same behavior like app_offline.htm, you may also want to put under maintenance an already opened client.
In this case, you can install a MessageFilter in order to intercept any event across the whole Winforms app.
I want to test my server as to how many simultaneous connections it can handle .. having considerably low connection problems... in other words to simulate a stress testing Scenario. How do I go about it?
Thanks for your advice.
You could create a class called SimulatedClient, which encapsulates a Thread. The Thread could just connect to your server, or send a HTTP GET request simulating downloading a file, or anything else you'd like. You could create any sort of application to host the clients, say a Console or WPF app.
It would create any number of SimulatedClients (perhaps configurable in app.config), start them all then monitor for problems (by catching and logging exceptions - or simply breaking into the debugger) and/or perform any performance testing. If it's the latter I would suggest taking a look at the System.Diagnostics.Stopwatch class.
With a WPF or other kind of visual app you could have a nice grid (e.g. ListView with the View set to a GridView) bound to the collection of simulated clients, with columns for things like Status, Duration, Errors - if you made them DependencyProperties you would see the results update in realtime.
If it's a web server see http://support.microsoft.com/kb/231282
if an administrator logs on to my service, he may wish to disconnect sessions which meet (or don't meet) certain requirements, be it automated or manual. throwing exceptions seems like a simple and effective solution, as all resources are released.
i could use a local bool field which, if true, would disconnect this user the next time he calls any of the methods, but that doesn't seem like an elegant solution.
and, it doesn't have to be throwing exception, as i've already noticed you can use OperationContext.Current.Channel.Close(), or abort, to disable access to that session.
is there a "standard" way to do this in wcf?
From within a given 'session', I do not think there is an out-of-the-box way to do anything with another session (i.e. instance context).
You can however track clients that connect to your service by utilizing the IChannelInitializer interface in conjunction with a service or contract behavior. This would give you access to each clients' associated channel which you could then close if you wanted to, although this would not necessarily produce a very informative fault on the client end as it would look like a communication issue.
Another option is to look at callbacks if you have control over the clients that are accessing the service. By utilizing the above mentioned client tracking in conjunction with callbacks you can actually cause the client to more gracefully close its own channel and potentially inform the user of what happened.
i have to implement a Info Terminal. I choose dot.net and the terminal is only a touchpad.
So this System running 7 days 24 hours.
So i call a Webservice, display Data, show Website stuff. Many things can going wrong.
Have you some recommendations for this scenario?
Every function in an try catch? AppDomain.CurrentDomain.UnhandledException event?
Thanks Andreas
Basically, you should handle any error as soon as it is possible - so if you're calling webservice wrap all the calls in a try/catch block and handle the error there - you can, for example, log the exact error, aggregate many webservice-related exception in more generic, DataSourceFaultException (name is only for example), which will be then received by UI and UI will be able to easily determine, that it can't display requested info because communication failed, and choose to retry, notify user or do anything else.
However - with long running application there are many more errors you'll have to deal with. Many of them are not easy to predict, as they're not necessarily related to any specific call - you can run out of memory, a recursion might cause stack overflow, a system timer can reach it's max value and start from the beginning etc.
You shouldn't handle those errors in every method, as it will only hurt code readibility and will be error prone. Those errors are best handled by UnhandledException event. However, you must remember, that when the exception reaches UnhandledException event, you cannot assume anything about state of your application - the error might have corrupted some (or even all) of internal state. So when such condition occurs, it's best to try to create an error log and gracefuly restart the application (not necessarily whole application - maybe it will be possible to reinitialize application's state - if so, that's a valid option too. However, you must be aware that you won't be able to recover from some errors and handle such situation anyway).
It depends.
If you can handle appropriately an exception within a function - handle it. If not - create a global exception handler to inform user or log it.