I built a little web application that displays charts. I was thinking that it might be useful for the superuser of the app to do a complete data refresh, however this process takes around 10 minutes to complete. I was thinking perhaps the user could click a button that would start off a new thread to do a data refresh and subsequent clicks would kill the thread and restart the data population process. The user would then be free to browse about the site and view the charts as their data is populated.
Is there a simple method of accomplishing something like this?
You can twist ASP.NET to do this sort of thing, but it violates a few good general rules for ASP.NET development -- and could really cause problems in a server farm.
So, the most obvious route is to do this work in a web service. You can have the method return a chunk of HTML if you want. You could also add status methods to see how the thread is progressing.
Other options include: Handing the intense processing off to a database server (sounds like this might be a good use of OLAP) or, another cheap trick might be to set up the click to fire off a scheduled task that runs on the server. Can you provide some additional detail about the environment? Single server? Data storage platform, version of .net?
Ok, I didn't use either answer so here is what I did. I decided that it would be better if subsequent clicks would terminate instead of the currently executing one. Thanks for your answers guys.
//code behind
protected void butRefreshData_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(DataRepopulater.DataRepopulater.RepopulateDatabase));
t.Start();
}
//DataRepopulater.cs
namespace DataRepopulater
{
public static class DataRepopulater
{
private static string myLock = "My Lock";
public static void RepopulateDatabase()
{
if(Monitor.TryEnter(myLock))
{
DoWork();
Monitor.Exit(myLock);
}
}
}
Related
I am writing a Windows Forms app in C# with Visual Studio 2022 on a Windows 10 machine. The app connects to an Azure database, which works fine. My issue is that sometimes it takes several seconds to connect (maybe 10 or so), or if there is an error it goes all the way to the timeout limit (usually 20 to 30 seconds) before coming back with whatever error message there is.
I am trying to provide some visual feedback to the user during this time, but the application does not appear to be processing any events, so whatever type of feedback I'm trying to send does not get done until the operation completes (at which point it is moot).
Any ideas on how to deal with this? Do I need to open the database on a different thread, and if so, will that be an issue throughout the rest of the app whenever I use the database object opened on a different thread?
I'm trying something simple, like gradually adding a row of dots, like so:
private void InitCloudDatabase()
{
Boolean success = true;
WorkingTimer.Enabled = true;
WorkingTimer.Start();
try
{
AzureAgDatabase db = new AzureAgDatabase();
db.OpenConnection();
}
catch
{
success = false;
}
WorkingTimer.Stop();
pbCloudResult.Image = (success) ? Properties.Resources.icons8_done_96 :
Properties.Resources.Red_X___Fail;
}
private void WorkingTimer_Tick(object sender, EventArgs e)
{
lblCloud.Text += " .";
if (lblCloud.Text.Contains(" . . . . . . . . . . ."))
{
lblCloud.Text = "Database Connection (Cloud)";
}
}
I haven't really worked with Windows Forms before, but in most UI based applications, you should reserve the UI Thread for just UI operations and move all time consuming tasks (Compute or I/O) to a different thread to ensure that the UI is still responsive.
In the case of Windows Forms, looks like you have a BackgroundWorker class that you can use to offload the DB operations into. Here is a walkthrough in the official docs that you can refer to.
Another approach would be to use the Task class to run your database code asynchronously, with lesser code compared to the first approach. You would simply wrap statements that take time in a Task.Run call and have follow up statements in a continuation task.
I have a long running action/method that is called when a user clicks a button on a internal MVC5 application. The button is shared by all users, meaning a second person can come in and click it seconds after it has been clicked. The long running task is updating a shared task window to all clients via SignalR.
Is there a recommended way to check if the task is still busy and simply notifying the user it's still working? Is there another recommended approach? (can't use external windows service for the work)
Currently what I am doing seems like a bad idea or I could be wrong and it's feasible. See below for a sample of what I am doing.
public static Task WorkerTask { get; set; }
public JsonResult SendData()
{
if (WorkerTask == null)
{
WorkerTask = Task.Factory.StartNew(async () =>
{
// Do the 2-15 minute long running job
});
WorkerTask = null;
}
else
{
TempData["Message"] = "Data is already being exported. Please see task window for the status.";
}
return Json(Url.Action("Export", "Home"), JsonRequestBehavior.AllowGet);
}
I don't think what you're doing will work at all. I see three issues:
You are storing the WorkerTask on the controller (I think). A new controller is created for every request. Therefore, a new WorkerTask will always be created.
If #1 weren't true, you would still need to wrap the instantiation of WorkerTask in a lock because multiple clients could reach the WorkerTask == null check at the same time.
You shouldn't have long running tasks in your web application. The app pool could restart at any time killing your WorkerTask.
If you want to skip the best practices advice of "don't do long running work in your web app", you could use the HostingEnvironment.QueueBackgroundWorkItem introduced in .NET 4.5.2 to kick off the long running task. You could store a variable in the HttpApplication.Cache to indicate whether the long running process has been kicked off.
This solution has more than a few issues (it won't work in a web farm, the app pool could die, etc.). A more robust solution would be to use something like Quartz.net or Hangfire.
In the last few days I've been trying to learn how to use ASP.NET Web Forms together with multithreading the hard way by building a simple applet using both and I've been struggling with aspects of interactions between different threads and the UI.
I've resolved some multithreading issues in some other questions (and also learned after waaaaaay too long that web forms and WPF are not the same thing) but now I'm running into trouble finding the best way to update UI elements based on data acquired in multiple threads.
Here's my code:
Default.aspx
public partial class _Default : System.Web.UI.Page
{
private NlSearch _search;
private static int _counter = 0;
private static SortedList<long, SearchResult> resultsList = new SortedList<long, SearchResult>();
protected void Page_Load(object sender, EventArgs e)
{
_search = new NlSearch();
}
protected void AddSearchMethod(object sender, EventArgs e)
{
var text = SearchForm.Text;
new Task(() => MakeRequest(text));
}
protected void UpdateMethod(object sender, EventArgs e)
{
resultsLabel.Text = "";
foreach (var v in resultsList.Values)
{
resultsLabel.Text += v.SearchTerm + ": " + v.Count + " occurances<br/>";
}
}
protected void ClearSearchMethod(object sender, EventArgs e)
{
resultsLabel.Text = "";
resultsList.Clear();
}
protected void MakeRequest(string text)
{
_counter++;
SearchResult s = new SearchResult
{
SearchTerm = text,
Count = _search.MakeRequests(text)
};
resultsList.Add(_counter, s);
}
}
I've tried quite a few versions of the same basic thing. NlSearch.MakeRequest (called by MakeRequests) sends an HTTP POST request to an outside web site imitating a search bar input, and then extracts an integer from the markup indicating how many results came back.
The current simple UI revolves around a SearchForm textfield, an "Add Search" button, an "Update Label" button a "Clear Search" method, and a ResultsLabel that displays results. The AddSearch button creates a new task that calls MakeRequest, which calls the method to send the HTTP request and then stores the results in the order they were sent in a static sorted list.
So now ideally in a good UI I would like to just update the label every time a thread returns, however I've tried using ContinueWhenAll and a few other task functions and the problem seems to be that other threads do not have the ability to change the UI.
I have also tried running a new thread on page load that updates the label every few seconds, but this likewise failed.
Because I haven't been able to implement this correctly, I've had to use the "Update Label" button which literally just tells the label to display what's currently in the static list. I would really like to get rid of this button but I can't figuer out how to get my threads to make UI changes.
In general, trying to do threading in a web app is a bad idea. Web servers are designed for this, but spinning off new threads or processes should be avoided if at all possible. While there used to be a mechanism (and maybe there still is) to "push" results to a client, there are better solutions available today.
What you're describing is exactly the problem that AJAX is intended to solve.
You mentioned WPF in your question -- are you perhaps instead looking for a Windows application, like WinForms? I think that perhaps the term "web forms" has confused the situation. Web forms are just webpages with some (okay, a lot) of added in Microsoft functionality.
It sounds like you're trying to send updates to a webpage from a thread in code. The web doesn't work that way. I'd suggest reading through the ASP.NET Page Life Cycle Overview if you're actually trying to design webpages. Other answers have suggested AJAX functionality (which is where the web page executes some JavaScript that goes out and talks to a web server).
Have you ever hear about AJAX before? I think you're a thinking as application dev instead of web dev.
If you want to run your code asynchonous you may want to use the Async Await keywords instead of managing threads yourself. See information about Asynchronous Programming with Async and Await
Do not let your threads get tangled up ;)
I have a GUI that is for all intents and purposes really basic. A listview, an html form, and that's really it.
I want the user to have the following behavioral ability:
1 - Click a checkbox that says "Real-time". When clicked, a background thread will run once every 10 seconds.
2 - If there is a new file created (this is easy, to observe a new file) I want an alert displayed in my main gui. Where it is displayed for now is arbitrary (in a label, for example).
The main issue is I cannot figure out how to do this in a multi-threaded example. My goal is exactly in line with multithreading: do tasks 1 and 2, without locking task 1. Meaning, while the update check is running, the user can interact with the GUI as if nothing was going on in the background.
If you need more details to better answer this please let me know.
Thanks!
Here are a couple sites I found useful for implementing a background worker when I needed to perform database operations while still allowing the GUI to be responsive:
http://msdn.microsoft.com/en-us/library/zw97wx20.aspx
http://www.codeproject.com/KB/cs/AsynchronousCodeBlocks.aspx
Use events from the thread to tell the UI that something's changed:
// Just detected that that a new file has been created
if (this.FileCreated_Event != null)
{
this.FileCreate_Event(this, new FileEventArgs(newFileName));
}
where FileCreated_Event and FileEventArgs are declared appropriately.
Then in the UI when you receive the event you have the following:
this.fileChecker.FileCreated_Event += this.FileCreated_Event;
and:
private void FileCreated_Event(object sender, TrackStatusEventArgs e)
{
if ((sender as Control).InvokeRequired)
{
(sender as Control).Invoke(action);
}
else
{
action();
}
}
where action is the thing you want to do.
Try this tutorial. At the end I'm sure you'll be able to use threads. You must be careful though, because you'll have to manage those threads which can be a daunting task. I've never met a programmer who liked to debug multiple threads...
Long post.. sorry
I've been reading up on this and tried back and forth with different solutions for a couple of days now but I can't find the most obvious choice for my predicament.
About my situation; I am presenting to the user a page that will contain a couple of different repeaters showing some info based on the result from a couple of webservice calls. I'd like to have the data brought in with an updatepanel (that would be querying the result table once per every two or three seconds until it found results) so I'd actually like to render the page and then when the data is "ready" it gets shown.
The page asks a controller for the info to render and the controller checks in a result table to see if there's anything to be found. If the specific data is not found it calls a method GetData() in WebServiceName.cs. GetData does not return anything but is supposed to start an async operation that gets the data from the webservice. The controller returns null and UpdatePanel waits for the next query.
When that operation is complete it'll store the data in it's relevant place in the db where the controller will find it the next time the page asks for it.
The solution I have in place now is to fire up another thread. I will host the page on a shared webserver and I don't know if this will cause any problems..
So the current code which resides on page.aspx:
Thread t = new Thread(new ThreadStart(CreateService));
t.Start();
}
void CreateService()
{
ServiceName serviceName = new ServiceName(user, "12345", "MOVING", "Apartment", "5100", "0", "72", "Bill", "rate_total", "1", "103", "serviceHost", "password");
}
At first I thought the solution was to use Begin[Method] and End[Method] but these don't seem to have been generated. I thought this seemed like a good solution so I was a little frustrated when they didn't show up.. is there a chance I might have missed a checkbox or something when adding the web references?
I do not want to use the [Method]Async since this stops the page from rendering until [Method]AsyncCompleted gets called from what I've understood.
The call I'm going to do is not CPU-intensive, I'm just waiting on a webService sitting on a slow server, so what I understood from this article: http://msdn.microsoft.com/en-us/magazine/cc164128.aspx making the threadpool bigger is not a choice as this will actually impair the performance instead (since I can't throw in a mountain of hardware).
What do you think is the best solution for my current situation? I don't really like the current one (only by gut feeling but anyway)
Thanks for reading this awfully long post..
Interesting. Until your question, I wasn't aware that VS changed from using Begin/End to Async/Completed when adding web references. I assumed that they would also include Begin/End, but apparently they did not.
You state "GetData does not return anything but is supposed to start an async operation that gets the data from the webservice," so I'm assuming that GetData actually blocks until the "async operation" completes. Otherwise, you could just call it synchronously.
Anyway, there are easy ways to get this working (asynchronous delegates, etc), but they consume a thread for each async operation, which doesn't scale.
You are correct that Async/Completed will block an asynchronous page. (side note: I believe that they will not block a synchronous page - but I've never tried that - so if you're using a non-async page, then you could try that). The method by which they "block" the asynchronous page is wrapped up in SynchronizationContext; in particular, each asynchronous page has a pending operation count which is incremented by Async and decremented after Completed.
You should be able to fake out this count (note: I haven't tried this either ;) ). Just substitute the default SynchronizationContext, which ignores the count:
var oldSyncContext = SynchronizationContext.Current;
try
{
SynchronizationContext.SetSynchronizationContext(new SynchronizationContext());
var serviceName = new ServiceName(..);
// Note: MyMethodCompleted will be invoked in a ThreadPool thread
// but WITHOUT an associated ASP.NET page, so some global state
// might be missing. Be careful with what code goes in there...
serviceName.MethodCompleted += MyMethodCompleted;
serviceName.MethodAsync(..);
}
finally
{
SynchronizationContext.SetSynchronizationContext(oldSyncContext);
}
I wrote a class that handles the temporary replacement of SynchronizationContext.Current as part of the Nito.Async library. Using that class simplifies the code to:
using (new ScopedSynchronizationContext(new SynchronizationContext()))
{
var serviceName = new ServiceName(..);
// Note: MyMethodCompleted will be invoked in a ThreadPool thread
// but WITHOUT an associated ASP.NET page, so some global state
// might be missing. Be careful with what code goes in there...
serviceName.MethodCompleted += MyMethodCompleted;
serviceName.MethodAsync(..);
}
This solution does not consume a thread that just waits for the operation to complete. It just registers a callback and keeps the connection open until the response arrives.
You can do this:
var action = new Action(CreateService);
action.BeginInvoke(action.EndInvoke, action);
or use ThreadPool.QueueUserWorkItem.
If using a Thread, make sure to set IsBackground=true.
There's a great post about fire and forget threads at http://consultingblogs.emc.com/jonathangeorge/archive/2009/09/10/make-methods-fire-and-forget-with-postsharp.aspx
try using below settings
[WebMethod]
[SoapDocumentMethod(OneWay = true)]
void MyAsyncMethod(parameters)
{
}
in your web service
but be careful if you use impersonation, we had problems on our side.
I'd encourage a different approach - one that doesn't use update panels. Update panels require an entire page to be loaded, and transferred over the wire - you only want the contents for a single control.
Consider doing a slightly more customized & optimized approach, using the MVC platform. Your data flow could look like:
Have the original request to your web page spawn a thread that goes out and warms your data.
Have a "skeleton" page returned to your client
In said page, have a javascript thread that calls your server asking for the data.
Using MVC, have a controller action that returns a partial view, which is limited to just the control you're interested in.
This will reduce your server load (can have a backoff algorithm), reduce the amount of info sent over the wire, and still give a great experience to the client.