[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-5103:
-----------------------------------------
True, but it's unlikely to cause harm: that field will very unlikely add more than a handful of terms to the index
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5103:
---------------------------------------
Additional thought: having now proven that the ID is good enough to unequivocally map the the right Id, the field which stores the class name might become redundant.
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5109) Topology hint breaks cross site replication in CacheTopologyControlCommand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5109?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5109:
-----------------------------------------------
Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1177228|https://bugzilla.redhat.com/show_bug.cgi?id=1177228] from ASSIGNED to POST
> Topology hint breaks cross site replication in CacheTopologyControlCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-5109
> URL: https://issues.jboss.org/browse/ISPN-5109
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Environment: JDG 6.4.0.ER8 (Infinispan 6.2.0.ER8)
> Reporter: Osamu Nagano
> Attachments: clustered_xSite-A.xml, clustered_xSite-B.xml
>
>
> When topology hints like site, rack and machine are set under cross site replication configuration, server will keep generating the following WARN log messages.
> {noformat}
> 17:51:03,037 WARN [org.infinispan.topology.CacheTopologyControlCommand] (MSC service thread 1-3) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=namedCache, type=JOIN, sender=svr01/xSite-A ( flags=2 (can_be_sm), site-id=s1, rack-id=r1, machine-id=m1), joinInfo=CacheJoinInfo{consistentHashFactory=org.infinispan.distribution.ch.TopologyAwareConsistentHashFactory@f0d, hashFunction=MurmurHash3, numSegments=80, numOwners=2, timeout=60000, totalOrder=false, distributed=true}, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=0}: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.infinispan.remoting.transport.TopologyAwareAddress
> at org.infinispan.distribution.topologyaware.TopologyInfo.addTopology(TopologyInfo.java:56) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.distribution.topologyaware.TopologyInfo.<init>(TopologyInfo.java:37) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.distribution.ch.TopologyAwareConsistentHashFactory.addBackupOwners(TopologyAwareConsistentHashFactory.java:27) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:126) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.create(DefaultConsistentHashFactory.java:41) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.create(DefaultConsistentHashFactory.java:25) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.ClusterCacheStatus.createInitialCacheTopology(ClusterCacheStatus.java:567) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.ClusterCacheStatus.doJoin(ClusterCacheStatus.java:551) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleJoin(ClusterTopologyManagerImpl.java:131) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:162) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:377) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:103) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:109) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_71]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_71]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_71]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_71]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) [infinispan-commons-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.CacheImpl.start(CacheImpl.java:756) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:581) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:536) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:414) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:428) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:104) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:101) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.security.Security.doPrivileged(Security.java:76) [infinispan-core-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:48) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:109) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:79) [infinispan-server-infinispan-6.2.0.ER8-redhat-1.jar:6.2.0.ER8-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
> {noformat}
> If such topology hints are removed from udp stack transport element, this issue doesn't happen.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5125) EventType methods are not public
by William Burns (JIRA)
William Burns created ISPN-5125:
-----------------------------------
Summary: EventType methods are not public
Key: ISPN-5125
URL: https://issues.jboss.org/browse/ISPN-5125
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 7.0.3.Final
Reporter: William Burns
Assignee: William Burns
Fix For: 7.1.0.Beta1
The org.infinispan.notifications.cachelistener.filter.EventType has some methods that are not marked as public (isRetry, isPreEvent, isRemove, isCreate, isModified).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5103:
---------------------------------------
As a reminder of our IRC chat:
it seems this would be safe as Infinispan Query handles the identifiers in a slightly different way than Hibernate Search / ORM : the {{org.infinispan.query.Transformer}} guarantees a unique relation between each encoded id and makes it possible to reconstruct from it not only the ID instance but also the {{Transformer}} implementation to be used for the transformation itself.
A similar optimisation wouldn't be always safe in ORM world as the {{org.hibernate.search.bridge.TwoWayFieldBridge}} needs to be known, or we'd need to be sure that different {{FieldBridge}} implementations would encode values in some unique way.
For example we'd have a problem when mapping Integer(5) and Long(5) using keyword encoding as they would both map to "5".
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5123) MultiNodeDistributedTest dealock
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5123?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-5123:
-----------------------------------------
After 30min, the exception is logged:
{code}
Tests run: 1844, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2,017.689 sec <<< FAILURE! - in TestSuite
testIndexingWorkDistribution(org.infinispan.query.distributed.MultiNodeDistributedTest) Time elapsed: 1,963.317 sec <<< FAILURE!
java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node MultiNodeDistributedTest-NodeB-61010, current topology is CacheTopology{id=10, rebalanceId=5, currentCH=DefaultConsistentHash{ns = 60, owners = (3)[MultiNodeDistributedTest-NodeB-61010: 23+7, MultiNodeDistributedTest-NodeC-41016: 18+12, MultiNodeDistributedTest-NodeD-40175: 19+11]}, pendingCH=DefaultConsistentHash{ns = 60, owners = (3)[MultiNodeDistributedTest-NodeB-61010: 20+20, MultiNodeDistributedTest-NodeC-41016: 20+20, MultiNodeDistributedTest-NodeD-40175: 20+20]}, unionCH=DefaultConsistentHash{ns = 60, owners = (3)[MultiNodeDistributedTest-NodeB-61010: 23+17, MultiNodeDistributedTest-NodeC-41016: 18+23, MultiNodeDistributedTest-NodeD-40175: 19+23]}, actualMembers=[MultiNodeDistributedTest-NodeB-61010, MultiNodeDistributedTest-NodeC-41016, MultiNodeDistributedTest-NodeD-40175]}. rebalanceInProgress=true, currentChIsBalanced=false
at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:239)
at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:249)
at org.infinispan.query.helper.TestableCluster.waitForRehashToComplete(TestableCluster.java:62)
at org.infinispan.query.helper.TestableCluster.killNode(TestableCluster.java:57)
at org.infinispan.query.distributed.MultiNodeDistributedTest.killMasterNode(MultiNodeDistributedTest.java:79)
at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:63)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
{code}
> MultiNodeDistributedTest dealock
> --------------------------------
>
> Key: ISPN-5123
> URL: https://issues.jboss.org/browse/ISPN-5123
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Query
> Affects Versions: 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Attachments: stack.zip
>
>
> I've been seeing this intermittent problem in my environment. Sometimes the query suite hangs for 30min (and then proceeds). See attached stack trace.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5123) MultiNodeDistributedTest dealock
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5123?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5123:
------------------------------------
Description: I've been seeing this intermittent problem in my environment. Sometimes the query suite hangs for 30min (and then proceeds). See attached stack trace. (was: I've been seeing this intermittent problem in my environment. Sometimes the query hangs for 30 min (and then proceeds). See attached stack trace.)
> MultiNodeDistributedTest dealock
> --------------------------------
>
> Key: ISPN-5123
> URL: https://issues.jboss.org/browse/ISPN-5123
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Query
> Affects Versions: 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Attachments: stack.zip
>
>
> I've been seeing this intermittent problem in my environment. Sometimes the query suite hangs for 30min (and then proceeds). See attached stack trace.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months