A Guava-based CacheManager implementation

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

A Guava-based CacheManager implementation

Brendan Le Ny
Hi everyone (new subscriber here),

For my current project, I've just made an implementation of CacheManager
based on Guava.

At first, i was using MemoryConstrainedCacheManager but it seems to
retain data in cache for too long for me.

I've seen others implementation (ehcache, terracotta) but these
dependencies are too large, i don't need all those features.

So i created mine, based on Guava caches [1]. It's convenient to me
since it's in-memory and thread-safe, Guava has a mature quality code
base and it support few tweaking options (sufficient to me):

     concurrencyLevel
     initialCapacity
     maximumSize
     maximumWeight
     expireAfterAccess
     expireAfterWrite
     refreshAfterWrite
     weakKeys
     softValues
     weakValues
     recordStats

I've already programmed the whole thing (two little classes) and I was
wondering if the Shiro team would be interested to integrate this as a
new module. It's tiny (no dependency except guava and shiro-cache), it
could be just near ehcache support and be convenient for people who
don't have big caching issues.

It's not perfect but i did some Javadoc, followed your code-style, made
a minimalistic pom.xml.

[1] https://code.google.com/p/guava-libraries/wiki/CachesExplained

--
Brendan Le Ny, Code Lutin
[hidden email]
(+33) 02 40 50 29 28
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Les Hazlewood-2
Hi Brendan!

Thanks for the notice!  I use Guava from time to time myself and enjoy it.
 I'm not sure yet if the dev team wants to undertake long term maintenance
of this - I'd personally like to see Hazelcast be our recommended caching
solution (it is Apache 2.0 licensed, which is ideal for Shiro), and it
supports both embedded and clustered modes with full TTL/TTI support.
 Until now, Ehcache was sort of the implicit recommended solution since we
have out-of-the-box implementation, but in all honesty I'd personally like
to drop it since it is LGPL (we don't modify or subclass any of their
classes, so we're safe to use it in an Apache project, but there is that
gray area that would be nice to just remove entirely).

In any event, this is all of course open for discussion, but the best thing
to do to ensure your request isn't lost is to open a Shiro Jira issue and
link the issue to your GitHub project (or wherever else it might be
located) or attach a patch, and then we can discuss it.

Thanks again! I look forward to your participation!

Best,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Mon, Jan 6, 2014 at 7:27 AM, Brendan Le Ny <[hidden email]> wrote:

> Hi everyone (new subscriber here),
>
> For my current project, I've just made an implementation of CacheManager
> based on Guava.
>
> At first, i was using MemoryConstrainedCacheManager but it seems to retain
> data in cache for too long for me.
>
> I've seen others implementation (ehcache, terracotta) but these
> dependencies are too large, i don't need all those features.
>
> So i created mine, based on Guava caches [1]. It's convenient to me since
> it's in-memory and thread-safe, Guava has a mature quality code base and it
> support few tweaking options (sufficient to me):
>
>     concurrencyLevel
>     initialCapacity
>     maximumSize
>     maximumWeight
>     expireAfterAccess
>     expireAfterWrite
>     refreshAfterWrite
>     weakKeys
>     softValues
>     weakValues
>     recordStats
>
> I've already programmed the whole thing (two little classes) and I was
> wondering if the Shiro team would be interested to integrate this as a new
> module. It's tiny (no dependency except guava and shiro-cache), it could be
> just near ehcache support and be convenient for people who don't have big
> caching issues.
>
> It's not perfect but i did some Javadoc, followed your code-style, made a
> minimalistic pom.xml.
>
> [1] https://code.google.com/p/guava-libraries/wiki/CachesExplained
>
> --
> Brendan Le Ny, Code Lutin
> [hidden email]
> (+33) 02 40 50 29 28
>
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Brian Demers
Very Cool!

I agree with Les with being cautious about long term support.  However, I
noticed we do not have a 'third-party' library page.
(Lots of projects do this, but here is an example that sticks out in my
mind: http://metrics.codahale.com/manual/third-party/)

I think this would fit for a page like that (at least initially)

-Brian


On Mon, Jan 6, 2014 at 1:58 PM, Les Hazlewood <[hidden email]> wrote:

> Hi Brendan!
>
> Thanks for the notice!  I use Guava from time to time myself and enjoy it.
>  I'm not sure yet if the dev team wants to undertake long term maintenance
> of this - I'd personally like to see Hazelcast be our recommended caching
> solution (it is Apache 2.0 licensed, which is ideal for Shiro), and it
> supports both embedded and clustered modes with full TTL/TTI support.
>  Until now, Ehcache was sort of the implicit recommended solution since we
> have out-of-the-box implementation, but in all honesty I'd personally like
> to drop it since it is LGPL (we don't modify or subclass any of their
> classes, so we're safe to use it in an Apache project, but there is that
> gray area that would be nice to just remove entirely).
>
> In any event, this is all of course open for discussion, but the best thing
> to do to ensure your request isn't lost is to open a Shiro Jira issue and
> link the issue to your GitHub project (or wherever else it might be
> located) or attach a patch, and then we can discuss it.
>
> Thanks again! I look forward to your participation!
>
> Best,
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
>
> On Mon, Jan 6, 2014 at 7:27 AM, Brendan Le Ny <[hidden email]> wrote:
>
> > Hi everyone (new subscriber here),
> >
> > For my current project, I've just made an implementation of CacheManager
> > based on Guava.
> >
> > At first, i was using MemoryConstrainedCacheManager but it seems to
> retain
> > data in cache for too long for me.
> >
> > I've seen others implementation (ehcache, terracotta) but these
> > dependencies are too large, i don't need all those features.
> >
> > So i created mine, based on Guava caches [1]. It's convenient to me since
> > it's in-memory and thread-safe, Guava has a mature quality code base and
> it
> > support few tweaking options (sufficient to me):
> >
> >     concurrencyLevel
> >     initialCapacity
> >     maximumSize
> >     maximumWeight
> >     expireAfterAccess
> >     expireAfterWrite
> >     refreshAfterWrite
> >     weakKeys
> >     softValues
> >     weakValues
> >     recordStats
> >
> > I've already programmed the whole thing (two little classes) and I was
> > wondering if the Shiro team would be interested to integrate this as a
> new
> > module. It's tiny (no dependency except guava and shiro-cache), it could
> be
> > just near ehcache support and be convenient for people who don't have big
> > caching issues.
> >
> > It's not perfect but i did some Javadoc, followed your code-style, made a
> > minimalistic pom.xml.
> >
> > [1] https://code.google.com/p/guava-libraries/wiki/CachesExplained
> >
> > --
> > Brendan Le Ny, Code Lutin
> > [hidden email]
> > (+33) 02 40 50 29 28
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Brendan Le Ny
In reply to this post by Les Hazlewood-2
Hi,

Le 06/01/2014 19:58, Les Hazlewood a écrit :
> Thanks for the notice!  I use Guava from time to time myself and enjoy it.
>   I'm not sure yet if the dev team wants to undertake long term maintenance
> of this - I'd personally like to see Hazelcast be our recommended caching
> solution (it is Apache 2.0 licensed, which is ideal for Shiro), and it
> supports both embedded and clustered modes with full TTL/TTI support.

In my opinion, Hazelcast (or Ehcache) should not be the first solution
to come to mind as the recommended solution.

Here is why :
* 80% of Shiro users won't need a cache (because small user base or less
than 10 simultaneous user on the system, or permissions change to often
and must be computed each time)
* In the remaining 20%, 80% will need a cache, but a trivial in-memory
one will be more than sufficient
* On the remaining 20% (of the 20%) who will need a big cache, i would
recommend an out-of-JVM in-memory cache, memcached in damn simple to
install, Amazon provide support for GB-sized memcached instances.

(I didn't made any stats, just my experience about the project I had to
work on.)

Ehcache, Terracota are such solution are a last resort (admin cost...)
So, i think people who will *really* need to use a big java-ish solution
like ehcache or terracota (with clusters, replication through JMS, etc.)
are a minority and as such, should be considered but not the main
concern. (i don't know the english idiom but in french, i'd say "a
cannon to kill a fly")

The main concern should be the 80% and providing light implementations
of CacheManager would be a big plus to Shiro.

I've refactored the whole thing (now extending
org.apache.shiro.cache.AbstractCacheManager) and now it takes a single
class with two methods.

Also, Guava is now a common dependency you will find in most of the
project, just like Apache Commons so providing a Guava support is now a
common feature. Thus, Guava is already declared and used in Shiro, so it
wouldn't add any dependency.

So, in my opinion, we could just put this CacheManager implementation in
shiro-core or in shiro-cache module (because it's absurd to add a module
for a single class that don't add any dependency).

 >   Until now, Ehcache was sort of the implicit recommended solution
since we
 > have out-of-the-box implementation, but in all honesty I'd personally
like
 > to drop it since it is LGPL (we don't modify or subclass any of their
 > classes, so we're safe to use it in an Apache project, but there is that
 > gray area that would be nice to just remove entirely).

LGPL in not a problem, if you subclass a class, you have to put it in a
separate module and distribute this module as LGPL but keep Shiro under
Apache Licence. But I understand you worrying.

> In any event, this is all of course open for discussion, but the best thing
> to do to ensure your request isn't lost is to open a Shiro Jira issue and
> link the issue to your GitHub project (or wherever else it might be
> located) or attach a patch, and then we can discuss it.

Will see to create an issue.

> Thanks again! I look forward to your participation!

Thank you too.

--
Brendan Le Ny, Code Lutin
[hidden email]
(+33) 02 40 50 29 28
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Brendan Le Ny
In reply to this post by Brian Demers
Hi Brian,

Le 07/01/2014 15:40, Brian Demers a écrit :
> I agree with Les with being cautious about long term support.

I totally agree with you, any code commited should be viewed as the long
term cost of its maintenance. We are talking of single class, so i think
there won't be any maintenance to do.

Also, Guava cache API is no longer annotated @Beta so the API should not
change so it's now safe to consider the maintenance cost will be minor.

 > However, I
> noticed we do not have a 'third-party' library page.
> (Lots of projects do this, but here is an example that sticks out in my
> mind: http://metrics.codahale.com/manual/third-party/)
>
> I think this would fit for a page like that (at least initially)

If we don't integrate support in Shiro, i will publish it on nuiton.org,
it's a forge for java libraries maintained by my company which nexus
repo is synchronized on central.

My company/nuiton.org policy is to publish under LGPL so it may be a
concern. I may ask to my company to publish under the same license as Shiro.

A third-party page is good idea :)

Thanks for your answer.

--
Brendan Le Ny, Code Lutin
[hidden email]
(+33) 02 40 50 29 28
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Les Hazlewood
Administrator
In reply to this post by Brendan Le Ny
>
> Thanks for the notice!  I use Guava from time to time myself and enjoy it.
>>   I'm not sure yet if the dev team wants to undertake long term
>> maintenance
>> of this - I'd personally like to see Hazelcast be our recommended caching
>> solution (it is Apache 2.0 licensed, which is ideal for Shiro), and it
>> supports both embedded and clustered modes with full TTL/TTI support.
>>
>
> In my opinion, Hazelcast (or Ehcache) should not be the first solution to
> come to mind as the recommended solution.
>

I think you might be confused by Hazelcast's capabilities.

Hazelcast can easily run in the same process-space (in-memory) as your
application, and it's a java .jar file - no 'installation' necessary.
 Deployed this way (as a simple .jar file included in your app), Hazelcast
is effectively the same as a Guava cache: they're both single-JVM/in-memory
and both lightweight.  To put it another way, Hazelcast and Guava are
(effectively) equal choices in this deployment mode.

But here is why Hazelcast can be better than Guava, especially as a default
cache solution:  the instant you decide you need to move beyond simple
in-memory/in-process caching, you just have to 'turn on' Hazelcast's
clustering.  You will instantly have a clustered cache, and you didn't have
to change anything in your app other than some config.  Guava cannot do
this.

This is why I personally think Hazelcast is a better default offering for
Shiro's community: it is Apache licensed and it satisfies the needs of our
entire community, from small, single-JVM applications to the largest
distributed clustered SaaS web applications.

Additionally, by being able to use the same cache mechanism, regardless of
the size of your application, you can become proficient with one cache
mechanism and use it in any situation - no need to learn 1 caching product
for situation X and another caching product for situationY.  Oh, and
Hazelcast can serve the Memcache protocol so memcache clients work with it
too (if you require that) :)


> Ehcache, Terracota are such solution are a last resort (admin cost...)



> >   Until now, Ehcache was sort of the implicit recommended solution since
> we
> > have out-of-the-box implementation, but in all honesty I'd personally
> like
> > to drop it since it is LGPL (we don't modify or subclass any of their
> > classes, so we're safe to use it in an Apache project, but there is that
> > gray area that would be nice to just remove entirely).
>
> LGPL in not a problem, if you subclass a class, you have to put it in a
> separate module and distribute this module as LGPL but keep Shiro under
> Apache Licence. But I understand you worrying.


Shiro is fully compliant with the ASF's requirements regarding LGPL (we
don't subclass or implement any LGPL interfaces or classes - we just invoke
them, and this is allowed by the ASL).  However, if we can avoid LGPL
entirely and use an equally powerful / feature-rich Apache-licensed
project, it's a simple choice for an Apache project to use the
ASL-versioned dependency instead of the LGPL one; it is just 'safer', and
less for the dev team to worry about (especially as it regards long-term
maintenance).

Thanks again for your continued feedback - you help make the community
stronger!

Best,

Les
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Brendan Le Ny
Hi Les,

Le 12/01/2014 03:14, Les Hazlewood a écrit :
> Hazelcast can easily run in the same process-space (in-memory) as your
> application, and it's a java .jar file - no 'installation' necessary.
>   Deployed this way (as a simple .jar file included in your app), Hazelcast
> is effectively the same as a Guava cache: they're both single-JVM/in-memory
> and both lightweight.  To put it another way, Hazelcast and Guava are
> (effectively) equal choices in this deployment mode.

Nice. If Hazelcast allows such an embedded mode, it's a good solution to
go and Guava implementation should not be provided :-)

> But here is why Hazelcast can be better than Guava, especially as a default
> cache solution:  the instant you decide you need to move beyond simple
> in-memory/in-process caching, you just have to 'turn on' Hazelcast's
> clustering.

I understand your point of view. Actually, I'm just usually more
skeptical than necessary when one talk me about a solution that seems to
fit the needs "whatever they are". But I must admit I didn't gave any
chance to such solutions about caching: i'll try to drop an eye on
Hazelcast soon.

Thank you for opinion.

Regards.

--
Brendan Le Ny, Code Lutin
[hidden email]
(+33) 02 40 50 29 28
Reply | Threaded
Open this post in threaded view
|

Re: A Guava-based CacheManager implementation

Brendan Le Ny
In reply to this post by Les Hazlewood-2
Le 06/01/2014 19:58, Les Hazlewood a écrit :
> In any event, this is all of course open for discussion, but the best thing
> to do to ensure your request isn't lost is to open a Shiro Jira issue and
> link the issue to your GitHub project (or wherever else it might be
> located) or attach a patch, and then we can discuss it.

Hi Les,

Here it is:

https://issues.apache.org/jira/browse/SHIRO-481

Regards.

--
Brendan Le Ny, Code Lutin
[hidden email]
(+33) 02 40 50 29 28