How to create Infinispan ClusteredLockManager in Wildfly? - locking

I have Wildfly 26.1.2 and Infinispan 13.0.10.Final.
We already have a cluster and Wildfly Infinispan subsystem with cache containers, transport, jgroups, and local caches.
Now we want to use clustered-locks, and I need to create ClusteredLockManager
If I read the manuals here
https://infinispan.org/docs/stable/titles/embedding/embedding.html
They say
// Set up a clustered Cache Manager.
GlobalConfigurationBuilder global = GlobalConfigurationBuilder.defaultClusteredBuilder();
// Configure the cache mode, in this case it is distributed and synchronous.
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.clustering().cacheMode(CacheMode.DIST_SYNC);
// Initialize a new default Cache Manager.
DefaultCacheManager cm = new DefaultCacheManager(global.build(), builder.build());
// Initialize a Clustered Lock Manager.
ClusteredLockManager clm1 =
EmbeddedClusteredLockManagerFactory.from(cm);
In the logs, I see it creates a NEW cluster with a default name (ISPN), and I need to put here all the configurations (at least with jgroups and transport), and duplicate them from the inifinispan-wildfly subsystems
But I don't want to do it because I already have configured cluster in my standalone-ec2-full-ha.xml file with Infinispan caches containers and managers and all that stuff
Can I somehow create my ClusteredLockManager using an already-defined configuration and infinispan-cluster from a standalone-ec2-full-ha.xml file?
Or can I define a config for ClusteredLockManager in my Wildfly subsystem?
And just inject it as a resource in Java Code
If I do something like
#Resource(name = "java:jboss/infinispan/container/cacheManager")
private EmbeddedCacheManager cacheManager;
...
ClusteredLockManager lockManager = EmbeddedClusteredLockManagerFactory.from(cacheManager);
It returns null. And the factory can create ClusteredLockManager only from cacheManager.
Are there any options for creating ClusteredLockManager using the existing cluster and wildfly-infinispan-subsystems configuration?

Related

setIndexedTypes seems to be ignored when the cache configuration is set with a template

I am getting the following exception when querying a cache
javax.cache.CacheException: Indexing is disabled for cache: DEFAULT. Use setIndexedTypes or setTypeMetadata methods on CacheConfiguration to enable.
The cache configuration is set using a template
// template for cache configurations
CacheConfiguration cacheCfg = new CacheConfiguration("cacheTemplate");
cacheCfg.setBackups(backups);
cacheCfg.setCacheMode(CacheMode.PARTITIONED);
cacheCfg.setIndexedTypes(Key.class, Payload.class);
ignite.addCacheConfiguration(cacheCfg);
Shouldn't that work? Or do I need to set the configuration explicitely, in which case, what is the point of having a template?

Trying to disable the metrics logging in Ignite but failed

Found that the Ignite Metrics logging is a bit excessive so decided to disabled it.
As indicated in the screenshot, it should be done by setting setMetricsLogFrequency to 0.
However, it does not work. Below is my code for creating IgniteConfiguration. Note that Ignite is created with client mode.
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setMetricsLogFrequency(0); // Trying to disabled it!
cfg.setIgniteInstanceName("IgnitePod");
cfg.setClientMode(true);
cfg.setAuthenticationEnabled(true);
// Ignite persistence configuration.
DataStorageConfiguration storageCfg = new DataStorageConfiguration();
storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);
cfg.setDataStorageConfiguration(storageCfg);
cfg.setDiscoverySpi(spi);
Ignite ignite = Ignition.start(cfg);
Any idea on how to solve this?
It is a different Ignite instance. Your one is called "IgnitePod" but this one is "CacheManager_0". You need to adjust its config, too.

How to modify cache settings on a running ignite instance?

Is there any setOrCreateCache method in ignite? I just find a getOrCreateCache method.
I want to modify cache settings on a running ignite instance. How to?
My ignite version is 1.9.0. Thanks.
Here is my codes:
IgniteCache<Integer, String> cache = ignite.getOrCreateCache("myCacheName"); // I've created a cache
// How to change the config of myCacheName?
You can dynamically create cache on running ignite by using getOrCreateCache(CacheConfiguration cacheCfg) method. It's possible to dynamically configure cache before create it.

How to add a Datasource to embedded Weblogic 12

How can I add a datasource configuration file within a embedded Weblogic EJB Container?
As far as I know, this is only possible with a already installed and preconfigured weblogic, instance? Is this correct?
My configuration is the following:
Properties prop = new Properties();
prop.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("datasource.properties"));
EJBContainer container = EJBContainer.createEJBContainer(prop);
Context initialContext = container.getContext();
((MyEJB)initialContext.lookup("MyEjb")).writeInDatabase();
I have not found a lot of documentation on this topic.
http://vineetreynolds.blogspot.com/2012/11/the-embedded-ejb-container-in-weblogic.html
see if this helps, although I cant get stuff to run yet on my end
you are better of being in jpa land, and create a test persistence.xml that basically uses jdbc url/user/pass and not jndi

EJB lookup problem

I have a Glassfish v2.1.1 cluster setup. I deployed an EAR file consisting a single stateless bean to stand alone server. It has an IIOP port 3752.
My client application which will be communicating with this bean is deployed on cluster. When i lookup bean's name, i get NameNotFoundException. Code looks as below:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
if (logger.isDebugEnabled()) {
logger.debug("Looking for bean from location : " + PropertiesService.instance().getSchedulerOrbHost() + ":"
+ PropertiesService.instance().getSchedulerOrbPort());
}
props.setProperty("org.omg.CORBA.ORBInitialHost", PropertiesService.instance().getSchedulerOrbHost());
props.setProperty("org.omg.CORBA.ORBInitialPort", PropertiesService.instance().getSchedulerOrbPort());
InitialContext context = null;
try {
context = new InitialContext(props);
} catch (NamingException e) {
e.printStackTrace();
}
String beanName = "test.OperationControllerRemote";
OperationControllerRemote remote = (OperationControllerRemote) context.lookup(beanName);
Note that i checked JNDI tree and name "test.OperationControllerRemote" is there.
Any opinions please?
Here are the ways I have got it to work with a GF 2.1.1 cluster and a Swing client. I'm currently going with the Standalone option because of client launch speed, but the ACC might work for you.
Standalone
The way you're doing it is considered standalone.
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB
http://blogs.oracle.com/dadelhardt/entry/standalone_iiop_clients_with_glassfish
ACC
Another way to approach this is to launch the client with the ACC. This means packaging the client code into the ear as an Application Client and either launching using the JNLP method or manually installing a bundled ACC (mini glassfish really) on client machines. In GF 2.1, either way works ok, but both are pretty fat and JNLP method can make startup times a bit longer. Supposedly in GF 3.1 they've reworked the ACC and it starts up faster. Something that may not be obvious is that with the ACC you get the list of servers in the cluster provided automatically at client startup.
http://blogs.oracle.com/theaquarium/entry/java_ee_clients_with_or
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beakv.html#scrolltoc
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/gkusn.html
Lookups
Either of the above ways provides RMI/CORBA failover and load balancing for the client.
Either way, when you have the right dependencies on your classpath and the com.sun.appserv.iiop.endpoints system property set (like node1:33700,node2:33701), you'll only need the no-args InitialContext because Glassfish's stuff autoregisters their connection properties, etc as described in the first link:
new InitialContext()
And lookups will work. For my remote session beans (EJB 3.0) I typically do it like:
#Stateless(mappedName="FooBean")
public class FooBean implements FooBeanRemote {}
#Remote
public interface FooBeanRemote {}
then in client code:
FooBeanRemote foo = (FooBeanRemote) ctx.lookup("FooBean");