[JBoss JIRA] (ISPN-4734) Hot Rod marshaller for custom events...etc, needs to be configurable in server
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4734?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4734:
----------------------------------------
Actually, thinking this through, the way the filter/converter event marshaller is configured is not the right way. In similar vein to filters and converters, we need to be able to detect marshaller deployments. To be more precise, we could enforce filter/converter jars to provide service definitions for Marshaller instances to use with them. To keep it simple, if we find a marshaller in the deployment, we use it with the filter and/or converter. If we find various, we only use the first. This makes plugging the filter/event marshaller. Down the line, we could support deployment of marshallers in general and plugging them to Infinispan cache.
> Hot Rod marshaller for custom events...etc, needs to be configurable in server
> ------------------------------------------------------------------------------
>
> Key: ISPN-4734
> URL: https://issues.jboss.org/browse/ISPN-4734
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 7.0.0.Beta2
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.CR1
>
>
> The marshaller used by Hot Rod to marshall custom events is configurable via HotRodServerConfigurationBuilder. This needs to be extended to server side configuration.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ISPN-4588) JpaConfigurationTest.testConfigBuilder fails in Karaf
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4588?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4588:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1141806|https://bugzilla.redhat.com/show_bug.cgi?id=1141806] from ON_QA to VERIFIED
> JpaConfigurationTest.testConfigBuilder fails in Karaf
> -----------------------------------------------------
>
> Key: ISPN-4588
> URL: https://issues.jboss.org/browse/ISPN-4588
> Project: Infinispan
> Issue Type: Bug
> Reporter: Ion Savin
> Assignee: Ion Savin
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> Exception reported while running in Karaf JpaConfigurationTest.testConfigBuilder
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:191)
> at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:221)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:563)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:529)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:409)
> at org.infinispan.persistence.jpa.JpaConfigurationTest.testConfigBuilder(JpaConfigurationTest.java:52)
> at org.infinispan.it.osgi.persistence.jpa.JpaConfigurationTest.testConfigBuilder(JpaConfigurationTest.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
> at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Related issue in jgroups: https://issues.jboss.org/browse/JGRP-1864
> The Karaf container is not using -Djava.net.preferIPv4Stack=true
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ISPN-4468) HR client is not able to unmarshall custom class when using AS modules
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-4468?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-4468:
---------------------------------------
Hi Galder,
the actual test is here:
https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....
HR client is deployed into EAP sever from where it connects to ISPN server. When HR client libraries are bundled in war file, everything works fine. When HR client is moved into EAP modules and war file contains only test class (+ few other needed jars), HR clien is not able to unmarshall custom classes contained in war file (in test class). I don't remember the details, but obviously there's some class loading issue - probably modules use different classloader than one used for deployment (which makes sense for EAP as modules shouldn't depend deployed apps, but this is not the cases of HR client)
> HR client is not able to unmarshall custom class when using AS modules
> ----------------------------------------------------------------------
>
> Key: ISPN-4468
> URL: https://issues.jboss.org/browse/ISPN-4468
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Protocols
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> When using HR client in JBoss and use JBoss modules for HR client, storing custom objects into remote cache works, however when custom objects is read back from remote cache, it fails as {{ClassNotFoundException}}:
> {noformat}
> testPutGetCustomObject(com.jboss.datagrid.test.hotrod.HotRodRemoteCacheIT) Time elapsed: 1.749 sec <<< ERROR!
> org.infinispan.client.hotrod.exceptions.HotRodClientException: Unable to unmarshall byte stream
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:555)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> [...]
> {noformat}
> Caused by: java.lang.ClassNotFoundException: org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person from [Module "org.infinispan.commons:jdg-6.3" from local module loader @5cbf5bb7 (finder: local module finder @171e7af3 (roots: /opt/test_servers/jboss-eap-6.2.2/modules,/opt/test_servers/jboss-eap-6.2.2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:113)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:553)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> Adding jar file with {{org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person}} into jboss-deployment-structure as a module didn't helped.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ISPN-4579) SingleNodeJdbcStoreIT.cleanup NPE after test failure
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4579?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4579:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2885
> SingleNodeJdbcStoreIT.cleanup NPE after test failure
> ----------------------------------------------------
>
> Key: ISPN-4579
> URL: https://issues.jboss.org/browse/ISPN-4579
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 7.0.0.CR1
>
>
> After a failure in {{SingleNodeJdbcStoreIT.testForcedShutdown}}, it seems not all the test stores are properly initialized, and cleanup fails with a NullPointerException:
> {noformat}
> [00:57:07] : [testForcedShutdown] java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.junit.Assert.assertNotNull(Assert.java:631)
> at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.testRestartStringStoreBefore(SingleNodeJdbcStoreIT.java:223)
> at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.testForcedShutdown(SingleNodeJdbcStoreIT.java:163)
> ...
> [00:57:07]W: [org.infinispan.server:test-suite] java.lang.NullPointerException
> at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.cleanup(SingleNodeJdbcStoreIT.java:82)
> {noformat}
> This bug is only about the NPE, the test failure is agent-specific (probably caused by the low open files/user processes limits).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ISPN-4579) SingleNodeJdbcStoreIT.cleanup NPE after test failure
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4579?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4579:
----------------------------------------
Ah sorry, I had been focusing on the test error itself. Sure, I'll add the null check :)
> SingleNodeJdbcStoreIT.cleanup NPE after test failure
> ----------------------------------------------------
>
> Key: ISPN-4579
> URL: https://issues.jboss.org/browse/ISPN-4579
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 7.0.0.CR1
>
>
> After a failure in {{SingleNodeJdbcStoreIT.testForcedShutdown}}, it seems not all the test stores are properly initialized, and cleanup fails with a NullPointerException:
> {noformat}
> [00:57:07] : [testForcedShutdown] java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.junit.Assert.assertNotNull(Assert.java:631)
> at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.testRestartStringStoreBefore(SingleNodeJdbcStoreIT.java:223)
> at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.testForcedShutdown(SingleNodeJdbcStoreIT.java:163)
> ...
> [00:57:07]W: [org.infinispan.server:test-suite] java.lang.NullPointerException
> at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.cleanup(SingleNodeJdbcStoreIT.java:82)
> {noformat}
> This bug is only about the NPE, the test failure is agent-specific (probably caused by the low open files/user processes limits).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ISPN-4468) HR client is not able to unmarshall custom class when using AS modules
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4468?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4468:
----------------------------------------
Vojtech, what's the HR client being executed from? IOW, what kind of deployment is it running within? Looking at the test class I see no other deployments other than the filter/converter deployments, which are specific to HR event filter/converter tests.
If the test class, and custom class are running as if they were in a JBoss module, they'd be some module hardwiring required to make this work. There's no way to get around that. On the contrary, if the test class and custom class are inside a WAR/EAR, the application server will do what it needs to do to make sure that the custom class is visible: https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Finally, rather than AbstractRemoteCacheIT, a test that's closer to what you are trying to do of marshalling a custom object is {{org.infinispan.test.integration.as.HotRodClientIT}}, where you have a remote HR client running within JBoss, using Infinispan Server modules which include HR client, hooked in Wildfly, and then have HotRodClientIT run inside a WAR in Wildfly. If you add a test to marshall custom classes there, it should work.
> HR client is not able to unmarshall custom class when using AS modules
> ----------------------------------------------------------------------
>
> Key: ISPN-4468
> URL: https://issues.jboss.org/browse/ISPN-4468
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Protocols
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> When using HR client in JBoss and use JBoss modules for HR client, storing custom objects into remote cache works, however when custom objects is read back from remote cache, it fails as {{ClassNotFoundException}}:
> {noformat}
> testPutGetCustomObject(com.jboss.datagrid.test.hotrod.HotRodRemoteCacheIT) Time elapsed: 1.749 sec <<< ERROR!
> org.infinispan.client.hotrod.exceptions.HotRodClientException: Unable to unmarshall byte stream
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:555)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> [...]
> {noformat}
> Caused by: java.lang.ClassNotFoundException: org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person from [Module "org.infinispan.commons:jdg-6.3" from local module loader @5cbf5bb7 (finder: local module finder @171e7af3 (roots: /opt/test_servers/jboss-eap-6.2.2/modules,/opt/test_servers/jboss-eap-6.2.2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:113)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:553)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> Adding jar file with {{org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person}} into jboss-deployment-structure as a module didn't helped.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4584:
---------------------------------------
{quote}Another check that would be useful is that the triple locking/metadata/data caches is not shared, e.g cache indexedA using lockingA, metadataA and dataA, while cache indexedB uses lockingA, metadataA and dataA - I've accidentally configured it that way (as in my test only indexedB should have been used) and stumbled again on ISPN-4577.{quote}
Good point, if we don't accept that configuration we should validate against it.
Although, there is the use case in which people actually want to share the same index across Caches or even applications; a better solution however would be to finish the CacheManager level Query Engine, so that different caches can actually forward work to the same IndexWriter rather than locking each other out.
But I agree, if we don't do that timely we should validate this.
> Stricter validation of cache configurations for distributed indexes
> -------------------------------------------------------------------
>
> Key: ISPN-4584
> URL: https://issues.jboss.org/browse/ISPN-4584
> Project: Infinispan
> Issue Type: Enhancement
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
>
> See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode.
> Ideally think of additional strict checks which we should apply.. suggestions?
> Mitigated by ISPN-4340
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months