split infinispan-lucene-directory.jar

[brackxm]

Can the infinispan-lucene-directory.jar be split?

Part of it is (e.g. InfinispanDirectory) for use on top of infinispan, but part of it (e.g. LuceneKey2StringMapper) is needed in the backend.

A use case is infinispan configured in jboss, with ear's using InfinispanDirectory.

[sannegrinovero]

Hi Michael,

what do you mean by backend in this case? What is the issue when using it in JBoss?

If the problem is related to configure the keymapper in a cachemanager started by JBoss, I'd suggest you move the infinispan-lucene-directory.jar to the common lib, out of the EAR.

[brackxm]

Yes, configuring they keymapper requires adding the infinispan-lucene-directory.jar to the common lib.

However, having the InfinispanDirectory there gives problems. It forces having lucene in there also.

For me, the InfinispanDirectory and lucene belong in the ear's.

For example not all ear's use an InfinispanDirectory, or use different versions of lucene.

[sannegrinovero]

Good points. But are you starting a cachemanager from your application, or intending to modify the configuration of the AS to include caches for your applications? I would have expected people to start a new cachemanager, and so have all the needed jars and configuration files in the EAR.

[brackxm]

I'm using a shared cachemanager, bound to jndi, configured via xml.

Basically using infinispan as a service, similar to a datasource.

[dan.berindei]

I think with 5.0.0.CR6 you could define the cache configuration programmatically and use Configuration.setClassLoader(Thread.currentThread().getContextClassLoader()) to allow Infinispan to load the LuceneKey2StringMapper from your EAR.

We don't support asymetric clusters though, so you should make sure that the cache is created on startup or you might encounter other problems.

[sannegrinovero]

Dan, if he wants to use Infinispan "like a datasource", I don't think it's practical to use the programmatic API.

Also since we don't support asymmetric clusters it makes sense to have a single configuration defined independently from the application being deployed or not (yet).

I'm not a big fan of the idea of splitting the keymapper and all it's dependencies from the rest, I don't even know if it's possible. I'd prefer to make sure it's deployable to the common libs without having to move Lucene there too: after all this module is tightly bound to the Infinispan version so it's not possible to have multiple versions, and at the same time the same code is compatible with several different Lucene versions.

Michael, would that work for you? More thoughts?

[sannegrinovero]

I've discussed this issue with Galder, our conclusion was that splitting the jar would be a very hard task which doesn't bring much of a benefit as we're aiming to support asymmetric clusters for version 5.1; at the moment there are two alternatives:

1. Start a cachemanager from your application rather than reusing the one from the application server
2. Move the jar and it's dependencies to the commons/lib of the application server

There's one additional reason: while you spotted the missing LuceneKey2StringMapper as it's a non-optional dependency since you specify it in the configuration, you're also missing the custom Externalizers which provide much better performance; these externalizers are auto-discovered if found on classpath when the CacheManager is started.

Let's see if https://issues.jboss.org/browse/ISPN-658 is indeed solved soon, otherwise we will seek an alternative.

[manik]

Sanne, note that it isn't definite that we support asymmetric clusters in 5.1.  That is a hard problem and needs careful investigation.  What I have committed to though, is programmatic definition and startup of caches in a cluster.   While there is some overlap, the actual solution can be quite different.  So don't take for granted that asymmetric clusters will be supported.

[sannegrinovero]

ok, sorry for that. As mentioned in previous post, let's see what happens in 5.1 otherwise we will think about this again. Opening an issue to track this as a separate concept: ISPN-1224

[sannegrinovero]

I've closed https://issues.jboss.org/browse/ISPN-1224 rejecting my own issue. As commented on the issue, there are fat better alternatives.