-
Notifications
You must be signed in to change notification settings - Fork 579
dev.meetings
Recording available here on YouTube
Next public meeting on G+ Hangout on Air at 11:30pm IST / 8pm CET / 2pm EST / 11am PST
-
Stats
-
send ideas to the developer mailing list.
Recording available here on YouTube
Recording available here on YouTube
-
Expiry to be the Store’s concern, just as eviction is
-
Store doesn’t know about the public event listeners though, uses internal private mechanism
-
An entry, being present but expired, is considered absent (i.e. a
Cache.putIfAbsentwould succeed). -
ValueHolderprobably can go now too
-
-
Some XML stuff as of here
Recording available here on YouTube
-
Exception hierarchy
-
Conclusion being we postpone deciding what we do, until we tackle the OSS Beta milestone. 107 dictates what we need to do now anways
-
-
-
INFO: Logs lifecycle stuff -
WARN/ERROR: We don’t log, but throw -
DEBUG/TRACE: Regular ops stuff, including delegating to theResilienceStrategy
-
Recording available here on YouTube
-
PR #109 on
ClassLoaderperCache-
Should it be a
Serviceor do we want to keep it as in the PR? -
Let’s revisit this based on user sample code we plan on doing after the 107 Alpha
-
-
Update the
READMEto explain how to get to this though sonatype -
107 Alpha to be released as
3.0.0-Alphato central
Recording available here on YouTube
Recording available here on YouTube
-
Project structure and especially the spi-tester sources
-
What should a Cache if everything gets veto’ed from being evicted?
-
CacheLoader & CacheWriter only for implementing the Cache Through pattern?
-
Some background here in this previous meeting
-
-
Mocking time in tests
Recording available here on YouTube
-
Release milestones:
-
107 Alpha
-
OSS Beta
-
-
Recap on SPI Testing
-
CacheLoader & CacheWriter lifecycle in StandaloneCache vs. managed ones
-
more TBD on the Ehcache Developer Google Group
Recording available here on YouTube
Our build infrastructure is now on Cloudbees here: https://ehcache.ci.cloudbees.com
Still need to publish -SNAPSHOT to Sonatype though
We said we should not git push --force to a branch that’s currently under review (because of the PR associated); but rather closing the PR and creating a new one.
|
Warning
|
This decision has been invalidated since: it’s okay to do it, but be vocal about it. One case where you just want to do it, is rebasing your branch should some other PR been merged in between. |
If you do changes based on the feedback from the PR, they probably should be a commit on their own atop of the other
Is ported from jsr-166 cvs (revision information is recorded in the commit). Still uses Unsafe, but lets leave it like that for now (won’t work on GAE for instance though).
Need to have the CHMv8 tests not run everytime (at least not as they stand).
JSR166Wrapper contains all interfaces to please javac
Actually make use of CHMv8 in OnHeapStore is still work that’s still pending
Also have a Unsafe wrapper that adds the methods not present in 1.6
SPI Testing strategy (discussed here)
Hung is currently working on a proposal, based on this here: https://gist.github.com/alexsnaps/f42557d008e2ed37f2b1
Acceptance criteria:
-
Not runtime dependency on a given testing framework (e.g. junit)
-
but can provide support for testing framework (e.g. to provide nice reporting)
-
-
SPI tester should report a complete run, not stop on first failure it encounters
-
A given SPI tester doesn’t know about any given implementation, but implementations pull the SPI tester in
-
Probably want to make the SPI testers available through maven using some qualifier (e.g. core:SpiTesters)
-
The Java™ Technology Test Suite Development Guide 1.2 would probably contain some good input on writing actual SPI tests
-
SPI tests are probably somewhat easier to write, given that we know where and how (UTSL!) a given SPI is actually used
Recording available here on YouTube
-
Let’s implement the void ones (e.g. remove(K): void) for now, we may do more later. It’s a cache, no real reason to wanting the old value ever…
-
Stick to ResilienceStrategy and have Ehcache be resilient:
-
No issues for on-heap Store implementations
-
Persistent ones will cope just fine (i.e. recover)
-
Distributed ones will force some .dealWithUnconsistentCache() cases
-
-
Have a checked, do it all yourself, interface of some kind
-
Postponing the work until all CRUD operations are implemented
-
Lacks archiving, more work for us to do, but that’s the work we’d want to be part of the S in CIaaS
-
Louis to take ownership and most probably move to cloudbees…
Recording available here on YouTube
We want CacheBuilder to create instances of types:
-
Unmanaged(ShortLived)Cache
-
UnmanagedLongLivedCache
While CacheManagerBuilder create:
-
(ShortLived)CacheManager
-
LongLivedCacheManager
which manages Cache, i.e. not Unmanaged ones. LongLived exposes the methods to delete 'persistent' data (i.e. that outlives the life of the JVM). A Cache is closed or destroyed through the CacheManager.
Issues are now ordered on waffle.io:
-
'API' labeled issues for public API require
-
JavaDoc
-
-
'API' labeled issues that are about SPI, require
-
JavaDoc
-
Tester of some kind, that
-
-
'Enhancement' labeled issues require
-
JavaDoc, as required
-
Unit tests
-
If ported from the 2.x line, best is to have decent coverage on the responsibilities the class will keep, prior to refactoring it; then refactor and add/tweak tests as required
-
Recording available here on YouTube
Let’s try to introduce a type hierarchy for both Cache and CacheManager that the builder would actually build, narrowing the type down à la Quartz 2.0 builders.
PersistentCache cache = newCacheBuilder() // (1)
.diskPersistent(
cfg // (3)
) // (2)
.build(); // (4)-
static method that creates a builder: Builder<Cache>
-
narrows to the builder’s type down to Builder<PersistentCache>
-
cfg actually defines the mode to use for persistence, eg: expect data on disk; expect none; use data if there; wipe data if there; wipe data on Cache.close()
-
actually builds the PersistentCache
Alex to make an actual proposal by next week.
-
Keep these, where the user is actually responsible to provide services
-
Only these Cache's type would expose .close()
-
CacheManager managed Cache instances would be 'closed' through the CacheManager
-
To further lifecycle PersistentCache instance, managed by a CacheManager, the latter could expose some method to retrieve DiskPersisted (interface with minimal lifecycle methods) instances; e.g.
Iterable<Map.Entry<String, DiskPersisted>> it = cacheManager.getManaged(DiskPersisted.class); it.next().value() // (1) .deleteOnDiskFiles(); // (2)
-
DiskPersisted could expose methods around lifecycling the data on disk only. No Cache methods
-
Implies Cache.close(), i.e. clear all 'VM transient' data and delete data from disk.
Recording available here on YouTube