Hi, could you try calling RemoteCache.withDataFormat(...).get(...) and provide the webapp-specific value marshaller directly instead of loading that from thread-local?
Thanks for that suggestion. It could work, but as I understand it, I would need to do the following before each call to cache.get:
DataFormat.Builder builder = new DataFormat.Builder();
SpecialWebappMarshaller marshaller = new SpecialWebappMarshaller();
That's a lot of object creation before every single get(). Am I missing a more efficient technique? BTW, I would also need to implement the above code via reflection, because a) we only use the BasicCache api to interact transparently both with a remote or embedded cache and b) I need this work with both 9.1.0 and 9.4.0.
Creating the DataFormat on each invocation would be inefficient, of course. I misread your first post, thinking that you store webapp-specific info in thread-local variable - who sets the thread context class loader in your case, is it the webapp container (WildFly, Tomcat...) or your code? Could you store the DataFormat in a ThreadLocal field? (notice the withInitial() static method). Even better approach would be to store the resulting BasicCache instance because each withDataFormat() creates a wrapping instance. Especially since you need to cope with multiple versions, your code probably needs some level of indirection. Rather than reflection I would recommend polymorphic implementations in modules based on your dependencies.
The reason everything happens now in the async thread pool is because seeing the limitations with blocking invocations in a distributed environment Infinispan goes to async-by-default, and the .get(key) is just a convenience method on .getAsync(key).join(). In the past it was the other way, .getAsync() just executed .get() in a limited thread-pool which could get depleted very fast, and such invocation also used more thread context switches. Future APIs will encourage reactive programming model even more (though often providing convenience classes that do the CompletableFuture.join() for user).