Given a client request of the form
return webClient.get()
.uri(customersUrl + id)
.retrieve()
.bodyToMono(Customer.class)
.block();
I would like to have a scriptable breakpoint at some place in the outgoing request where I can obtain the http headers, including any span id headers added by sleuth (and before any SSL encryption takes place). Preferably this breakpoint should be somewhere on the same thread as the above request - if the breakpoint is on the async thread that actually does the socket write, there is a danger that the next breakpoint hit will be that initiated by another client request.
There is a real reason why I need to use breakpoints like this so I can't do anything that requires modifying the code.
I have found places on the async thread where the http headers are available - e.g. in reactor/netty/http/HttpOperations.then but I am struggling to find a similar place on the original client thread. I'm hoping this isn't all deferred via lambdas or something until the async thread consumes the subscription.
I'm new on .NET technology and come into some problem. Currenlty i'm trying to build a REST API that handle long processing before sending the result to client.
What i'm trying to achieve is, i would like to do a background processing after receiving request from client. But, i would also like to send a response to client.
In short, it would be something like this.
Client Request -> Handled by controller ( doing some processing ) -> send response directly, ignoring the background that still running.
On Java, i can do this using Runnable Thread. How can i achieve this on C# Web API ?
Thank you.
In short, don't do this.
The job of an API is not to perform heavy duty, long running tasks.
You could simply let the API receive the request to perform something, then delegate that to another service. The API can then send a 200 response to show it received the request and maybe a URL to another resource which allows a user to track the progress.
The API needs to be available and responsive at all times. It needs to serve a number of users and if a number of them all request something that uses a lot of resources and takes a lot of time, chances are the API will simply go down and not serve anyone.
This is why you do not do such things in an API. Let other services do the heavy lifting.
Your api can call another async method and return 200/OK response without waiting for the request to complete.
You can learn more about async programing in c#.
static async Task Main(string[] args)
{
Console.WriteLine("coffee is ready");
var toastTask = MakeToastWithButterAndJamAsync(2);
async Task<Toast> MakeToastWithButterAndJamAsync(int number)
{
//Do something here.
}
}
This can be achieve this using loosed coupled architecture, by introducing service bus or blob storage, once you receive request in web api you can save it to blob/service bus and return acknowlegement response from web api. From service bus/blob storage use webjob/function/ durable function app to process the message using event.
i have a page that make 10 - 20 ajax request to load data from background. But as i look in mozilla developer tools network status, even all request is shown, processed request still run in fifo
you can see my network status screenshot
here
fyi, this is internal request and not cross-platform request and i use laravel 5.5 for application and axios to make ajax request
is this kind of flow (request executed in fifo order) is normal in async request?
or maybe i need to set something in my web server?
Thanks
Hi I am working with Web Api 2, is their any way I can handle request and response before reaching to the API controller.
You may be looking for a DelegatingHandler. These are HTTP Message Handlers that can process the request before it reaches the Controller and can also process the response on the way out of the pipeline. Delegating Handlers can also return the response themselves without calling the rest of the pipeline. You can read about Delegating Handlers here.
I have created simple async controllers that call into async methods that then call PostAsync on the HttpClient to retrieve various REST service endpoints. All works well, but how can I test to insure that the controller is really calling a background thread and releasing the primary thread back to the pool? I want to insure that I do have all the async sweetness working correctly and that I am not inadvertently running synchronous methods despite all my work to make everything async.
I found that System.Threading.Thread.CurrentThread.IsThreadPoolThread will provide whether the current thread is still a threadpool thread or not.