[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: ljacomet  XML
Profile for ljacomet -> Messages posted by ljacomet [77] Go to Page: Previous  1, 2, 3, 4, 5, 6 Next 
Author Message
Have a look at the quartz cron documentation
It looks like you inverted hours and minutes in your expression.
There is no ordering guarantee on the collection returned by Ehcache.getKeys()
The ehcache packaging as changed since version 2.7.0.

If this is an issue for you, please open an issue in the Ehcache Jira
Given the version 2.8.0 of ehcache enterprise:
1. Yes, but E2 would go to off-heap.

2. No

3. Ehcache does not split the memory between caches, rather the caches consumme memory from the common pool. There is no demo1 full vs demo2 not full, there is demo1 and demo2 in a 1GB pool, either full or not.

4. You should not use this setting unless faced with value storage errors. Default value is at 32MB. Space will not be wasted.

Hope this helps!
Some of the answers depend on the version you are using.

Can you specify your version?
A clustered cache does not use local disk, as such this setting is not relevant.

Can you provide more information on your ehcache setup?
Version and config are a minimum.

Is it possible that your cluster knows about an older version of this cache?
If yes, this could explain the configuration issue.
There was an issue with the website, which has been fixed.

There is no longer an open-source version for Terracotta in the 4.x line. Check the website for the different offerings.

Some tagging was required indeed.
I went through fixed issues and the list now reflects reality better.

Can you specify which version you are using?

Also a snippet of the locking code and your configurations (ehcache and terracotta ones) would help.

Ideally a small test case that reproduces the problem in isolation.
Have a look at the CronTrigger
You can create an entry for this in the Ehcache Jira
There is a confusion between two concepts here:
* tryWriteLockOnKey(Object, long) will lock the same lock that Ehcache uses internally when needed.
* Expiry will be applied to the element when it is next accessed. If before expiration time, it is returned. If after expiration time, no element is returned.

If you try to lock a second time the same key, standard lock semantics will apply, irrelevant of the expired situation of the entry.
Nothing to worry about, debug level logging tracking the disk operations
Profile for ljacomet -> Messages posted by ljacomet [77] Go to Page: Previous  1, 2, 3, 4, 5, 6 Next 
Go to:   
Powered by JForum 2.1.7 © JForum Team