Hi Michael, Thank you, that sounds reasonable to me. I'll bring back the JMS service engine and the JMS cache clearing on trunk, mark them deprecated for 26.11, log a warning when they are enabled, and add a note to UPGRADING.md.
The new mechanism will plug into the same delegator setting, so users can choose between JMS and the new bus by configuration. I'll aim to have the new mechanism in 26.11 alongside JMS, so users can migrate during that release, and we remove JMS for the following stable branch as you suggest. Thanks, Mridul Pathak On Sat, Nov 14, 2026 at 5:19 PM Michael Brohl <[email protected]> wrote: > Hi Mridul, > > thank you for your detailed analysis and explanations. I generally agree > with your points and support the migration to a more modern cache > clearing mechanism. > > How about we mark JMS as deprecated for the next stable branch (26.11) > and make the use of JMS / the new mechanism configurable? > We would then remove JMS for the following stable branch. > > That would give users enough time to prepare and migrate their > infrastructure from JMS to the new mechanism. > > What do you think? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 13.11.26 um 16:56 schrieb Mridul Pathak via dev: > > Hi Michael, > > > > Thank you for raising this. I understand the pace has been hard to follow > > alongside day work. The reason for doing it now is the 26.11 branch: > > whatever goes into it stays for the life of that release, and the next > > chance to drop it would be the following major release. > > > > The aim is to bring cache clustering in line with how current Java > > applications do it, rather than carry the JMS mechanism forward into > > another major release. On why to replace it rather than keep it: > > > > - It isn't how distributed caches are built today. Hibernate with > > Infinispan, Hazelcast-based setups, Redis-based setups and Moqui all > clear > > caches across servers over JGroups, Hazelcast topics or Redis pub/sub. > None > > of them uses JMS; Ehcache 2 offered JMS replication, and Ehcache 3 > clusters > > only through a Terracotta server. > > - It sends the clear before the transaction commits, so another server > can > > reload the old row and cache it again before the change is visible. > > - It sends whole entity values as serialized objects, the kind of payload > > behind the deserialization fix we made to the JMS listener in April. > > - It is built on the JMS 1.1 API from 2002, while current brokers such as > > ActiveMQ Classic 6 use jakarta.jms. Moving it to jakarta.jms would only > > update the API; the timing and serialization problems would stay. > > > > Benefits: > > > > - Clears are sent after commit and carry only keys, so there is no stale > > re-caching and nothing to deserialize. > > - Caffeine replaces concurrentlinkedhashmap, which is no longer > maintained; > > Caffeine is its successor from the same author, and the local cache > Spring > > Boot, Quarkus and Micronaut support out of the box. > > - Each component declares its own caches in its ofbiz-component.xml, > > checked by the schema, instead of one shared cache.properties. > > - Redis/Valkey is infrastructure many teams already run, with TLS and > > access control built in, and it leaves room for a shared near cache > later. > > - The bus is pluggable, so other transports can be added, including a JMS > > one if someone needs it. > > - A single server behaves exactly as today. > > > > Risks: > > > > - It is new code in the cache path every component uses. The first step > > only moves UtilCache onto the new interface, with no change in behaviour, > > and goes in as its own pull request so it can be reviewed and tested > before > > anything builds on it. > > - It hasn't run in a real cluster yet, so it needs people who run > clusters, > > like you, to try it. > > > > If you or others need cross-server cache clearing on trunk before the > > replacement is ready, I'll bring the JMS mechanism back until then. > > > > Thanks, > > Mridul Pathak > > > > On Thu, Nov 12, 2026 at 11:25 PM Michael Brohl <[email protected] > > > > wrote: > > > >> 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 > >>>> >
