[jira] [Commented] (SOLR-8162) JmxMonitoredMap#clear triggers a query on all the MBeans thus generating lots of warnings
[
https://issues.apache.org/jira/browse/SOLR-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1496#comment-1496
]
ASF subversion and git services commented on SOLR-8162:
---
Commit 1709242 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1709242 ]
SOLR-8162: JmxMonitoredMap#clear triggers a query on all the MBeans thus
generating lots of warnings
> JmxMonitoredMap#clear triggers a query on all the MBeans thus generating lots
> of warnings
> -
>
> Key: SOLR-8162
> URL: https://issues.apache.org/jira/browse/SOLR-8162
> Project: Solr
> Issue Type: Bug
> Components: JMX
>Affects Versions: 5.3
>Reporter: Marius Dumitru Florea
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-8162.patch
>
>
> [{{JmxMonitoredMap#clear()}}|http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_5_3_1/solr/core/src/java/org/apache/solr/core/JmxMonitoredMap.java?view=markup#l133]
> doesn't restrict the query to the MBeans registered by Solr thus forcing the
> {{MBeanServer}} to query all the registered MBeans if they have a
> "coreHashCode" attribute:
> {noformat}
> QueryExp exp = Query.eq(Query.attr("coreHashCode"),
> Query.value(coreHashCode));
> ...
> objectNames = server.queryNames(null, exp);
> {noformat}
> This triggers a lot of warnings because (I guess)
> [{{DynamicMBean#getAttribute()}}|https://docs.oracle.com/javase/7/docs/api/javax/management/DynamicMBean.html#getAttribute%28java.lang.String%29]
> throws {{AttributeNotFoundException}}.
> This is what I get for instance:
> {noformat}
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,284 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,284 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,285 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find quer
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60) - Build # 14282 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14282/ Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.component.DistributedFacetPivotWhiteBoxTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.handler.component.DistributedFacetPivotWhiteBoxTest: 1) Thread[id=11614, name=searcherExecutor-4739-thread-1, state=WAITING, group=TGRP-DistributedFacetPivotWhiteBoxTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)2) Thread[id=11606, name=qtp489986831-11606, state=RUNNABLE, group=TGRP-DistributedFacetPivotWhiteBoxTest] at java.util.WeakHashMap.get(WeakHashMap.java:403) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcEtag(HttpCacheHeaderUtil.java:102) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:224) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:452) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.handler.component.DistributedFacetPivotWhiteBoxTest: 1) Thread[id=11614, name=searcherExecutor-4739-thread-1, state=WAITING, group=TGRP-DistributedFacetPivotWhiteBoxTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2) Thread[id=11606, name=qtp489986831-11606, state=RUNNABLE, group=TGRP-DistributedFacetPivotWhiteBoxTest] at java.util.WeakHashMap.get(WeakHashMap.java:403) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcEtag(HttpCacheHeaderUtil.java:102) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.d
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 825 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/825/ 2 tests failed. FAILED: org.apache.lucene.rangetree.TestRangeTree.testRandomBig Error Message: background merge hit exception: _0(6.0.0):c190033/1881:delGen=1 _1(6.0.0):c185641/571:delGen=1 _2(6.0.0):c185641/330:delGen=1 _3(6.0.0):c185377/273:delGen=1 _4(6.0.0):c184339/217:delGen=1 _5(6.0.0):c181707/140:delGen=1 _6(6.0.0):c45252/18:delGen=1 into _7 [maxNumSegments=1] Stack Trace: java.io.IOException: background merge hit exception: _0(6.0.0):c190033/1881:delGen=1 _1(6.0.0):c185641/571:delGen=1 _2(6.0.0):c185641/330:delGen=1 _3(6.0.0):c185377/273:delGen=1 _4(6.0.0):c184339/217:delGen=1 _5(6.0.0):c181707/140:delGen=1 _6(6.0.0):c45252/18:delGen=1 into _7 [maxNumSegments=1] at __randomizedtesting.SeedInfo.seed([7C0697500647D4E8:FB51EADF971EA868]:0) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1765) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1705) at org.apache.lucene.rangetree.TestRangeTree.verify(TestRangeTree.java:401) at org.apache.lucene.rangetree.TestRangeTree.doTestRandom(TestRangeTree.java:347) at org.apache.lucene.rangetree.TestRangeTree.testRandomBig(TestRangeTree.java:297) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Caused b
[jira] [Commented] (LUCENE-6780) GeoPointDistanceQuery doesn't work with a large radius?
[ https://issues.apache.org/jira/browse/LUCENE-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962265#comment-14962265 ] ASF subversion and git services commented on LUCENE-6780: - Commit 1709253 from [~mikemccand] in branch 'dev/branches/lucene6780' [ https://svn.apache.org/r1709253 ] LUCENE-6780: don't allow too-large radius in distance query (depending on origin); reduce resolution for large bbox > GeoPointDistanceQuery doesn't work with a large radius? > --- > > Key: LUCENE-6780 > URL: https://issues.apache.org/jira/browse/LUCENE-6780 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Attachments: LUCENE-6780-heap-used-hack.patch, LUCENE-6780.patch, > LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, > LUCENE-6780.patch > > > I'm working on LUCENE-6698 but struggling with test failures ... > Then I noticed that TestGeoPointQuery's test never tests on large distances, > so I modified the test to sometimes do so (like TestBKDTree) and hit test > failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8162) JmxMonitoredMap#clear triggers a query on all the MBeans thus generating lots of warnings
[
https://issues.apache.org/jira/browse/SOLR-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962270#comment-14962270
]
ASF subversion and git services commented on SOLR-8162:
---
Commit 1709255 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1709255 ]
SOLR-8162: JmxMonitoredMap#clear triggers a query on all the MBeans thus
generating lots of warnings
> JmxMonitoredMap#clear triggers a query on all the MBeans thus generating lots
> of warnings
> -
>
> Key: SOLR-8162
> URL: https://issues.apache.org/jira/browse/SOLR-8162
> Project: Solr
> Issue Type: Bug
> Components: JMX
>Affects Versions: 5.3
>Reporter: Marius Dumitru Florea
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-8162.patch
>
>
> [{{JmxMonitoredMap#clear()}}|http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_5_3_1/solr/core/src/java/org/apache/solr/core/JmxMonitoredMap.java?view=markup#l133]
> doesn't restrict the query to the MBeans registered by Solr thus forcing the
> {{MBeanServer}} to query all the registered MBeans if they have a
> "coreHashCode" attribute:
> {noformat}
> QueryExp exp = Query.eq(Query.attr("coreHashCode"),
> Query.value(coreHashCode));
> ...
> objectNames = server.queryNames(null, exp);
> {noformat}
> This triggers a lot of warnings because (I guess)
> [{{DynamicMBean#getAttribute()}}|https://docs.oracle.com/javase/7/docs/api/javax/management/DynamicMBean.html#getAttribute%28java.lang.String%29]
> throws {{AttributeNotFoundException}}.
> This is what I get for instance:
> {noformat}
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,284 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,284 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,285 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did
[jira] [Resolved] (SOLR-8162) JmxMonitoredMap#clear triggers a query on all the MBeans thus generating lots of warnings
[
https://issues.apache.org/jira/browse/SOLR-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-8162.
-
Resolution: Fixed
Fix Version/s: Trunk
5.4
The patch had a couple of unnecessary changes which I removed before committing.
Thanks Marius!
> JmxMonitoredMap#clear triggers a query on all the MBeans thus generating lots
> of warnings
> -
>
> Key: SOLR-8162
> URL: https://issues.apache.org/jira/browse/SOLR-8162
> Project: Solr
> Issue Type: Bug
> Components: JMX
>Affects Versions: 5.3
>Reporter: Marius Dumitru Florea
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8162.patch
>
>
> [{{JmxMonitoredMap#clear()}}|http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_5_3_1/solr/core/src/java/org/apache/solr/core/JmxMonitoredMap.java?view=markup#l133]
> doesn't restrict the query to the MBeans registered by Solr thus forcing the
> {{MBeanServer}} to query all the registered MBeans if they have a
> "coreHashCode" attribute:
> {noformat}
> QueryExp exp = Query.eq(Query.attr("coreHashCode"),
> Query.value(coreHashCode));
> ...
> objectNames = server.queryNames(null, exp);
> {noformat}
> This triggers a lot of warnings because (I guess)
> [{{DynamicMBean#getAttribute()}}|https://docs.oracle.com/javase/7/docs/api/javax/management/DynamicMBean.html#getAttribute%28java.lang.String%29]
> throws {{AttributeNotFoundException}}.
> This is what I get for instance:
> {noformat}
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,281 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,282 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,283 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,284 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,284 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,285 [http://localhost:8080/xwiki/bin/view/Sandbox/Foo]
> WARN o.i.j.ResourceDMBean - ISPN42: Did not find queried
> attribute with name coreHashCode
> 2015-10-13 16:07:10,285 [
[jira] [Commented] (LUCENE-6780) GeoPointDistanceQuery doesn't work with a large radius?
[ https://issues.apache.org/jira/browse/LUCENE-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962284#comment-14962284 ] ASF subversion and git services commented on LUCENE-6780: - Commit 1709257 from [~mikemccand] in branch 'dev/branches/lucene6780' [ https://svn.apache.org/r1709257 ] LUCENE-6780: fix bug in midLat/midLon; don't test dateline crossing when small == true > GeoPointDistanceQuery doesn't work with a large radius? > --- > > Key: LUCENE-6780 > URL: https://issues.apache.org/jira/browse/LUCENE-6780 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Attachments: LUCENE-6780-heap-used-hack.patch, LUCENE-6780.patch, > LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, > LUCENE-6780.patch > > > I'm working on LUCENE-6698 but struggling with test failures ... > Then I noticed that TestGeoPointQuery's test never tests on large distances, > so I modified the test to sometimes do so (like TestBKDTree) and hit test > failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6780) GeoPointDistanceQuery doesn't work with a large radius?
[
https://issues.apache.org/jira/browse/LUCENE-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962286#comment-14962286
]
Michael McCandless commented on LUCENE-6780:
Thanks [~nknize], I committed the patch, but put a nocommit on the AwaitsFix
(we plan to fix that before landing this right?).
I also found a bug in how midLat/Lon was computed, that was causing us to
almost always use shiftFactor=5 even when the bbox was smallish ... I fix that,
and also fixed the test not to do dateline crossing when small==true.
However {{ant test -Dtestcase=TestGeoPointQuery -Dtestmethod=testAllLatEqual
-Dtests.seed=0}} is still quite slow (~5.6 seconds on my fastish haswell box),
even though it's always using a small bbox
> GeoPointDistanceQuery doesn't work with a large radius?
> ---
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-6780-heap-used-hack.patch, LUCENE-6780.patch,
> LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch,
> LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances,
> so I modified the test to sometimes do so (like TestBKDTree) and hit test
> failures.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b85) - Build # 14283 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14283/ Java: 32bit/jdk1.9.0-ea-b85 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 369 lines...] [junit4] JVM J2: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/temp/junit4-J2-20151018_105412_548.sysout [junit4] >>> JVM J2: stdout (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0xf6da211f, pid=6408, tid=6500 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0-b85) (build 1.9.0-ea-b85) [junit4] # Java VM: Java HotSpot(TM) Server VM (1.9.0-ea-b85, mixed mode, tiered, concurrent mark sweep gc, linux-x86) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0x8c211f] SuperWord::get_pre_loop_end(CountedLoopNode*)+0xaf [junit4] # [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/J2/hs_err_pid6408.log [junit4] # [junit4] # Compiler replay data is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/J2/replay_pid6408.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.java.com/bugreport/crash.jsp [junit4] # [junit4] <<< JVM J2: EOF [...truncated 1090 lines...] [junit4] ERROR: JVM J2 ended with an exception, command line: /home/jenkins/tools/java/32bit/jdk1.9.0-ea-b85/bin/java -server -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/heapdumps -ea -esa -Dtests.prefix=tests -Dtests.seed=875D3E7A6FDEA076 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.4.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp -Djava.io.tmpdir=./temp -Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/temp -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene -Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/clover/db -Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=5.4.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/J2 -Djunit4.childvm.id=2 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false -Dtests.filterstacks=true -Dtests.disableHdfs=true -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dfile.encoding=UTF-8 -classpath /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/codecs/classes/java:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/test-framework/classes/java:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/test-framework/lib/junit-4.10.jar:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.1.17.jar:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/java:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_60) - Build # 5213 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5213/ Java: 32bit/jdk1.8.0_60 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.PingRequestHandlerTest.testPingInClusterWithNoHealthCheck Error Message: Could not find a healthy node to handle the request. Stack Trace: org.apache.solr.common.SolrException: Could not find a healthy node to handle the request. at __randomizedtesting.SeedInfo.seed([50E075818B0B71E2:BE33CB510EE74B06]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150) at org.apache.solr.handler.PingRequestHandlerTest.testPingInClusterWithNoHealthCheck(PingRequestHandlerTest.java:201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache
[jira] [Updated] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[ https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-6276: - Attachment: LUCENE-6276.patch 2nd patch of 18 Oct 2015. More improvements: - Add TwoPhaseIterator.termPositionsCost() for use in matchCost() implementations. This replaces the earlier PhraseQuery.expTermFreqInMatchingDoc(). - In SpanOrQuery use better avarage cost for matchCost(). - Move positionsCost() throwing UOE from Near/ContainSpans to ConjunctionSpans only. - matchCost most be non negative in AssertingScorer. - Use a random matchCost in RandomApproximationQuery. - Better javadocs and code comments. > Add matchCost() api to TwoPhaseDocIdSetIterator > --- > > Key: LUCENE-6276 > URL: https://issues.apache.org/jira/browse/LUCENE-6276 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir > Attachments: LUCENE-6276-ExactPhraseOnly.patch, > LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, > LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch > > > We could add a method like TwoPhaseDISI.matchCost() defined as something like > estimate of nanoseconds or similar. > ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array > so that cheaper ones are called first. Today it has no idea if one scorer is > a simple phrase scorer on a short field vs another that might do some geo > calculation or more expensive stuff. > PhraseScorers could implement this based on index statistics (e.g. > totalTermFreq/maxDoc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[ https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962369#comment-14962369 ] Paul Elschot edited comment on LUCENE-6276 at 10/18/15 1:16 PM: 2nd patch of 18 Oct 2015. More improvements: - Add TwoPhaseIterator.termPositionsCost() for use in matchCost() implementations. This replaces the earlier PhraseQuery.expTermFreqInMatchingDoc(). - In SpanOrQuery use better avarage cost for matchCost(). - Move positionsCost() throwing UOE from Near/ContainSpans to ConjunctionSpans only. - matchCost must be non negative in AssertingScorer. - Use a random matchCost in RandomApproximationQuery. - Better javadocs and code comments. was (Author: paul.elsc...@xs4all.nl): 2nd patch of 18 Oct 2015. More improvements: - Add TwoPhaseIterator.termPositionsCost() for use in matchCost() implementations. This replaces the earlier PhraseQuery.expTermFreqInMatchingDoc(). - In SpanOrQuery use better avarage cost for matchCost(). - Move positionsCost() throwing UOE from Near/ContainSpans to ConjunctionSpans only. - matchCost most be non negative in AssertingScorer. - Use a random matchCost in RandomApproximationQuery. - Better javadocs and code comments. > Add matchCost() api to TwoPhaseDocIdSetIterator > --- > > Key: LUCENE-6276 > URL: https://issues.apache.org/jira/browse/LUCENE-6276 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir > Attachments: LUCENE-6276-ExactPhraseOnly.patch, > LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, > LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch > > > We could add a method like TwoPhaseDISI.matchCost() defined as something like > estimate of nanoseconds or similar. > ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array > so that cheaper ones are called first. Today it has no idea if one scorer is > a simple phrase scorer on a short field vs another that might do some geo > calculation or more expensive stuff. > PhraseScorers could implement this based on index statistics (e.g. > totalTermFreq/maxDoc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6801) PhraseQuery incorrectly advertises it supports terms at the same position
[
https://issues.apache.org/jira/browse/LUCENE-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-6801:
-
Attachment: LUCENE_6801.patch
The following patch enhances the javadocs on PhraseQuery and MultiPhraseQuery.
I also made trivial code refactorings in MultiPhraseQuery that my IDE pointed
out (like using Java 5 for loop where possible or removing explicit primitive
boxing/unboxing)
> PhraseQuery incorrectly advertises it supports terms at the same position
> -
>
> Key: LUCENE-6801
> URL: https://issues.apache.org/jira/browse/LUCENE-6801
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE_6801.patch
>
>
> The following in PhraseQuery has been here since Sept 15th 2004 (by "goller"):
> {code:java}
> /**
> * Adds a term to the end of the query phrase.
> * The relative position of the term within the phrase is specified
> explicitly.
> * This allows e.g. phrases with more than one term at the same position
> * or phrases with gaps (e.g. in connection with stopwords).
> *
> */
> public Builder add(Term term, int position) {
> {code}
> Of course this isn't true; it's why we have MultiPhraseQuery. Yet we even
> allow you to have consecutive terms with the same positions. We shouldn't
> allow that; we should throw an exception. For my own sanity, I modified a
> simple MultiPhraseQuery test to use PhraseQuery instead and of course it
> didn't work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8114) Grouping.java: sort variable names confusion
[
https://issues.apache.org/jira/browse/SOLR-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962432#comment-14962432
]
ASF subversion and git services commented on SOLR-8114:
---
Commit 1709288 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1709288 ]
SOLR-8114: in Grouping.java rename sort to groupSort
> Grouping.java: sort variable names confusion
>
>
> Key: SOLR-8114
> URL: https://issues.apache.org/jira/browse/SOLR-8114
> Project: Solr
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8114-part1of2.patch, SOLR-8114-part2of2.patch
>
>
> The undistributed case i.e. {{solr/Grouping.java}}'s variable names
> confusingly differ from the names used by lucene (and by the distributed
> case).
> Specifically the name {{groupSort}} in lucene (and in the distributed case)
> means between-groups-sort but in the Grouping.java it means within-group-sort.
> lucene:
> {code}
> TermFirstPassGroupingCollector(... Sort groupSort ...)
> TermSecondPassGroupingCollector(... Sort groupSort, Sort withinGroupSort ...)
> {code}
> solr:
> {code}
> SearchGroupsFieldCommand.java: firstPassGroupingCollector = new
> TermFirstPassGroupingCollector(field.getName(), groupSort, topNGroups);
> TopGroupsFieldCommand.java: secondPassCollector = new
> TermSecondPassGroupingCollector(... groupSort, sortWithinGroup ...);
> Grouping.java:public Sort groupSort; // the sort of the documents
> *within* a single group.
> Grouping.java:public Sort sort;// the sort between groups
> Grouping.java: firstPass = new TermFirstPassGroupingCollector(groupBy, sort,
> actualGroupsToFind);
> Grouping.java: secondPass = new TermSecondPassGroupingCollector(... sort,
> groupSort ...);
> {code}
> This JIRA proposes to rename the Grouping.java variables to remove the
> confusion:
> * part 1: in Grouping.java rename groupSort to withinGroupSort
> * part 2: in Grouping.java rename sort to groupSort
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 133 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/133/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.update.AutoCommitTest.testMaxTime Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([2B981CD37F2290B:984DFC2FA968B537]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:766) at org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=id:529&qt=standard&start=0&rows=20&version=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:759) ... 40 more Build Log: [...truncated 9593 lines...] [junit4] Suite: org.apache.solr.update.A
[jira] [Commented] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[
https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962471#comment-14962471
]
David Smiley commented on LUCENE-6276:
--
This is neat. Couple things...
* RandomAccessWeight's 2-phase should probably call to a protected method on
RAW so that a subclass could define the cost based on how expensive using the
Bits is. Maybe it should be abstract and not zero?
* It will be difficult for many of the 2-phase implementations to calculate a
matchCost -- particularly the ones _not_ based on the number of term positions.
What to do? A constant of '0' (which you often labelled FIXME) is way too
cheap I think? Maybe the best we can hope for is simply a stable sort of
same-cost 2-phases and assuming that the order of queries added to a
BooleanQuery.Builder remains stable. This at least allows the user to tune
performance by changing the clause order for such constant matchCost queries.
But I see that the latest BooleanQuery.Builder is _not_ stable due to use of
HashSet / MultiSet versus LinkedHashSet which would be stable. What do you
think [~jpountz]? Alternatively (or in addition) a query wrapper could allow
explicitly setting a cost (vaguely similar to Solr's ExtendedQuery.getCost).
This could look similar to BoostQuery but for 2-phase matchCost instead of
score.
* Maybe the {{explain}} could possibly display the matchCost? It'd be nice to
troubleshoot/inspect for diagnostics somehow. Not critical, of course.
> Add matchCost() api to TwoPhaseDocIdSetIterator
> ---
>
> Key: LUCENE-6276
> URL: https://issues.apache.org/jira/browse/LUCENE-6276
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6276-ExactPhraseOnly.patch,
> LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch,
> LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch
>
>
> We could add a method like TwoPhaseDISI.matchCost() defined as something like
> estimate of nanoseconds or similar.
> ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array
> so that cheaper ones are called first. Today it has no idea if one scorer is
> a simple phrase scorer on a short field vs another that might do some geo
> calculation or more expensive stuff.
> PhraseScorers could implement this based on index statistics (e.g.
> totalTermFreq/maxDoc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14576 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14576/ Java: 32bit/jdk1.8.0_60 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:38799/collection1 expected:<68> but was:<67> Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:38799/collection1 expected:<68> but was:<67> at __randomizedtesting.SeedInfo.seed([57B03F6C7F4DF853:DFE400B6D1B195AB]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:333) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.ru
[jira] [Updated] (SOLR-8165) Add new book 'Apache Solr Essentials'
[ https://issues.apache.org/jira/browse/SOLR-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Gazzarini updated SOLR-8165: --- Attachment: SOLR-8165.patch Hi, this is the patch containing the book description and the cover image. I inserted it in the list following a chronological order. > Add new book 'Apache Solr Essentials' > - > > Key: SOLR-8165 > URL: https://issues.apache.org/jira/browse/SOLR-8165 > Project: Solr > Issue Type: Task >Reporter: Zico Fernandes > Attachments: SOLR-8165.patch > > > Packt Publishing is proud to finally announce the book "Apache Solr > Essentials" by Andrea Gazzarini. This book is specifically for developers > with practical experience of technologies similar to Apache Solr and want to > develop efficient search applications. It leverages the power of Apache Solr > to create efficient search applications and upskill the readers with the > conceptual framework for robust search application creation. > Apache Solr Essentials is a fast paced guide that maximizes the data > searching capability of your application and help you customize your search > applications to meet your project specifications. > Apache Solr Essentials will quickly help you learn the process of creating a > scalable, efficient, and powerful search application. The book starts off by > explaining the fundamentals of Solr and then goes on to cover various topics > such as data indexing, ways of extending Solr, client APIs and their indexing > and data searching capabilities, an introduction to the administration, > monitoring, and tuning of a Solr instance, as well as the concepts of > sharding and replication. Next, you'll learn about various Solr extensions > and how to contribute to the Solr community. By the end of this book, you > will be able to create excellent search applications with the help of Solr. > Click here to read more about Apache Solr Essentials. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 504 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/504/ 1 tests failed. FAILED: org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:46832/g_a/zp/collection1] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:46832/g_a/zp/collection1] at __randomizedtesting.SeedInfo.seed([392A3B4FAD4CEF61:B17E049503B08299]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1378) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:103) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:87) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMetho
[jira] [Commented] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[ https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962541#comment-14962541 ] Paul Elschot commented on LUCENE-6276: -- I left the matchCosts that I could not easily determine at zero and added a CHECKME. This is more an indication that refinement is possible. Sorting subscorers/subspans by cost and matchCost is probably better than relying on any given order. Anyway I don't expect the impact of matchCost on performance be more than 4-8% except maybe for really complex queries. Showing the matchCost in explain will be tricky because it is computed by LeafReaderContext, i.e. by segment. The matchCost is not yet used for the second phase in disjunctions. Yet another priority queue might be needed for that, so I'd prefer to delay that to another issue. > Add matchCost() api to TwoPhaseDocIdSetIterator > --- > > Key: LUCENE-6276 > URL: https://issues.apache.org/jira/browse/LUCENE-6276 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir > Attachments: LUCENE-6276-ExactPhraseOnly.patch, > LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, > LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch > > > We could add a method like TwoPhaseDISI.matchCost() defined as something like > estimate of nanoseconds or similar. > ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array > so that cheaper ones are called first. Today it has no idea if one scorer is > a simple phrase scorer on a short field vs another that might do some geo > calculation or more expensive stuff. > PhraseScorers could implement this based on index statistics (e.g. > totalTermFreq/maxDoc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[
https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962547#comment-14962547
]
Paul Elschot commented on LUCENE-6276:
--
Another thing to be determined is this the relative cost of span queries vs
phrase queries.
The code for that is in SpanTermQuery here:
{code}
/** A guess of
* the relative cost of dealing with the term positions
* when using a SpanNearQuery instead of a PhraseQuery.
*/
private final float PHRASE_TO_SPAN_TERM_POSITIONS_COST = 4.0f;
{code}
This is a guess because it is only based on my recollection of a few years ago
of that performance of PhraseQuery was about 4 times as fast as an ordered
SpanNear.
In the long term it is probably better to make this a configurable parameter.
> Add matchCost() api to TwoPhaseDocIdSetIterator
> ---
>
> Key: LUCENE-6276
> URL: https://issues.apache.org/jira/browse/LUCENE-6276
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6276-ExactPhraseOnly.patch,
> LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch,
> LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch
>
>
> We could add a method like TwoPhaseDISI.matchCost() defined as something like
> estimate of nanoseconds or similar.
> ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array
> so that cheaper ones are called first. Today it has no idea if one scorer is
> a simple phrase scorer on a short field vs another that might do some geo
> calculation or more expensive stuff.
> PhraseScorers could implement this based on index statistics (e.g.
> totalTermFreq/maxDoc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[
https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962547#comment-14962547
]
Paul Elschot edited comment on LUCENE-6276 at 10/18/15 6:25 PM:
Another thing to be determined is this the relative cost of span queries vs
phrase queries.
The code for that is in SpanTermQuery here:
{code}
/** A guess of
* the relative cost of dealing with the term positions
* when using a SpanNearQuery instead of a PhraseQuery.
*/
private final float PHRASE_TO_SPAN_TERM_POSITIONS_COST = 4.0f;
{code}
This is a guess because it is only based on my recollection of a few years ago
that the performance of PhraseQuery was about 4 times better than an ordered
SpanNear.
In the long term it is probably better to make this a configurable parameter.
was (Author: paul.elsc...@xs4all.nl):
Another thing to be determined is this the relative cost of span queries vs
phrase queries.
The code for that is in SpanTermQuery here:
{code}
/** A guess of
* the relative cost of dealing with the term positions
* when using a SpanNearQuery instead of a PhraseQuery.
*/
private final float PHRASE_TO_SPAN_TERM_POSITIONS_COST = 4.0f;
{code}
This is a guess because it is only based on my recollection of a few years ago
of that performance of PhraseQuery was about 4 times as fast as an ordered
SpanNear.
In the long term it is probably better to make this a configurable parameter.
> Add matchCost() api to TwoPhaseDocIdSetIterator
> ---
>
> Key: LUCENE-6276
> URL: https://issues.apache.org/jira/browse/LUCENE-6276
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6276-ExactPhraseOnly.patch,
> LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch,
> LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch
>
>
> We could add a method like TwoPhaseDISI.matchCost() defined as something like
> estimate of nanoseconds or similar.
> ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array
> so that cheaper ones are called first. Today it has no idea if one scorer is
> a simple phrase scorer on a short field vs another that might do some geo
> calculation or more expensive stuff.
> PhraseScorers could implement this based on index statistics (e.g.
> totalTermFreq/maxDoc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6276) Add matchCost() api to TwoPhaseDocIdSetIterator
[ https://issues.apache.org/jira/browse/LUCENE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962553#comment-14962553 ] Paul Elschot commented on LUCENE-6276: -- Talking about priority queues, there is also this one: LUCENE-6453. > Add matchCost() api to TwoPhaseDocIdSetIterator > --- > > Key: LUCENE-6276 > URL: https://issues.apache.org/jira/browse/LUCENE-6276 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir > Attachments: LUCENE-6276-ExactPhraseOnly.patch, > LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, > LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch > > > We could add a method like TwoPhaseDISI.matchCost() defined as something like > estimate of nanoseconds or similar. > ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array > so that cheaper ones are called first. Today it has no idea if one scorer is > a simple phrase scorer on a short field vs another that might do some geo > calculation or more expensive stuff. > PhraseScorers could implement this based on index statistics (e.g. > totalTermFreq/maxDoc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60) - Build # 14287 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14287/ Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudCluster Error Message: 68 threads leaked from SUITE scope at org.apache.solr.cloud.TestMiniSolrCloudCluster: 1) Thread[id=1972, name=Scheduler-1760077041, state=TIMED_WAITING, group=TGRP-TestMiniSolrCloudCluster] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)2) Thread[id=1945, name=qtp552805075-1945-selector-ServerConnectorManager@4469fb6c/2, state=RUNNABLE, group=TGRP-TestMiniSolrCloudCluster] at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600) at org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549) at org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745)3) Thread[id=2033, name=Thread-685, state=WAITING, group=TGRP-TestMiniSolrCloudCluster] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at org.apache.solr.core.CloserThread.run(CoreContainer.java:1155)4) Thread[id=1985, name=qtp1493758743-1985, state=TIMED_WAITING, group=TGRP-TestMiniSolrCloudCluster] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:389) at org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:531) at org.eclipse.jetty.util.thread.QueuedThreadPool.access$700(QueuedThreadPool.java:47) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:745)5) Thread[id=2028, name=jetty-launcher-309-thread-5-EventThread, state=WAITING, group=TGRP-TestMiniSolrCloudCluster] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:494) 6) Thread[id=1969, name=qtp1965679568-1969-selector-ServerConnectorManager@216e4e7f/3, state=RUNNABLE, group=TGRP-TestMiniSolrCloudCluster] at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600) at org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549) at org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(Queued
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_80) - Build # 5214 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5214/ Java: 32bit/jdk1.7.0_80 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([EA6D67E07F66B2B:86F2E9A4A90A06D3]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.junit.Assert.assertNull(Assert.java:562) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist(CollectionsAPIDistributedZkTest.java:519) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:166) 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 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.jav
[jira] [Commented] (SOLR-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure
[
https://issues.apache.org/jira/browse/SOLR-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962604#comment-14962604
]
Gus Heck commented on SOLR-8135:
also with {code}ant test -Dtestcase=SolrCloudExampleTest
-Dtests.method=testLoadDocsIntoGettingStartedCollection
-Dtests.seed=D7797CB78640592B -Dtests.slow=true -Dtests.locale=mt_MT
-Dtests.timezone=Jamaica -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
{code}
on 5.x
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible
> failure
> --
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Hoss Man
> Attachments: SOLR-8135.failure.log
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch
> -- seed reproduces against pristine trunk...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=SolrCloudExampleTest
> -Dtests.method=testLoadDocsIntoGettingStartedCollection
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 49.5s |
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Delete action failed!
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>[junit4]> at
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>[junit4]> at
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b85) - Build # 14578 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14578/ Java: 64bit/jdk1.9.0-ea-b85 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: Captured an uncaught exception in thread: Thread[id=11751, name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=11751, name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Caused by: org.apache.solr.common.cloud.ZooKeeperException: at __randomizedtesting.SeedInfo.seed([110816795720D16D]:0) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:232) Caused by: org.apache.solr.common.SolrException: java.io.FileNotFoundException: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_110816795720D16D-001/jetty-001/cores/source_collection_shard1_replica2/data/tlog/tlog.007.1515401178201980928 (No such file or directory) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:244) at org.apache.solr.update.CdcrTransactionLog.incref(CdcrTransactionLog.java:173) at org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1079) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1579) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610) at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:877) at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:534) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225) Caused by: java.io.FileNotFoundException: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_110816795720D16D-001/jetty-001/cores/source_collection_shard1_replica2/data/tlog/tlog.007.1515401178201980928 (No such file or directory) at java.io.RandomAccessFile.open0(Native Method) at java.io.RandomAccessFile.open(RandomAccessFile.java:327) at java.io.RandomAccessFile.(RandomAccessFile.java:243) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:236) ... 7 more Build Log: [...truncated 10736 lines...] [junit4] Suite: org.apache.solr.cloud.CdcrReplicationHandlerTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_110816795720D16D-001/init-core-data-001 [junit4] 2> 1064865 INFO (SUITE-CdcrReplicationHandlerTest-seed#[110816795720D16D]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) [junit4] 2> 1064865 INFO (SUITE-CdcrReplicationHandlerTest-seed#[110816795720D16D]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 1064867 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 1064867 INFO (Thread-3971) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 1064867 INFO (Thread-3971) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 1064968 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.ZkTestServer start zk server on port:37729 [junit4] 2> 1064968 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 1064968 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 1064971 INFO (zkCallback-2091-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@63685440 name:ZooKeeperConnection Watcher:127.0.0.1:37729 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 1064971 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 1064971 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 1064971 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 1064985 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[110816795720D16D]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4]
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3643 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3643/ 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup Error Message: Failed to create backup Stack Trace: java.lang.AssertionError: Failed to create backup at __randomizedtesting.SeedInfo.seed([550CF99A28A9F5F7:1487D9FF0F1706B8]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.handler.CheckBackupStatus.fetchStatus(CheckBackupStatus.java:51) at org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup(TestReplicationHandlerBackup.java:197) 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 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11031 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandlerBackup [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandlerBackup_550CF99A28A9F5F7-001
[jira] [Commented] (SOLR-8114) Grouping.java: sort variable names confusion
[
https://issues.apache.org/jira/browse/SOLR-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962652#comment-14962652
]
ASF subversion and git services commented on SOLR-8114:
---
Commit 1709324 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1709324 ]
SOLR-8114: in Grouping.java rename sort to groupSort (merge in revision 1709288
from trunk)
> Grouping.java: sort variable names confusion
>
>
> Key: SOLR-8114
> URL: https://issues.apache.org/jira/browse/SOLR-8114
> Project: Solr
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8114-part1of2.patch, SOLR-8114-part2of2.patch
>
>
> The undistributed case i.e. {{solr/Grouping.java}}'s variable names
> confusingly differ from the names used by lucene (and by the distributed
> case).
> Specifically the name {{groupSort}} in lucene (and in the distributed case)
> means between-groups-sort but in the Grouping.java it means within-group-sort.
> lucene:
> {code}
> TermFirstPassGroupingCollector(... Sort groupSort ...)
> TermSecondPassGroupingCollector(... Sort groupSort, Sort withinGroupSort ...)
> {code}
> solr:
> {code}
> SearchGroupsFieldCommand.java: firstPassGroupingCollector = new
> TermFirstPassGroupingCollector(field.getName(), groupSort, topNGroups);
> TopGroupsFieldCommand.java: secondPassCollector = new
> TermSecondPassGroupingCollector(... groupSort, sortWithinGroup ...);
> Grouping.java:public Sort groupSort; // the sort of the documents
> *within* a single group.
> Grouping.java:public Sort sort;// the sort between groups
> Grouping.java: firstPass = new TermFirstPassGroupingCollector(groupBy, sort,
> actualGroupsToFind);
> Grouping.java: secondPass = new TermSecondPassGroupingCollector(... sort,
> groupSort ...);
> {code}
> This JIRA proposes to rename the Grouping.java variables to remove the
> confusion:
> * part 1: in Grouping.java rename groupSort to withinGroupSort
> * part 2: in Grouping.java rename sort to groupSort
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14579 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14579/ Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([6C7CA71AE3EC27E8:CB381FBE8E573451]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationWithTruncatedTlog(CdcrReplicationHandlerTest.java:121) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.Sta
[jira] [Commented] (LUCENE-6825) Add multidimensional byte[] indexing support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962676#comment-14962676 ] ASF subversion and git services commented on LUCENE-6825: - Commit 1709330 from [~mikemccand] in branch 'dev/branches/lucene6825' [ https://svn.apache.org/r1709330 ] LUCENE-6825: remove all nocommits; add missing MDW.createTempOutput wrapping; fix double-write per dim during build > Add multidimensional byte[] indexing support to Lucene > -- > > Key: LUCENE-6825 > URL: https://issues.apache.org/jira/browse/LUCENE-6825 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: Trunk > > Attachments: LUCENE-6825.patch > > > I think we should graduate the low-level block KD-tree data structure > from sandbox into Lucene's core? > This can be used for very fast 1D range filtering for numerics, > removing the 8 byte (long/double) limit we have today, so e.g. we > could efficiently support BigInteger, BigDecimal, IPv6 addresses, etc. > It can also be used for > 1D use cases, like 2D (lat/lon) and 3D > (x/y/z with geo3d) geo shape intersection searches. > The idea here is to add a new part of the Codec API (DimensionalFormat > maybe?) that can do low-level N-dim point indexing and at runtime > exposes only an "intersect" method. > It should give sizable performance gains (smaller index, faster > searching) over what we have today, and even over what auto-prefix > with efficient numeric terms would do. > There are many steps here ... and I think adding this is analogous to > how we added FSTs, where we first added low level data structure > support and then gradually cutover the places that benefit from an > FST. > So for the first step, I'd like to just add the low-level block > KD-tree impl into oal.util.bkd, but make a couple improvements over > what we have now in sandbox: > * Use byte[] as the value not int (@rjernst's good idea!) > * Generalize it to arbitrary dimensions vs. specialized/forked 1D, > 2D, 3D cases we have now > This is already hard enough :) After that we can build the > DimensionalFormat on top, then cutover existing specialized block > KD-trees. We also need to fix OfflineSorter to use Directory API so > we don't fill up /tmp when building a block KD-tree. > A block KD-tree is at heart an inverted data structure, like postings, > but is also similar to auto-prefix in that it "picks" proper > N-dimensional "terms" (leaf blocks) to index based on how the specific > data being indexed is distributed. I think this is a big part of why > it's so fast, i.e. in contrast to today where we statically slice up > the space into the same terms regardless of the data (trie shifting, > morton codes, geohash, hilbert curves, etc.) > I'm marking this as trunk only for now... as we iterate we can see if > it could maybe go back to 5.x... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6825) Add multidimensional byte[] indexing support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962680#comment-14962680 ] ASF subversion and git services commented on LUCENE-6825: - Commit 1709331 from [~mikemccand] in branch 'dev/branches/lucene6825' [ https://svn.apache.org/r1709331 ] LUCENE-6825: merge trunk > Add multidimensional byte[] indexing support to Lucene > -- > > Key: LUCENE-6825 > URL: https://issues.apache.org/jira/browse/LUCENE-6825 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: Trunk > > Attachments: LUCENE-6825.patch > > > I think we should graduate the low-level block KD-tree data structure > from sandbox into Lucene's core? > This can be used for very fast 1D range filtering for numerics, > removing the 8 byte (long/double) limit we have today, so e.g. we > could efficiently support BigInteger, BigDecimal, IPv6 addresses, etc. > It can also be used for > 1D use cases, like 2D (lat/lon) and 3D > (x/y/z with geo3d) geo shape intersection searches. > The idea here is to add a new part of the Codec API (DimensionalFormat > maybe?) that can do low-level N-dim point indexing and at runtime > exposes only an "intersect" method. > It should give sizable performance gains (smaller index, faster > searching) over what we have today, and even over what auto-prefix > with efficient numeric terms would do. > There are many steps here ... and I think adding this is analogous to > how we added FSTs, where we first added low level data structure > support and then gradually cutover the places that benefit from an > FST. > So for the first step, I'd like to just add the low-level block > KD-tree impl into oal.util.bkd, but make a couple improvements over > what we have now in sandbox: > * Use byte[] as the value not int (@rjernst's good idea!) > * Generalize it to arbitrary dimensions vs. specialized/forked 1D, > 2D, 3D cases we have now > This is already hard enough :) After that we can build the > DimensionalFormat on top, then cutover existing specialized block > KD-trees. We also need to fix OfflineSorter to use Directory API so > we don't fill up /tmp when building a block KD-tree. > A block KD-tree is at heart an inverted data structure, like postings, > but is also similar to auto-prefix in that it "picks" proper > N-dimensional "terms" (leaf blocks) to index based on how the specific > data being indexed is distributed. I think this is a big part of why > it's so fast, i.e. in contrast to today where we statically slice up > the space into the same terms regardless of the data (trie shifting, > morton codes, geohash, hilbert curves, etc.) > I'm marking this as trunk only for now... as we iterate we can see if > it could maybe go back to 5.x... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory
[ https://issues.apache.org/jira/browse/SOLR-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-8113: --- Attachment: SOLR-8113.patch After chatting briefly with [~hossman] at Lucene/Solr Revolution it became clear that the key point of his suggestion was the complete separation of the selection phase and the replacement phase. The attached patch provides his suggested configuration options. This does introduce the possibility that a field could match the selector and not match the replacement pattern. I have handled this case by ignoring such fields (as if they were not selected) and logging a debug message. I also wound up creating my own entire unit test before I found the existing tests in FieldMutatingProcessorFactoryTest. I have moved the tests from there into my test class (CloneFieldUpdateFactoryTest) as well so that they are easier to find. Both tests read the same config file. > Accept replacement strings in CloneFieldUpdateProcessorFactory > -- > > Key: SOLR-8113 > URL: https://issues.apache.org/jira/browse/SOLR-8113 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 5.3 >Reporter: Gus Heck > Attachments: SOLR-8113.patch, SOLR-8113.patch > > > Presently CloneFieldUpdateProcessorFactory accepts regular expressions to > select source fields, which mirrors wildcards in the source for copyField in > the schema. This patch adds a counterpart to copyField's wildcards in the > dest attribute by interpreting the dest parameter as a regex replacement > string. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b85) - Build # 14580 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14580/ Java: 64bit/jdk1.9.0-ea-b85 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample Error Message: Could not find a healthy node to handle the request. Stack Trace: org.apache.solr.common.SolrException: Could not find a healthy node to handle the request. at __randomizedtesting.SeedInfo.seed([DAFEC60B81ABE1A2:18F26C1B6DE24C4]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464) at org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:443) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:520) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapte
[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 134 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/134/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.update.AutoCommitTest.testMaxDocs Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([DA2F6D8BB760D027:63AEBB549B8AD4AD]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:766) at org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=id:14&qt=standard&start=0&rows=20&version=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:759) ... 40 more Build Log: [...truncated 10012 lines...] [junit4] Suite: org.apache.solr.updat
[jira] [Reopened] (LUCENE-6829) OfflineSorter should use Directory API
[
https://issues.apache.org/jira/browse/LUCENE-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reopened LUCENE-6829:
My Jenkins found a nightly seed that causes
{{TestStressIndexing..testStressIndexAndSearching()}} to fail nearly 100% of
the time:
{noformat}
[junit4] Suite: org.apache.lucene.index.TestStressIndexing
[junit4] 1> Thread[Thread-66,5,TGRP-TestStressIndexing]: exc
[junit4] 1> java.lang.NullPointerException
[junit4] 1>at
java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:317)
[junit4] 1>at
java.util.ComparableTimSort.sort(ComparableTimSort.java:198)
[junit4] 1>at java.util.Arrays.sort(Arrays.java:1246)
[junit4] 1>at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:653)
[junit4] 1>at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
[junit4] 1>at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
[junit4] 1>at
org.apache.lucene.index.TestStressIndexing$SearcherThread.doWork(TestStressIndexing.java:106)
[junit4] 1>at
org.apache.lucene.index.TestStressIndexing$TimedThread.run(TestStressIndexing.java:48)
[junit4] 1> Thread[Thread-65,5,TGRP-TestStressIndexing]: exc
[junit4] 1> java.lang.NullPointerException
[junit4] 1>at
java.util.ComparableTimSort.binarySort(ComparableTimSort.java:258)
[junit4] 1>at
java.util.ComparableTimSort.sort(ComparableTimSort.java:203)
[junit4] 1>at java.util.Arrays.sort(Arrays.java:1246)
[junit4] 1>at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:653)
[junit4] 1>at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
[junit4] 1>at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
[junit4] 1>at
org.apache.lucene.index.TestStressIndexing$SearcherThread.doWork(TestStressIndexing.java:106)
[junit4] 1>at
org.apache.lucene.index.TestStressIndexing$TimedThread.run(TestStressIndexing.java:48)
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing
-Dtests.method=testStressIndexAndSearching -Dtests.seed=98FCDFF6002C97E1
-Dtests.nightly=true -Dtests.slow=true -Dtests.locale=tr
-Dtests.timezone=Indian/Comoro -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.12s J3 | TestStressIndexing.testStressIndexAndSearching
<<<
[junit4]> Throwable #1: java.lang.AssertionError
[junit4]>at
__randomizedtesting.SeedInfo.seed([98FCDFF6002C97E1:7F95878F4DC6F61D]:0)
[junit4]>at
org.apache.lucene.index.TestStressIndexing.runStressTest(TestStressIndexing.java:155)
[junit4]>at
org.apache.lucene.index.TestStressIndexing.testStressIndexAndSearching(TestStressIndexing.java:172)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene53):
{contents=PostingsFormat(name=Memory doPackFST= false),
id=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128)))},
docValues:{}, sim=ClassicSimilarity, locale=tr, timezone=Indian/Comoro
[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=573503112,total=1469054976
[junit4] 2> NOTE: All tests run in this JVM: [TestNumericRangeQuery32,
TestMmapDirectory, TestSpans, TestIndexWriterDelete, TestIndexReaderClose,
TestSearchForDuplicates, TestStringHelper, TestPackedInts,
TestControlledRealTimeReopenThread, TestDirectory, TestMinimize,
TestNamedSPILoader, TestLucene50SegmentInfoFormat, TestStressIndexing]
{noformat}
I put a debug println in {{SegmentInfos.FindSegmentsFile.run()}} and found that
{{RAMDirectory.listAll()}} can sometimes produce null entries. [~mikemccand],
looks like your commit to {{RAMDirector.listAll()}} on this issue is the
problem:
{code:java}
@@ -111,10 +111,7 @@
// and do not synchronize or anything stronger. it's great for testing!
// NOTE: fileMap.keySet().toArray(new String[0]) is broken in non Sun JDKs,
// and the code below is resilient to map changes during the array
population.
-Set fileNames = fileMap.keySet();
-List names = new ArrayList<>(fileNames.size());
-for (String name : fileNames) names.add(name);
-return names.toArray(new String[names.size()]);
+return fileMap.keySet().toArray(new String[fileMap.size()]);
}
{code}
I'm guessing that an inconsistency between {{fileMap.size()}} and
{{fileMap.keySet()}} will cause this issue - if the number of entries goes down
inbetween these calls then trailing entries in the resulting array will be null.
> OfflineSorter should use Directory API
>
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 990 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/990/ 2 tests failed. FAILED: org.apache.solr.TestDistributedSearch.test Error Message: Captured an uncaught exception in thread: Thread[id=48950, name=Thread-48086, state=RUNNABLE, group=TGRP-TestDistributedSearch] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=48950, name=Thread-48086, state=RUNNABLE, group=TGRP-TestDistributedSearch] at __randomizedtesting.SeedInfo.seed([411FC918F9FFEC9E:C94BF6C257038166]:0) Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:33250//collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:42) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:749) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:732) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:409) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:151) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2079) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:667) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([411FC918F9FFEC9E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:1110) FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=5249, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=5249, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:51918/bx/e: collection already exists: awholynewstresscollection_collection3_9 at __randomizedtesting.SeedInfo.seed([411FC918F9FFEC9E]:0) at org.apach
[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b85) - Build # 14291 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14291/ Java: 64bit/jdk1.9.0-ea-b85 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithKerberosAlt Error Message: 5 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=11323, name=changePwdReplayCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:747)2) Thread[id=11322, name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:516) at java.util.TimerThread.mainLoop(Timer.java:526) at java.util.TimerThread.run(Timer.java:505)3) Thread[id=11326, name=kdcReplayCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:747)4) Thread[id=11324, name=ou=system.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:747)5) Thread[id=11325, name=groupCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:747) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=11323, name=changePwdReplayCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.u
[jira] [Created] (LUCENE-6842) No way to limit the fields cached in memory and leads to OOM when there are thousand of fields (thousands)
Bala Kolla created LUCENE-6842: -- Summary: No way to limit the fields cached in memory and leads to OOM when there are thousand of fields (thousands) Key: LUCENE-6842 URL: https://issues.apache.org/jira/browse/LUCENE-6842 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6.1 Environment: Linux, openjdk 1.6.x Reporter: Bala Kolla I am opening this defect to get some guidance on how to handle a case of server running out of memory and it seems like it's something to do how we index. But want to know if there is anyway to reduce the impact of this on memory usage before we look into the way of reducing the number of fields. Basically we have many thousands of fields being indexed and it's causing a large amount of memory being used (25GB) and eventually leading to application to hang and force us to restart every few minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6829) OfflineSorter should use Directory API
[
https://issues.apache.org/jira/browse/LUCENE-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962819#comment-14962819
]
Steve Rowe commented on LUCENE-6829:
Another test failure my Jenkins found with the same root cause, only reproduces
8/100 iters for me:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterCommit -Dtests.method=testPrepareCommitRollback
-Dtests.seed=98FCDFF6002C97E1 -Dtests.nightly=true -Dtests.slow=true
-Dtests.linedocsfile=/home/jenkins/lucene-data/e
nwiki.random.lines.txt -Dtests.locale=is -Dtests.timezone=Australia/Sydney
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.32s | TestIndexWriterCommit.testPrepareCommitRollback <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at __randomizedtesting.SeedInfo.seed([98FCDFF6002C97E1:9
4F93159522F894E]:0)
[junit4]>at java.util.ComparableTimSort.binarySort(ComparableTimS
ort.java:258)
[junit4]>at java.util.ComparableTimSort.sort(ComparableTimSort.ja
va:203)
[junit4]>at java.util.Arrays.sort(Arrays.java:1246)
[junit4]>at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:660)
[junit4]>at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
[junit4]>at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
[junit4]>at
org.apache.lucene.index.TestIndexWriterCommit.testPrepareCommitRollback(TestIndexWriterCommit.java:599)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene53):
{content=Lucene50(blocksize=128)}, docValues:{},
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {content=DFR
I(ne)3(800.0)}, locale=is, timezone=Australia/Sydney
[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=401791056,total=514850816
[junit4] 2> NOTE: All tests run in this JVM: [TestIndexWriterCommit]
{noformat}
> OfflineSorter should use Directory API
> --
>
> Key: LUCENE-6829
> URL: https://issues.apache.org/jira/browse/LUCENE-6829
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6829.patch, LUCENE-6829.patch, LUCENE-6829.patch,
> LUCENE-6829.patch
>
>
> I think this is a blocker for LUCENE-6825, because the block KD-tree makes
> heavy use of OfflineSorter and we don't want to fill up tmp space ...
> This should be a straightforward cutover, but there are some challenges, e.g.
> the test was failing because virus checker blocked deleting of files.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6829) OfflineSorter should use Directory API
[
https://issues.apache.org/jira/browse/LUCENE-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962819#comment-14962819
]
Steve Rowe edited comment on LUCENE-6829 at 10/19/15 4:24 AM:
--
Another test failure my Jenkins found with the same root cause, only reproduces
8/100 iters for me:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterCommit -Dtests.method=testPrepareCommitRollback
-Dtests.seed=98FCDFF6002C97E1 -Dtests.nightly=true -Dtests.slow=true
-Dtests.linedocsfile=/home/jenkins/lucene-data/e
nwiki.random.lines.txt -Dtests.locale=is -Dtests.timezone=Australia/Sydney
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.32s | TestIndexWriterCommit.testPrepareCommitRollback <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at
__randomizedtesting.SeedInfo.seed([98FCDFF6002C97E1:94F93159522F894E]:0)
[junit4]>at
java.util.ComparableTimSort.binarySort(ComparableTimSort.java:258)
[junit4]>at
java.util.ComparableTimSort.sort(ComparableTimSort.java:203)
[junit4]>at java.util.Arrays.sort(Arrays.java:1246)
[junit4]>at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:660)
[junit4]>at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
[junit4]>at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
[junit4]>at
org.apache.lucene.index.TestIndexWriterCommit.testPrepareCommitRollback(TestIndexWriterCommit.java:599)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene53):
{content=Lucene50(blocksize=128)}, docValues:{},
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {content=DFR
I(ne)3(800.0)}, locale=is, timezone=Australia/Sydney
[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=401791056,total=514850816
[junit4] 2> NOTE: All tests run in this JVM: [TestIndexWriterCommit]
{noformat}
was (Author: steve_rowe):
Another test failure my Jenkins found with the same root cause, only reproduces
8/100 iters for me:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterCommit -Dtests.method=testPrepareCommitRollback
-Dtests.seed=98FCDFF6002C97E1 -Dtests.nightly=true -Dtests.slow=true
-Dtests.linedocsfile=/home/jenkins/lucene-data/e
nwiki.random.lines.txt -Dtests.locale=is -Dtests.timezone=Australia/Sydney
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.32s | TestIndexWriterCommit.testPrepareCommitRollback <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at __randomizedtesting.SeedInfo.seed([98FCDFF6002C97E1:9
4F93159522F894E]:0)
[junit4]>at java.util.ComparableTimSort.binarySort(ComparableTimS
ort.java:258)
[junit4]>at java.util.ComparableTimSort.sort(ComparableTimSort.ja
va:203)
[junit4]>at java.util.Arrays.sort(Arrays.java:1246)
[junit4]>at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:660)
[junit4]>at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
[junit4]>at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
[junit4]>at
org.apache.lucene.index.TestIndexWriterCommit.testPrepareCommitRollback(TestIndexWriterCommit.java:599)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene53):
{content=Lucene50(blocksize=128)}, docValues:{},
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {content=DFR
I(ne)3(800.0)}, locale=is, timezone=Australia/Sydney
[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=401791056,total=514850816
[junit4] 2> NOTE: All tests run in this JVM: [TestIndexWriterCommit]
{noformat}
> OfflineSorter should use Directory API
> --
>
> Key: LUCENE-6829
> URL: https://issues.apache.org/jira/browse/LUCENE-6829
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6829.patch, LUCENE-6829.patch, LUCENE-6829.patch,
> LUCENE-6829.patch
>
>
> I think this is a blocker for LUCENE-6825, because the block KD-tree makes
> heavy use of OfflineSorter and we don't want to fill up tmp space ...
> This should be a straightforward cutover, but there are some challenges, e.g.
> the test was failing be
[jira] [Updated] (LUCENE-6842) No way to limit the fields cached in memory and leads to OOM when there are thousand of fields (thousands)
[ https://issues.apache.org/jira/browse/LUCENE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bala Kolla updated LUCENE-6842: --- Attachment: HistogramOfHeapUsage.png > No way to limit the fields cached in memory and leads to OOM when there are > thousand of fields (thousands) > -- > > Key: LUCENE-6842 > URL: https://issues.apache.org/jira/browse/LUCENE-6842 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 4.6.1 > Environment: Linux, openjdk 1.6.x >Reporter: Bala Kolla > Attachments: HistogramOfHeapUsage.png > > > I am opening this defect to get some guidance on how to handle a case of > server running out of memory and it seems like it's something to do how we > index. But want to know if there is anyway to reduce the impact of this on > memory usage before we look into the way of reducing the number of fields. > Basically we have many thousands of fields being indexed and it's causing a > large amount of memory being used (25GB) and eventually leading to > application to hang and force us to restart every few minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6842) No way to limit the fields cached in memory and leads to OOM when there are thousand of fields (thousands)
[ https://issues.apache.org/jira/browse/LUCENE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bala Kolla updated LUCENE-6842: --- Priority: Critical (was: Major) > No way to limit the fields cached in memory and leads to OOM when there are > thousand of fields (thousands) > -- > > Key: LUCENE-6842 > URL: https://issues.apache.org/jira/browse/LUCENE-6842 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 4.6.1 > Environment: Linux, openjdk 1.6.x >Reporter: Bala Kolla >Priority: Critical > Attachments: HistogramOfHeapUsage.png > > > I am opening this defect to get some guidance on how to handle a case of > server running out of memory and it seems like it's something to do how we > index. But want to know if there is anyway to reduce the impact of this on > memory usage before we look into the way of reducing the number of fields. > Basically we have many thousands of fields being indexed and it's causing a > large amount of memory being used (25GB) and eventually leading to > application to hang and force us to restart every few minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8165) Add new book 'Apache Solr Essentials'
[ https://issues.apache.org/jira/browse/SOLR-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zico Fernandes updated SOLR-8165: - Attachment: B03955_Apache Solr Essentials.jpg > Add new book 'Apache Solr Essentials' > - > > Key: SOLR-8165 > URL: https://issues.apache.org/jira/browse/SOLR-8165 > Project: Solr > Issue Type: Task >Reporter: Zico Fernandes > Attachments: B03955_Apache Solr Essentials.jpg, SOLR-8165.patch > > > Packt Publishing is proud to finally announce the book "Apache Solr > Essentials" by Andrea Gazzarini. This book is specifically for developers > with practical experience of technologies similar to Apache Solr and want to > develop efficient search applications. It leverages the power of Apache Solr > to create efficient search applications and upskill the readers with the > conceptual framework for robust search application creation. > Apache Solr Essentials is a fast paced guide that maximizes the data > searching capability of your application and help you customize your search > applications to meet your project specifications. > Apache Solr Essentials will quickly help you learn the process of creating a > scalable, efficient, and powerful search application. The book starts off by > explaining the fundamentals of Solr and then goes on to cover various topics > such as data indexing, ways of extending Solr, client APIs and their indexing > and data searching capabilities, an introduction to the administration, > monitoring, and tuning of a Solr instance, as well as the concepts of > sharding and replication. Next, you'll learn about various Solr extensions > and how to contribute to the Solr community. By the end of this book, you > will be able to create excellent search applications with the help of Solr. > Click here to read more about Apache Solr Essentials. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
