Vert.x is great, but one thing that os missing is ...

# vertx

[dave08]

Vert.x is great, but one thing that os missing is cache that expires older entries and can be reset... Or maybe I missed something?

[julienviet]

what kind of cache are you referring to ? do you mean a data cache like an AsyncMap ?

[dave08]

Like this: https://cache2k.org/docs/1.0/user-guide.html#getting-started

[dave08]

But if I use that, I'll have a cache for each verticle instance running... when I really want a global cache for all instances of that verticle

[dave08]

Or even something similar to Spring's caching facility, I guess it could be implemented on the SharedData in Vert.x somehow...

[dave08]

Also, it might be sufficient to have an LRU on SharedData...

[julienviet]

I think that SharedData does not want to be a cache, however a cache component for Vert.x would be a great thing I think, it could be implemented by cache2k or ehcache

[julienviet]

I think for the moment however we should be pragmatic and test how cache2k works with Vert.x and come up with examples / recommandations

[julienviet]

perhaps you can try to use cache2k and make experiments to see how it goes ?

[julienviet]

and we can see if that works well or not

[dave08]

@julienviet I probably will, but I still don't see what the problem would be with SharedData, it would allow cross-vertx instance cache...

[julienviet]

to be honnest, the main issue I see is that if we start to make it like a cache, then we will need to have more and more caching features in it and it will gain in complexity + features and I thin kit's not the scope of vertx core

[julienviet]

that's my main opinion

[julienviet]

now I think that some people asked to have a TTL on SharedData

[dave08]

@julienviet I think TTL would probably cover alot of use cases... I don't want to requery the db for info that tons of requests commonly need, but it needs to expire periodically to be fresh...

[julienviet]

actually AsyncMap has TTL

[julienviet]

void put(K k, V v, long ttl, Handler<AsyncResult<Void>> completionHandler);

[dave08]

@julienviet Nice! I'll check it out (although the AsyncMap is a bit harder to work with... maybe a coroutine extension function will take care of that...)

I guess another useful feature would be a limited space LRU, but maybe that's too much? Because, sometimes TTL with lots of requests for different types of info could fill up memory with cache data that might not always be reused... but TTL is already great!

Why is TTL only in AsyncMap?

[julienviet]

have you tried coroutines ?

[julienviet]

LocalMap is not a cache and AsyncMap neither is

[julienviet]

that's the point

[julienviet]

otherwise it would be io.vertx.cache package

[julienviet]

imho we should investigate how Vert.x works well with Cache2k

[julienviet]

that's a real cache 🙂

[julienviet]

and eventually comes with a Vert.x Cache facade to improve things

[dave08]

@julienviet I'm currently using your coroutine extension with my own extension function that I'll offer to the project when I get enough of them together..😉

[julienviet]

great!

[dave08]

@julienviet Why do you think cache2k would not work with vert.x?

[julienviet]

I think after 3.5 we should rework the current vertx lang integration and make it happen outside of Vert.x projects so it's easier to contribute specific kotlin extensions

[dave08]

Also it would be nice to turn all your delegate classes (like rx) into extension functions, it just adds complexity... and its not Kotlinish 🤓

[dave08]

@julienviet How would cache2k work through multiple verticle instances, is there a way to do this currently? Maybe putting the whole cache in a SharedData?

[julienviet]

that's something to investigate

[julienviet]

for Rx, we cannot make extension classes for Java

[julienviet]

that's unfortunate