[JBoss JIRA] (ISPN-4356) Solr analysis cannot be used in OSGi due to Hibernate Search not being able to find Solr on classpath
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4356?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero resolved ISPN-4356.
-----------------------------------
Resolution: Out of Date
I'm going to assume this is out of date. Please reopen if we any test proves me wrong.
> Solr analysis cannot be used in OSGi due to Hibernate Search not being able to find Solr on classpath
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-4356
> URL: https://issues.jboss.org/browse/ISPN-4356
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Gustavo Fernandes
>
> Stacktrace I got while running org.infinispan.query.analysis.SolrAnalyzerTest in Karaf :
> {code}
> org.hibernate.search.SearchException: Use of @AnalyzerDef while Solr is not present in the classpath. Add apache-solr-analyzer.jar
> at org.hibernate.search.impl.ConfigContext.buildAnalyzer(ConfigContext.java:226)
> at org.hibernate.search.impl.ConfigContext.initLazyAnalyzers(ConfigContext.java:204)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:389)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildIncrementalSearchFactory(SearchFactoryBuilder.java:166)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
> at org.hibernate.search.impl.MutableSearchFactory.addClasses(MutableSearchFactory.java:251)
> at org.infinispan.query.backend.QueryInterceptor.enableClassesIncrementally(QueryInterceptor.java:272)
> at org.infinispan.query.backend.QueryInterceptor.updateKnownTypesIfNeeded(QueryInterceptor.java:313)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:161)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:99)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:271)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:195)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:111)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:74)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1429)
> at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:907)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:899)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1474)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:232)
> at org.infinispan.query.analysis.SolrAnalyzerTest.testAnalyzerDef(SolrAnalyzerTest.java:56)
> at org.infinispan.it.osgi.query.blackbox.SolrAnalyzerTest.testAnalyzerDef(SolrAnalyzerTest.java:40)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> 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)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)[111:org.ops4j.pax.tipi.junit:4.11.0.1]
> 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:125)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:98)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)[:1.7.0_17]
> at sun.rmi.transport.Transport$1.run(Transport.java:177)[:1.7.0_17]
> at sun.rmi.transport.Transport$1.run(Transport.java:174)[:1.7.0_17]
> at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_17]
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)[:1.7.0_17]
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)[:1.7.0_17]
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)[:1.7.0_17]
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)[:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ]
Dan Berindei updated ISPN-825:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3848
> Consider staggering remote get requests when using DIST
> -------------------------------------------------------
>
> Key: ISPN-825
> URL: https://issues.jboss.org/browse/ISPN-825
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 4.1.0.Final
> Reporter: Manik Surtani
> Assignee: William Burns
> Priority: Critical
> Labels: optimization, performance
>
> In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic.
> The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster.
> A solution around this could be based on either (or both) of:
> * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc.
> * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5.
> Needs careful thought and design.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-3395) ISPN000196: Failed to recover cluster state after the current node became the coordinator
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3395?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3395:
-----------------------------------------------
Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1283465|https://bugzilla.redhat.com/show_bug.cgi?id=1283465] from ASSIGNED to POST
> ISPN000196: Failed to recover cluster state after the current node became the coordinator
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-3395
> URL: https://issues.jboss.org/browse/ISPN-3395
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 5.3.0.Final
> Reporter: Mayank Agarwal
> Fix For: 6.0.2.Final, 7.0.0.Final
>
>
> We are using infinispan 5.3.0.Final in our distributed application. we are testing infinispan in HA scenarios and getting following exception when new node becomes co-ordinator.
> ISPN000196: Failed to recover cluster state after the current node became the coordinator
> java.lang.NullPointerException: null
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:455) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final]
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:235) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final]
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:647) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_25]
> at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_25]
> at java.lang.Thread.run(Unknown Source) [na:1.6.0_25]
> This is happening because cacheTopology is null at ClusterTopologyManagerImpl.java:455
> at 449: code is checking cacheTopology for null that for loop which is updating cacheStatusMap at 457 should be in that check itself.
> Fix:
> --- a/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java
> +++ b/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java
> @@ -448,7 +448,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager {
> // but didn't get a response back yet
> if (cacheTopology != null) {
> topologyList.add(cacheTopology);
> - }
> +
>
> // Add all the members of the topology that have sent responses first
> // If we only added the sender, we could end up with a different member order
> @@ -457,6 +457,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager {
> cacheStatusMap.get(cacheName).addMember(member);
> }
> }
> + }
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-5978) Unused scripts in EAP bin directory
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/ISPN-5978?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on ISPN-5978:
----------------------------------------
You might remove run.sh and run.bat as well.
This scripts are only needed because of compatibility for older EAP.
until EAP6 the server was started by run.* so the script just note the user to use standalone or domain.
For JDG this is not needed
> Unused scripts in EAP bin directory
> -----------------------------------
>
> Key: ISPN-5978
> URL: https://issues.jboss.org/browse/ISPN-5978
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.1.0.Beta1
> Reporter: Vaclav Dedik
> Assignee: Vaclav Dedik
> Fix For: 8.1.0.Final
>
>
> There are these unecessary scripts in the EAP bin directory:
> appclient.sh
> jboss-cli.sh
> wsconsume.sh
> wsprovide.sh
> appclient.sh, wsconsume.sh and wsprovide.sh are already removed from upstream. jboss-cli.sh is still present.
> See bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1198413
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months