Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink use of Guava cache using play's plugin architecture #337

Merged
merged 1 commit into from
Jul 6, 2015

Conversation

yl3w
Copy link
Contributor

@yl3w yl3w commented Jul 3, 2015

Summary:
What started off as a simple rewrite of tattler (logging user id) ran into issues
when I found ~20 unit tests that were not running.

Getting the unit tests to run resulted in failure and
so began a journey into the guts of the cache plugin architecture

Previously we use squeryl callback mechanism to implement
domain model caching. Why? I'm no so sure, but this did lead
to some fairly tight coupling of domain objects and caching logic.

We also use Guava cache at a few different places

(a) Cache file (user spec) for FileAuthentication
(b) Cachining permissions file
(c) Authenticated ldap users
(d) Metrics used with graphing
(e) Provisioning profiles

This pulls out the use of Guava cache from play's plugin arch
keeps the use cases other than domain objects in place, and
no longer caches domain objects.

Since we no longer use caching for domain objects, I updated
the admin page to not display cache stats. We can always
add those back in.

@yl3w
Copy link
Contributor Author

yl3w commented Jul 3, 2015

And the entire reason to do this, 15 more unit tests

[info] Passed: Total 315, Failed 0, Errors 0, Passed 315
[success] Total time: 280 s, completed Jul 3, 2015 2:24:07 AM

Summary:
What started off as a simple rewrite of tattler ran into issues
when I found ~20 unit tests that were running.

Getting the unit tests to run resulted in failure and
so began a journey into the gutting of the cache plugin architecture

Previously we use squeryl callback mechanism to implement
domain model caching. Why? I'm no so sure, but this did lead
to some fairly tight coupling of domain objects and caching logic.

We also use Guava cache at a few different places

(a) Cache file (user spec) for FileAuthentication
(b) Cachining permissions file
(c) Authenticated ldap users
(d) Metrics used with graphing
(e) Provisioning profiles

This pulls out the use of Guava cache from play's plugin arch
keeps the use cases other than domain objects in place, and
no longer caches domain objects
@yl3w
Copy link
Contributor Author

yl3w commented Jul 3, 2015

Also as part of this PR, I made a change to allow for complete specification of Guava cache settings as provided for by Guava CacheBuilderSpec.

@yl3w
Copy link
Contributor Author

yl3w commented Jul 6, 2015

@defect @byxorna @nsauro @Primer42

yl3w added a commit that referenced this pull request Jul 6, 2015
Rethink use of Guava cache using play's plugin architecture
@yl3w yl3w merged commit a796262 into master Jul 6, 2015
@yl3w yl3w deleted the bhaskar-cache-ectomy branch September 12, 2015 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant