I am building a c# application (.NET Core 6), calling a Trading Exchange API(WCF) using an HttpClient. They have a strict policy of not invoking their APIs asynchronously and they monitor this as well.
I also need to devise a mechanism where I must invoke some of their APIs multiple times a day based on different timestamps. Basically, I need a timer logic.
HttpClient offers Send which is a synchronous way of calling. I am wondering if there is any better way to make sure I am calling this API synchronously over HTTP and also using a better polling logic.
Related
This past year we've been working on a new web app that calls into our company's existing service layer.
We made the decision to wrap up all of our service oriented calls into our own service layer (which I'll refer to as our web-service layer) so that the details of which services we use (we'll move to a new API at some point in the future) are hidden from the web layer itself.
We also decided that most of our web-service layer methods would return Task<T>.
As it stands, the underlying services that we call are not async and so there are some concerns that our web-service layer will max out the available threads and cause problems when we have a large volume of users.
I'm looking for information, one way or the other, to further understand how our decision to return Task<T> will impact our site and whether or not we need to consider changing our return types.
We'll be moving to VS2012 at some point but right now we're using VS2010 and are not using async and await.
As it stands, the underlying services that we call are not async and
so there are some concerns that our web-service layer will max out the
available threads and cause problems when we have a large volume of
users.
Yes that's something you should be concerned with. I would recommend you doing this only if you have real asynchronous methods. But simply wrapping blocking synchronous methods into an async API will be worse than calling the synchronous methods directly from the consuming code. In an ASP.NET application you will get benefit from asynchronous calls only if the underlying API is relying on I/O Completion Ports. Otherwise it's just a waste of resource.
The only useful scenario in which you could do that is if your methods could be called in parallel instead of sequentially. This is possible only is the different methods are not connected between them. In this case you could indeed wrap your sync methods in async tasks.
I have an application written in C++/CLI that uses a library written in C#. The application was written using standard socket APIs and uses select() to multiplex a bunch of ordinary non-async sockets. However, the third party library uses .NET sockets and uses the asynchronous results and callbacks.
Here's the scenario: I create a bunch of regular sockets in the main thread (a C++/CLI application that uses mostly native-style code). I create the third party library vendor's C# "session" object which, internally, has a bunch of asynchronous sockets from the .NET classes.
What I noticed was that if I put a NULL timeout parameter into select() in the main thread in which I instantiate the C# "session" object, that no asynchronous callbacks are made at all for their .NET sockets. If I use a time-out of, say, 1-second, and no other activity happens on my non-async sockets, then no async-socket callbacks are delivered until select() times out.
Somehow, select() is preventing the callbacks to happen for the .NET sockets. How do I avoid this? Is there some alternative polling method I can use for the old sockets that would still allow the .NET sockets to have their asynchronous callbacks delivered?
I found the solution.
In AsyncCallbacks used in .NET, you cannot have any functions that block at all, including send()/recv() functions -- even if they are non-blocking[1] (at least according to my own tests.) When a blocking function is called in an AsyncCallback, the behavior is undefined. Once I got rid of this "undefinedness" from the code, things started working as normal.
I re-templatized my classes by writing some policy classes that swapped out select() for WaitForMultipleObjectsEx() and solved the issue by putting a SetEvent() in the AsyncCallback to trigger the multiplexing. This seemed to solve most of the issues.
[1] Edit: See below comment. Whether I used send() on a non-blocking or blocking socket didn't seem to make a difference with regards to "breaking things" and going into undefined behaviors.
We are developing an application where in UI calls a Service(WCF) layer and a component that resides inside service layer calls external webservices asynchronously. For instance: UI sends says calls WCF layer by uploading a file, and if file has 1000 entries, currently we call external services asynchronously in a loop (BeginxxxMethod) 1000 times for response. Is this the right way of doing so? Second question: what is the maximum number of asynchronous connections that can be made? Our technology is ASP.NEt and C# 4.0.
Two suggestions:
If you control the web service API add another method that lets you pass all 1000 args and returns all results. This is chunky vs chatty so you only go through the cross process pain once.
If you do not control the web service API, come up with a wrapper that makes n number of remote calls synchonously, then call this wrapper asynchonously n times. Play around until you find the best balance between number of async calls and number of sequential remote calls per async call.
Is this the right way of doing so?
Async calls are often the best way to get large batch jobs done. I think you're looking good with this approach. As a developer, it's often our job to see where cutting new threads no longer optimizes response times. Myles mentioned using a wrapper around a service. I have often done this when calling 1000's of calls at a time... calling a few thousand async calls actually hurt performance (in my application), so I created functionality to group calls a few hundred (asynchronously) at a time until all x-thousand calls were finished. This gave me the best of both worlds... I was able to find the point number of async calls at once gave me the best performance and went from there.
As far as max threads, it depends on resources, but here is a link that explains the defaults... I'll post below for ease
1023 in Framework 4.0 (32-bit environment)
32768 in Framework 4.0 (64-bit environment)
250 per core in Framework 3.5
25 per core in Framework 2.0
WE have resolved this by implementing Task Parallel library.
Below is the pseudo code.
Read the file contents in to generic list.
Use Parallel for to process each request and set MaxDOP (Degree of parallelism) according to processor count in the server to process the request.
Thanks
In C#, what is the best way to create a polling mechanism? So I have some code which can periodically do some action.
This is for web services so any UI-related solutions won't apply.
Thanks
If you are saying that you have a web service which is supposed to periodically take some action on it's own, then I think you haven't quite got the web services model. Web services are supposed to sit there (just like a web page) until something kicks it off.
Otherwise you are dealing with a very brittle situation where anything could cause it to just stop.
If you have a bit of code that needs to run on a timer, then you should investigate placing that code in a windows service (not to be confused with Web Service). That's what they are for.
"code which can periodically do some action" is called a "Timer". Search MSDN, you'll find three or four classes for the purpose, several of which are non-gui (System.Threading.Timer comes to mind).
EDIT: To whom do the changes need to be visible? If they are only visible to other consumers of the web service, then one approach is for each incoming request can check whether a periodic action is overdue and perform it. However, you shouldn't do things this way if (1) the changes need to be visible to e.g. other clients of the same database, or (2) the periodic changes need greater permissions than arbitrary incoming requests. Also, the periodic actions might be interrupted if the client cancels their request, and doing the actions might significantly delay the response to the client. For these reasons I don't recommend adding periodic processing to normal request/response processing.
Take a look at the System.Threading.Timer class. This makes periodic calls to a method you supply. These calls are made on a separate thread (a thread in the thread pool).
You'll want to use a timer.
There are a few timers in the .NET framework, including:
System.Timers.Timer
System.Threading.Timer
System.Windows.Forms.Timer
See this article for help choosing the right one: Comparing the Timer Classes in the .NET Framework Class Library
It sounds like you want a Timer, but that does not make sense to use in a Web service. It would make more sense if the timer was in a client. What clients use your web service?
I was going through MSDN documentation on WebServices. Here and here, both these links talk about calling a webservice and wait for the response, which is also a general trend that I have seen while asynch implementation.
I don't understand "why do we need to wait for service call to return"? And, if we are waiting why don't make an synchronous call. What is the difference between an "asynch call followed by wait" and a "synchronous call"?
To be useful, the asynchronous call needs to do its thing while you go do something else. There are two ways to do that:
Provide a callback method for the asynchronous handle, so that it can notify you when it is completed, or
Periodically check the asynchronous handle to see if its status has changed to "completed."
You wouldn't use a WaitHandle to do these two things. However, the WaitHandle class makes it possible for clients to make an asynchronous call and wait for:
a single XML Web service
(WaitHandle.WaitOne),
the first of many XML Web services
(WaitHandle.WaitAny), or
all of many XML Web services
(WaitHandle.WaitAll)
to return results.
In other words, if you use WaitOne or WaitAny on an asynchronous web service that returns several results, you can obtain a single result from your web service call, and process it while you are waiting on the remaining results.
One very practical use of asynchronous calls is stuff like this
http://i.msdn.microsoft.com/Bb760816.PB_oldStyle%28en-us,VS.85%29.png
If you want to update your UI while you're waiting for a 'server' to do something, you need to make an asynchronous call. If you make a synchronous call, your code will be stuck waiting, but if you make an asynchronous call you can update the UI or even let the user go do other stuff while you're waiting for the callback. This goes beyond UI, you may make an asynchronous call to start some non-critical task and continue on with your code and its possible you don't even register for a callback if the result is unimportant.
If you do NOTHING while waiting for the asyncronous call, then its less useful.
Using asynchronous call can free up your application to do other things while waiting for the response. Since there is a fairly large amount of time (in computer cycles) waiting for a web server to respond, that time can be used for better things such as displaying a status update or doing some other work.
For example, if you had a program that performed a complicated calculation and a step of that calculation included using some reference data from a remote web service. By calling the web service asynchronously at the start of the calculation, continuing the parts of computation that can be performed locally, and then using the result of the web service call when it is available to complete the computation you can reduce the overall time of the calculation.
Since your application code is not blocked waiting for the web service to respond, you are able to utilize that wait time to the benefit of the user.
Another reason is scaling, particularly in web sites that make calls to other web services. By using asynchronous page methods (or tasks), IIS can scale your application more effectively by deferring your pages that are waiting on asynchronous web requests to whats known as an "IO thread", freeing up the main ASP.NET worker threads to serve more web pages.
The first example you're linking to issues an async call and then immediately waits for the result. Other than forking off the job to another thread, there's little difference between this and a synchronous call as far as I can tell.
The other example, however, talks about doing multiple async calls at once. If this is the case, it makes sense to launch all calls and then wait because the calls may execute in parallel.
One of the possible uses of an asynchronous call followed by a wait is that asynchronous operations often support cancellation whereas blocking calls do not. Combined with the CancellationToken pattern in .NET 4.0 (or a similar custom pattern pre-.NET4) you can create an operation that appears to be synchronous but can be cancelled easily.