Is it good practice to be using cancellation tokens when making an asynchronous request to a SQL Server?
Lets just say we have a situation where we could end up with the SQL Server reporting an 'Operation Time out' failure.
Eventually SQL Server will return the exception to us.. and a Task from the thread pool that made receive a result containing the exception.
But would it be better if we where to defend against this by introducing a cancellation token with a shortened timeout limit.
My gut tells me that i should leave this up to the SQL Server to report any exceptions, but that could mean leaving the request hanging for minutes..
Hope this makes sense.
SQL Server does not have a time-out on the server side. ADO.NET already sets a timer that, when triggered, will abort the query.
Let me rephrase that: the client will ask the server to abort the query.
There's a more detailed explanation in this MSDN blog.
Related
I want to execute database operation in a handler and then send three commands to other handlers.
I want to make sure that all the execution of database operation together with sending commands occur in a transaction and whether all succeed or all fail.
I am using .net core and when I try to do this I get an exception that "This platform does not support distributed Transactions"
I was using RabbitMQ Transport and then SQL server transport but still getting the same problem.
I would like to know the best way to ensure that all the execution is ATOMIC under .NET Core and RabbitMQ or SQL Server transport.
Thanks
I am surprised that you get this particular exception, because Rebus does not participate in distributed transactions (at least not with any of the supported transports, and especially not with RabbitMQ).
Could you maybe update your question to include the full exception details (with stack trace and everything)? And maybe tell a little bit about how you're performing your database operations?
Lets assume rebus could not publish message to rabbitmq or some other queue, what is the best practice to handle this exception.
I stopped rabbitmq service and rebus threw Aggregate exception. I can manually cacth this exception in try - catch block but is there a better solution to catch exceptions when such situations happened ?
First off: If you get an exception when initially sending/publishing a message (e.g. while handling a web request), there's nothing you can do, really. Sorry ;)
You should probably log - thoroughly - all the information you can, and then be sure to set up logging so that the information ends up in a file or in some other persistent log. And then you should have some kind of notification or a process in place that ensures that someone will at some point look at the log.
You should probably have this kind of logging in place, regardless of the type of work you do.
Depending on how important your information is, you could also set up some kind of retry mechanism (although you should be careful that you do not consume threads and too much memory while retrying). Also, since your web application should be able to be recycled at any time, you probably should not rely (too much) on retries.
You can do some things, though, in order to minimize the risk of ending up in a situation where you can't send/publish.
I can recommend that you use some kind of high-availability transport, like MSMQ (because it has local outgoing queues), RabbitMQ (with a shovel on each machine), or Azure Service Bus or Azure Storage Queues if you're in Azure.
Moreover - if you were using MSMQ, and you want to publish an event - I would recommend that you await bus.Send(theEvent) first, and then when you handle the message, you await bus.Publish(theEvent). This is because Rebus (with the MSMQ transport) needs to do a lookup in the subscription storage in order to get all subscribers for the given event. This is not a problem with RabbitMQ though, because Rebus will use Rabbit's topics to do pub/sub and will be just as safe as doing an ordinary send.
When you're sending/publishing from within a Rebus message handler, there is of course no problem, since the receive operation will be rolled back, and eventually the incoming message will end up in an error queue.
I hope that cast some light on the situation :)
I use asynchronous XMLHttpRequest to call a function in ASP.net web service.
When I call an abort method on the XMLHttpRequest, after the server has received the request and processing it, the server continues processing the request.
Is there a way to stop the request processing on the server?
Generally speaking, no, you can't stop the request being processed by the server once it has started. After all, how would the server know when a request has been aborted?
It's like if you navigated to a web page but browsed to another one before the first one had loaded. That initial request will, at least to some extent (any client-side work will of course not take place), be fulfilled.
If you do wish to stop a long-running operation on the server, the service that is being invoked will need to be architected such that it can support being interrupted. Some psuedo code:
void MyLongRunningMethod(opId, args)
{
work = GetWork(args)
foreach(workItem in work)
{
DoWork(workItem)
//Has this invocation been aborted?
if(LookUpSet.Contains(opId))
{
LookUpSet.Remove(opId)
return
}
//Or try this:
if(Response.IsClientConnected)
{
HttpContext.Current.Response.End();
return;
}
}
}
void AbortOperation(opId)
{
LookUpSet[opId] = true
}
So the idea here is that MyLongRunningMethod periodically checks to see if it has been aborted, returning if so. It is intended that opId is unique, so you could generate it based on the session Id of the client appended with the current time or something (in Javascript, new Date().getTime() will get you the number of milliseconds since the epoch).
With this sort of approach, the server must maintain state (the LookUpSet in my example), so you will need some way of doing that, such as a database or just storing it in memory. The service will also need to be architected such that calling abort does not leave things in a non-working state, which of course depends very heavily on what it does.
The other really important requirement is that the data can be split up and worked on in chunks. This is what allows the service to be interruptable.
Finally, if some operation is to be aborted, then AbortOperation must be called - simply aborting the XMLHttpRequest invocation won't do help as the operation will continue until completion.
Edit
From this question: ASP.Net: How to stop page execution when browser disconnects?
You could also check the Response.IsClientConnected property to try and determine whether the invocation had been aborted.
Generally speaking, the server isn't going to know that a client has disconnected until it attempts to send data to it. See Best practice to detect a client disconnection in .NET? and Instantly detect client disconnection from server socket.
As nick_w wrote you can't stop the request being processed by the server once it has started. But there is ability to implement solution which will give you ability to cancel server task. Dino Esposito has several great articles about how such things can be implemented:
Canceling Server Tasks with ASP.NET AJAX
And in the following articles to implement pooling to server Dino Esposito describes how to use SignalR library:
Build a Progress Bar with SignalR;
Long Polling and SignalR
So if you really need to cancel some task on server these articles can be used as starting point to implement required solution.
I have a variation of the benefits-of-async/await-on-ASP.NET from this question.
My understanding is that asynchrony is not the same thing as parallelism. So, on a web server, I wonder about how much benefit async/await brings to ASP.NET pages.
Isn't IIS+ASP.NET already really good at allocating threads for requests, and if onen page is busy waiting for a resource the server will just switch to processing another request that has work to do?
There are a limited number of threads in the pool for ASP.NET to use - does async use them any more effectively?
As Mr. Skeet pointed out in answering the question above, we're not talking about blocking a UI thread. We're already multi-threaded and the web response can't be completed until all the request's tasks are done, async or not, right?
I guess what it boils down to is this:
Is there any benefit to an async read of a resource (say a file or DB request) in an ASP.NET page vs. blocking on it?
if one page is busy waiting for a resource the server will just switch to processing another request that has work to do?
I don't think so. I would be very surprised if this were the case. It's theoretically possible, but very complex.
There are a limited number of threads in the pool for ASP.NET to use - does async use them any more effectively?
Yes, because when you await something, the thread for that request is immediately returned to the pool.
We're already multi-threaded and the web response can't be completed until all the request's tasks are done, async or not, right?
That is correct. async in a server scenario is all about removing pressure on the thread pool.
Is there any benefit to an async read of a resource (say a file or DB request) in an ASP.NET page vs. blocking on it?
Absolutely!
If you block on a file/service call/db request, then that thread is used for the duration of that operation. If you await a file/service call/db request, then that thread is immediately returned to the thread pool.
One (really cool!) result of this is that you can have a request in progress, and while it's (a)waiting some operation, there are no threads servicing that request! Zero-threaded concurrency, if you will.
When the operation completes, the method resumes after the await - on a (possibly different) thread from the thread pool.
In conclusion: async scales better than threads, so there is definitely a benefit on the server side.
More info: my own intro to async post and this awesome video.
I'm new to web development so I'm not sure what's the best option for the problem that I'm having.
Basically I have a web application that calls a web service for processing some data.
This process may take a long time (hours) and I would to know if there is an easy way to send some status information to the client from time to time.
Right now, the client makes the request from the browser and it just waits there until it finishes.
How can I send some information from the web service? I would like to send a percentage and some additional text specifying what is being done.
Thanks
WCF services can be marked as [OneWay] so that they don't return a response.
or, you could have the service kick off the process in an async manner and then just return to the client that the process has/or hasn't kicked off.
Then, the client can poll another method as the other user has suggested.
If you process takes hours you definitely can't use a sync service because you'll hit your execution timeout or rather the connection timeout for the client.
Maybe you can poll another method for status?
If I were you, I would make the original request asynchronous, as in instead of waiting for the response, it just "starts" the task and returns immediately. Then I would have a separate method on your web service that the app can poll periodically to get the status of the job. once it completes, it can display the data like the original request was doing.
if you want to do it synchronously, you can turn off Response.Buffer and write directly to the response.