I have an Silverlight application (Silverlight 5) and communicating through regular basic Service for normal operations (no database involved).
Problem:-
Before calling the service I just show the Loading (Busy Indicator control) and then calls the Service. Once it is back from the service (inside the completed event) I used to hide the Busy Indicator and performs other required operations.
In my case, Service executes all the logic successfully and returns true within max 2 minutes. But after that the logic that is placed inside the completed event is not getting executed always.
Note: Out of 3 times 2 times it works and once it fails. i.e 2 times it executes the logic perfectly and sometimes it will not do anything and just shows the progress bar. There is no pattern as such.
Also the important factor is IE7 and Chrome always works, IE8 we have this issue. Sometimes it works sometimes not. Very inconsistent !!!
I checked my code there seems to be no error and the service method on the server side is getting executed perfectly all the time.
I have cross verified the timwout parameters Client as well as Service and no problem and just to let you know I have another operation which takes around 6 minutes working fine in the same application.
Any Ideas would be highly appreciated.
Technical Details: Silverlight 5, WCF, In-Browser app, No database interactions.
Finally i figured out that it was due to the service client config file's receive timeout was the one which was creating the problem. Whenever it takes more than the defined the time period it just does not come back or no response and silverlight was not throwing up that error. Increasing the ReceiveTimeout helped me to resolve this. Thanks for all your help.
Wrap your service call with a "finally" to close your Busy indicator:
try
{
// Notify Busy is true
// Define Completed
// OnCompleted
// Notify Busy is false
// Make Service call
}
catch (Exception ex)
{
// Check for Timeout
// Handle Error
}
finally
{
// Notify Busy is false if Exception
}
Related
I am writing an API using ASP.NET and I have some potentially long running code from the different end points. The system uses CQRS and Event Sourcing. A Command comes into to an end point and is then published as an event using MediatR. However the Handlers are potentially long running. Since some of the Requests coming in might be sent to multiple Handlers. This process could take longer than the 12s that AWS allows before returning an Error code.
Is there a way to return a response back to the caller to say that the event has been created while still contining with the process? That is to say fire off a separate task that performs the long running piece of code, that also catches and logs errors. Then return a value back to the user saying the Event has been successfully created?
I believe that ASP.NET spins up a new instance each time a call is made, will the old instance die one a value is returned, killing the task?
I could be wrong with a number of points here, this is my knowledge gleaned from the internet but I could have missunderstood articles.
Thanks.
Yes, you should pass the long-running task off to a background process and return to the user. When the task is complete, notifiy the user with whatever mechanism is appropriate for your site.
But do not start a new thread, what you want is to have a background service running for this, and use that to manage your request.
If a new thread is running the long operation it will remain “open/live” until it finishes. Also you can configure the app pool to always be active.
There are a lot of frameworks to work with long running tasks like Hangfire.
And to keep the user updated with the status of the task you can use SignalR to push notifications to the UI
I've got a WinForm application and a service that does some work from the application on a server. I want the user to able to control the service from the application, so I added a ServiceController to do all the work (Start, Stop, Restart at first only). Everything works fine so far but while testing different scenarios I encountered a problem: My service is running on a server, the application is running on a client in the same network. I connect to the service and open the ServiceController.
I then shut down the server (VM) where the service is running and trigger the stop method from the client. I use the WaitForStatus method with a timeout, problem is: the timeout is seemingly ignored by the app:
public void StopService()
{
if (this._serviceController.CanStop &&
(this.ServiceStatus == ServiceControllerStatus.Running || this.ServiceStatus == ServiceControllerStatus.Paused))
{
this._serviceController.Stop();
this._serviceController.WaitForStatus(ServiceControllerStatus.Stopped, TimeSpan.FromSeconds(30));
}
}
In my case, the methods seems to try to stop the service for around 90 seconds and then throws an InvalidOperationException, which I can handle but I don't want the user to wait 90 seconds.
I think my question basically is: What happens when the timer (30 seconds in this case) runs out? Shouldn't the code just continue to run? And when does this function throw an TimeoutException? MSDN says when "The value specified for the timeout parameter expires." - but it seems like this doesn't mean after the value reaches zero.
Can someone enlighten me?
When we specify TimeSpan, WaitForStatus will rise timeout exception after waiting for given time but it seems to be you having exception on privileges.
please read this answer.
I am creating a Windows Service app that I would like to have programmatically pause when either a system error, odbc connection, or missing file error occur while . I was wondering if anyone knows how to do this? The Windows service app uses an odbc connection and datareader to connect to an MS Access database and an Oracle table, so there are the probable errors that I would be handling with those, I just want to allow a pause for the user handle the errors if/when they occur.
ServiceController service = new ServiceController(serviceName);
TimeSpan timeout = TimeSpan.FromMilliseconds(timeoutValue);
service.Pause(); //or whatever you want here.
sevice.WaitForStatus(ServiceControllerStatus.Paused, timeout);
...
Then to restart, do the same thing except for
service.Continue();
sevice.WaitForStatus(ServiceControllerStatus.Running, timeout);
You can do this for any state you want. Check out the msdn documentation by googling SeviceController. It will be the first result returned.
Also, you will need to handle the OnPause and OnContinue events in your service.
Have you tried?
System.Threading.Thread.Sleep(1000); // sleep for 1 second
Adjust the 1000 to 1000 times however long you want it to sleep in seconds.
Assuming that your service has a continual loop that checks for data, add a check to an external source for pause/continue commands. This source can be a message queue like MSMQ or a database table.
I implemented something along like this by having my service continually check a table for commands, and reporting its status in another table. When it gets a start command it launches a processing loop on another thread. A stop command causes it to signal the thread to gracefully exit. The service core never stops running.
The user interacts via a separate app with a UI that lets them view the service's status and submit commands. Since the app does its control via a database it doesn't have to run on the same machine that the service is running on.
I have a c# application and I want to fire off a webservice but I dont care about the response and I also dont care if it fails. At the moment i fire of the service async but i am getting an error when the call fails.
Is there anyway I can configure the app/webservice to stop it failing without rapping try catches around them (basiclly fire and forget)?
Thanks
Sp
Here is one idea:
Write your web service do that it returns 'success' right away, then fires off an async process that does the work.
You can also do this by creating a queue or something, where another process watches the queue and performs the work. Then the web service's only job, then, is to add an entry to the queue.
This question already has answers here:
check the availability of the WCF Web Service
(4 answers)
Closed 8 years ago.
I will have a client application using a proxy to a WCF Service. This client will be a windows form application doing basicHttpBinding to N number of endpoints at an address.
The problem I want to resolve is that when any windows form application going across the internet to get my web server that must have my web server online will need to know that this particular WCF Service is online. I need an example of how this client on a background thread will be able to do a polling of just "WCF Service.., Are You There?" This way our client application can notify clients before they invest a lot of time in building up work client-side to only be frustrated with the WCF Service being offline.
Again I am looking for a simple way to check for WCF Service "Are You There?"
What this obsession with checking whether those services are there??
Just call the service and as any defensive programming course will teach you, be prepared to handle exceptions.
There's really no benefit in constantly sending "are you there?" requests all over the wire...
Even if you could have something like a Ping() method (that just returns a fixed value or something - your service name or whatever) - that only checks whether your service is reachable - what about the database you need to query to get data from? What about other services your service method depends on? It gets quite messy and very very tricky to figure out a way to check all that - just to see if it's there.
In brief: no, there is no reliable and meaningful way to check whether a given service is "there" and "alive" - just call it ! And be prepared to handle a failure - it will fail at times....
There is no value in checking if a service is alive or not. Absolutely none. Why?
if(serviceIsAlive())
{
callService();
}
else
{
handleFailure()
}
Do you see the problem with this snippet? What happens if between the time you check if the service is alive, and the time you call it, the service goes down? This is a race condition, and a bug waiting to happen. So what you need to do, even if you can check the service condition, is:
if(serviceIsAlive())
{
try
{
callService();
}
catch(CommunicationException)
{
handleFailure();
}
}
else
{
handleFailure();
}
But in this block, the handleFailure() call is in two different places - we've got two different paths to handle the same error condition - which seems like a bad thing. So this can be safely reduced to:
try
{
callService();
}
catch(CommunicationException)
{
handleFailure();
}
If your service is hosted in IIS (or WAS), you can perform a resiliency built-in to the IIS6/7 process model. If an worker process fails, another will be started in its place. How it works? Using Ping to analyse. Its called AppoPool Health Monitoring (described here).