Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

at very first look, it seems thread is blocked on net.sf.ehcache.Cache.getKeysWithExpiryCheck() method.
this method has some performce overhead. Read the javadoc:
The time taken is O(n), where n is the number of elements in the cache. On a 1.8Ghz P4, the time taken is approximately 200ms per 1000 entries. This method is not synchronized, because it relies on a non-live list returned from getKeys() , which is synchronised, and which takes 8ms per 1000 entries. This way cache liveness is preserved, even if this method is very slow to return.

Consider whether your usage requires checking for expired keys. Because this method takes so long, depending on cache settings, the list could be quite out of date by the time you get it.

what exception are you getting? In below link you get examples and code samples for Ehcache search.
http://ehcache.org/documentation/apis/search

Collection<String> pauseTriggers(GroupMatcher<TriggerKey> matcher)
throws JobPersistenceException

Pause all of the Triggers in the given group.

The JobStore should "remember" that the group is paused, and impose the pause on any new triggers that are added to the group while the group is paused.

Throws:
JobPersistenceException
See Also:
#resumeTriggerGroup(String)

you can add a job to this new trigger.

Quartz is used for Java application. I am not sure how are you using it with C#.net.

If I understand your requirment correclty, you can use a paused trigger group and add the job in in it.

I would suggest to use Job/TriggerListener to controll the behavior of your job or trigger.
For more details:
http://quartz-scheduler.org/documentation/quartz-2.1.x/tutorials/tutorial-lesson-07

Cheers!!!

you are using very big heap size. For Terracotta servers, we normally recommend to use ParallelGC and not to use Concurrent MarkSweep. For cleints, you can use any GC collector.
If you want to avoid disconnection of clients, you can increase health check setting. By default, TSA throws clients out after 45 sec in case log GC.

Hope this will help
Cheers!!

Terracotta has dev-console and ops-center monitoring utility which can show you lot of information about Terracotta cluster. You can find these utility in Terracotta_dir/bin folder.

The Terracotta server publishes a number of MBeans to provide information on the operation of the cluster.You can these MBeans via connecting Jconsole:
For example:
jconsole -J-Djava.class.path="<JDK installation dir>\lib\jconsole.jar;<JDK installation dir>\lib\tools.jar;<Terracotta installation Dir>\lib\jmxremote_optional-tc-1.0.1.jar;<Terracotta installation Dir>\lib\tc.jar" service:jmx:jmxmp://<Terracotta server IP>:9520

Hope this will help.

Cheers!!

A misfire occurs if a persistent trigger "misses" its firing time because of the scheduler being shutdown, or because there are no available threads in Quartz's thread pool for executing the job. when Quartz resume it start scheduling all the misfire triggers as per their misfire instructions. So it will take sufficient time depending upon your number of misfire triggers.
If there are thousands of job , you can increase the number of scheduler instances. I can help you more if you can answer below queries:
1. Number of Quartz instance
2. Number of jobs
3. Jobstore
4.Misfire instruction policy used

Cheers!!!

If i understand your issue correctly,Your application is querying the database excessively only to find that there is no result. Since there is no result, there is nothing to cache. you can cache null values.caching empty values can be desirable to deflect load from the database. below link will be helpful.

http://ehcache.org/documentation/recipes/cachenull

The answer of your question is "YES". Ehcache can store images. However, generally customers store metadata of images in cache to pick right images quick and fast and real images on disk.It depend upon users use-case.

If you really want your images to be viewed very fast , you can put images in Ehcache.

sorry, My mistake. You can not use RAMJobStore in clustered invironment.
If you do not want to store job in DB, you can use TerracottaJobstore (open source)which provides persistance and clustering both features.

You can also acheive above asked question in TerracottaJobStore.

Thanks

the list below is some things for you to check if you are experiencing deadlocks.
•Some databases falsely detect deadlocks when a tx takes a long time. Make sure you have put indexes on your tables (see improving performance of JDBCJobStore).
•Make sure you have at least number-of-threads-in-thread-pool + 2 connections in your datasources.
•Make sure you have both a managed and non-managed datasource configured for Quartz to use.
•Make sure that all work you do with the Scheduler interface is done from within a transaction. Accomplish this by using the Scheduler within a SessionBean that has its tx settings "Required" and "Container". Or within a MessageDrivenBean with similar settings. Finally, start a UserTransaction yourself, and commit the work when done.
•If your Jobs' execute() methods use the Scheduler, make sure a transaction is in progress by using a UserTransaction or by setting the Quartz config property "org.quartz.scheduler.wrapJobExecutionInUserTransaction=true".

I think problem is in your seocond job. did you test it by breaking the job from 18-24 and 00 to 4 am?