simonedeponti / play26-lettuce Goto Github PK

View Code? Open in Web Editor NEW

2.0 2.0 1.0 49 KB

Redis cache plugin for Play 2.6, based on lettuce

License: BSD 3-Clause "New" or "Revised" License

Scala 100.00%

lettuce scala play-framework playframework play26 redis play-cache async sync java

play26-lettuce's Introduction

play26-lettuce

A Redis cache plugin for Play 2.6+, based on lettuce (https://lettuce.io/).

It does support Scala (2.12 and 2.11) and Java AsyncCacheApi and SyncCacheApi.

It supports SSL, and therefore is suitable for use with Azure Redis Cache.

Usage

Add dependency to sbt (along with the resolver to BinTray):

libraryDependencies += "com.github.simonedeponti" %% "play26-lettuce" % "1.0.0"

resolvers ++= Seq(
  "simonedeponti-bintray" at "https://dl.bintray.com/simonedeponti/maven"
)

Enable the module:

# Enable redis cache plugin
play.modules.enabled += "com.github.simondeponti.play26lettuce.LettuceModule"

Then (optionally) enable Kryo serialization, by adding:

libraryDependencies += "com.twitter" %% "chill-akka" % "0.9.3"
libraryDependencies += "com.twitter" % "chill-java" % "0.9.3"

And then adding in you configuration something like this:

akka {
  actor {
    kryo {
      idstrategy = default
      resolve-subclasses = true
    }
    serializers {
      java = "akka.serialization.JavaSerializer"
      kryo = "com.twitter.chill.akka.AkkaSerializer"
    }

    serialization-bindings {
      "scala.Product" = kryo
      "scala.None" = kryo
      "scala.Some" = kryo
      "scala.collection.Seq" = kryo
      "scala.collection.Map" = kryo
      "my.custom.Class" = kryo
      "java.io.Serializable" = kryo
    }
  }
}

Configuration

After doing all of the above, one must set the redis endpoint for each cache by specifying lettuce.$cachename.url:

play.cache {
  defaultCache = "default"
  bindCaches = []
}

lettuce.default.url = "redis://localhost/0"

If you need additional caches, put them into bindCaches and then create the corresponding lettuce.$cacheName.url config key.

Never specify the exact same URL for two caches: please use different databases to separate them

Correct example:

play.cache {
  defaultCache = "default"
  bindCaches = ["users"]
}

lettuce.default.url = "redis://localhost/0"
lettuce.users.url = "redis://localhost/1"

Wrong example (the two caches might have key conflicts, and will throw an error upon start):

play.cache {
  defaultCache = "default"
  bindCaches = ["users"]
}

lettuce.default.url = "redis://localhost/0"
lettuce.users.url = "redis://localhost/0"  # Same URL, everything explodes in a ball of fire.

Optionally, for each cache, a timeout can be set for syncronous wrappers:

lettuce.default.syncTimeout = 3s

History

v1.0.0

Added multiset/multiget support in custom interface (dominics)
No configuration silently exports no bindings (dominics)
Better support for multiple caches without using KEYS command but mandating separated databases for different caches

v0.2.3

Timeout for sync wrappers is configurable

v0.2.2

More robust serialization

v0.2.1

Cross building scala 2.12 & 2.11

v0.2.0

Added support for Scala sync API
Added support for Java API (sync & async)

v0.1

Initial version

play26-lettuce's People

Contributors

Stargazers

Watchers

Forkers

mebur

play26-lettuce's Issues

getOptional is not available

Play framework 2.7 is deprecating cache.get() in favor of cache.getOptional()

Can getOptional be added to the cache?

Binaries unavailable on jcenter

Hi @simonedeponti - this looks really useful.

Just a heads up that I'm unable to resolve the libs on jcenter.bintray.com after following the README and adding the resolver. SBT is looking for: http://jcenter.bintray.com/com/github/simonedeponti/play26-lettuce_2.12/0.2.3/play26-lettuce_2.12-0.2.3.pom (404 for me)

Support injecting the codec

LettuceClient accepts an injected ActorSystem, but instantiates its own AkkaCodec - this prevents changing the implementation of the AkkaCodec.

Given that creating the AkkaCodec is the only usage of the ActorSystem, I think the LettuceClient should just receive an injected AkkaCodec directly.

(The reason I'd like to inject an alternative AkkaCodec implementation is I'd like to do some monitoring of the serialized size of the cache entries)

Use of KEYS is discouraged

The removeAll method is implemented in terms of the KEYS command. This is discouraged because it'll block all use of the server for all other clients while it runs, causing latency for all the other named caches implemented for the same instance. Thus the advice from Redis upstream is:

Don't use KEYS in your regular application code

It'd be better to either:

Instead of implementing named caches as key-prefixed caches, require them to use separate connection settings e.g. database number. This still provides any number of databases per server instance (configurable with the databases config parameter), and also provides FLUSHDB allowing keys to be cleared without an expensive KEYS prefix* command to retrieve them first.

Implement removeAll in terms of a SCAN iteration

Providing access to the underlying RedisClient and/or implementing multi-key operations

Would you consider allowing (even just protected) access to the underlying Lettuce client instance (RedisClient) in one of the classes?

My motivation is to support MGET/MSET/MSETNX, somewhat similar to https://github.com/KarelCemus/play-redis/blob/25f0dca70bd8a610170b58d97c6b936dc9a83c0f/src/main/scala/play/api/cache/redis/CacheApi.scala#L24-L30 or https://github.com/KarelCemus/play-redis/blob/25f0dca70bd8a610170b58d97c6b936dc9a83c0f/src/main/scala/play/api/cache/redis/CacheApi.scala#L114-L133

Alternatively, we could directly support multiple-key operations on one of the extension interfaces (such as LettuceCacheApi and implement in LettuceClient)?