Persistent caching of HTTP responses fails due to presence of non-serializable classes about play-ws HOT 5 CLOSED

Play-WS does not assume that you want to use Java serialization as your persistence mechanism. In fact, persistence isn't handled through Play-WS -- that's abstracted out to the HTTP cache trait, which is responsible for serialization:

https://github.com/playframework/play-ws/blob/master/play-ahc-ws-standalone/src/main/scala/play/api/libs/ws/ahc/cache/Cache.scala

So the problem here is that the ehcache cache has overflow to disk set to true:

https://github.com/grigoriy/play-ws-persistent-cache-bug/blob/master/source/main/resources/ehcache.xml

Instead, you can configure ehcache as follows:

https://playframework.com/documentation/2.6.x/WsCache

<ehcache
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
        name="play-ws-cache"
        updateCheck="false"
        >

	<cache name="play-ws-cache" maxEntriesLocalHeap="10000" eternal="false"
		timeToIdleSeconds="360" timeToLiveSeconds="1000" overflowToDisk="false" />

</ehcache>

from play-ws.

Thanks for the explanation. Could you consider it as a feature request or is it completely out of the scope of Play-WS? I am willing to participate in implementing this if needed. The use case is as follows: we want to use long-term on-disk HTTP cache, adhering to RFC 5861, 7232 and 7234, which would allow our application to reuse it after the application restarts. Do you think it is feasible without (Java) serializability of responses?

from play-ws.

Oh, it's totally feasible. It's not something I can do myself at this point, but it's an option -- that being said, the assumption right now is that the cache is in-memory and synchronous. You can see in the README there's an example of Caffeine being used:

https://github.com/playframework/play-ws#caching

One thing that would have to be added is that Cache would have to implement Future[T] so that you could have IO thread handling behind an asynchronous boundary: #133

For serialization, I'd probably use Kryo with Chill and setRegistrationRequired: https://github.com/twitter/chill / https://github.com/EsotericSoftware/kryo#registration as it'd be faster and inline with the JVM. If you're looking for a shared cache between programs, then personally I think Avro is the best overall choice.

from play-ws.

It'd be best if you could do it as an sbt subproject with a dependency on the AHC implementation. I didn't do any work to break out the cache implementation or API from AHC itself, so that's another possibility.

from play-ws.

Thanks for advice Will! I'll definitely consider the options you've mentioned. Closing. Cheers, Grigoriy.

from play-ws.