Issue Details (XML | Word | Printable)

Key: QRTZNET-82
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Marko Lahma
Reporter: Anson Goldade
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Quartz.NET

Xml Job plugin doesn't need write access to schedule file

Created: 02/Jan/08 08:00 AM   Updated: 20/Jan/08 11:22 AM
Component/s: Core
Affects Version/s: 0.9
Fix Version/s: 0.9.1

Environment: Windows 2003, .NET 3.5, IIS 6.0


 Description  « Hide
When running the quartz scheduler within an ASP.NET process, the Xml Job plug-in code goes to read the xml file and errors out because the code to open and read the file is requesting write access to the underlying file. I don't believe there is a need to have write access to the xml job schedule file. If the code to open the FileStream is updated to only request read access to the file, it'll run in ASP.NET without issue. Here is the stack trace from the exception.

System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) +651 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) +1038 System.IO.FileStream..ctor(String path, FileMode mode) +64 Quartz.Plugin.Xml.JobFile.Initialize() +562 Quartz.Plugin.Xml.JobFile..ctor(JobInitializationPlugin plugin, String fileName) +56 Quartz.Plugin.Xml.JobInitializationPlugin.Initialize(String pluginName, IScheduler sched) +273 Quartz.Impl.StdSchedulerFactory.Instantiate() +14187 Quartz.Impl.StdSchedulerFactory.GetScheduler() +217

Here is the existing code at line 439 in the JobInitializationPlguin.cs class

f = new FileStream(file.FullName, FileMode.Open);

I would propose that the code be changed to

f = new FileStream(file.FullName, FileMode.Open, FileAccess.Read);



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Marko Lahma added a comment - 07/Jan/08 02:52 PM
Thanks for reporting this, this is very true and needs to be fixed. Please be aware of thread pool recycles which can potentially stop your scheduler unexpectedly when hosted in ASP.NET runtime, generally a windows service is preferred. There's talk about this on the Quartz.NET mailing list also.

Anson Goldade added a comment - 07/Jan/08 03:40 PM
I totally agree with you that a service would be a better place to host the scheduler. For the case that surfaced this issue, we are deploying websites on customers boxes and have some basic scheduling needs that only need to be dealt with when the site is active. It's also a lot lower bar to get over deploying a dll in the bin directory of the website vs. installing a windows service on their box(es) :-) I do appreciate the heads up and thanks for the response. Great product from our experience so far.

Marko Lahma added a comment - 07/Jan/08 04:24 PM
Now fixed in trunk.