Good morning everyone!
I'm doing a distributed application using .NET 4.0, C# and Remoting (IPC at the moment but that may change, Object is WellKnownObjectMode.Singleton).
Upon startup of the client I'd like to test whether the server is up and running.
What would be the best practice to implement this? Call any one method? Implement a special method just for that startup test?
At the moment I start the client and it then calls methods on the server periodically (every 100 ms). That causes the client to show an estimated 1,000,000,000 error dialogs pointing out that the server is unreachable.
You could probably use a global mutex.
Related
At my work we have some old 'services' which are actually Console applications which run 24/7 on our servers. Finally we decided to replace it with Windows Services, but now we can see from each console window when there are errors or certain events (like too many requests etc.)
Now the idea came up to let every windows service write in a database every minute (so we can see if the service hasn't stopped), and also write in the database when there's certain events (like the many requests).
Now I've been thinking about hosting a WCF Service in each of the windows services instead, because I think there's more possibilities (and I don't really like the idea of our databases having data inserted from 10+ services every minute) and it's still possible to write an application which sends requests to the WCF services every x amount of time.
Are there any downsides of WCF vs the approach of writing in a database? In a database of course it's easier to keep the data until it's been read, but that's only one (small) issue I can think of.
Thanks in advance!
I would have go with the follow options:
As you suggested, create WCF endpoint and verify you services are on. You will still need to implement error escalation. I like to use ELMAH
Using a watchdog How can I verify if a Windows Service is running
For the events, log services activities using a logger such as log4net or Nlog. Then append it to DB/Email/File. My favorite is to manage logs using ELK (Elastic/Logstash/Kibana) or Splunk.
I'm writing a C# application to control the windows tomcat service. I need a way to get some sort of event when tomcat finishes starting after I run the service. (i.e. all the apps deploy.)
I can read the log file and wait for the "Server startup in" message but it seems like there must be a less messy way. I know you can register a lifecycle listener using Java but I can't think of a way to do something similar with C#.
Does anyone know a good way to monitor tomcat with C#? Thanks in advance.
Edit: In case I wasn't clear, simply checking the status of the isn't sufficient since it will report "Running" during the startup time while the apps are being deployed and it isn't yet accessible.
Unless there's a reason you can't do so (permissions, etc) I would just issue a web request to the service and wait until it comes back.
Even if you don't want to give the account hosting the service permission to use the app(s) in question, you can still create an app that only it has permission to use, and have it call that.
I ended up writing a tomcat wrapper in Java which acts as a lifecycle listener. The C# application launches the java program and receives lifecycle messages through a named pipe.
We've got a client app which connects using TCP to a server. Additionally, the client app makes use of .NET remoting to talk to another piece of locally running code.
I'm tasked with creating a "Client Simulator" to do some testing, where we'd need to have 100's of clients connected simultaneously to the server. Ideally, this would work out great if I were to run each client in it's own space, such as a VM, but this is not logistically feasible.
Any suggestions on how to handle this? Is there a tool that could do something like this? Or some sort-of .NET concept I could use?
Thanks in advance.
What about stress testing? http://support.microsoft.com/kb/231282
You can do it with Test Edition of Visual Studio: http://msdn.microsoft.com/en-us/vstudio/dd408381.aspx
There is load runner but we found it to be a very expensive piece of shelf ware. We created a server controlled client spawner that could once installed on a machine listen to broadcast message and perform actions on the server. We simulated 3000 + clients very eisly on 10 machines since the clients didn't have to do any processing.
In an old project i worked on, I implemented a set of NUnit tests that executed cookie-less web requestes on a locally running Cassini server.
Each request generated a unique sessions and the session persistence was handled by the unit tests using the session id returned by asp-net on the first response.
The check on the output was handled via regular expressions that verified the presence of well-knowns contents parts.
That was enough for my needs, but maybe you need something more exaustive.
I'm programming a monitoring application that needs to display the state of several windows services. In the current version, I can know whether a service is Running, Stopped, Suspended or in one of the pending states. That's good, but I'm wondering if there is a way to test if a service is actually responding? I guess it can be in a running state but not responding at all!
I am using the ServiceController class from System.ServiceProcess. Do you think that if a service is not responding, the ServiceController.Status would return an exception?
How would you approach the problem?
Thanks
EDIT
Seems that: ServiceController.Status can return 2 types of exceptions:
System.ComponentModel.Win32Exception: An error occurred when accessing a system API.
System.InvalidOperationException: The service does not exist as an installed service.
Nothing about reactivity.
This might be obvious, but have you tried talking to the service?
There's no common way to talk to a service, so there is no way Windows can interrogate whether the service is still responding as normal. It is perfectly normal for a service to go into a complete sleep waiting for external I/O to happen, and thus Windows would not get a response while the service is actually alive and functioning exactly as designed.
The only way is to actually send a request to it, and wait for the response, and for that you need some inter-process communication channel, like:
Network
Named pipes
Messages
Basically, if you need to determine if a service is able to respond, you need to check if it is responding.
The service controller types and APIs can only provide information on the basis of the service's response to those APIs.
E.g. you can create a service which responds to those APIs correctly, but provides no functionality on even numbered hours.
In the end you need to define "responsive" in terms of the services functionality (e.g. a batch processor is processing batches) and provide a mechanism (A2A API, WMI, Performance Counters) to surface this.
I've written a client/server model in C# using .Net remoting. If I have the client connected to the server, then kill the server and restart it without trying to call any server methods from the client whilst the server is down, I can reconnect happily.
If I close the server then try to ping the server from the client (which I do from a separate thread to avoid an endless wait) then when the server comes back online, the client can never talk to it and my Ping thread that was fired during the downtime waits forever deep in the guts of the remoting libraries. I try to Abort this (if trying to Join the thread fails after a short time) but it won't abort. I'm wondering if this is part of the problem.
If I start up another client, then that client can talk to the server just fine. I figured I needed to restart some aspect of the original client but cannot see what would need to be shut down. I certainly null the server I'm connected to and call Activator.GetObject with the same address (something the second client does to connect to the server, which works fine), but re-getting the server doesn't help at all.
The server is running a as singleton via RegisterWellKnownServiceType.
I would start with wireshark and use it to see what is really going across the wire.
Is .NET remoting a requirement, or could you consider moving to WCF instead? The protocols are better factored and more clearly exposed when needed.
I was solving a similar problem. I had a working .NET remoting application using configuration files for the remoting and the routines of the .NET remoting I had to integrate into a larger application. I integrated this into the larger project, by the Activator.GetObject returned an instance of the proxy. As soon as there was a call of a member from the proxy instance, it ended up inside the member call and could not get off. The larger application contained various configuration files already thus the .NET remoting configurations I placed right there along with another configs for another thihs, and there was the crux of the matter. After I placed the .NET remoting configurations into a new empty config(s) file, the .NET remoting in the larger application started to work.