Author |
Message |
|
So you used the script from the 2.2.0 distribution. Are you absolutely sure that you are running version 2.2.0 ? I can't find anywhere in the 2.2.0 code base where an insert statement is created for that table without having the SCHED_TIME column populated. But in previous versions we didn't have that column, so that is the likely cause (having a jar other than the 2.2.0 jar on your classpath).
|
|
|
Is this a new install? An upgrade?
Sounds like you somehow have bad data in a column of the fired_triggers table.
|
|
|
Sounds like CalendarIntervalTrigger would be your friend.
|
|
|
Your heap size setting is pretty large (8GB). Are you seeing GC issues (pausing work)? How large are your JVM process actually getting?
|
|
|
There has always been this limitation ("Support for specifying multiple "nth" days is not implemented.").
However in the 1.x code line, attempts by the user to use such expressions was not properly detected. In the 2.x line it is detected and an exception is thrown.
What you are suffering from is that the 1.x code line was silently failing, and seeming to work (but not), and the 2.x code line is noisily failing.
|
|
|
.. and yes, it's probably fine to use the older quartz with the newer Terracotta (at least with the versions you mention --- the older quartz definitely won't work with the newest (4.x line) releases of terracotta).
|
|
|
Yeah, according to your stacktrace and details, you're not using Quartz directly - you're using Spring as a wrapper around it. When the Quartz APIs changed with the 2.x release, Spring had to also update their wrappers to work with it.
|
|
|
Have you also updated to the latest Spring?
|
|
|
Can you be more specific about which quartz versions you are talking about.
And can you be more specific about what "won't work" means? what errors are you getting?
|
|
|
Yes, this isn't well supported for clustered environments. You need to query each node individually - typically by enabling RMI or JMX on each.
|
|
|
Cluster-wide? No. Not without enabling remote connections, and querying each node.
Why are you allowing the execution threads to "crash"? your job should ideally catch exceptions.
|
|
|
This is not something Quartz can resolve. Your app needs to shutdown quartz before it shuts down the services it uses.
|
|
|
You'd be interested in CalendarIntervalTrrigger.
|
|
|
You ran into an OutOfMemoryError. JVMs do bad things when that happens - all sort of unpredictable outcomes from that point forth (and threads within the jvm could be killed, had program state can exist, etc). There's really nothing you can do with a JVM once that error has occurred except restart it (hopefully with larger head size settings so that it doesn't occur again). This time it was the QuartzSchedulerThread that ran into the OOME, but it could have been any thread.
|
|
|
You should have the job reschedule itself. (replace the existing trigger with one that has a start time on the following day).
|
|
|