Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi,

The CacheWriterConfiguration changes will not be applied on a running cache.
The fact that the API offers mutation methods results from the way creation and use by the cache are mixed up on the same object.

You may want to have a look at this part of the documentation:
http://ehcache.org/documentation/configuration/fast-restart

Thanks for the specific pointers.
I have created a Jira to update the documentation.

Hello,

Not sure to which version of the documentation you are referring to here. Can you provide a link? It may be a leftover from previous versions.

That extract does not apply to the latest ehcache, 2.7.x, which moved from an overflow model to a tiered model where data is always stored on the lower tier, disk in your case, and available on the higher (and faster) tier(s) based on resource usage.

Regards,

Hello,

When does your initial load starts:
- right at the start of webapp initialization?
- right at the start of Spring initialization?
- later?

The first two may take some time and you may want to check how long your webapp / Spring context initialization takes on its own - without doing the load.

Regards,

Not fully sure given the very short extract, but I assume this log message comes from the MemoryGo license being parsed, not from the Cache allocating offheap.

For offheap allocation, you should see something like:
INFO: Creating Off-Heap Area Using Config

Followed by sizing information

and then:
INFO: Allocated 4GB in 1GB chunks.
INFO: Took 2867 ms to create CacheManager off-heap storage of 4GB.

Hello,

From the cron expression section in Quartz documentation:

The '/' character can be used to specify increments to values. For example, if you put '0/15' in the Minutes field, it means 'every 15th minute of the hour, starting at minute zero'. If you used '3/20' in the Minutes field, it would mean 'every 20th minute of the hour, starting at minute three' - or in other words it is the same as specifying '3,23,43' in the Minutes field. Note the subtlety that "/35" does *not mean "every 35 minutes" - it mean "every 35th minute of the hour, starting at minute zero" - or in other words the same as specifying '0,35'.

Which means the trigger you create is schedule to run at minutes 0, 15, 30 and 45 only.

As indicated in the Javadoc of startNow(), its effect depends on the schedule configured for the trigger.

If you really need a trigger firing every 15 minutes from now, you might want to use:
org.quartz.SimpleScheduleBuilder#withIntervalInMinutes as your parameter of withSchedule

Regards,

Hi,

Either:
- you need to clear the DB when stopping the app and recreate all jobs on restart
or
- you need to account on restart that jobs could have been created by a previous run.

Hope that helps

Looks like you are using Osgi here, right?

Stack trace seem to indicate that the ehcache not finding the Hibernate file is the one from the bundle org.apache.servicemix.bundles.ehcache.
Can it be that bundle which does not have Hibernate class visible?

Thinking out loud here as I am not an Osgi specialist.

Hello,

This looks like a classpath issue, related to what Hibernates puts in Ehcache.

Make sure the class org.hibernate.engine.TypedValue is available to your application.

Hi Amber,

A and B should be pretty much equivalent, as strong consistency implies the usage of lock underneath.
C, but only locking on write operations, makes sense in a heavy read use case, where you can live with a client viewing stale data for a while.

Hope this helps,

There was indeed a race condition in this code.

It has been fixed as part of QTZ-386.

The fix will be part of the upcoming 2.2.1 Quartz release.

The CacheManager has been closed by one of the two applications.
Did one of the two spring context restart for any reason?

As the documentation says, I advise to not use such a setup, as it will most likely lead to trouble.

Have a look at Lesson 6: CronTrigger
It has all the information you need for building that expression.

[Answer copied from Quartz Jira]

Hello Jeff,

It looks like this is a JDBC driver issue, not a Quartz issue.
See this StackOverflow thread and the link to an issue describing the same problem on the MySQL tracker.

You need to upgrade your MySql driver when migrating from 5.0.x to 5.6.x