Any way to delay replicated-cache in infinispan from starting?

[Davy Koravand]

(WildFly 23)

I have the following situation:

- Two WildFly instances, clustered with jgroups

- The first one starts up, then an additional ear gets deployed after startup which puts something in the replicated-cache

- The second one starts up, but before the additional ear is deployed, it already initializes the replicated-cache which throws an error because the class in the cache does not exist yet

Caused by: org.jboss.modules.ModuleNotFoundException: deployment.myOtherModule.ear

So according to the documentation, the default mode for a replicated cache is 'LAZY'' (though this property is deprecated), which implies it should lazy load the first time it's being interacted with. But this is not true, it always starts up at the same time early on before I write or read anything.

This means that anything you put in the cache in an ear that starts later, will cause an error,  even if you don't even read from the cache until that ear is deployed. 

Is there anything I can do about this? There's no real way for me to realistically move the code to the ear that starts first. Is it a bug that it's not lazy loading the cache as one would expect?

[Paul Ferraro]

> So according to the documentation, the default mode for a replicated cache is 'LAZY'' 

You have a couple of options:

1. Upgrade to WF28.

On Friday, June 21, 2024 at 6:11:38 AM UTC-4 Davy Koravand wrote:

(WildFly 23)

I have the following situation:

- Two WildFly instances, clustered with jgroups

- The first one starts up, then an additional ear gets deployed after startup which puts something in the replicated-cache

- The second one starts up, but before the additional ear is deployed, it already initializes the replicated-cache which throws an error because the class in the cache does not exist yet

Caused by: org.jboss.modules.ModuleNotFoundException: deployment.myOtherModule.ear

So according to the documentation, the default mode for a replicated cache is 'LAZY'' (though this property is deprecated), which implies it should lazy load the first time it's being interacted with. But this is not true, it always starts up at the same time early on before I write or read anything.

According to which documentation?

In WildFly, caches defined within the infinispan subsystem are started on-demand, not lazily.  If a deployment requires a cache, it must first start it.

 

This means that anything you put in the cache in an ear that starts later, will cause an error,  even if you don't even read from the cache until that ear is deployed.

 

A newly started cache must receive state from other cluster members as part of the startup process - that is why it must be able to read cache entries before the application tries to read anything.

Is there anything I can do about this? There's no real way for me to realistically move the code to the ear that starts first. Is it a bug that it's not lazy loading the cache as one would expect?

The extent of your options depend on how your application obtains it reference to the server managed cache as well as the cache configuration itself.

Can you paste the relevant application code as well as your infinispan subsystem configuration?

Paul