Hi Mridul,
I forgot: what would be the reasoning to replace the JMS based cache
clear mechanism with the solution you propose?
What are the chances and risks?
Thanks you,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 12.11.26 um 18:41 schrieb Michael Brohl:
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
