Hi Mridul,
I appreciate your work (a lot of work) and that you bring things
forward. Really.
But: I am concerned that we rush to remove core features for enterprise
application operation like the distributed cache clear mechanism.
It is switched off by default because it does not make sense to have it
activated in a single instance environment which is the default.
It is NOT an experimental feature like some of the other cases you
removed and we have used it in custom projects in a cluster environment.
We should at least have a proper discussion about it with enough time.
The amount of news in our mailing list and the different topics are hard
to follow besides $daywork and I think we should give everyone enough
time to think and discuss. There were only 10 days between your first
proposal and the execution of the task.
Maybe also better in different threads with clear subjects instead of
buried inside longer emails.
I would appreciate if you can bring back the current solution. We should
also discuss why we should remove the old while introducing a new one
(like you proposed below).
I am not sure about the other removals. It might be that users who use
them are in the same boat here and had not enough time to react.
Thanks and best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 12.11.26 um 15:29 schrieb Mridul Pathak via dev:
Hi all,
With the JMS service engine removed, OFBiz no longer has a way to clear
caches across servers that share a database. I would like to propose a
replacement.
The old approach also had two flaws worth fixing: it sent the cache clear
before the transaction committed, so another server could re-cache the old
value, and it sent Java-serialized entity values over the wire.
The proposal, in phases, each with its own JIRA and PR:
1. A small cache SPI in the framework, with Caffeine as the default local
cache in place of concurrentlinkedhashmap. UtilCache stays the API callers
use, cache settings move into each component's ofbiz-component.xml, and a
few UtilCache internals are tidied.
2. An invalidation bus in the framework that publishes small key-only JSON
messages after commit. Without a bus, a single server behaves exactly as
today.
3. A Redis/Valkey plugin that provides the bus.
4. Later, if needed: a near cache through Redis client-side caching, and a
JCache bridge.
I chose a small OFBiz SPI over JCache because JCache has not changed since
2019, is not part of Jakarta EE, and has no notion of invalidation or near
caching, which is what this needs. A JCache bridge can still be added as a
provider.
I would appreciate your thoughts, especially from anyone running OFBiz on
more than one server.
Thanks,
Mridul Pathak
