I consume Java Service in my .NET appliaction. I have one question: When service serialize in .NET he also create Async methods. For example for GetPersons() method service create GetPersonsAsync() which is return void. In which cases I can use this Async methods and what the destination of these methods.
Generally, for async methods, you also need to specify a callback method. The called web method immediately returns but keeps working in the backround. When its done, it invokes your callback method with its results
Related
I have a CRUD app in Blazor that simply fetches the assignment lists from a table and has an AssignmentReminderService for data access layer that has a method (async version)
public async Task<AssignmentReminder> AddAssignment(AssignmentReminder assignment)
{
_context.assignments.Add(assignment);
await _context.SaveChangesAsync();
return assignment;
}
I can also call the method with synchromus code as :
public AssignmentReminder AddAssignment(AssignmentReminder assignment)
{
_context.assignments.Add(assignment);
_context.SaveChanges();
return assignment;
}
Now it is just one database being accessed from a local server(could be hosted on cloud as well) with just one assignment table and the default authentication/authorization tables generated when one uses Individual User Account (aspnetusers, aspnetroles etc)
Can someone let me know which of the two ways I should use (between async or sync) method declaration?
In the general case, you should use asynchronous APIs if they are available. This will result in greater scalability on the server side, since asynchrony will allow the calling request thread to be used for other requests while the asynchronous operation is in progress.
There are specific scenarios where this guideline doesn't apply. E.g., if you're calling a generic asynchronous API (like Stream.ReadAsync) but you know that the implementation is actually synchronous (like MemoryStream). But in general, if there's an asynchronous API, then that's the one you should use.
You should be clear about the version of blazor you're talking about, because using async methods in the client is different from using them in the server version.
which of the two ways I should use (between async or sync) method declaration?
The first one.
The scarce resource here are the Threads. You want to keep their number down, and the first approach enables that by releasing the Thread to do other work.
In the second approach the Thread is suspended for the duration of the I/O operation. You would need more Threads to handle the same number of requests.
So using async I/O lets the same hardware handle more requests at the same time.
I am too much confused the difference between #EnableAsync and AbstractDispatcherServletInitializer#isAsyncSupported().
As per this link,
The isAsyncSupported protected method of AbstractDispatcherServletInitializer provides a single place to enable async support on the DispatcherServlet and all filters mapped to it. By default this flag is set to true
Based on my knowledge #EnableAsync is to enable scan #Async annotations and provide multi-threading support. But still I am unable to understand when to use AbstractDispatcherServletInitializer#isAsyncSupported()
There is a big difference between the two, #EnableAsync with #Async are not concerned with spring-web-mvc, they allow the execution of a method asynchronously using a TaskExecutor. For example, if you had a clean up service that deletes all logs in a server, you can allow its doCleanUp method to run asynchronously without having to write the scheduling code, spring will take care of it for you:
public class CleanUpService {
#Async
public void doCleanUp() {
// This code will be executed using a different thread than the calling thread by a TaskExecuter
}
}
As you can see this is not related to web development in particular. Also note that this method returns void, but if you wanted it to return a result, for instance CleanupStatistics, you can't just write the method like this
#Async
public CleanupStatistics doCleanUp() {
// This code will be executed using a different thread than the calling thread by a TaskExecuter
return new CleanupStatistics("someinformation");
}
You are required to return either void or a Future. A Future represents the result of an asynchronous computation that you can use to obtain the result of the computation when it becomes available. We will get back to Future and see how it can be used in controller methods while isAsyncSupported is true.
isAsyncSupported is a totally different story, this flag enables Servlet 3.0 asynchronous request processing, prior to Servlet 3.0 a servlet container (Tomcat for instance) would have a thread pool that handles the processing of Http requests, each thread would handle the request till the processing is complete, even if the thread had to stay idle, for example, to wait for a database query to finish or for an API call result to come back. This affects the scalability of the servlet container. In Servlet 3.0 requests can be handled asynchronously, the container thread will call your handler method, in its turn the handler method can schedule its work to be done asynchronously and return immediately, freeing the container thread to process other requests, after the result is available any container thread can resume the processing of the request. From the prospective of the client, nothing has changed, the client, all that time, is still waiting for the result to come back, but from the perspective of the server, the container threads are better utilised.
In spring-mvc you can trigger asynchronous request processing for a controller method by returning certain java types, for example
DeferredResult
Callable
ListenableFuture
CompletionStage
CompletableFuture
Reactive types
and streaming types
If you wanted to use #Async with isAsyncSupported you could write a controller method that calls a method annotated with #Async and returns ListenableFuture.
You can learn more about task execution and scheduling here. And more about Servlet 3.0 asynch here.
If we want to experience benefits provided by Spring MVC and don't want to manually register DispatcherServlet it'll be better to use: AbstractDispatcherServletInitializer. It adds two abstract methods: createServletApplicationContext() and getServletMappings().
First method returns WebApplicationContext that will be passed to DispatcherServlet, which will be automatically added into container ServletContext. This context will be established as a child of the context returned by createRootApplicationContext() method. Second method -returns mappings that are used during servlet registration.
The #EnableAsync annotation switches on Spring’s ability to run #Async methods in a background thread pool. For Enabling asynchronous processing with Java configuration got by simply adding the #EnableAsync to a configuration class.
#EnableAsync
#Configuration
public class SpringAsyncConfigurer implements AsyncConfigurer {...}
#Async is applicable only to the public methods.
Calling the #Async method within the same class woould not work.
I'm using an asp.net 4.5 web application and asp.net membership. I implement the MembershipProvider interface which has a method:
public override bool ValidateUser(string username, string password)
The code within this method for my implementation has to make two WCF service calls which can be expensive. In the spirit and my desire of learning and using async, I'd like to make the code use async await.
I created my two Tasks that need to call the WCF service methods. What I'm unclear on is how to properly use async from the "ValidateUser" method to call these Tasks. I cannot change this method signature to add async as I would have to then change bool to Task so I'm stuck with a method signature that cannot be adored with the async modifier.
In this case how can I call my two tasks and have them run on a background thread? I know I can use Task.Result but my understanding is that would be a synchronous call and is frowned upon. I'm not sure of the gain by using Task.Result as my intention is to background thread my two WCF service method calls.
Well, you can certainly call the tasks asynchronously inside your membership provider, you just can't call ValidateUser asynchronously.
The old Membership API was created long before Async existed and is not compatible. You could wrap this around an async method. Here's a blog entry about it.
http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx
The gist is something like this (change to use for ValidateUser)
public Task SleepAsync(int millisecondsTimeout)
{
return Task.Run(() => Sleep(millisecondsTimeout));
}
The Working with the BeginMethod/EndMethod Pattern section of Using an Asynchronous Controller in ASP.NET MVC refers to a Sync() method. It is not linked and I am having trouble finding documentation on it through google searches since sync is too common a term. Can someone point me in the write direction?
To make sure that you have access to
the HttpContext.Current instance and
to avoid the race condition, you can
restore HttpContext.Current by calling
Sync() from the callback method.
When you spawn asynchronous operations by calling BeginXyz / EndXyz methods from within your controller action, the threads handling the asynchronous response are not under the control of ASP.NET. As such, you can't touch HttpContext, the controller instance, or any other shared state from within those threads. Calling the Sync() method basically synchronizes access to the request; it restores HttpContext.Current and grants you access to touch HttpContext, the controller, etc., but only for the duration of the Sync() call. The RegisterTask() extension method from MVC Futures attempts to make this a bit easier, as you basically pass it delegates to the target Begin and End methods, and the RegisterTask() helper will ensure that the End thread executes within an appropriate synchronization context.
If you're spawning asynchronous operations by calling XyzAsync / XyzCompleted methods from within your controller action, you don't have to worry about this, as the completed handler automatically runs within a synchronization context.
It's a method of the AsyncManager class. http://msdn.microsoft.com/en-us/library/system.web.mvc.async.asyncmanager.sync.aspx
I have a web application the relies heavily on web services. Everything with the services is done asynchronously and with AddOnPreRequestHandlerExecuteAsync. Anyhow, most of my calls work just fine, but some are returning from their asynchronous service calls to find a null HttpContext.Current.Response/Request object in the endprerequest, which of course errors the instant I try to use either. Both objects (Response and Request are available/not null on beginprerequest of failing calls and work in the endprerequest of other calls).
Anyone run into similar, or have a guess as to what might be the problem?
Update: Seem to have found a solution, if I create a variable for the HttpApplication on Init(of the HttpModule this all occurs in) the HttpContext can be accessed from that variable.
Update: Passing either HttpApplication or HttpContext.Current on the begin function has the same issue. When passed as part of the "State" of the asynchronous call, they end up null in the end function, even though they are valid in the begin function.
Update: I've added some logging and found that the Asynchronous call I am making is returning correctly, the results are there, the callback function is invoked properly.
I suspect I know the problem you're running into. The answer, almost certainly, is to replace usage of HttpWebRequest with WebClient, and to use the *Async methods of WebClient.
Here's the long explanation: there are two totally different Async programming models: the IAsyncResult Async Pattern and the Event-based Asynchronous Pattern. The IAsyncResult pattern uses BeginXXX and EndXXX methods, uses IAsyncResult instances, uses delegates for callbacks, and supports waiting for completion. The Event-based pattern uses XXXAsync methods to initiate async actions, uses XXXCompleted events instead of callbacks to handle completion, and (this is important to your case) transfers thread-specific context into every callback event handler.
In other words, if you put your callback code inside a XXXCompleted event handler (like WebClient.DownloadStringCompleted), then HttpContext.Current will be populated correctly.
If, however, you use a BeginXXX method (like HttpWebRequest.BeginGetResponse) and a delegate callback, your callback will be executed in the context of a thread that does not guarantee to have the right ASP.NET context attached.
Generally, .NET Framework library classes either use one async pattern or the other. Typically, the lower-level classes (e.g. HttpWebRequest) will use the IAsyncResult pattern, while the higher-level classes (e.g. WebClient) will use the event-based pattern. Some oddball classes (e.g. auto-generated .NET Remoting proxies) will support both patterns, but that's a rarity.
So if it's easy to do, I'd suggest moving to WebClient and event handlers instead of HttpWebRequest and callback delegates. This should solve your problem. If switching to WebClient is too hard, comment and I can probably suggest some more obscure alternatives.
Seem to have found a solution, if I create a variable for the HttpApplication on Init(of the HttpModule this all occurs in) the HttpContext can be accessed from that variable.