Update cache SPI and resource serialization #92
Conversation
There was a problem hiding this comment.
Thank you @wzy1935 , I've added another batch of comments
Can you also add a test that verifies the behavior of a shared cached? That is, if it has stored a response for a one reverse proxy instance, another proxy instance will not have to contact the backend.
|
Can you please rebase this PR? Thank you |
|
|
||
| @Override | ||
| public Future<Void> close() { | ||
| return Future.succeededFuture(); |
There was a problem hiding this comment.
We didn't talk about clearing the map on close, did we? Would it be necessary in your opinion?
There was a problem hiding this comment.
Personally I also think there's no need, but when I called the vertx.createSharedResource() in ReverseProxy#newCache, there's a closeFuture that I don't know how to deal with it.
Maybe you could check if the following would work? I think I should change to this version:
// ReverseProxy#newCache
public Cache newCache(CacheOptions options, Vertx vertx) {
if (options.getShared()) {
CloseFuture closeFuture = new CloseFuture();
return ((VertxInternal) vertx).createSharedResource("__vertx.shared.proxyCache", options.getName(), closeFuture, (cf_) -> {
Cache cache = new CacheImpl(options);
return cache;
});
}
return new CacheImpl(options);
}There was a problem hiding this comment.
The close future is not bound to anything, neither Vert.x nor the context. Take a look at how Vert.x creates shared http clients, or shared Vert.x SQL Clients, shared Kafka Producers
Closes #67
Updated the cache SPI and added serialization for the
Resourceclass.