Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XMLSchedulingDataProcessorPlugin incompatible with StdAdoDelegate when useProperties=true #44

Jawvig opened this issue May 23, 2012 · 4 comments


Copy link

Jawvig commented May 23, 2012

I'm playing around with and adding support for a persistent job store via the ADO.NET Job Store. As per the recommendation in tutorial 9, I'm instructing the job store to persist job parameters in plain text rather than BLOBs, using the configuration:

Unfortunately in triggering a simple job, which has no explicit job data map, I receive this error:

JobDataMap values must be Strings when the 'useProperties' property is set. Key of offending value: LAST_MODIFIED_TIME

When looking in the debugger at the JobDataMap object provided to the job I scheduled, there is no LAST_MODIFIED_TIME present. Digging a bit deeper, it seems that there is another job running called FileScanJob, scheduled by the XMLSchedulingDataProcessorPlugin (used to read the job and trigger configuration from an XML file). This job adds the LAST_MODIFIED_TIME entry to its JobDataMap during job execution, which is of type DateTime rather than string.

This raising an exception due to the implementation of the StdAdoDelegate class. When the quartz.jobStore.useProperties configuration value is set to true it will deliberately fail to write to the job store database any job data that does not use string for both key and value. Despite this restriction, it still uses binary serialization to store the data after this check (in the form of a NameValueCollection).

To come back to the original reason for setting this property, the tutorial advises to use it to avoid serializing complex types and getting into versioning issues after type upgrades. I'd contest that this objective could be simply achieved by supporting all the primitive .NET types whose serialization is not likely to change. The change to StdAdoDelegate would be to perform a type validation of each name/value pair to ensure only simple types are in use in the case of quartz.jobStore.useProperties being true and convert it to System.Collections.Hashtable to allow for changes to the JobDataMap class to be made in Quartz without causing serialization issues.

Another solution could be to have an XmlAdoDelegate that used XML serialization instead of binary serialization.

Maybe I am missing some extra design constraint here?

Copy link

I think having ability to choose serializer for JobDataMap is a good option.

Copy link

I found that you can use property "quartz.serializer.type" and define any custom serializer that implement IObjectSerializer interface.

Copy link

lahma commented Jun 23, 2012

I agree that some relaxations could be made for the basic types as their serialization is well tested and known, the problem just is that serialized implementation is a NameValueCollection that cannot have any other types.

I think that UseProperties can well be false if one acknowledges the possible issues with serialization if non-primitive types are being used.

@lahma lahma added this to the 2.3 milestone Jul 19, 2014
@lahma lahma removed this from the 2.3 milestone Nov 8, 2014
@lahma lahma added this to the 2.6 milestone Jul 25, 2017
lahma added a commit that referenced this issue Jul 25, 2017
@lahma lahma closed this as completed in b43a56a Jul 25, 2017
Copy link

lahma commented Jul 25, 2017

Well that didn't take long. Now binary serialization is used for job data map that is detected to be from FileScanJob. Kind of a hack, but gets the job done without too much worries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

3 participants