Using a Generic Handler, I'd like to 2 do things in parallel. First, I need to send a request to a 3rd part and get the result back (this can take up to 25 seconds) and while that is happening, parse some XML and insert a record into a database.
How would I go about issuing an Http request (like GetResponse()) but not have it pause until it gets a response?
Create an asynchronous HTTP handler class. In your BeginProcessRequest, you can create two tasks, one for the 3rd party request, one for the XML parse and then run them in parallel. Here's a pretty good tutorial that shows how to define tasks that return values and run them in parallel.
Another option is creating a web service class in your project and having the web service do the work for the 3rd party request. Methods in a web service can be called asynchronously, so you can create a method in the service, reference the service from your page, then use the asynchronous overload of the method.
Related
We currently have third-party software that we use to extract information from.
We use their SDK to send and receive request and noted that the request aren't always accurate. After troubleshooting and reading (not well documented) documentation we realised that the SDK can only receive and send one request at a time.
This causes a issue for us as we are using an ASP.Net web application to access the SDK which means that we have multiple clients that access the SDK at the same time and send multiple request. What the SDK does is if it get a new request while busy with a current request it discards the current request and continues with the new request.
I would like to find out what would be the best way of creating a queuing system for the requests.
I was thinking of creating a WCF service and set the instancecontexctmode to single so that there is only one instance of the service running. Then setting the ThreadPool max threads to 1 and using it to queue the functions so that there is only one active call to the SDK at a time. Although I do not know much about ThreadPool queuing the solution should work.
Here is what I have in mind
Public Sub Sub1(var As String)
'Do work
ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf Function1), "Text")
End Sub
Public Function Function1(var As String) As DataTable
'Do Work
Return DataTable
End Function
Sub New()
ThreadPool.SetMaxThreads(1, 1)
End Sub
How would I create the queueing using ThreadPool or is there another way to accomplish the same result?
Will the web application wait for a response from the service?
Update 1
I found another way while fiddling with some code
If I specify the InstanceContextMode must be single and the the function's ReleaseInstanceMode to AfterCall this blocks any other functions from executing while the function is busy. It uses instance deactivation (Details found here)
<ServiceBehavior(InstanceContextMode:=InstanceContextMode.Single)>
Public Class Service1
<OperationBehavior(ReleaseInstanceMode:=ReleaseInstanceMode.AfterCall)>
Public Function DoWork() As String
Return WorkDone
End Function
End Class
Will this work and is there any specific problems that I could run into?
If I was you I would prefer to make one more abstraction, as you can control restriction third party component.
You can inherit third party class (if it's a class) and organize queue inside. Use it as a singleton. Singleton
Using tasks and task factory with limited threads (very similar to your idea): Scheduler
Your idea with ThreadPool.
In case it's a service, the easiest way is to create your own WCF service which will be responsible for queueing, which can be organized by WCF: Throttling
a colleague of my said that a MVC 3 app handles all incoming requests one at a time.
So when i make two AJAX calls to my application from a webpage, asp.net MVC / IIS handles the first request first, then returns the result and then processes the second request.
He has this line of documentation from MSDN of evidence (http://msdn.microsoft.com/en-us/library/ee728598(v=vs.98).aspx)
You can use asynchronous action methods for long-running, non-CPU
bound requests. This avoids blocking the Web server from performing
work while the request is being processed
Where it says that 'asynchronous action methods' don't block, so 'normal' controller actions do.
He also said that he saw that in effect on his page ( in the browser debug tools, lokking at the request sent), that first ajax request one was processed, and then, even that it was fired at the same time as the first by the browser, the second.
I find it hard to believe that IIS can only serve one request at a time per application?
If you are on the same session, then AJAX queries will be serialized (one at a time).
You can change your controller to be sessionless. See What are some scenario's of having a Session-less Controller in ASP.NET MVC3?.
I have MVC application (applies to non MVC as well) where a user is posting in data. I need to take this data, send it off to two seperate end points (one using a WebRequest form POST and one using a Web Service), parse the result, and send the result back to the original user.
The issue at hand is that both end points take about 20-30 seconds to respond (response is a string) which means that I should probably execute these two calls asynchronously. At the same time I want to wait to respond to the original user until I get both results back. I am guessing I might have to use some sort of object lock so the response does not get sent back before the two calls are complete?
Am I on the right path? Does anyone have any information on how to achieve this? Any help is appreciated.
Thanks
EDIT
Based on the responses I decided to go with async controllers since I am already working with a MVC application. Thank you for your input.
You can invoke Join on the two asynchronous threads to wait for their return. You'll also want to look into asynchronous controllers. This is available in MVC2 but you can also look at the MVC1 features I believe to implement asynchronous actions. You'll want to do this so you're not blocking IIS from processing more threads.
I think you'll find this helpful: Rx: Piecing together multiple IObservable web requests
In particular, using ForkJoin to wait until both responses come back as mentioned in the comments:
Also bonus question, there is a case where I would like to execute web calls simultaneously
and when all are finished execute another observable which will until other calls are finished.
Use Observable.ForkJoin to execute
multiple async calls simultaneously
and then join all of the results into
a single IObservable. Then use
SelectMany (another from statement)
just like above, to subscribe to
another observable based on the joined
result.
We have an application that hits a web service successfully, and the data returned updates our DB. What I'm trying to do is allow the user to continue using other parts of our web app while the web service processes their request and returns the necessary data.
Is this asynchronous processing? I've seen some console app samples on the msdn site, but considering this is a web form using a browser I'm not sure those samples apply. What if the user closes the browser window mid request? Currently we're using the Message Queue which "waits" for the web service to respond then handles the DB update, but we'd really like to get rid of that.
I'm (obviously) new to async requests and could use some help figuring this out. Does anyone have some code samples or pertinent articles I could check out?
Yes, what you're describing is async processing.
The best solution depends to some degree on the nature of the web services call and how you want to handle the results. A few tips that might help:
One approach is to send a request from the initial web request to a background thread. This works best if your users don't need to see the results of the call as soon as it completes.
Another approach is to have your server-side code make an async web services call. This is the way to go if your users do need to see the results. The advantage of an async call on the server side is that it doesn't tie up an ASP.NET worker thread waiting for results (which can seriously impair scalability)
Your server-side code can be structured either as a web page (*.aspx) or a WCF service, depending on what you want to have it return. Both forms support async.
From the client, you can use an async XMLHTTP request (Ajax). That way, you will receive a notification event when the call completes.
Another approach for long-running tasks is to write them to a persistent queue using Service Broker. This works best for things that you'd like users to be able to start and then walk away from and see the results later, with an assurance that the task will be completed.
In case it helps, I cover each of these techniques in detail in my book, along with code examples: Ultra-Fast ASP.NET.
If you're not blocking for a method return you're doing asychronous processing. Have a look at Dino Esposito's article on using AJAX for server task checking.
You can perform asynchronous web service calls using both Web Service Enhancements (WSE) and Windows Communication Foundation (WCF) in your C# code. WSE is discontinued, so its use is not recommended. Generically speaking, if you were to terminate program execution in the middle of an asynchronous call before the response returned, nothing bad would happen; the client would simply not process the result, but the web service would still be able to perform its processing to completion.
If your client web application is responsible for updating the DB, then without anything else in your client code, quitting in the middle of an asynchronous operation would mean that the DB was not updated. However, you could add some code to your client application that prevented the browser from quitting entirely while it is waiting for an asynchronous response while preventing new web service calls from being run after Close is called (using Javascript).
You have 2 distinct communications here: (1) from web browser to web application and (2) from web application to web service.
diagram http://img697.imageshack.us/img697/6713/diagramo.png
There is no point of making (2) asynchronous: you still would have to wait for web service to finish processing request. If you end HTTP request from browser to web application the client would have no clue what the result of request was.
It is much better to make asynchronous request from web browser to your web application. Ajax is ideal for that. In fact, that's what it was created for. Here's couple of links to get you started:
jQuery Ajax
ASP.NET AJAX
What is the difference between Web Services Asynchronous Call and Asynchronous Task's.
We are working an a ASP.NET application that requires to make a call to a Web Service Method that will process thousand rows of data. This process usually takes between 2 to 3 minutes (maybe more maybe less it depends of the amount of Data). So we run all the time in Timeout's on that specific page.
So we decided to go in rout of calling this Web Service Method Asynchronously, but we had a conflict caused by HTTP handler of one of the UI component's that we are using. Well lucky on that case we could remove the page from the httphandler directives.
So far no issues, but here it comes the question, a coworker find out that we can use instead of Asynchronous Webs Services Call, wrap a Synchronous call in a Asynchronous Task in the ASP.NET page and be able to keep the directives to the component, and execute the Web Service Method with out getting a Timeout.
So now my concern is what kind of issues we can find using Asynchronous Task's instead of an Asynchronous Call.
Thank you in advance.
Web services should not be used in this manner by the way. There's a reason HTTP timeouts are so low. You should have the Web service trigger the task either by setting a flag in the DB that an actual service picks up on or the web service should spawn a process.
If I understand your scenario, there should be no issues. In both cases, your page is asynchronous. In both cases, you don't wait for the service to complete - you give up the request thread while the service is running. In both cases, your page takes the same amount of time to execute as it would if you had called the service synchronously.