I need some clarification on how these 2 entities interact...
If I use the BackgroundTransferService only to upload some files, the moment I move away from the application, the upload will stop. When I come back to the application, the upload will resume. Is that correct? Or is the upload lost?
However, if I wanted to make sure that the file will upload regardless of whether the user moves away from the application, I should kick off the BackgroundTransferService upload inside of a class that implements the ScheduledTaskAgent. Is that correct? If this is the case, how can that be done? BackgroundTransferService reports its progress via Events, thus I can't call NotifyComplete from the OnInvoke method of the ScheduleTaskAgent.
Am I going about it the wrong way?
No, this is not correct. If the background transfer is initiated, it is inserted in a queue that is dependent on a set of multiple factors, including other pending background transfers (from other third-party application) and the general network speed. You can find additional details here. That queue is processed, even if the application is tombstoned.
Related
I am using Windows Workflow Foundation 4and as part of more complicated scenario I have those two states:
The idea is that the users are allowed to upload files which is part of the whole workflow. There may be several reason which my lead to the fact that an uploaded file can not be processed immediately. One of the reasons may be that currently there is a file uploaded from a certain user which is being processed so every other file uploaded during the processing should be in state WaitingProcessing. However when I enter the WaitingProcessing state I need to check this. In order to do that I have to implement something like this:
where generally the HasFileToProcess is a function which will call a stored procedure from the database to check if currently there is a file for this user which is in state Processing.
Almost all parts of the tasks are clear, one thing that I don't know how to do is how to call e function inside the condition field. In fact I have almost zero experience with Windows Workflow at all so I'm not even sure that this is the way to go so as a sub-question I would appreciate if someone knows and show me if there is better way to implement this kind of logic.
hello guys I have been given the task to create a web-app that would allow an end user to load a file to one of our servers. the server would then manipulate the file and then give it back to the end user.The server has IIS7 and .net framework 4
Here is my problem.
I have everything figured out except that I'm having a hard time getting rid of the file from the server once i manipulated. Is there a way that i can put a timer say after 30 mins to have the file removed from the server in my code? or is there another solution to doing this?
I know the timer suggestion perhaps does not make sense however i cant think of another way to do it so i'm looking for an opinion or another method.
A timer is a good method to schedule something in the future. You could even reset the timer if the user requests the file again. Just give the timer a delegate that deletes the file when the timer fires.
Are you able to set up a scheduled task on the server?
This sort of thing is perfect for a simple console app that simply deletes files that have a modified date/time that is older than, say, now.AddMinutes(-10).
The task can run every 10 minutes or so if you like too.
Sometimes best to keep this sort of thing away from your website. Let your site serve your users and create something else to serve your server.. :)
Update
If its a heavy-traffic site you could simply delete all old files the next time someone uploads a file.
So:
User Selects file to upload, clicks Upload -> you get file -> you
delete old files (regardless of who they belong to) -> you manipulate
file -> file will be deleted by next users upload...
Why not delete it after manipulating? Or whatever the last step in the process is? That would seem to be the best and easiest way.
Depending on volume, it's probably not a great idea to do a single task for each file - rather you should batch them into a queue and have a single thread process the queue.
For instance, you can spin up a background thread in global.asax (perhaps using a Timer) to handle cleanup tasks by comparing file times or something.
Or, as step 1 of the process you could clean any old files. Not exactly the same thing, but may be close enough.
Or, you could abuse the Cache remove callback as a timer.
If you can ensure the app stays running all the time you can skip scheduled tasks and use Quartz.NET. In this case, even if it shuts down using quartz would not be that bad -- unless there is something else to this having a few old files hanging around while the app is idle wouldn't hurt.
Insofar as handling this, I would store in an appropriate manner (eg -- your database) an list of the files with a marker for the job being complete as well as deleted. Your quartz task could then grab the files that are marked done but not marked deleted and clean those up. Bonus points for using transactions around the file deletes and updates and logging so you know what happened while the world was sleeping.
I am trying to implement file based autoincrement identity value (at int value stored in TXT file) and I am trying to come up with the best way to handle concurrency issues. This identity will be used for unique ID for my content. When saving new content this file gets opened, the value gets read, incremented, new content is saved and the incremented value is written back to the file (whether we store the next available ID or the last issued one doesn't really matter). While this is being done another process might come along and try to save new content. The previous process opens the file with FileShare.None so no other process will be able to read the file until it is released by the first process. While the odds of this happening are minimal it could still happen.
Now when this does happen we have two options:
wait for the file to become available -
Emulate waiting on File.Open in C# when file is locked
we are talking about miliseconds here, so I guess this wouldn't be an issue as long as something strange happens and file never becomes available, then this solution would result in an infinite loop, so not an ideal solution
implement some sort of a queue and run all operations on files within a queue. My user experience requirements are such that at the time of saving/modifying files user should never be informed about exceptions or that something went wrong - he would get informed about them through a very friendly user interface later when operations would fail on the queue too.
At the moment of writing this, the solution should work within ASP.NET MVC application (both synchronously and async thru AJAX) but, if possible, it should use the concepts that could also work in Silverlight or Windows Forms or WPF application.
With regards to those two options which one do you think is better and for the second option what are possible technologies to implement this?
The ReaderWriterLockSlim class seems like a good solution for synchronizing access to the shared resource.
I am setting out to create an app that will watch a directory for any files created. pretty straightforward time to use a filesystemwatcher. My question relates to how to utilize it. Is it common practice to use a windows service to ensure the application is always running?
i have been trying to get away from building windows services if i don't have to, but i really don't see an alternative to doing it that way in this instance. normally, i would convert my service to a console app and schedule it using windows scheduler, but that doesn't really apply in this situation.
can anyone recommend a better way of implementing the filesystemwatcher than a windows service?
thanks for any thoughts.
EDIT
in response to the comments below, more specifically, i just have to watch a directory on a server, and when a new file is created, i have to move a copy of that file into a different directory on the same server, perhaps renaming it in the process.
The frequency and amount of files will be quite small. perhaps 5-10 at most in a day.
I'm not sure yet how the file watcher works, but this is what I'm thinking: The file system fires events; I mean like NTFS must be doing that. Your file watcher hooks into those events. The file watcher probably suspends the thread it's running in until an event occurs and the event somehow wakes up the thread. A suspended thread uses pretty much very few cpu cycles (actually none) while it is suspended, so waiting for a file event costs nothing. So a polled approach wastes mucho beaucoup (that's French, it means 'a shit load') of cpu cycles but the file watcher does not. You could probably look at PerfMon to see if this is likely true.
You should describe more about what you want to do, but typically if you have something that needs to run in the background and does not require direct user interaction, then a service often makes sense.
You can use Remoting to connect a front-end to your service as needed if you'd like.
Yes, use a service for this kind of operation, but don't use filesystem watcher. If you poll for files in your service, dont use the Timer class either.
Do check to make sure the file is completed writing and is no longer locked before trying to move it.
Its trivial to poll for file changes (syntax may be off), and eliminates much of the extra programming associated with file system watcher events.
While True 'or your exit condition'
Dim _files() as FileInfo = Directory.GetFiles(yourTargetDirectory)
For Each _file as FileInfo In _files
If _file.LastModifiedDate < DateTime.Now.AddMinutes(1) Then
'move your files'
End If
Next
End While
Using a Windows service to wrap FileSystemWatcher is perfectly fine for what you need.
FSW is the right tool for the job (native code for filesystem watching is a bear to get right), and a service is the right mechanism to deploy it given you need 'always on' operation.
The service credentials will be independent of logged-in user too, which may be useful to you.
I just posted the question how-to-determine-why-the-browser-keeps-trying-to-load-a-page and discovered that my problem is with Gravatar.
I also noticed that StackOverflow is suffering from the same outage.
Does anyone know of a graceful way to determine if Gravatar, or any third party website for that matter, is up or not, before trying to retrieve avatar icons from them?
This would eliminate the long page load and the never ending busy cursor ... I shouldn't say never ending ... it just takes a long time to go away and is very confusing to the user as they sit there and wait ... for nothing.
You can have a different process that is periodically checking the status of the site. Set a rule about what is down for you, for instance you could say: "ping time > 1500 ms = down". Have this process to leave a note in a database table or config file. Then you check this value on each page rendering at almost no cost.
Depending on how critical is this external site, you can do the check more or less often.
This process could be an out of the web stack program, or a page only accessible through localhost that gets executed via Scheduled Tasks or an ASP.NET facility like mentioned in the comments.
For Gravatar you can cache all theses images instead of taking them from their server everytime. Of course, if user change their icon, it might not refresh as fast as it would be if it were direct access to the main server but at least you do not have to request gravar server everytime.