Cache APIs and async

[Stephen Couchman]

Hi,

I've been a user of Play for a couple years now and I've found myself deliberately ignoring the Play Cache API more often than using it thanks to its blocking interface.

I understand of course that being cache, the assumption that is any given operation should complete quickly, but anything short of an in-memory cache is bound to involve external IO of some sort, if only across a local socket to memcached or redis, or similar, and for duration it would block that processing thread entirely.

I'm assuming this was given consideration before, so for my own education, I thought I'd inquire about the decision to restrict the Cache API to blocking calls.  Was the overhead of of creating a pre-completed future (using Future.successful etc) considered too high for in-memory cache?  Or was it too significant a barrier to entry?  Or perhaps the possible re-queueing of the cashe result into the worker queue causes too much delay before a response that could have been served entirely from cache could be sent out?

Obviously this is all idle speculation.

I hope this hasn't been addressed too recently, though I didn't dredge up anything with a few preliminary searches.

Thanks for any insight you can offer.

[James Roper]

Hi Stephen,

No one that is currently actively maintaining Play was around when the cache API was first written, so we can only speculate.

I guess that it is due to zero or more of the following reasons:

* The API is backed by ehcache by default, which is blocking

* The API was copied from/based on the cache API from Play 1, which was blocking

* There wasn't enough time to come up with a decent non blocking API and implementation

It could be all three, I don't know.  But I am quite sure that there was no good technical reason for it to be blocking.

We could rewrite it to be non blocking, that would be a good thing to do.  But it's not high on our priorities, the fact is, for in memory caching, it's not hard to use spray-cache, you don't need an abstraction around it to use it in Play.  For off heap caching, it's not hard to use any of the many non blocking redis or memcached java or scala drivers, you don't need an abstraction around them to use them in Play.  If someone in the community were to decide to take on the task of writing a non blocking abstraction for caching in Play and provide a half decent in heap and off heap implementation for it, then we'd probably accept it.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Will Sargent]

I like the API used by Scalacache myself:

https://github.com/cb372/scalacache/blob/master/core/src/main/scala/scalacache/Cache.scala

Unfortunately, because Scalacache depends on 2.11.x, it can't be passed in with Play itself (although Play applications certainly can use it).

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala