Add cache layer support about ninja

[raphaelbauer]

Play is a good role model:

Memcached configuration

~~~~~

Enable memcached if needed. Otherwise a local cache is used.

memcached=enabled

Specify memcached host (default to 127.0.0.1:11211)

memcached.host=127.0.0.1:11211

Or you can specify multiple host to build a distributed cache

memcached.1.host=127.0.0.1:11211

memcached.2.host=127.0.0.1:11212

[zoza]

i suggest to use guava cache
http://code.google.com/p/guava-libraries/wiki/CachesExplained

for local cache is already done and perfect, and later, i will impl hazelcast and\or memcache storage for distributed cache.

probably need to create some NinjaCacheManager class

[raphaelbauer]

Hi zoza,

I would closely model it after an interface from Play 1:
https://github.com/playframework/play/blob/master/framework/src/play/cache/Cache.java

Then we can use different Cache Implementations under the hood. The guava cache is for sure a pretty good idea if the cache should live on one machine. In other cases EhCache might be useful...

But a must is memcached - especially when scaling up the instances...

Cheers,

Raphael

[zoza]

Play cache is very simple delegate interface. For low level usage it's
mandatory.
But in addition, I was thinking about some annotations based cache like
spring has. (For controller.action or any method cache)
15.02.2013 11:53 пользователь "reyez" [email protected] написал:

Hi zoza,

I would closely model it after an interface from Play 1:

https://github.com/playframework/play/blob/master/framework/src/play/cache/Cache.java

Then we can use different Cache Implementations under the hood. The guava
cache is for sure a pretty good idea if the cache should live on one
machine. In other cases EhCache might be useful...

But a must is memcached - especially when scaling up the instances...

Cheers,

Raphael

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-13599632.

[zoza]

Also please look at hazelcast
15.02.2013 11:53 пользователь "reyez" [email protected] написал:

Hi zoza,

I would closely model it after an interface from Play 1:

https://github.com/playframework/play/blob/master/framework/src/play/cache/Cache.java

Then we can use different Cache Implementations under the hood. The guava
cache is for sure a pretty good idea if the cache should live on one
machine. In other cases EhCache might be useful...

But a must is memcached - especially when scaling up the instances...

Cheers,

Raphael

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-13599632.

[zoza]

i started to implement

[raphaelbauer]

On Wed, Mar 13, 2013 at 4:37 PM, Anatoly [email protected] wrote:

i started to implement

cool :) please post really early and really often so we can discuss stuff...

I'd really love to see:

1. An interface like http://www.playframework.com/documentation/1.2.5/cache
2. Different implementations for the interface (EhCache would be my
   favorite for now)

Binding the interface with the implementation is of course done simply via
guice...

Cheers!

Raphael

[zoza]

as a concept it will be as play 1 cache.
I'm planing to implement 3 basic backends: memcache, ehcache and hazelcast

i want to create 1 maven project (jar at the end): cache-manager with
basic impls (without any deps for ninja or guice)
1 maven project: cache-manager-guice with annotations and guice aop (like
spring cache)

Binding the interface with the implementation is of course done simply via
guice...
yes, only interface CacheManager that binded to SomeImplCacheManager as
singleton

On Wed, Mar 13, 2013 at 10:41 PM, reyez [email protected] wrote:

On Wed, Mar 13, 2013 at 4:37 PM, Anatoly [email protected] wrote:

i started to implement

cool :) please post really early and really often so we can discuss
stuff...

I'd really love to see:

1. An interface like
   http://www.playframework.com/documentation/1.2.5/cache
2. Different implementations for the interface (EhCache would be my
   favorite for now)

Binding the interface with the implementation is of course done simply via guice...

Cheers!

Raphael

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-14867161
.

[raphaelbauer]

On Wed, Mar 13, 2013 at 11:03 PM, Anatoly [email protected] wrote:

as a concept it will be as play 1 cache.
I'm planing to implement 3 basic backends: memcache, ehcache and hazelcast

i want to create 1 maven project (jar at the end): cache-manager with
basic impls (without any deps for ninja or guice)
1 maven project: cache-manager-guice with annotations and guice aop
(like
spring cache)

Binding the interface with the implementation is of course done simply
via
guice...
yes, only interface CacheManager that binded to SomeImplCacheManager as
singleton

sounds perfect :)

cheers,

raphael

[raphaelbauer]

Once that is up and running it should be really simple to cache the response of a controller method via a filter like:
@FilterWith(PageCache.impl)

:)

[zoza]

no, its not.. :)
that about eviction??
if i change something (with another method) that change the response ????
also, what about a cache key (method params) ??

On Thu, Mar 14, 2013 at 10:47 AM, reyez [email protected] wrote:

Once that is up and running it should be really simple to cache the
response of a controller method via a filter like:
@FilterWith(PageCache.impl)

:)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-14891829
.

[zoza]

first commit:
https://github.com/zoza/cache-manager

[raphaelbauer]

On Thu, Mar 14, 2013 at 11:55 AM, Anatoly [email protected] wrote:

first commit:
https://github.com/zoza/cache-manager

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-14896359
.

looks good to me :)

[zoza]

im just now comited some code
please look closely, if you have any comments

On Thu, Mar 14, 2013 at 6:48 PM, reyez [email protected] wrote:

On Thu, Mar 14, 2013 at 11:55 AM, Anatoly [email protected]
wrote:

first commit:
https://github.com/zoza/cache-manager

—
Reply to this email directly or view it on GitHub<
https://github.com/reyez/ninja/issues/22#issuecomment-14896359>
.

looks good to me :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-14914069
.

[zoza]

few questions:
about increment\decrement:
i can implement that you need to call put method before (to init the counter) or null will returned
or add some putIfAbsent inside the incr method, that will actually work only first time (call) (but a little slow)

also about exceptions:
throw ex in case of error (and define them in methods) or throw runtime ex or return null ???

[raphaelbauer]

On Sun, Mar 17, 2013 at 3:32 PM, Anatoly [email protected] wrote:

few questions:
about increment\decrement:
i can implement that you need to call put method before (to init the
counter) or null will returned
or add some putIfAbsent inside the incr method, that will actually work
only first time (call) (but a little slow)

also about exceptions:
throw ex in case of error (and define them in methods) or throw runtime ex
or return null ???

Hi Anatoly,

I did not use the increment decrement functionality myself. I would just
mimic how Play (or Rails) handles it.

Regarding exceptions => I'd also mimic the behavior of Play. The good thing
is that a user should never ever rely on a cache to work. So returning null
should be always okay...

Cheers,

Raphael

[zoza]

im comited some code
please look closely, if you have any comments

[raphaelbauer]

On Fri, Mar 29, 2013 at 4:00 PM, Anatoly [email protected] wrote:

im comited some code
please look closely, if you have any comments

Hi zoza,

I'll have a look next week. Sorry, I am a bit busy right now :(

Thanks!

Raphael

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-15644488
.

inc: http://ars-machina.raphaelbauer.com
tech: http://ars-codia.raphaelbauer.com
web: http://raphaelbauer.com

[raphaelbauer]

1. I'd change the package to something more detailed... (Yes - I know ninja also has only "ninja", but it is usually bad pratice - especially with a generic "cache"...)
2. Do you plan to release the project to maven central?
3. In what projects do you intend to use the cache manager? => Will the
   library be maintained a bit? Because if you want we could move it (with
   guice binding I guess) to Ninja as well...
4. Why not use simple classes and interfaces and bind them via guice?
5. I'd need something to customize stuff further. eg "/memcache.ini" and so
   on => In reality this should come from NinjaProperties (in case of ninja).
   => Therefore a guice provider would be cool again.. :)

Just my quick remarks. I really like what I see - (testcases hooray!) Good
work!

Best,

Raphael

[zoza]

1. no problem. see 2 and 3
2. no. you do. :) (as part of ninja)
3. i think, we need to add this as maven jar (ninja-cache) to ninja like ninja-servlet
4. that what i'm done, no?? or explain... (see https://github.com/zoza/cache-manager-guice)
5. no problem. the only thing i want -- cache-manager should be configured and work easily without ninja and cache-manager-guice with any guice app. (as maven dep)
   => Therefore a guice provider would be cool again.. :) => see https://github.com/zoza/cache-manager-guice

[raphaelbauer]

Hi zoza,

If you want to independently use the lib you should put it under your own namespace and upload it to the maven repo. We can then use that for ninja.

Ninja ideally would only use simple interfaces (ninja.cache or so) that are then bound to your cache manager.

We can also integrate that into Ninja like what you proposed with ninja-servlet. We could also host it as external library (something like https://github.com/reyez/ninja-ebean).

To sum it up: Just fork Ninja and integrate it the way you want :) We can discuss stuff then :)

Best,

Raphael

[raphaelbauer]

cache layer now integrated via ehcache and memcached