[JENKINS] Lucene-Solr-Tests-5.2-Java7 - Build # 5 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.2-Java7/5/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:53712/dm/collection1 expected:68 but was:67 Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:53712/dm/collection1 expected:68 but was:67 at __randomizedtesting.SeedInfo.seed([104FB88EF14E2A84:981B87545FB2477C]: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:344) 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:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3167 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3167/ 1 tests failed. REGRESSION: org.apache.solr.cloud.MultiThreadedOCPTest.test Error Message: Captured an uncaught exception in thread: Thread[id=5491, name=parallelCoreAdminExecutor-2866-thread-7, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=5491, name=parallelCoreAdminExecutor-2866-thread-7, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] at __randomizedtesting.SeedInfo.seed([643A542B43DC5C4F:EC6E6BF1ED2031B7]:0) Caused by: java.lang.AssertionError: Too many closes on SolrCore at __randomizedtesting.SeedInfo.seed([643A542B43DC5C4F]:0) at org.apache.solr.core.SolrCore.close(SolrCore.java:1150) at org.apache.solr.common.util.IOUtils.closeQuietly(IOUtils.java:31) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:611) at org.apache.solr.handler.admin.CoreAdminHandler.handleCreateAction(CoreAdminHandler.java:628) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:213) at org.apache.solr.handler.admin.CoreAdminHandler$ParallelCoreAdminHandlerThread.run(CoreAdminHandler.java:1249) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10149 lines...] [junit4] Suite: org.apache.solr.cloud.MultiThreadedOCPTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build/solr-core/test/J2/temp/solr.cloud.MultiThreadedOCPTest 643A542B43DC5C4F-001/init-core-data-001 [junit4] 2 1122819 T5184 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (false) [junit4] 2 1122819 T5184 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: / [junit4] 2 1122824 T5184 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 2 1122824 T5185 oasc.ZkTestServer$2$1.setClientPort client port:0.0.0.0/0.0.0.0:0 [junit4] 2 1122824 T5185 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2 1122924 T5184 oasc.ZkTestServer.run start zk server on port:48743 [junit4] 2 1122925 T5184 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 1122926 T5184 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 1122929 T5192 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@6a5b9c7c name:ZooKeeperConnection Watcher:127.0.0.1:48743 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 1122930 T5184 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 1122930 T5184 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 1122930 T5184 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2 1122933 T5184 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 1122935 T5184 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 1122936 T5195 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@37d4768a name:ZooKeeperConnection Watcher:127.0.0.1:48743/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 1122936 T5184 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 1122937 T5184 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 1122937 T5184 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2 1122940 T5184 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2 1122942 T5184 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2 1122944 T5184 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2 1122947 T5184 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2 1122947 T5184 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2 1122953 T5184 oasc.AbstractZkTestCase.putConfig put
[jira] [Updated] (SOLR-7389) Expose znode version in clusterstatus API
[ https://issues.apache.org/jira/browse/SOLR-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Grama updated SOLR-7389: --- Attachment: (was: SOLR-7389.txt) Expose znode version in clusterstatus API - Key: SOLR-7389 URL: https://issues.apache.org/jira/browse/SOLR-7389 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Labels: difficulty-easy, impact-medium Fix For: Trunk, 5.2 We should expose the znode version of the cluster state for each collection that is returned by the clusterstatus API. Apart from giving an idea about when the clusterstatus was executed, this information can be used by non-java clients to use the same _stateVer_ mechanism that SolrJ currently uses for routing requests without watching all cluster states. -- 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-7389) Expose znode version in clusterstatus API
[ https://issues.apache.org/jira/browse/SOLR-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558022#comment-14558022 ] Shalin Shekhar Mangar commented on SOLR-7389: - [~mariusneo] - You attached the wrong file as a patch I guess. Expose znode version in clusterstatus API - Key: SOLR-7389 URL: https://issues.apache.org/jira/browse/SOLR-7389 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Labels: difficulty-easy, impact-medium Fix For: Trunk, 5.2 Attachments: SOLR-7389.txt We should expose the znode version of the cluster state for each collection that is returned by the clusterstatus API. Apart from giving an idea about when the clusterstatus was executed, this information can be used by non-java clients to use the same _stateVer_ mechanism that SolrJ currently uses for routing requests without watching all cluster states. -- 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-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558037#comment-14558037
]
Marius Grama commented on SOLR-7566:
[~shalinmangar] could you please give me some tips on how to reproduce this
issue?
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components: search, SolrCloud
Affects Versions: 5.1
Reporter: Shalin Shekhar Mangar
Priority: Trivial
Fix For: Trunk, 5.2
If no replicas of a shard are up and running, a search request gives the
following response:
{code}
{
responseHeader: {
status: 503,
QTime: 2,
params: {
q: *:*,
indent: true,
wt: json,
_: 1432048084930
}
},
error: {
msg: no servers hosting shard: ,
code: 503
}
}
{code}
The message should mention the shard which is down/unreachable.
--
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-6835) ReRankQuery throws NullPointerException
[ https://issues.apache.org/jira/browse/SOLR-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Grama updated SOLR-6835: --- Attachment: SOLR-6835.patch Attached patch containing error handling and unit test for testing the change. ReRankQuery throws NullPointerException --- Key: SOLR-6835 URL: https://issues.apache.org/jira/browse/SOLR-6835 Project: Solr Issue Type: Bug Affects Versions: 4.9, 4.10, 4.10.2 Reporter: 帅广应 Assignee: Joel Bernstein Fix For: Trunk, 5.2 Attachments: SOLR-6835.patch when I use ReRankQParserPlugin, I found if I leave reRankQuery paramter to null,then Solr will throw NullPointerException in ReRankQuery.hashCode() method. If reRankQuery parameter should not be null, It should be intercepted in ReRankQParser.parser() method to make it clear for users. -- 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-7389) Expose znode version in clusterstatus API
[ https://issues.apache.org/jira/browse/SOLR-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Grama updated SOLR-7389: --- Attachment: SOLR-7389.patch [~shalinmangar] : indeed. sorry about that. these were my notes (i spent some time trying to understand how where the change needs to be performed) Expose znode version in clusterstatus API - Key: SOLR-7389 URL: https://issues.apache.org/jira/browse/SOLR-7389 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Labels: difficulty-easy, impact-medium Fix For: Trunk, 5.2 Attachments: SOLR-7389.patch We should expose the znode version of the cluster state for each collection that is returned by the clusterstatus API. Apart from giving an idea about when the clusterstatus was executed, this information can be used by non-java clients to use the same _stateVer_ mechanism that SolrJ currently uses for routing requests without watching all cluster states. -- 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-NightlyTests-trunk - Build # 692 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/692/ 5 tests failed. REGRESSION: org.apache.solr.cloud.MultiThreadedOCPTest.test Error Message: Captured an uncaught exception in thread: Thread[id=55886, name=parallelCoreAdminExecutor-3246-thread-21, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=55886, name=parallelCoreAdminExecutor-3246-thread-21, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] at __randomizedtesting.SeedInfo.seed([9ACFA50220067BA0:129B9AD88EFA1658]:0) Caused by: java.lang.AssertionError: Too many closes on SolrCore at __randomizedtesting.SeedInfo.seed([9ACFA50220067BA0]:0) at org.apache.solr.core.SolrCore.close(SolrCore.java:1150) at org.apache.solr.common.util.IOUtils.closeQuietly(IOUtils.java:31) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:611) at org.apache.solr.handler.admin.CoreAdminHandler.handleCreateAction(CoreAdminHandler.java:628) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:213) at org.apache.solr.handler.admin.CoreAdminHandler$ParallelCoreAdminHandlerThread.run(CoreAdminHandler.java:1249) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) REGRESSION: org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest.testUpdateDistribChainSkipping Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([9ACFA50220067BA0:EB2B5BD456ED5C6C]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest.testUpdateDistribChainSkipping(UpdateRequestProcessorFactoryTest.java:111) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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)
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build #12782 - Failure!
I'v edone a clean checkout I still see these errors
meta http-equiv=Content-Type content=text/html; charset=UTF-8/
titleError 500 Server Error/title
/head
bodyh2HTTP ERROR 500/h2
pProblem accessing /solr/.system_shard1_replica2/update. Reason:
preServer Error/pre/ph3Caused
by:/h3prejava.lang.NoSuchFieldError: totalTermCount
at
org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:277)
at
org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3032)
at org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3018)
at
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2707)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2852)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2819)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:586)
On Sat, May 23, 2015 at 11:52 AM, Erick Erickson
erickerick...@gmail.com wrote:
thanks! I'll give it a whirl. It's particularly weird b/c my pro runs
everything just fine, my laptop fails all the time.
On Fri, May 22, 2015 at 10:10 PM, Ishan Chattopadhyaya
ichattopadhy...@gmail.com wrote:
Not sure if it is related or helpful, but while debugging tests for
SOLR-7468 yesterday, I encountered this
java.lang.NoSuchFieldError:
totalTermCount
few times, I had to forcefully clean at root of the project and it worked. I
remember Anshum had to do that clean thing more than once to make it work
and he remarked don't ask why.
Sent from my Windows Phone
From: Erick Erickson
Sent: 5/23/2015 6:15 AM
To: dev@lucene.apache.org
Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build
#12782 - Failure!
OK, this is somewhat weird. I still have the original tree that I
checked in from which was up to date before I committed the code and
the tests run from there fine. But a current trunk fails every time.
Now, the machine it works on is my Mac Pro, and the failures are on my
MacBook so there may be something going on there.
I've got to leave for a while, I'll copy the tree that works on the
Pro, update the copy and see if this test fails when I get back. If
they fail, I can diff the trees to see what changed and see if I can
make any sense out of this.
I can always @Ignore this test to cut down on the noise, probably do
that tonight if I don't have any revelations.
I see this stack trace which makes no sense to me whatsoever (see the
lines with lots of * in front). I looked at where the code
originates (BufferedUpdatesStream[277]) and it looks like this:
if (coalescedUpdates != null coalescedUpdates.totalTermCount != 0) {
And it's telling me there's no such field? Wha
Which is freaking me out since I don't see how this would trigger the
exception. Is this a red herring? And, of course, this doesn't fail in
IntelliJ but it does fail every time from the shell. Shhh.
Of course if this were something fundamental to Lucene, it seems like
this would be failing all over the place so I assume it's something to
do with CDCR... But what do I know?
1:56434/source_collection_shard2_replica1/commit_end_point=truewt=javabinversion=2expungeDeletes=false}
status=0 QTime=8
* [junit4] 2 143699 T370 n:127.0.0.1:56443_
c:source_collection s:shard1 r:core_node3
x:source_collection_shard1_replica1 C122 oasc.SolrException.log ERROR
null:java.lang.RuntimeException: java.lang.NoSuchFieldError:
totalTermCount
[junit4] 2 at
org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:579)
[junit4] 2 at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:451)
[junit4] 2 at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
[junit4] 2 at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2 at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:105)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2 at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
[junit4] 2 at
org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:300)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
[junit4] 2 at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
[junit4] 2 at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
[junit4] 2 at
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 10 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/10/ 1 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithKerberos.testKerberizedSolr Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:39003, http://127.0.0.1:51276, http://127.0.0.1:33817, http://127.0.0.1:40748, http://127.0.0.1:39669] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:39003, http://127.0.0.1:51276, http://127.0.0.1:33817, http://127.0.0.1:40748, http://127.0.0.1:39669] at __randomizedtesting.SeedInfo.seed([7F80B71B49A3C81:ACE1DDB6FEFBFCB6]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:152) at org.apache.solr.cloud.TestSolrCloudWithKerberos.testKerberizedSolr(TestSolrCloudWithKerberos.java:159) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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
[jira] [Commented] (SOLR-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558105#comment-14558105
]
Shalin Shekhar Mangar commented on SOLR-7566:
-
# Create a two node solrcloud cluster
# create a collection with numShards=2replication factor=1maxShardsPerNode=1
# shutdown one node
# run a search query using the collection name on the running node
The request will fail with the error in the description.
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components: search, SolrCloud
Affects Versions: 5.1
Reporter: Shalin Shekhar Mangar
Priority: Trivial
Fix For: Trunk, 5.2
If no replicas of a shard are up and running, a search request gives the
following response:
{code}
{
responseHeader: {
status: 503,
QTime: 2,
params: {
q: *:*,
indent: true,
wt: json,
_: 1432048084930
}
},
error: {
msg: no servers hosting shard: ,
code: 503
}
}
{code}
The message should mention the shard which is down/unreachable.
--
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-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558174#comment-14558174 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/86 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558173#comment-14558173 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/86#issuecomment-105224437 Superseded by today's patch at LUCENE-5627 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: efbytesref as of 20140629
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/60 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558185#comment-14558185 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/60#issuecomment-105225303 See LUCENE-5524 and LUCENE-5627 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558184#comment-14558184 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/60 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558182#comment-14558182 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/61 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: Labeledtree 201406a
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/61#issuecomment-105225260 See LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Labeledtree 201405a1
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/51 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Labeledtree 201405a1
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/51#issuecomment-105225333 See LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558193#comment-14558193 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/50#issuecomment-105225405 See LUCENE-5524 and LUCENE-5627 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558197#comment-14558197 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/45#issuecomment-105225478 See LUCENE-5524 and LUCENE-5627 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558196#comment-14558196 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/46 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: Squashed commit of efbytesref, 20140422
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/45#issuecomment-105225478 See LUCENE-5524 and LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558195#comment-14558195 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/46#issuecomment-105225447 See LUCENE-5627 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: Labeledfragments 201404a
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/46#issuecomment-105225447 See LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558198#comment-14558198 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/45 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558194#comment-14558194 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/50 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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
[GitHub] lucene-solr pull request: Squashed commit of efbytesref, 20140422
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/45 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558204#comment-14558204 ] ASF GitHub Bot commented on LUCENE-5092: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/42 join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- 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
[GitHub] lucene-solr pull request: Lucene 5293 Also use EliasFanoDocIdSet i...
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/19 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558203#comment-14558203 ] ASF GitHub Bot commented on LUCENE-5092: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/42#issuecomment-105225583 No more needed, LUCENE-5092 is closed. join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- 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
[GitHub] lucene-solr pull request: Lucene 5293 Also use EliasFanoDocIdSet i...
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/19#issuecomment-105225659 No more needed, EliasFanoDocIdSet was removed from Lucene trunk --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5293) Also use EliasFanoDocIdSet in CachingWrapperFilter
[ https://issues.apache.org/jira/browse/LUCENE-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558207#comment-14558207 ] ASF GitHub Bot commented on LUCENE-5293: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/19 Also use EliasFanoDocIdSet in CachingWrapperFilter -- Key: LUCENE-5293 URL: https://issues.apache.org/jira/browse/LUCENE-5293 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5293.patch, LUCENE-5293.patch, LUCENE-5293.patch, LUCENE-5293.patch, LUCENE-5293.patch -- 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-7589) A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier.
[ https://issues.apache.org/jira/browse/SOLR-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558216#comment-14558216 ] ASF subversion and git services commented on SOLR-7589: --- Commit 1681585 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1681585 ] SOLR-7589: A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier. A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier. --- Key: SOLR-7589 URL: https://issues.apache.org/jira/browse/SOLR-7589 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- 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-7589) A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier.
[ https://issues.apache.org/jira/browse/SOLR-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558221#comment-14558221 ] ASF subversion and git services commented on SOLR-7589: --- Commit 1681586 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1681586 ] SOLR-7589: A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier. A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier. --- Key: SOLR-7589 URL: https://issues.apache.org/jira/browse/SOLR-7589 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- 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] [Created] (SOLR-7589) A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier.
Mark Miller created SOLR-7589: - Summary: A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier. Key: SOLR-7589 URL: https://issues.apache.org/jira/browse/SOLR-7589 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- 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
[GitHub] lucene-solr pull request: Labeledtree 201408a
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/87 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Labeledtree 201408a
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/87#issuecomment-105224253 Superseded by today's patch at LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-5627: - Attachment: LUCENE-5627-20150525.patch Patch of 20150525 against 5.2 branch. Includes PrefillTokenStream from LUCENE-5687 and an EliasFano sequence of LUCENE-5524. Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: efbytesref of 20140817
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/86 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558171#comment-14558171 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/87 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558169#comment-14558169 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/87#issuecomment-105224253 Superseded by today's patch at LUCENE-5627 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: efbytesref of 20140817
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/86#issuecomment-105224437 Superseded by today's patch at LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Labeledtree 201407a
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/63#issuecomment-105225140 See LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Labeledtree 201407a
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/63 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: efbytesref of 20140717, move Elias-Fano ...
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/62 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558177#comment-14558177 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/63#issuecomment-105225140 See LUCENE-5627 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558178#comment-14558178 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/63 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: efbytesref of 20140717, move Elias-Fano ...
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/62#issuecomment-105225222 See LUCENE-5524 and LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558179#comment-14558179 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/62#issuecomment-105225222 See LUCENE-5524 and LUCENE-5627 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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
[GitHub] lucene-solr pull request: Labeledtree 201406a
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/61 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558180#comment-14558180 ] ASF GitHub Bot commented on LUCENE-5524: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/62 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5524-20141126.patch -- 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
[GitHub] lucene-solr pull request: Labeledfragments 201404a
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/46 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: efbytesref 201405a1
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/50 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: efbytesref as of 20140629
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/60#issuecomment-105225303 See LUCENE-5524 and LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558181#comment-14558181 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/61#issuecomment-105225260 See LUCENE-5627 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558186#comment-14558186 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/51#issuecomment-105225333 See LUCENE-5627 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558187#comment-14558187 ] ASF GitHub Bot commented on LUCENE-5627: Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/51 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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
[GitHub] lucene-solr pull request: efbytesref 201405a1
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/50#issuecomment-105225405 See LUCENE-5524 and LUCENE-5627 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Lucene 5092 pull 4
Github user PaulElschot commented on the pull request: https://github.com/apache/lucene-solr/pull/42#issuecomment-105225583 No more needed, LUCENE-5092 is closed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Lucene 5092 pull 4
Github user PaulElschot closed the pull request at: https://github.com/apache/lucene-solr/pull/42 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7589) A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier.
[ https://issues.apache.org/jira/browse/SOLR-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-7589. --- Resolution: Fixed Fix Version/s: 5.3 Trunk A few improvements to the ObjectReleaseTracker to make test fail debugging a little easier. --- Key: SOLR-7589 URL: https://issues.apache.org/jira/browse/SOLR-7589 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: Trunk, 5.3 -- 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
Re: Configsets and Config APIs in Solr
but I think it would be better if the mutable part is placed under /collections/x/..., otherwise /configs it makes sense. The problem we have is managedschema currently writes to the same If we could change the managedschema behavior somehow it would have been better On Fri, May 22, 2015 at 10:21 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: TLDR: we should think about this as configset base vs per-collection diff, not as immutable base vs per-collection mutable. Makes sense, I was mostly thinking of it being immutable from the current Config APIs. Editing a configset for multiple collection is a valid and useful feature, the problem is doing that from inside one collection's API call. So then the question becomes, do we want an API that can *also* make collection-specific changes to a shared config? If we feel there is no need for collection-specific config changes, I'm OK, but again, the API should be outside of the collection, like a Configset API. The generate configset based on X should also be a command of this API. In addition, this could allow users to edit a configset that's not currently being used by any collection. Tomás On Fri, May 22, 2015 at 7:10 AM, Yonik Seeley ysee...@gmail.com wrote: Makes sense Greg. Just looking at it from the ZK perspective (APIs aside), the original idea behind referencing a config set by name was so that you could change it in one place and everyone relying on it would get the changes. If one wants collections to have separate independent config sets they can already do that. So then the question becomes, do we want an API that can *also* make collection-specific changes to a shared config? An alternative would be a command to make a copy of a config set, and a command to switch a specific collection to use that new config set. Then any further changes would be collection specific. That's sort of like SOLR-5955 - config templates - but you can template off of any other config set, at any point in time. Actually, that type of functionality seems generally useful regardless. -Yonik On Thu, May 21, 2015 at 8:07 PM, Gregory Chanan gcha...@cloudera.com wrote: I'm +1 on the general idea, but I'm not convinced about the mutable/immutable separation. Do we not think it is valid to modify a single config(set) that affects multiple collections? I can imagine a case where my data with the same config(set) is partitioned into many different collections, whether by date, sorted order, etc. that all use the same underlying config(set). Let's say I have collections partitioned by month and I decide I want to add another field; I don't want to have to modify jan/schema feb/schema mar/schema etc. I just want to modify the single underlying config(set). You can imagine having a configset API that let's me do that, so if I wanted to modify a single collection's config I would call: jan/schema but if i wanted to modify the underlying config(set) I would call: configset/month_partitioned_config My point is this: if the problem is that it is confusing to have configsets modified when you make collection-level calls, then we should fix that (I'm 100% in agreement with that, btw). You can fix that by having a configset and a per-collection diff; defining the configset as immutable doesn't solve the problem, only locks us into a implementation that doesn't support the use case above. I'm not even saying we should implement a configset API, only that defining this as an immutable vs mutable implementation blocks us from doing that. TLDR: we should think about this as configset base vs per-collection diff, not as immutable base vs per-collection mutable. Thoughts? Greg On Tue, May 19, 2015 at 10:52 AM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: I created https://issues.apache.org/jira/browse/SOLR-7570 On Fri, May 15, 2015 at 10:31 AM, Alan Woodward a...@flax.co.uk wrote: +1 A nice way of doing it would be to make it part of the SolrResourceLoader interface. The ZK resource loader could check in the collection-specific zknode first, and then under configs/, and we could add a writeResource() method that writes to the collection-specific node as well. Then all config I/O goes via the resource loader, and we have a way of keeping certain parts immutable. On 15 May 2015, at 17:39, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: I agree about differentiating the mutable part (configoverlay, generated schema, etc) and the immutable (the configset) , but I think it would be better if the mutable part is placed under /collections/x/..., otherwise /configs would have a mix of ConfigSets and collection-specific configuration. On Fri, May 15, 2015 at 6:38 AM, Noble Paul noble.p...@gmail.com wrote: I think this needs more discussion When a
[jira] [Commented] (SOLR-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558278#comment-14558278 ] Mark Miller commented on SOLR-7590: --- I tried to debug some jenkins logs today and realized a bunch of this logging is incomplete and buggy. Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch -- 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-7389) Expose znode version in clusterstatus API
[ https://issues.apache.org/jira/browse/SOLR-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558306#comment-14558306 ] Shalin Shekhar Mangar commented on SOLR-7389: - Thanks [~mariusneo] but this is patch isn't quite right. The DocCollection#write method is used to persist the collection information to ZK but we don't want znodeVersion to be persisted to ZK as part of the collection. It is best to add the znodeVersion manually to the collection information being returned by the cluster status API. Look at OverseerCollectionProcessor#getClusterStatus where this is all done. Also, all tests for this API are in TestCollectionAPI so I'd appreciate if you can add a test for this new feature as well. Expose znode version in clusterstatus API - Key: SOLR-7389 URL: https://issues.apache.org/jira/browse/SOLR-7389 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Labels: difficulty-easy, impact-medium Fix For: Trunk, 5.2 Attachments: SOLR-7389.patch We should expose the znode version of the cluster state for each collection that is returned by the clusterstatus API. Apart from giving an idea about when the clusterstatus was executed, this information can be used by non-java clients to use the same _stateVer_ mechanism that SolrJ currently uses for routing requests without watching all cluster states. -- 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-6371) Improve Spans payload collection
[ https://issues.apache.org/jira/browse/LUCENE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6371: -- Attachment: LUCENE-6371.patch Here's a patch taking into account all the comments here and on LUCENE-6494. * SpanCollector becomes an interface again, so payload collection is entirely defined in the .payloads package * BufferedSpanCollector is removed, replaced by a simple array of SpanCollectors in NearSpansOrdered. SpanCollector has two methods to deal with this, newSubCollectors() and collectedComposite(), to create and then replay. * SpanCollectors are passed through in getSpans(). A null passed here means no collection, and there's a default getSpans() call on SpanWeight that always passes a null collector. * I've removed SpanSimilarity, in favour of passing a map of Terms to TermContexts to the SpanWeight constructor. If this is null, then scoring isn't required; if not, then SpanWeight builds a SimScorer and passes that to its scorer. Improve Spans payload collection Key: LUCENE-6371 URL: https://issues.apache.org/jira/browse/LUCENE-6371 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Alan Woodward Priority: Minor Fix For: Trunk, 5.3 Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558390#comment-14558390 ] Mark Miller commented on SOLR-7590: --- I've also unified our context logging solution - we can't maintain one approach for tests and another for production. Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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] [Created] (SOLR-7591) Bug with heatmaps
Håvard Wahl Kongsgård created SOLR-7591: --- Summary: Bug with heatmaps Key: SOLR-7591 URL: https://issues.apache.org/jira/browse/SOLR-7591 Project: Solr Issue Type: Bug Affects Versions: 5.1 Reporter: Håvard Wahl Kongsgård Hi, I have been experimenting with the new heatmap facet in solr 5. When I use grid level 5 I notice a bug. with level 7, I get for example rows: 6 cols: 26 XmaX: 10.7514953613 Xmin 10.7157897949 YmaX: 59.9317932129 Ymin 59.9235534668 Cell size 0.00137329101562 x 0.00137329101562 with level 6 rows: 11 cols: 26 X maX: 10.8435058594 Xmin 10.5578613281 Y maX: 59.9468994141 Ymin 59.8864746094 Cell size 0.010986328125 x 0.0054931640625 notice the cell size I could be that my code is faulty, but this works for all other grid levels -- 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-6494) Make PayloadSpanUtil apply to other postings information
[ https://issues.apache.org/jira/browse/LUCENE-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558370#comment-14558370 ] Alan Woodward commented on LUCENE-6494: --- Thanks for dealing with this guys. I've tried to address some of the comments on the general shape of the API over on LUCENE-6371, and then we can keep this issue for PayloadSpanUtil itself. Make PayloadSpanUtil apply to other postings information Key: LUCENE-6494 URL: https://issues.apache.org/jira/browse/LUCENE-6494 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Fix For: 5.2 Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch With the addition of SpanCollectors, we can now get arbitrary postings information from SpanQueries. PayloadSpanUtil does some rewriting to convert non-span queries into SpanQueries so that it can collect payloads. It would be good to make this more generic, so that we can collect any postings information from any query (without having to make invasive changes to already optimized Scorers, etc). -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch -- 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-7389) Expose znode version in clusterstatus API
[ https://issues.apache.org/jira/browse/SOLR-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Grama updated SOLR-7389: --- Attachment: SOLR-7389.patch Attached a new patch which adds zNodeVersion property for the collection status representation within OverseerCollectionProcessor#getClusterStatus method. Expose znode version in clusterstatus API - Key: SOLR-7389 URL: https://issues.apache.org/jira/browse/SOLR-7389 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Labels: difficulty-easy, impact-medium Fix For: Trunk, 5.2 Attachments: SOLR-7389.patch, SOLR-7389.patch We should expose the znode version of the cluster state for each collection that is returned by the clusterstatus API. Apart from giving an idea about when the clusterstatus was executed, this information can be used by non-java clients to use the same _stateVer_ mechanism that SolrJ currently uses for routing requests without watching all cluster states. -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Getting closer to something reasonable. Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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-7468) Kerberos authentication module
[ https://issues.apache.org/jira/browse/SOLR-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558344#comment-14558344 ] ASF subversion and git services commented on SOLR-7468: --- Commit 1681597 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1681597 ] SOLR-7468: Enabling debug logging for kerberos connections during tests and trying to fix # of jettys (shards) Kerberos authentication module -- Key: SOLR-7468 URL: https://issues.apache.org/jira/browse/SOLR-7468 Project: Solr Issue Type: New Feature Components: security Reporter: Ishan Chattopadhyaya Assignee: Anshum Gupta Fix For: 5.2 Attachments: SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch SOLR-7274 introduces a pluggable authentication framework. This issue provides a Kerberos plugin implementation. -- 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-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558347#comment-14558347
]
Marius Grama commented on SOLR-7566:
[~shalinmangar] thank you. I could reproduce the issue and I have also found
the cause of it.
When doing a distributed search, the available shards are taken from the
cluster state and are joined together
(HttpShardHandler#checkDistributed(ResponseBuilder) method)
{code:title=HttpShardHandler#checkDistributed}
// ...
StringBuilder sliceShardsStr = new StringBuilder();
for (Replica replica : sliceShards.values()) {
if (!clusterState.liveNodesContain(replica.getNodeName())
|| replica.getState() != Replica.State.ACTIVE) {
continue;
}
if (first) {
first = false;
} else {
sliceShardsStr.append('|');
}
String url = ZkCoreNodeProps.getCoreUrl(replica);
sliceShardsStr.append(url);
}
rb.shards[i] = sliceShardsStr.toString();
{code}
In the case when the replicas for a shard are not available, the string
corresponding to the shard addresses will remain empty.
In the SearchHandler#handleRequestBody method, the empty shard will be simply
forwarded to the HttpShardHandler to be evaluated asynchronously :
SearchHandler.java line 352
{code:language=java}
shardHandler1.submit(sreq, shard, params);
{code}
and in the HttpShardHandler#submit() method will be thrown the exception with
an inconsistent message because the shard is empty.
{code:language=java}
// if there are no shards available for a slice, urls.size()==0
if (urls.size()==0) {
// TODO: what's the right error code here? We should use the same
thing when
// all of the servers for a shard are down.
throw new
SolrException(SolrException.ErrorCode.SERVICE_UNAVAILABLE, no servers hosting
shard: + shard);
}
{code}
One solution would be to throw the SolrException within the code of
HttpShardHandler#checkDistributed method when the _sliceShardsStr_
StringBuilder is empty. This seems to me the easy way to handle this situation.
Can somebody give me feedback whether I am on the right track here? Thanks in
advance.
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components: search, SolrCloud
Affects Versions: 5.1
Reporter: Shalin Shekhar Mangar
Priority: Trivial
Fix For: Trunk, 5.2
If no replicas of a shard are up and running, a search request gives the
following response:
{code}
{
responseHeader: {
status: 503,
QTime: 2,
params: {
q: *:*,
indent: true,
wt: json,
_: 1432048084930
}
},
error: {
msg: no servers hosting shard: ,
code: 503
}
}
{code}
The message should mention the shard which is down/unreachable.
--
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] (SOLR-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558347#comment-14558347
]
Marius Grama edited comment on SOLR-7566 at 5/25/15 3:51 PM:
-
[~shalinmangar] thank you. I could reproduce the issue and I have also found
the cause of it.
When doing a distributed search, the available shards are taken from the
cluster state and are joined together
(HttpShardHandler#checkDistributed(ResponseBuilder) method)
{code:title=HttpShardHandler#checkDistributed}
// ...
StringBuilder sliceShardsStr = new StringBuilder();
for (Replica replica : sliceShards.values()) {
if (!clusterState.liveNodesContain(replica.getNodeName())
|| replica.getState() != Replica.State.ACTIVE) {
continue;
}
if (first) {
first = false;
} else {
sliceShardsStr.append('|');
}
String url = ZkCoreNodeProps.getCoreUrl(replica);
sliceShardsStr.append(url);
}
rb.shards[i] = sliceShardsStr.toString();
{code}
In the case when the replicas for a shard are not available, the string
corresponding to the shard addresses will remain empty.
In the SearchHandler#handleRequestBody method, the empty shard will be simply
forwarded to the HttpShardHandler to be evaluated asynchronously :
SearchHandler.java line 352
{code:language=java}
shardHandler1.submit(sreq, shard, params);
{code}
and in the HttpShardHandler#submit() method will be thrown the exception with
an inconsistent message because the shard is empty.
{code:title=HttpShardHandler#submit|language=java}
// if there are no shards available for a slice, urls.size()==0
if (urls.size()==0) {
// TODO: what's the right error code here? We should use the same
thing when
// all of the servers for a shard are down.
throw new
SolrException(SolrException.ErrorCode.SERVICE_UNAVAILABLE, no servers hosting
shard: + shard);
}
{code}
One solution would be to throw the SolrException within the code of
HttpShardHandler#checkDistributed method when the _sliceShardsStr_
StringBuilder is empty. This seems to me the easy way to handle this situation.
Can somebody give me feedback whether I am on the right track here? Thanks in
advance.
was (Author: mariusneo):
[~shalinmangar] thank you. I could reproduce the issue and I have also found
the cause of it.
When doing a distributed search, the available shards are taken from the
cluster state and are joined together
(HttpShardHandler#checkDistributed(ResponseBuilder) method)
{code:title=HttpShardHandler#checkDistributed}
// ...
StringBuilder sliceShardsStr = new StringBuilder();
for (Replica replica : sliceShards.values()) {
if (!clusterState.liveNodesContain(replica.getNodeName())
|| replica.getState() != Replica.State.ACTIVE) {
continue;
}
if (first) {
first = false;
} else {
sliceShardsStr.append('|');
}
String url = ZkCoreNodeProps.getCoreUrl(replica);
sliceShardsStr.append(url);
}
rb.shards[i] = sliceShardsStr.toString();
{code}
In the case when the replicas for a shard are not available, the string
corresponding to the shard addresses will remain empty.
In the SearchHandler#handleRequestBody method, the empty shard will be simply
forwarded to the HttpShardHandler to be evaluated asynchronously :
SearchHandler.java line 352
{code:language=java}
shardHandler1.submit(sreq, shard, params);
{code}
and in the HttpShardHandler#submit() method will be thrown the exception with
an inconsistent message because the shard is empty.
{code:language=java}
// if there are no shards available for a slice, urls.size()==0
if (urls.size()==0) {
// TODO: what's the right error code here? We should use the same
thing when
// all of the servers for a shard are down.
throw new
SolrException(SolrException.ErrorCode.SERVICE_UNAVAILABLE, no servers hosting
shard: + shard);
}
{code}
One solution would be to throw the SolrException within the code of
HttpShardHandler#checkDistributed method when the _sliceShardsStr_
StringBuilder is empty. This seems to me the easy way to handle this situation.
Can somebody give me feedback whether I am on the right track here? Thanks in
advance.
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components:
[jira] [Commented] (SOLR-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558300#comment-14558300 ] Mark Miller commented on SOLR-7590: --- The Overseer uses MDC logging all wrong IMO. The logging should identify the active core, not the core being operated on by overseer actions. Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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
Lucene indexation
Hi all, We are trying to find an expert on Lucene indexation. I hope you might be able to help or direct us to the most relevant person in the community: We have designed a Java web platform on top of JBoss Infinispan and Apache Lucene (version ). It is a distributed platform which uses Lucene for full-text indexing but also for structured documents indexing in order to reflect objects relationships and allow performing complex query on them. The actual data is distributed across cluster nodes and stored in memory (you can see it as a distributed in-memory key/value store). It includes Lucene indexes data, which are stored as metadata blocks, and chunks (lucene files are handled as chunks to allow even distribution). We use one index per object type, mainly, and use some sort of sharding in a context of multi-tenancy. The bigger indexes could handle millions of documents (more sharding is investigated, which could lower this to 5 figures numbers). Currently, we go up to about 30 documents in one index. This architecture works nicely functionally speaking, but now that it is in production, we encounter several issues related to indexing: - We took care of having only one writer per index in the whole cluster, as required by Lucene. We did that using our distributed locking system. However, it seems that Lucene fail on some lower level locks when preparing for write. We suspect that it does something we don't understand with locking, maybe related to refresh/merge of documents. - We see that it does document merging (and so deleting) all the time, which may impact indexing throughput. - We have the feeling that indexing takes too long in general So, we are mainly looking for advice about: - Understanding better the locking strategy of Lucene in regards to reading, writing and refreshing/merging - Any particular best practice in handling Lucene indexes in a distributed architecture - Tuning Lucene in regards to throughput, memory/CPU usage, refreshing/merging , data volume and GC Gilles
[jira] [Comment Edited] (SOLR-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558361#comment-14558361
]
Marius Grama edited comment on SOLR-7566 at 5/25/15 4:17 PM:
-
Attached a small patch that could possibly be used as solution for this issue.
I think throwing of the exception from HttpShardHandler#submit() method
(mentioned in the above comment) should not be kept anymore in its current
form. When there are no replica urls available there's no more need to submit
the callable function.
{code:language=java|title=HttpShardHandler#submit}
final ListString urls = getURLs(sreq, shard);
if (urls.size()==0) {
throw new IllegalArgumentException(The shard argument doesn't contain any
valid URLs. got + shard);
}
{code}
was (Author: mariusneo):
Attached a small patch that could possibly be used as solution for this issue.
I think throwing of the exception from HttpShardHandler#submit() method
(exposed in the above comment) should not be kept anymore in its current form.
When there are no replica urls available there's no more need to submit the
callable function.
{code:language=java|title=HttpShardHandler#submit}
final ListString urls = getURLs(sreq, shard);
if (urls.size()==0) {
throw new IllegalArgumentException(The shard argument doesn't contain any
valid URLs. got + shard);
}
{code}
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components: search, SolrCloud
Affects Versions: 5.1
Reporter: Shalin Shekhar Mangar
Priority: Trivial
Fix For: Trunk, 5.2
Attachments: SOLR-7566.patch
If no replicas of a shard are up and running, a search request gives the
following response:
{code}
{
responseHeader: {
status: 503,
QTime: 2,
params: {
q: *:*,
indent: true,
wt: json,
_: 1432048084930
}
},
error: {
msg: no servers hosting shard: ,
code: 503
}
}
{code}
The message should mention the shard which is down/unreachable.
--
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-MacOSX (64bit/jdk1.8.0) - Build # 2343 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2343/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.TestDistributedSearch.test Error Message: Error from server at http://127.0.0.1:64167//collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:102) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:744) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:727) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:388) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2059) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:640) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:436) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:105) 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:497) 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: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:64167//collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:102) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:744) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:727) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:388) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2059) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:640) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:436) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:105) 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
[jira] [Created] (SOLR-7590) Finish and improve MDC logging support.
Mark Miller created SOLR-7590: - Summary: Finish and improve MDC logging support. Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 -- 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
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build #12782 - Failure!
The problem went away for me. I took sledgehammer approach and deleted
the entire tree locally and checked out the tree fresh.
On Mon, May 25, 2015 at 4:37 AM, Noble Paul noble.p...@gmail.com wrote:
I'v edone a clean checkout I still see these errors
meta http-equiv=Content-Type content=text/html; charset=UTF-8/
titleError 500 Server Error/title
/head
bodyh2HTTP ERROR 500/h2
pProblem accessing /solr/.system_shard1_replica2/update. Reason:
preServer Error/pre/ph3Caused
by:/h3prejava.lang.NoSuchFieldError: totalTermCount
at
org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:277)
at
org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3032)
at
org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3018)
at
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2707)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2852)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2819)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:586)
On Sat, May 23, 2015 at 11:52 AM, Erick Erickson
erickerick...@gmail.com wrote:
thanks! I'll give it a whirl. It's particularly weird b/c my pro runs
everything just fine, my laptop fails all the time.
On Fri, May 22, 2015 at 10:10 PM, Ishan Chattopadhyaya
ichattopadhy...@gmail.com wrote:
Not sure if it is related or helpful, but while debugging tests for
SOLR-7468 yesterday, I encountered this
java.lang.NoSuchFieldError:
totalTermCount
few times, I had to forcefully clean at root of the project and it worked. I
remember Anshum had to do that clean thing more than once to make it work
and he remarked don't ask why.
Sent from my Windows Phone
From: Erick Erickson
Sent: 5/23/2015 6:15 AM
To: dev@lucene.apache.org
Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build
#12782 - Failure!
OK, this is somewhat weird. I still have the original tree that I
checked in from which was up to date before I committed the code and
the tests run from there fine. But a current trunk fails every time.
Now, the machine it works on is my Mac Pro, and the failures are on my
MacBook so there may be something going on there.
I've got to leave for a while, I'll copy the tree that works on the
Pro, update the copy and see if this test fails when I get back. If
they fail, I can diff the trees to see what changed and see if I can
make any sense out of this.
I can always @Ignore this test to cut down on the noise, probably do
that tonight if I don't have any revelations.
I see this stack trace which makes no sense to me whatsoever (see the
lines with lots of * in front). I looked at where the code
originates (BufferedUpdatesStream[277]) and it looks like this:
if (coalescedUpdates != null coalescedUpdates.totalTermCount != 0) {
And it's telling me there's no such field? Wha
Which is freaking me out since I don't see how this would trigger the
exception. Is this a red herring? And, of course, this doesn't fail in
IntelliJ but it does fail every time from the shell. Shhh.
Of course if this were something fundamental to Lucene, it seems like
this would be failing all over the place so I assume it's something to
do with CDCR... But what do I know?
1:56434/source_collection_shard2_replica1/commit_end_point=truewt=javabinversion=2expungeDeletes=false}
status=0 QTime=8
* [junit4] 2 143699 T370 n:127.0.0.1:56443_
c:source_collection s:shard1 r:core_node3
x:source_collection_shard1_replica1 C122 oasc.SolrException.log ERROR
null:java.lang.RuntimeException: java.lang.NoSuchFieldError:
totalTermCount
[junit4] 2 at
org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:579)
[junit4] 2 at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:451)
[junit4] 2 at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
[junit4] 2 at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2 at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:105)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2 at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
[junit4] 2 at
org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:300)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2 at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
[junit4] 2 at
[jira] [Updated] (SOLR-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marius Grama updated SOLR-7566:
---
Attachment: SOLR-7566.patch
Attached a small patch that could possibly be used as solution for this issue.
I think throwing of the exception from HttpShardHandler#submit() method
(exposed in the above comment) should not be kept anymore in its current form.
When there are no replica urls available there's no more need to submit the
callable function.
{code:language=java|title=HttpShardHandler#submit}
final ListString urls = getURLs(sreq, shard);
if (urls.size()==0) {
throw new IllegalArgumentException(The shard argument doesn't contain any
valid URLs. got + shard);
}
{code}
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components: search, SolrCloud
Affects Versions: 5.1
Reporter: Shalin Shekhar Mangar
Priority: Trivial
Fix For: Trunk, 5.2
Attachments: SOLR-7566.patch
If no replicas of a shard are up and running, a search request gives the
following response:
{code}
{
responseHeader: {
status: 503,
QTime: 2,
params: {
q: *:*,
indent: true,
wt: json,
_: 1432048084930
}
},
error: {
msg: no servers hosting shard: ,
code: 503
}
}
{code}
The message should mention the shard which is down/unreachable.
--
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] (SOLR-7566) Search requests should return the shard name that is down
[
https://issues.apache.org/jira/browse/SOLR-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558361#comment-14558361
]
Marius Grama edited comment on SOLR-7566 at 5/25/15 4:16 PM:
-
Attached a small patch that could possibly be used as solution for this issue.
I think throwing of the exception from HttpShardHandler#submit() method
(exposed in the above comment) should not be kept anymore in its current form.
When there are no replica urls available there's no more need to submit the
callable function.
{code:language=java|title=HttpShardHandler#submit}
final ListString urls = getURLs(sreq, shard);
if (urls.size()==0) {
throw new IllegalArgumentException(The shard argument doesn't contain any
valid URLs. got + shard);
}
{code}
was (Author: mariusneo):
Attached a small patch that could possibly be used as solution for this issue.
I think throwing of the exception from HttpShardHandler#submit() method
(exposed in the above comment) should not be kept anymore in its current form.
When there are no replica urls available there's no more need to submit the
callable function.
{code:language=java|title=HttpShardHandler#submit}
final ListString urls = getURLs(sreq, shard);
if (urls.size()==0) {
throw new IllegalArgumentException(The shard argument doesn't contain any
valid URLs. got + shard);
}
{code}
Search requests should return the shard name that is down
-
Key: SOLR-7566
URL: https://issues.apache.org/jira/browse/SOLR-7566
Project: Solr
Issue Type: Bug
Components: search, SolrCloud
Affects Versions: 5.1
Reporter: Shalin Shekhar Mangar
Priority: Trivial
Fix For: Trunk, 5.2
Attachments: SOLR-7566.patch
If no replicas of a shard are up and running, a search request gives the
following response:
{code}
{
responseHeader: {
status: 503,
QTime: 2,
params: {
q: *:*,
indent: true,
wt: json,
_: 1432048084930
}
},
error: {
msg: no servers hosting shard: ,
code: 503
}
}
{code}
The message should mention the shard which is down/unreachable.
--
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-MacOSX (64bit/jdk1.7.0) - Build # 2297 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2297/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([4ACB10187834731F]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:235) at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) 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:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) 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:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.cloud.SaslZkACLProviderTest.testSaslZkACLProvider Error Message: Could not get the port for ZooKeeper server Stack Trace: java.lang.RuntimeException: Could not get the port for ZooKeeper server at org.apache.solr.cloud.ZkTestServer.run(ZkTestServer.java:506) at org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:226) at org.apache.solr.cloud.SaslZkACLProviderTest.setUp(SaslZkACLProviderTest.java:91) at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) 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:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) 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:365) at
[jira] [Comment Edited] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558427#comment-14558427 ] Paul Elschot edited comment on LUCENE-5627 at 5/25/15 6:37 PM: --- The patch of 20150525 against the 5.2 branch has: - support for two phase iteration by using ConjunctionDISI over the term enum of the payload term and the spans of the input span query. This defers payload loading for the payloads that contain the fragment positions and the tree info. This is implemented in an added package private LabelQuery that is the superclass of all positional joins queries. - various improved/simplified hashCode/equals methods, removal of unused imports. - LeafFragmentsQuery was deleted, this was untested and not working well. I'll add it again later. This provided the non empty leaf fragments from a label tree, and this is occasionally good to have. - the test code uses SpanWithinQuery from core. The util.eliasfano package has a new BitSelect class which is based on the recently removed BitUtil.select method. I'll move the util.eliasfano package into the label module here later, in the patch it is in the core module. The patch was prepared on an svn checkout of the 5.2 branch. I'd rather use git, but the 5.2 branch is not yet available in the git mirror, see INFRA-9182. was (Author: paul.elsc...@xs4all.nl): The patch of 20150525 against the 5.2 branch has: - support for two phase iteration by using ConjunctionIterator over the term enum of the payload term and the spans of the input span query. This defers payload loading for the payloads on the fragment positions and the tree info. This is implemented in an added package private LabelQuery that is the superclass of all positional joins queries. - various improved/simplified hashCode/equals methods, removal of unused imports. - LeafFragmentsQuery was deleted, this was untested and not working well. I'll add it again later. This provided the non empty leaf fragments in from a label tree, and this is occasionally good to have. - the test code uses SpanWithinQuery from core. The util.eliasfano package has a new BitSelect class which is based on the recently removed BitUtil.select method. I'll move the util.eliasfano into the label module here later, in the patch it is the core module. The patch was prepared on an svn checkout of the 5.2 branch. I'd rather use git, but the 5.2 branch is not yet available in the git mirror, see INFRA-9182. Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-5627-20141126.patch, LUCENE-5627-20150525.patch Prototype of analysis and search for labeled fragments -- 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-NightlyTests-5.x - Build # 858 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/858/ 1 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=4271, name=collection1, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=4271, name=collection1, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42343/zg_x: collection already exists: awholynewstresscollection_collection1_1 at __randomizedtesting.SeedInfo.seed([A7DF9F764311F131]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1621) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1642) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:877) Build Log: [...truncated 10359 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest A7DF9F764311F131-001/init-core-data-001 [junit4] 2 491076 T3943 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (false) [junit4] 2 491076 T3943 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: /zg_x/ [junit4] 2 491081 T3943 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 2 491081 T3944 oasc.ZkTestServer$2$1.setClientPort client port:0.0.0.0/0.0.0.0:0 [junit4] 2 491082 T3944 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2 491181 T3943 oasc.ZkTestServer.run start zk server on port:39162 [junit4] 2 491182 T3943 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 491183 T3943 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 491187 T3951 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@72318b04 name:ZooKeeperConnection Watcher:127.0.0.1:39162 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 491188 T3943 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 491188 T3943 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 491189 T3943 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2 491193 T3943 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 491193 T3943 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 491195 T3954 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@6b4c6d89 name:ZooKeeperConnection Watcher:127.0.0.1:39162/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 491195 T3943 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 491196 T3943 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 491196 T3943 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2 491200 T3943 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2 491203 T3943 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2 491205 T3943 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2 491209 T3943 oasc.AbstractZkTestCase.putConfig put
[jira] [Updated] (LUCENE-6499) WindowsFS misses to remove open file handle if file is concurrently deleted
[ https://issues.apache.org/jira/browse/LUCENE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-6499: Attachment: LUCENE-6499.patch another patch that reproduces much faster without any sleeps WindowsFS misses to remove open file handle if file is concurrently deleted --- Key: LUCENE-6499 URL: https://issues.apache.org/jira/browse/LUCENE-6499 Project: Lucene - Core Issue Type: Bug Components: modules/test-framework Affects Versions: 5.1 Reporter: Simon Willnauer Fix For: Trunk, 5.3 Attachments: LUCENE-6499.patch, LUCENE-6499.patch WindowsFs has some race conditions when files are concurrently opened and deleted. A file might be successfully opened while concurrently deleted which should be prevented by the WindowsFS with an IOException / access denied. The problem is that we try to remove the leaked file handle form the internal map on close which fails since we fail to read the key from the filesystem since it has already been deleted. This manifests in subsequent `access denied` exceptions even though all streams on the file are closed. -- 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-ea-b12) - Build # 12819 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12819/ Java: 32bit/jdk1.8.0_60-ea-b12 -client -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.SaslZkACLProviderTest Error Message: 6 threads leaked from SUITE scope at org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=6944, name=kdcReplayCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 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=6942, name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 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)3) Thread[id=6946, name=NioSocketAcceptor-1, state=RUNNABLE, group=TGRP-SaslZkACLProviderTest] 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.apache.mina.transport.socket.nio.NioSocketAcceptor.select(NioSocketAcceptor.java:234) at org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:417) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)4) Thread[id=6941, name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at java.util.TimerThread.mainLoop(Timer.java:526) at java.util.TimerThread.run(Timer.java:505)5) Thread[id=6945, name=changePwdReplayCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 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)6) Thread[id=6943, name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 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)
[jira] [Commented] (SOLR-7441) Streaming aggregation error messages could use some improvement
[ https://issues.apache.org/jira/browse/SOLR-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558501#comment-14558501 ] Gus Heck commented on SOLR-7441: Will this make 5.2? Is there anything you need from me? Streaming aggregation error messages could use some improvement --- Key: SOLR-7441 URL: https://issues.apache.org/jira/browse/SOLR-7441 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Erick Erickson Assignee: Joel Bernstein Priority: Minor Attachments: SOLR-7441.patch, SOLR-7441.patch It's harder than it could be to figure out what the error is when using Streaming Aggregation. For instance if you specify an fl parameter for a field that doesn't exist it's hard to figure out that's the cause. This is true even if you look in the Solr logs. I'm not quite sure whether it'd be possible to report this at the client level or not, but it seems at least we could repor something more helpful in the Solr logs. -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558402#comment-14558402 ] Mark Miller commented on SOLR-7590: --- Okay, now it's fairly solid. Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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-6673) MDC based logging of collection, shard etc.
[ https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558403#comment-14558403 ] Mark Miller commented on SOLR-6673: --- Upon review, I found a lot of problems with this issue - I've tried to address them all in SOLR-7590. MDC based logging of collection, shard etc. --- Key: SOLR-6673 URL: https://issues.apache.org/jira/browse/SOLR-6673 Project: Solr Issue Type: Improvement Reporter: Ishan Chattopadhyaya Assignee: Noble Paul Labels: logging Fix For: Trunk, 5.1 Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673_NPE_fix.patch, log4j.properties, log4j.properties In cloud mode, the many log items don't contain the collection name, shard name, core name etc. Debugging becomes specially difficult when many collections/shards are hosted on the same node. The proposed solution adds MDC based stamping of collection, shard, core to the thread. See also: SOLR-5969, SOLR-5277 -- 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-7590) Finish and improve MDC logging support.
[ https://issues.apache.org/jira/browse/SOLR-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7590: -- Attachment: SOLR-7950.patch Finish and improve MDC logging support. --- Key: SOLR-7590 URL: https://issues.apache.org/jira/browse/SOLR-7590 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.3 Attachments: SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch, SOLR-7950.patch -- 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-7591) Bug with heatmaps
[ https://issues.apache.org/jira/browse/SOLR-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14558498#comment-14558498 ] David Smiley commented on SOLR-7591: Could you please provide the full request parameters for #7 and for #6 ? And also provide your RPT field type configuration? Bug with heatmaps - Key: SOLR-7591 URL: https://issues.apache.org/jira/browse/SOLR-7591 Project: Solr Issue Type: Bug Components: spatial Affects Versions: 5.1 Reporter: Håvard Wahl Kongsgård Assignee: David Smiley Labels: heatmap Hi, I have been experimenting with the new heatmap facet in solr 5. When I use grid level 6 I notice a bug. with level 7, I get for example rows: 6 cols: 26 XmaX: 10.7514953613 Xmin 10.7157897949 YmaX: 59.9317932129 Ymin 59.9235534668 Cell size 0.00137329101562 x 0.00137329101562 with level 6 rows: 11 cols: 26 X maX: 10.8435058594 Xmin 10.5578613281 Y maX: 59.9468994141 Ymin 59.8864746094 Cell size 0.010986328125 x 0.0054931640625 notice the cell size I could be that my code is faulty, but this works for all other grid levels -- 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-ea-b12) - Build # 12817 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12817/
Java: 32bit/jdk1.8.0_60-ea-b12 -server -XX:+UseConcMarkSweepGC
2 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithKerberos
Error Message:
Suite timeout exceeded (= 720 msec).
Stack Trace:
java.lang.Exception: Suite timeout exceeded (= 720 msec).
at __randomizedtesting.SeedInfo.seed([A2A1245FAA84822E]:0)
FAILED: org.apache.solr.cloud.TestSolrCloudWithKerberos.testKerberizedSolr
Error Message:
Test abandoned because suite timeout was reached.
Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([A2A1245FAA84822E]:0)
Build Log:
[...truncated 11048 lines...]
[junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithKerberos
[junit4] 2 Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.TestSolrCloudWithKerberos
A2A1245FAA84822E-001/init-core-data-001
[junit4] 2 1400609 T8432
oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system
property: /
[junit4] 2 1404125 T8432
oadsc.DefaultDirectoryService.showSecurityWarnings WARN You didn't change the
admin password of directory service instance 'DefaultKrbServer'. Please update
the admin password as soon as possible to prevent a possible security breach.
[junit4] 2 1406078 T8432 oasc.ZkTestServer.run STARTING ZK TEST SERVER
[junit4] 2 1406078 T8440 oasc.ZkTestServer$2$1.setClientPort client
port:0.0.0.0/0.0.0.0:0
[junit4] 2 1406078 T8440 oasc.ZkTestServer$ZKServerMain.runFromConfig
Starting server
[junit4] 2 1406178 T8432 oasc.ZkTestServer.run start zk server on
port:32795
[junit4] 2 1406180 T8447 oascc.ConnectionManager.process WARN zkClient
received AuthFailed
[junit4] 2 1406182 T8450 oascc.ConnectionManager.process WARN zkClient
received AuthFailed
[junit4] 2 1406185 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
to /configs/conf1/solrconfig.xml
[junit4] 2 1406186 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/schema.xml
to /configs/conf1/schema.xml
[junit4] 2 1406187 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
[junit4] 2 1406187 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
to /configs/conf1/stopwords.txt
[junit4] 2 1406188 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/protwords.txt
to /configs/conf1/protwords.txt
[junit4] 2 1406189 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/currency.xml
to /configs/conf1/currency.xml
[junit4] 2 1406190 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml
to /configs/conf1/enumsConfig.xml
[junit4] 2 1406190 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/open-exchange-rates.json
to /configs/conf1/open-exchange-rates.json
[junit4] 2 1406191 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/mapping-ISOLatin1Accent.txt
to /configs/conf1/mapping-ISOLatin1Accent.txt
[junit4] 2 1406192 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/old_synonyms.txt
to /configs/conf1/old_synonyms.txt
[junit4] 2 1406193 T8432 oasc.AbstractZkTestCase.putConfig put
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/synonyms.txt
to /configs/conf1/synonyms.txt
[junit4] 2 1406194 T8454 oascc.ConnectionManager.process WARN zkClient
received AuthFailed
[junit4] 2 1406244 T8432 oas.SolrTestCaseJ4.writeCoreProperties Writing
core.properties file to
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.TestSolrCloudWithKerberos
A2A1245FAA84822E-001/control-001/cores/collection1
[junit4] 2 1406245 T8432 oejs.Server.doStart jetty-9.2.10.v20150310
[junit4] 2 1406246 T8432 oejsh.ContextHandler.doStart Started
o.e.j.s.ServletContextHandler@8a634b{/,null,AVAILABLE}
[junit4] 2 1406247 T8432
[jira] [Created] (LUCENE-6499) WindowsFS misses to remove open file handle if file is concurrently deleted
Simon Willnauer created LUCENE-6499: --- Summary: WindowsFS misses to remove open file handle if file is concurrently deleted Key: LUCENE-6499 URL: https://issues.apache.org/jira/browse/LUCENE-6499 Project: Lucene - Core Issue Type: Bug Components: modules/test-framework Affects Versions: 5.1 Reporter: Simon Willnauer Fix For: Trunk, 5.3 WindowsFs has some race conditions when files are concurrently opened and deleted. A file might be successfully opened while concurrently deleted which should be prevented by the WindowsFS with an IOException / access denied. The problem is that we try to remove the leaked file handle form the internal map on close which fails since we fail to read the key from the filesystem since it has already been deleted. This manifests in subsequent `access denied` exceptions even though all streams on the file are closed. -- 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
