[jira] [Commented] (SOLR-7850) Move user customization out of solr.in.* scripts
[
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709142#comment-14709142
]
Jan Høydahl commented on SOLR-7850:
---
I think this discussion should merge with SOLR-7871 (Platform independent
config file instead of solr.in.sh and solr.in.cmd)
The steps of development could then be
# Move logic from bin/solr to SolrCLI.java (SOLR-7043)
# Support new platform independent start config (SOLR-7871) (while keeping
support for current include scripts)
# Deprecate old solr.in.{sh|cmd} in next major release
The new config file should ship as a template only as you suggest, and if not
found there will be good defaults.
Move user customization out of solr.in.* scripts
Key: SOLR-7850
URL: https://issues.apache.org/jira/browse/SOLR-7850
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Shawn Heisey
Priority: Minor
I've seen a fair number of users customizing solr.in.* scripts to make
changes to their Solr installs. I think the documentation suggests this,
though I haven't confirmed.
One possible problem with this is that we might make changes in those scripts
which such a user would want in their setup, but if they replace the script
with the one in the new version, they will lose their customizations.
I propose instead that we have the startup script look for and utilize a user
customization script, in a similar manner to linux init scripts that look for
/etc/default/packagename, but are able to function without it. I'm not
entirely sure where the script should live or what it should be called. One
idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of
thought into it yet.
If the internal behavior of our scripts is largely replaced by a small java
app as detailed in SOLR-7043, then the same thing should apply there -- have
a config file for a user to specify settings, but work perfectly if that
config file is absent.
--
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-7960) bin/solr -h should print generic help
Jan Høydahl created SOLR-7960:
-
Summary: bin/solr -h should print generic help
Key: SOLR-7960
URL: https://issues.apache.org/jira/browse/SOLR-7960
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Reporter: Jan Høydahl
Priority: Trivial
Typing only:
{code}
bin/solr
{code}
...prints the generic tool help, but if you add a -h
{code}
bin/solr -h
{code}
...you get an error message and the help for the {{start}} command.
This is confusing, since -h is a common help option. Could check for the
special case where there is *only* the {{-h}} switch given, in which case we
should not assume the intention is to do {{start}} but to get help.
--
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-7961) Add version command to bin/solr start script
Jan Høydahl created SOLR-7961:
-
Summary: Add version command to bin/solr start script
Key: SOLR-7961
URL: https://issues.apache.org/jira/browse/SOLR-7961
Project: Solr
Issue Type: New Feature
Components: scripts and tools
Reporter: Jan Høydahl
Priority: Trivial
It would be nice to be able to tell which version of Solr you have. You can get
it with the {{status}} command today, but only if Solr is already running.
Proposal:
{noformat}
$ bin/solr -version
5.3.0
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6789) The global block cache option should become the default even if not configured.
[ https://issues.apache.org/jira/browse/SOLR-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6789: -- Fix Version/s: (was: 5.0) The global block cache option should become the default even if not configured. --- Key: SOLR-6789 URL: https://issues.apache.org/jira/browse/SOLR-6789 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk We didn't do this in 4x because of back compat, but should now. Not using global is very trappy and expert. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b78) - Build # 13704 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13704/ Java: 32bit/jdk1.9.0-ea-b78 -server -XX:+UseConcMarkSweepGC 52 tests failed. FAILED: org.apache.lucene.index.TestDocsAndPositions.testRandomPositions Error Message: iteration: 0 initDoc: 71 doc: 71 base: 0 positions: [205] expected:205 but was:161 Stack Trace: java.lang.AssertionError: iteration: 0 initDoc: 71 doc: 71 base: 0 positions: [205] expected:205 but was:161 at __randomizedtesting.SeedInfo.seed([4A60AB39E8D08E88:3444D20CBB7AA341]: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.lucene.index.TestDocsAndPositions.testRandomPositions(TestDocsAndPositions.java:175) 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:504) 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.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 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:746) FAILED: org.apache.lucene.index.TestDocsAndPositions.testRandomDocs Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([4A60AB39E8D08E88:8658A538BE15A274]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at
[jira] [Created] (SOLR-7963) Suggester context filter query to accept local params query
Arcadius Ahouansou created SOLR-7963:
Summary: Suggester context filter query to accept local params
query
Key: SOLR-7963
URL: https://issues.apache.org/jira/browse/SOLR-7963
Project: Solr
Issue Type: Improvement
Components: Suggester
Affects Versions: 5.4
Reporter: Arcadius Ahouansou
Priority: Minor
SOLR-7888 has introduced a new parameter for filtering suggester queries
{code}suggest.cfq=ctx1 OR ctx2{code}
The implementation use the Solr {{StandardQueryParser}} for parsing the cfq
param.
This card is to allow to pass in local param queries such as
{code}
suggest.cfq={!terms f=contextx}ctx1,ctx2
{code}
--
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-7962) Passing additional arguments to solr.cmd does not work on Windows
[ https://issues.apache.org/jira/browse/SOLR-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709225#comment-14709225 ] Dawid Weiss commented on SOLR-7962: --- Could you take a look, [~thelabdude]? The changes to the solr.cmd script are a bit overwhelming -- I'm not sure how these variables get cleared along the way. Passing additional arguments to solr.cmd does not work on Windows - Key: SOLR-7962 URL: https://issues.apache.org/jira/browse/SOLR-7962 Project: Solr Issue Type: Bug Affects Versions: 5.3 Reporter: Dawid Weiss Assignee: Timothy Potter -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709271#comment-14709271 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1697388 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1697388 ] LUCENE-6699: woops Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- 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-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709303#comment-14709303
]
Karl Wright commented on LUCENE-6759:
-
[~mikemccand] ant clean test in my workarea yields:
{code}
-test:
[mkdir] Created dir: C:\wip\lucene\lucene6699\lucene\build\spatial3d\test
[mkdir] Created dir: C:\wip\lucene\lucene6699\lucene\build\spatial3d\test\te
mp
[junit4] JUnit4 says ??! Master seed: C9F7F99B0030A6AB
[junit4] Your default console's encoding may not display certain unicode glyp
hs: windows-1252
[junit4] Executing 9 suites with 3 JVMs.
[junit4]
[junit4] Started J1 PID(8768@localhost).
[junit4] Started J2 PID(1576@localhost).
[junit4] Started J0 PID(9308@localhost).
[junit4] Suite: org.apache.lucene.geo3d.GeoCircleTest
[junit4] Completed [1/9] on J1 in 0.19s, 4 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.GeoBBoxTest
[junit4] Completed [2/9] on J2 in 0.23s, 4 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.GeoModelTest
[junit4] Completed [3/9] on J1 in 0.01s, 2 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.GeoPolygonTest
[junit4] Completed [4/9] on J2 in 0.01s, 2 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.PlaneTest
[junit4] Completed [5/9] on J1 in 0.01s, 2 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.XYZSolidTest
[junit4] Completed [6/9] on J2 in 0.05s, 2 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.GeoPathTest
[junit4] Completed [7/9] on J1 in 0.03s, 5 tests
[junit4]
[junit4] Suite: org.apache.lucene.geo3d.GeoConvexPolygonTest
[junit4] Completed [8/9] on J2 in 0.00s, 2 tests
[junit4]
[junit4] Suite: org.apache.lucene.bkdtree3d.TestGeo3DPointField
[junit4] IGNOR/A 0.09s J0 | TestGeo3DPointField.testRandomBig
[junit4] Assumption #1: 'nightly' test group is disabled (@Nightly())
[junit4] Completed [9/9] on J0 in 5.18s, 6 tests, 1 skipped
[junit4]
[junit4] JVM J0: 1.86 .. 8.29 = 6.43s
[junit4] JVM J1: 1.86 .. 3.37 = 1.51s
[junit4] JVM J2: 1.86 .. 3.36 = 1.50s
[junit4] Execution time total: 8.30 sec.
[junit4] Tests summary: 9 suites, 29 tests, 1 ignored (1 assumption)
[echo] 5 slowest tests:
[junit4:tophints] 9.50s | org.apache.lucene.bkdtree3d.TestGeo3DPointField
[junit4:tophints] 1.73s | org.apache.lucene.bkdtree3d.TestBKD3DTree
[junit4:tophints] 0.20s | org.apache.lucene.geo3d.XYZSolidTest
[junit4:tophints] 0.19s | org.apache.lucene.geo3d.GeoCircleTest
[junit4:tophints] 0.16s | org.apache.lucene.geo3d.GeoBBoxTest
-check-totals:
common.test:
BUILD SUCCESSFUL
Total time: 16 seconds
{code}
After sync:
{code}
C:\wip\lucene\lucene6699\lucene\spatial3dsvn status
? capture
C:\wip\lucene\lucene6699\lucene\spatial3d
{code}
A repeat ant clean test also succeeds at that point. So I'm puzzled. Did
you run ant clean first? Changing MINIMUM_RESOLUTION does require that,
seemingly...
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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-7962) Passing additional arguments to solr.cmd does not work on Windows
Dawid Weiss created SOLR-7962: - Summary: Passing additional arguments to solr.cmd does not work on Windows Key: SOLR-7962 URL: https://issues.apache.org/jira/browse/SOLR-7962 Project: Solr Issue Type: Bug Affects Versions: 5.3 Reporter: Dawid Weiss -- 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-7896) Solr Administrative Interface Lacks Password Protection
[
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709254#comment-14709254
]
Konstantin Gribov commented on SOLR-7896:
-
My point on enabling/disabling SSL by default is that Solr is often behind
firewall and _near_ to back-end which use it, they are both in some kind of
private network, so TLS will be cpu, network and management overhead for such
cases. I believe that it's primary use case and exposed Solr installations are
rare.
Also, requiring admin UI auth seems to be a good idea only at first glance.
Under the cover it will require non-trivial role model to separate user actions
and admin actions on all available handlers (like discussed in SOLR-7838) which
heavy depends on configured handlers and use case: sometimes {{update}} is
normal action for user and {{delete by id}} is not, sometimes {{delete by id}}
should be allowed, but {{delete by query}} shouldn't etc.
Another potential issue with self-made security framework is creating high
quality security modules. If some of them may be created and distributed with
Solr, so pass some QA by Solr committers, third party modules can have lesser
quality and affect overall Solr experience. Buggy or just slow third party
security filter will lead to bad user experience. Credentials and authN/authZ
rules caching and synchronization are other hard-to-implement-correctly part,
especially in distributed environment.
Since role to user mapping is non-trivial and authN/authZ is hard to configure,
security setup as standard Solr installation step would be frightening for many
users. I think, it should be optional for users, who want or have to use such
security model.
Solr Administrative Interface Lacks Password Protection
---
Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical
Out of the box, the Solr interface should require an administrative password
that the user is required to set. Apparently there are ways of configuring
Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced
Linux admin and a programmer; I've tried, numerous times, and I've not once
been able to get it to work. The point is this, though:
*No one should have to try to get their Solr instance to support password
authentication and preferably SSL (even if it's just with a self-signed
certificate). Solr is designed to store huge amounts of data and is therefore
a likely target for malicious users.*
This needs to be addressed! It's 2015 and Solr is on version 5!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 13983 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13983/ Java: 32bit/jdk1.8.0_60 -client -XX:+UseParallelGC 2 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([18E435A723339E7D]: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:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: [/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_18E435A723339E7D-001/solr-instance-018/./collection1/data, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_18E435A723339E7D-001/solr-instance-018/./collection1/data/index.20150824160622123, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_18E435A723339E7D-001/solr-instance-018/./collection1/data/index.2015082416064] expected:2 but was:3 Stack Trace: java.lang.AssertionError: [/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_18E435A723339E7D-001/solr-instance-018/./collection1/data, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_18E435A723339E7D-001/solr-instance-018/./collection1/data/index.20150824160622123, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_18E435A723339E7D-001/solr-instance-018/./collection1/data/index.2015082416064] expected:2 but was:3 at __randomizedtesting.SeedInfo.seed([18E435A723339E7D:EF97DBFFE5DB319B]: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.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:813) at
[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709283#comment-14709283
]
Michael McCandless commented on LUCENE-6759:
bq. I'd also like to know what exactly you do to beast this patch, so that I
may do the same here.
I use the {{repeatLuceneTest.py}} from luceneutil, but {{ant beast}} should
work well too, something like:
{noformat}
ant beast -Dbeast.iters=100 -Dtestcase=TestGeo3DPointField
-Dtestmethod=testRandomMedium -Dtests.dups=6 -Dtests.iters=10
{noformat}
will run 6 JVMs concurrently (I think?), each JVM repeating this one test
method 10 times w/ the same master seed, and those 6 JVMs will stop and start
100 times.
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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-6759) Integrate lat/long BKD and spatial 3d, part 2
[ https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709296#comment-14709296 ] Karl Wright commented on LUCENE-6759: - Hmm, I don't see that in my workarea (before synching anyway). Let me dig. Integrate lat/long BKD and spatial 3d, part 2 - Key: LUCENE-6759 URL: https://issues.apache.org/jira/browse/LUCENE-6759 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Attachments: LUCENE-6699.patch This is just a continuation of LUCENE-6699, which became too big. -- 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-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709317#comment-14709317
]
Karl Wright commented on LUCENE-6759:
-
Running the beaster made it through 6 rounds, but then failed with this:
{code}
[beaster] 2 sie 24, 2015 3:48:21 PM com.carrotsearch.randomizedtesting.Rand
omizedRunner$QueueUncaughtExceptionsHandler uncaughtException
[beaster] 2 WARNING: Uncaught exception in thread: Thread[T0,5,TGRP-TestGeo
3DPointField]
[beaster] 2 java.lang.AssertionError: expected WITHIN (1) or OVERLAPS (2) b
ut got 3; shape=GeoCircle: {planetmodel=PlanetModel.SPHERE, center=[lat=-0.00216
27146783861745, lon=-0.0017298167021592304], radius=2.0818312293195752E-4(0.0119
28014309854351)}; XYZSolid=XYZSolid: {planetmodel=PlanetModel.SPHERE, isWholeWor
ld=false, minXplane=[A=1.0, B=0.0, C=0.0, D=-0.955669921241, side=1.0], maxX
plane=[A=1.0, B=0.0, C=0.0, D=-0.967200767939, side=-1.0], minYplane=[A=0.0,
B=1.0, C=0.0, D=0.0019379945667919352, side=1.0], maxYplane=[A=0.0, B=1.0, C=0.
0, D=0.0015216289462746052, side=-1.0], minZplane=[A=0.0, B=0.0, C=1.0, D=0.0023
708955797907497, side=1.0], maxZplane=[A=0.0, B=0.0, C=1.0, D=0.0019545303111802
707, side=-1.0]}
[beaster] 2at __randomizedtesting.SeedInfo.seed([485BDCE0789B5CDC]:
0)
[beaster] 2at org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1.
scorer(PointInGeo3DShapeQuery.java:105)
[beaster] 2at org.apache.lucene.search.LRUQueryCache$CachingWrapper
Weight.scorer(LRUQueryCache.java:589)
[beaster] 2at org.apache.lucene.search.Weight.bulkScorer(Weight.jav
a:135)
[beaster] 2at org.apache.lucene.search.AssertingWeight.bulkScorer(A
ssertingWeight.java:69)
[beaster] 2at org.apache.lucene.search.AssertingWeight.bulkScorer(A
ssertingWeight.java:69)
[beaster] 2at org.apache.lucene.search.IndexSearcher.search(IndexSe
archer.java:618)
[beaster] 2at org.apache.lucene.search.AssertingIndexSearcher.searc
h(AssertingIndexSearcher.java:92)
[beaster] 2at org.apache.lucene.search.IndexSearcher.search(IndexSe
archer.java:425)
[beaster] 2at org.apache.lucene.bkdtree3d.TestGeo3DPointField$4._ru
n(TestGeo3DPointField.java:587)
[beaster] 2at org.apache.lucene.bkdtree3d.TestGeo3DPointField$4.run
(TestGeo3DPointField.java:521)
[beaster] 2
[beaster] 2 NOTE: reproduce with: ant test -Dtestcase=TestGeo3DPointField
-Dtests.method=testRandomMedium -Dtests.seed=485BDCE0789B5CDC -Dtests.slow=true
-Dtests.locale=pl_PL -Dtests.timezone=Africa/Tripoli -Dtests.asserts=true -Dtest
s.file.encoding=ISO-8859-1
[beaster] [09:48:13.669] ERROR 11.3s J0 | TestGeo3DPointField.testRandomMedi
um {#0 seed=[485BDCE0789B5CDC:F585EB4839FE3FBA]}
[beaster] Throwable #1: com.carrotsearch.randomizedtesting.UncaughtExcept
ionError: Captured an uncaught exception in thread: Thread[id=17, name=T0, state
=RUNNABLE, group=TGRP-TestGeo3DPointField]
[beaster]at __randomizedtesting.SeedInfo.seed([485BDCE0789B5CDC:F
585EB4839FE3FBA]:0)
[beaster] Caused by: java.lang.AssertionError: expected WITHIN (1) or OVE
RLAPS (2) but got 3; shape=GeoCircle: {planetmodel=PlanetModel.SPHERE, center=[l
at=-0.0021627146783861745, lon=-0.0017298167021592304], radius=2.081831229319575
2E-4(0.011928014309854351)}; XYZSolid=XYZSolid: {planetmodel=PlanetModel.SPHERE,
isWholeWorld=false, minXplane=[A=1.0, B=0.0, C=0.0, D=-0.955669921241, side
=1.0], maxXplane=[A=1.0, B=0.0, C=0.0, D=-0.967200767939, side=-1.0], minYpl
ane=[A=0.0, B=1.0, C=0.0, D=0.0019379945667919352, side=1.0], maxYplane=[A=0.0,
B=1.0, C=0.0, D=0.0015216289462746052, side=-1.0], minZplane=[A=0.0, B=0.0, C=1.
0, D=0.0023708955797907497, side=1.0], maxZplane=[A=0.0, B=0.0, C=1.0, D=0.00195
45303111802707, side=-1.0]}
[beaster]at __randomizedtesting.SeedInfo.seed([485BDCE0789B5CDC]:
0)
[beaster]at org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1.
scorer(PointInGeo3DShapeQuery.java:105)
[beaster]at org.apache.lucene.search.LRUQueryCache$CachingWrapper
Weight.scorer(LRUQueryCache.java:589)
[beaster]at org.apache.lucene.search.Weight.bulkScorer(Weight.jav
a:135)
[beaster]at org.apache.lucene.search.AssertingWeight.bulkScorer(A
ssertingWeight.java:69)
[beaster]at org.apache.lucene.search.AssertingWeight.bulkScorer(A
ssertingWeight.java:69)
[beaster]at org.apache.lucene.search.IndexSearcher.search(IndexSe
archer.java:618)
[beaster]at org.apache.lucene.search.AssertingIndexSearcher.searc
h(AssertingIndexSearcher.java:92)
[beaster]at org.apache.lucene.search.IndexSearcher.search(IndexSe
archer.java:425)
[beaster]at org.apache.lucene.bkdtree3d.TestGeo3DPointField$4._ru
n(TestGeo3DPointField.java:587)
[beaster]at
[jira] [Updated] (SOLR-7962) Passing additional arguments to solr.cmd does not work on Windows
[ https://issues.apache.org/jira/browse/SOLR-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-7962: - Assignee: (was: Timothy Potter) Passing additional arguments to solr.cmd does not work on Windows - Key: SOLR-7962 URL: https://issues.apache.org/jira/browse/SOLR-7962 Project: Solr Issue Type: Bug Affects Versions: 5.3 Reporter: Dawid Weiss -- 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-7962) Passing additional arguments to solr.cmd does not work on Windows
[
https://issues.apache.org/jira/browse/SOLR-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709221#comment-14709221
]
Dawid Weiss commented on SOLR-7962:
---
SOLR-7847 broke the windows {{solr.cmd}} script. Specifically, passing
arguments via {{-a}} no longer works in conjunction with example ({{-e}})
option. For example this:
{code}
bin\solr start -e techproducts -a -Dsolr.clustering.enabled=true
{code}
Does not pass the sysproperty properly. The problem is, as far as I can tell,
in the fact that local variables ({{SOLR_ADDL_ARGS}}) get erased somehow during
example setup.
Passing additional arguments to solr.cmd does not work on Windows
-
Key: SOLR-7962
URL: https://issues.apache.org/jira/browse/SOLR-7962
Project: Solr
Issue Type: Bug
Affects Versions: 5.3
Reporter: Dawid Weiss
--
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-7962) Passing additional arguments to solr.cmd does not work on Windows
[ https://issues.apache.org/jira/browse/SOLR-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-7962: -- Assignee: Timothy Potter Passing additional arguments to solr.cmd does not work on Windows - Key: SOLR-7962 URL: https://issues.apache.org/jira/browse/SOLR-7962 Project: Solr Issue Type: Bug Affects Versions: 5.3 Reporter: Dawid Weiss Assignee: Timothy Potter -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709268#comment-14709268 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1697386 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1697386 ] LUCENE-6699: MINIMUM_RESOLUTION back to 1e-12 Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- 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-7962) Passing additional arguments to solr.cmd does not work on Windows
[
https://issues.apache.org/jira/browse/SOLR-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709316#comment-14709316
]
Timothy Potter commented on SOLR-7962:
--
Can you try just passing the -D sys props without the -a wrapper, ie.
{code}
bin\solr start -e techproducts -Dsolr.clustering.enabled=true
{code}
The -a isn't intended for -D args, but we still need to fix the solr.cmd script
to support it. In the meantime, you can add any additional args to the
solr.in.cmd file and they will get applied correctly.
Passing additional arguments to solr.cmd does not work on Windows
-
Key: SOLR-7962
URL: https://issues.apache.org/jira/browse/SOLR-7962
Project: Solr
Issue Type: Bug
Affects Versions: 5.3
Reporter: Dawid Weiss
Assignee: Timothy Potter
--
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 # 774 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/774/ 2 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=17888, name=collection1, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=17888, name=collection1, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:34691, http://127.0.0.1:46838, http://127.0.0.1:43095, http://127.0.0.1:48099, http://127.0.0.1:47081] at __randomizedtesting.SeedInfo.seed([16065656F6904182]:0) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:898) Caused by: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:34691, http://127.0.0.1:46838, http://127.0.0.1:43095, http://127.0.0.1:48099, http://127.0.0.1:47081] at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895) Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34691: KeeperErrorCode = Session expired for /overseer/collection-queue-work/qn- at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325) ... 5 more FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=29644, name=collection3, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=29644, name=collection3, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35116: Could not find collection : awholynewstresscollection_collection3_0 at __randomizedtesting.SeedInfo.seed([16065656F6904182]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895) Build Log: [...truncated 10519 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest_16065656F6904182-001/init-core-data-001 [junit4] 2 1465543 INFO (SUITE-CollectionsAPIDistributedZkTest-seed#[16065656F6904182]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2 1465544 INFO (SUITE-CollectionsAPIDistributedZkTest-seed#[16065656F6904182]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2
[jira] [Updated] (SOLR-7960) bin/solr -h should print generic help
[
https://issues.apache.org/jira/browse/SOLR-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7960:
--
Description:
Typing only:
{code}
bin/solr
{code}
...prints the generic tool help, but if you add a -h
{code}
bin/solr -h
{code}
...you get an error message and the help for the {{start}} command. In fact,
any unknown parameter given, such as {{bin/solr -foo}} will assume {{start}}.
This is confusing, since -h is a common help option. Could check for the
special case where there is *only* the {{-h}} switch given, in which case we
should not assume the intention is to do {{start}} but to get help.
was:
Typing only:
{code}
bin/solr
{code}
...prints the generic tool help, but if you add a -h
{code}
bin/solr -h
{code}
...you get an error message and the help for the {{start}} command.
This is confusing, since -h is a common help option. Could check for the
special case where there is *only* the {{-h}} switch given, in which case we
should not assume the intention is to do {{start}} but to get help.
bin/solr -h should print generic help
-
Key: SOLR-7960
URL: https://issues.apache.org/jira/browse/SOLR-7960
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Reporter: Jan Høydahl
Priority: Trivial
Typing only:
{code}
bin/solr
{code}
...prints the generic tool help, but if you add a -h
{code}
bin/solr -h
{code}
...you get an error message and the help for the {{start}} command. In fact,
any unknown parameter given, such as {{bin/solr -foo}} will assume {{start}}.
This is confusing, since -h is a common help option. Could check for the
special case where there is *only* the {{-h}} switch given, in which case we
should not assume the intention is to do {{start}} but to get help.
--
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] [Assigned] (SOLR-7121) Solr nodes should go down based on configurable thresholds and not rely on resource exhaustion
[ https://issues.apache.org/jira/browse/SOLR-7121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-7121: - Assignee: Mark Miller Solr nodes should go down based on configurable thresholds and not rely on resource exhaustion -- Key: SOLR-7121 URL: https://issues.apache.org/jira/browse/SOLR-7121 Project: Solr Issue Type: New Feature Reporter: Sachin Goyal Assignee: Mark Miller Attachments: SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch Currently, there is no way to control when a Solr node goes down. If the server is having high GC pauses or too many threads or is just getting too many queries due to some bad load-balancer, the cores in the machine keep on serving unless they exhaust the machine's resources and everything comes to a stall. Such a slow-dying core can affect other cores as well by taking huge time to serve their distributed queries. There should be a way to specify some threshold values beyond which the targeted core can its ill-health and proactively go down to recover. When the load improves, the core should come up automatically. -- 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-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709274#comment-14709274
]
Michael McCandless commented on LUCENE-6759:
[~daddywri] thank you, I committed that last patch, but noticed
GeoCircleTest.testCircleBounds is angry:
{noformat}
[junit4] Suite: org.apache.lucene.geo3d.GeoCircleTest
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=GeoCircleTest
-Dtests.method=testCircleBounds -Dtests.seed=8068B689836F03CE
-Dtests.locale=es_PR -Dtests.timezone=Europe/Zagreb -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.05s J1 | GeoCircleTest.testCircleBounds
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([8068B689836F03CE:75EBD17B83B5147A]:0)
[junit4]at
org.apache.lucene.geo3d.GeoCircleTest.testCircleBounds(GeoCircleTest.java:111)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53): {},
docValues:{}, sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {},
locale=es_PR, timezone=Europe/Zagreb
[junit4] 2 NOTE: Linux 3.13.0-46-generic amd64/Oracle Corporation
1.8.0_40 (64-bit)/cpus=8,threads=1,free=425655240,total=504889344
[junit4] 2 NOTE: All tests run in this JVM: [GeoCircleTest]
[junit4] Completed [6/9] on J1 in 0.27s, 4 tests, 1 failure FAILURES!
{noformat}
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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-7962) Passing additional arguments to solr.cmd does not work on Windows
[
https://issues.apache.org/jira/browse/SOLR-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709276#comment-14709276
]
Dawid Weiss commented on SOLR-7962:
---
It seems like running the example doesn't pass the additional args at all now:
{code}
:run_example
REM Run the requested example
%JAVA% %SOLR_SSL_OPTS% -Dsolr.install.dir=%SOLR_TIP%
-Dlog4j.configuration=file:%DEFAULT_SERVER_DIR%\scripts\cloud-scripts\log4j.properties
^
-classpath
%DEFAULT_SERVER_DIR%\solr-webapp\webapp\WEB-INF\lib\*;%DEFAULT_SERVER_DIR%\lib\ext\*
^
org.apache.solr.util.SolrCLI run_example -script %SDIR%\solr.cmd -e
%EXAMPLE% -d %SOLR_SERVER_DIR% -urlScheme !SOLR_URL_SCHEME!
!PASS_TO_RUN_EXAMPLE!
REM End of run_example
goto done
{code}
Passing additional arguments to solr.cmd does not work on Windows
-
Key: SOLR-7962
URL: https://issues.apache.org/jira/browse/SOLR-7962
Project: Solr
Issue Type: Bug
Affects Versions: 5.3
Reporter: Dawid Weiss
Assignee: Timothy Potter
--
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-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-7569: --- Attachment: SOLR-7569_lir_down_state_test.patch A patch containing the test that simulates the state described above. Create an API to force a leader election between nodes -- Key: SOLR-7569 URL: https://issues.apache.org/jira/browse/SOLR-7569 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Shalin Shekhar Mangar Labels: difficulty-medium, impact-high Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569_lir_down_state_test.patch There are many reasons why Solr will not elect a leader for a shard e.g. all replicas' last published state was recovery or due to bugs which cause a leader to be marked as 'down'. While the best solution is that they never get into this state, we need a manual way to fix this when it does get into this state. Right now we can do a series of dance involving bouncing the node (since recovery paths between bouncing and REQUESTRECOVERY are different), but that is difficult when running a large cluster. Although it is possible that such a manual API may lead to some data loss but in some cases, it is the only possible option to restore availability. This issue proposes to build a new collection API which can be used to force replicas into recovering a leader while avoiding data loss on a best effort basis. -- 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-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709330#comment-14709330 ] Ishan Chattopadhyaya commented on SOLR-7569: I just tried to simulate the scenario where all the replicas are in down state due to LIR, and there is no leader. In this state, the leader election queue is empty. So, I am thinking of some way to have the replicas (that are on live nodes) to join the leader election. Is there any clean way of doing that, short of a core reload? Create an API to force a leader election between nodes -- Key: SOLR-7569 URL: https://issues.apache.org/jira/browse/SOLR-7569 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Shalin Shekhar Mangar Labels: difficulty-medium, impact-high Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569_lir_down_state_test.patch There are many reasons why Solr will not elect a leader for a shard e.g. all replicas' last published state was recovery or due to bugs which cause a leader to be marked as 'down'. While the best solution is that they never get into this state, we need a manual way to fix this when it does get into this state. Right now we can do a series of dance involving bouncing the node (since recovery paths between bouncing and REQUESTRECOVERY are different), but that is difficult when running a large cluster. Although it is possible that such a manual API may lead to some data loss but in some cases, it is the only possible option to restore availability. This issue proposes to build a new collection API which can be used to force replicas into recovering a leader while avoiding data loss on a best effort basis. -- 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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arcadius Ahouansou updated SOLR-7888:
-
Attachment: SOLR-7888.patch
Adding in the test a reference to SOLR-7963 and SOLR-7964
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Assignee: Jan Høydahl
Fix For: 5.4
Attachments: SOLR-7888.patch, SOLR-7888.patch, SOLR-7888.patch,
SOLR-7888.patch, SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
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] [Assigned] (SOLR-7960) bin/solr -h should print generic help
[
https://issues.apache.org/jira/browse/SOLR-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-7960:
-
Assignee: Jan Høydahl
bin/solr -h should print generic help
-
Key: SOLR-7960
URL: https://issues.apache.org/jira/browse/SOLR-7960
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Trivial
Typing only:
{code}
bin/solr
{code}
...prints the generic tool help, but if you add a -h
{code}
bin/solr -h
{code}
...you get an error message and the help for the {{start}} command. In fact,
any unknown parameter given, such as {{bin/solr -foo}} will assume {{start}}.
This is confusing, since -h is a common help option. Could check for the
special case where there is *only* the {{-h}} switch given, in which case we
should not assume the intention is to do {{start}} but to get help.
--
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: [VOTE] 5.3.0 RC2
I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
Lucene News (on Lucene sub page) completely unformatted which page exactly others fixed. Actually I was planning to release later that's why I kept it 25 August ;) On Mon, Aug 24, 2015 at 8:24 PM, Uwe Schindler u...@thetaphi.de wrote: Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
*) In built security plugins = Built-in? In fact, I am confused reading that item and the next one. Are they the same or different? Items #1 and #2 are different Built-in or in-built ? I'm not sure either On Mon, Aug 24, 2015 at 8:45 PM, Alexandre Rafalovitch arafa...@gmail.com wrote: Under Solr highlights: *) In built security plugins = Built-in? In fact, I am confused reading that item and the next one. Are they the same or different? *) The MoreLikeThis QParser mlt = ... extra mlt? *) (Added?) Scoring mode for query-time join and block join. *) (Added? language-neutral?) Smile response format Regards, Alex. Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter: http://www.solr-start.com/ On 24 August 2015 at 10:47, Noble Paul noble.p...@gmail.com wrote: I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709389#comment-14709389
]
Karl Wright commented on LUCENE-6759:
-
{code}
[junit4] 2 Distance to circle plane = 2.220446049250313E-16
{code}
... which is 4 orders of magnitude less than MINIMUM_RESOLUTION. Clearly not
the problem. Looking at getBounds() next...
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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: [VOTE] 5.3.0 RC2
Under Solr highlights: *) In built security plugins = Built-in? In fact, I am confused reading that item and the next one. Are they the same or different? *) The MoreLikeThis QParser mlt = ... extra mlt? *) (Added?) Scoring mode for query-time join and block join. *) (Added? language-neutral?) Smile response format Regards, Alex. Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter: http://www.solr-start.com/ On 24 August 2015 at 10:47, Noble Paul noble.p...@gmail.com wrote: I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6629) Watch /collections zk node on all nodes
[ https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709456#comment-14709456 ] Shalin Shekhar Mangar commented on SOLR-6629: - [~dragonsinth] - did you upload the right patch? I still see caching in LazyCollectionRef. Watch /collections zk node on all nodes --- Key: SOLR-6629 URL: https://issues.apache.org/jira/browse/SOLR-6629 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: Trunk Attachments: SOLR-6629.patch, SOLR-6629.patch, SOLR-6629.patch, SOLR-6629.patch The main clusterstate.json is refreshed/used as a poor substitute for informing all nodes about new or deleted collections even when the collection being created or deleted has state format 1. When we move away from state format 1 then we should do away with this workaround and start watching the /collections zk node on all nodes. -- 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-SmokeRelease-trunk - Build # 257 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/257/
No tests ran.
Build Log:
[...truncated 52325 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist
[copy] Copying 461 files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene
[copy] Copying 245 files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.8
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
[smoker] NOTE: output encoding is UTF-8
[smoker]
[smoker] Load release URL
file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/...
[smoker]
[smoker] Test Lucene...
[smoker] test basics...
[smoker] get KEYS
[smoker] 0.1 MB in 0.01 sec (11.8 MB/sec)
[smoker] check changes HTML...
[smoker] download lucene-6.0.0-src.tgz...
[smoker] 28.1 MB in 0.03 sec (887.6 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-6.0.0.tgz...
[smoker] 64.9 MB in 0.09 sec (751.5 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-6.0.0.zip...
[smoker] 75.2 MB in 0.09 sec (814.9 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] unpack lucene-6.0.0.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.8...
[smoker] got 5835 hits for query lucene
[smoker] checkindex with 1.8...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-6.0.0.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.8...
[smoker] got 5835 hits for query lucene
[smoker] checkindex with 1.8...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-6.0.0-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run ant validate
[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
[smoker] test demo with 1.8...
[smoker] got 213 hits for query lucene
[smoker] checkindex with 1.8...
[smoker] generate javadocs w/ Java 8...
[smoker]
[smoker] Crawl/parse...
[smoker]
[smoker] Verify...
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Releases that don't seem to be tested:
[smoker] 5.3.0
[smoker] Traceback (most recent call last):
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1416, in module
[smoker] main()
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1361, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, ' '.join(c.test_args))
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1399, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, svnRevision, version, testArgs, baseURL)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 583, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
svnRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 728, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1354, in confirmAllReleasesAreTestedForBackCompat
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/build.xml:527:
exec returned: 1
Total time: 37 minutes 48 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
Thanks Uwe , fixed On Mon, Aug 24, 2015 at 8:54 PM, Uwe Schindler u...@thetaphi.de wrote: http://lucene.staging.apache.org/ = NOW looks OK, 10 mins ago, the last Solr item was on wrong line http://lucene.staging.apache.org/core/corenews.html = this one is completely unformatted http://lucene.staging.apache.org/solr/news.html = looks OK Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:12 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Lucene News (on Lucene sub page) completely unformatted which page exactly others fixed. Actually I was planning to release later that's why I kept it 25 August ;) On Mon, Aug 24, 2015 at 8:24 PM, Uwe Schindler u...@thetaphi.de wrote: Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0- RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0- RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul -- --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7964) suggest.highlight=true does not work when using context filter query
Arcadius Ahouansou created SOLR-7964:
Summary: suggest.highlight=true does not work when using context
filter query
Key: SOLR-7964
URL: https://issues.apache.org/jira/browse/SOLR-7964
Project: Solr
Issue Type: Improvement
Components: Suggester
Affects Versions: 5.4
Reporter: Arcadius Ahouansou
Priority: Minor
When using the new suggester context filtering query param {{suggest.cfq}}
introduced in SOLR-7888, the param {{suggest.highlight=true}} has no effect.
This is a bug that needs to be addressed here
--
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-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709383#comment-14709383
]
Karl Wright commented on LUCENE-6759:
-
Coding this up as its own explicit test yields the following:
{code}
[junit4] 2 Shape edge points:
[junit4] 2 Point 0.965937741284 -0.0017298125353661473
-0.001954530310113696: isWithin? false; minx=1.0267820043097231E-6,
maxx=-1.2630266543744995E-7, miny=2.0818203142578787E-4,
maxy=-2.0818358909154206E-4, minz=4.1636526967705383E-4,
maxz=1.0665747798843661E-12
{code}
So the bounds object that's computed fails to contain the edgepoint for the
circle, by a very small amount (1.0665747798843661E-12). That's 7% larger than
the MINIMUM_RESOLUTION value.
I'm going to look first at whether there are any ways I can think of to reduce
the error. First I'll see how far the edgepoint is from the circle plane.
Presuming that's not the source of most of the error, then the next step would
be to look at the bounds computation itself for error reduction. If all else
fails, then MINIMUM_RESOLUTION will have to grow by 7%.
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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: [VOTE] 5.3.0 RC2
http://lucene.staging.apache.org/ = NOW looks OK, 10 mins ago, the last Solr item was on wrong line http://lucene.staging.apache.org/core/corenews.html = this one is completely unformatted http://lucene.staging.apache.org/solr/news.html = looks OK Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:12 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Lucene News (on Lucene sub page) completely unformatted which page exactly others fixed. Actually I was planning to release later that's why I kept it 25 August ;) On Mon, Aug 24, 2015 at 8:24 PM, Uwe Schindler u...@thetaphi.de wrote: Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0- RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0- RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul -- --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail:
[jira] [Commented] (SOLR-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709479#comment-14709479 ] Erick Erickson commented on SOLR-4316: -- bq: Would that work? Then, if people are happy with that, I can complete this task and get on with working on the collections Let's do the minimum necessary to cut over to the new Angular JS version. I think it's important to get people using that version, flush out any lingering issues then move on with improvements rather than wait for new functionality. FWIW Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, collections menu open.png, cores menu open.png, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-7961) Add version command to bin/solr start script
[
https://issues.apache.org/jira/browse/SOLR-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7961:
--
Fix Version/s: 5.4
Add version command to bin/solr start script
Key: SOLR-7961
URL: https://issues.apache.org/jira/browse/SOLR-7961
Project: Solr
Issue Type: New Feature
Components: scripts and tools
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Trivial
Fix For: 5.4
It would be nice to be able to tell which version of Solr you have. You can
get it with the {{status}} command today, but only if Solr is already
running. Proposal:
{noformat}
$ bin/solr -version
5.3.0
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
Hi Noble, On all three news pages, you have the announcement date at 25 August (tomorrow in the US, Europe and India). If you’re going to announce shortly (within the next 3.5 hours, when the date will advance for you in India), those should be 24 August. (Along the same lines, the dates on the announcment texts on the wikis don’t have the correct date either.) A couple issues I found in core/corenews.html (I saw you did some commits to fix formatting issues; if they aren’t showing up on the staging site, you might need to commit a whitespace-only change to a file under the top-level lib/ dir. to force a full site rebuild): * Lucene 5.3.0 release highlights:” shows up twice, not sure if there’s more duplication there. * In the 5.3.0 news item, there are a bunch of bullets that don’t start on their own line. Looks like you did some reformatting of the Lucene news on the top level news page, but not on the Lucene-specific page core/corenews.html? Otherwise, looks good! Thanks Noble for handling the release. Steve On Aug 24, 2015, at 10:47 AM, Noble Paul noble.p...@gmail.com wrote: I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-7569: --- Assignee: Shalin Shekhar Mangar Create an API to force a leader election between nodes -- Key: SOLR-7569 URL: https://issues.apache.org/jira/browse/SOLR-7569 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Labels: difficulty-medium, impact-high Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569_lir_down_state_test.patch There are many reasons why Solr will not elect a leader for a shard e.g. all replicas' last published state was recovery or due to bugs which cause a leader to be marked as 'down'. While the best solution is that they never get into this state, we need a manual way to fix this when it does get into this state. Right now we can do a series of dance involving bouncing the node (since recovery paths between bouncing and REQUESTRECOVERY are different), but that is difficult when running a large cluster. Although it is possible that such a manual API may lead to some data loss but in some cases, it is the only possible option to restore availability. This issue proposes to build a new collection API which can be used to force replicas into recovering a leader while avoiding data loss on a best effort basis. -- 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-6625) Add interceptor API for outgoing calls through HttpSolrClient
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709449#comment-14709449 ] Shalin Shekhar Mangar commented on SOLR-6625: - Is this feature complete? Can we close this issue? Add interceptor API for outgoing calls through HttpSolrClient - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-revert.patch, SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- 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-7775) support SolrCloud collection as fromIndex param in query-time join
[ https://issues.apache.org/jira/browse/SOLR-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-7775: --- Fix Version/s: (was: 5.3) 5.4 support SolrCloud collection as fromIndex param in query-time join -- Key: SOLR-7775 URL: https://issues.apache.org/jira/browse/SOLR-7775 Project: Solr Issue Type: Sub-task Components: query parsers Reporter: Mikhail Khludnev Assignee: Mikhail Khludnev Fix For: 5.4 Attachments: SOLR-7775.patch, SOLR-7775.patch it's allusion to SOLR-4905, will be addressed right after SOLR-6234 -- 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] [Assigned] (SOLR-7961) Add version command to bin/solr start script
[
https://issues.apache.org/jira/browse/SOLR-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-7961:
-
Assignee: Jan Høydahl
Add version command to bin/solr start script
Key: SOLR-7961
URL: https://issues.apache.org/jira/browse/SOLR-7961
Project: Solr
Issue Type: New Feature
Components: scripts and tools
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Trivial
Fix For: 5.4
It would be nice to be able to tell which version of Solr you have. You can
get it with the {{status}} command today, but only if Solr is already
running. Proposal:
{noformat}
$ bin/solr -version
5.3.0
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709403#comment-14709403 ] Ishan Chattopadhyaya commented on SOLR-7569: In this state, the leader election queue is empty. Ignore that, I was catching that state before the replicas had a chance to rejoin the election. The last assert in the patch is inappropriate. Create an API to force a leader election between nodes -- Key: SOLR-7569 URL: https://issues.apache.org/jira/browse/SOLR-7569 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Shalin Shekhar Mangar Labels: difficulty-medium, impact-high Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569_lir_down_state_test.patch There are many reasons why Solr will not elect a leader for a shard e.g. all replicas' last published state was recovery or due to bugs which cause a leader to be marked as 'down'. While the best solution is that they never get into this state, we need a manual way to fix this when it does get into this state. Right now we can do a series of dance involving bouncing the node (since recovery paths between bouncing and REQUESTRECOVERY are different), but that is difficult when running a large cluster. Although it is possible that such a manual API may lead to some data loss but in some cases, it is the only possible option to restore availability. This issue proposes to build a new collection API which can be used to force replicas into recovering a leader while avoiding data loss on a best effort basis. -- 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-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709402#comment-14709402
]
Karl Wright commented on LUCENE-6759:
-
getBounds() also seems to have low error when computing the Z bound:
{code}
[junit4] 2 this.evaluate(point)=1.1102230246251565E-16;
normalizedZPlane.evaluate(point)=0.0
[junit4] 2 this.evaluate(point)=0.0;
normalizedZPlane.evaluate(point)=2.1684043449710089E-19
{code}
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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: [VOTE] 5.3.0 RC2
Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_60) - Build # 5064 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5064/ Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseG1GC 2 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([77D0C33D8A2425E0]: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:236) at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog\tlog.000: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog\tlog.000: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_77D0C33D8A2425E0-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica2: java.nio.file.DirectoryNotEmptyException:
[jira] [Commented] (SOLR-4316) Admin UI - SolrCloud - extend core options to collections
[
https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709521#comment-14709521
]
Shalin Shekhar Mangar commented on SOLR-4316:
-
{quote}
However, that's a reasonable amount of work, and I'd rather get this feature
out before I engage with creating two very new panes, and all the issues of
interlinking them.
How's about, in the meantime, when in cloud mode, I add an annotation close to
the load terms button saying terms will be loaded from the XYZ core and do
not represent the whole collection.
{quote}
Sounds good to me. The reason why I was never able to complete this issue was
because it required me to create a completely new page (Collection Dashboard)
so let's shoot for progress first and perfection after.
Admin UI - SolrCloud - extend core options to collections
-
Key: SOLR-4316
URL: https://issues.apache.org/jira/browse/SOLR-4316
Project: Solr
Issue Type: Improvement
Components: web gui
Affects Versions: 4.1
Reporter: Shawn Heisey
Assignee: Upayavira
Fix For: 4.9, Trunk
Attachments: SOLR-4316.patch, SOLR-4316.patch, collections menu
open.png, cores menu open.png, solrcloud-admin-ui-menu.png, two-selectors.png
There are a number of sections available when you are looking at a core in
the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser,
Plugins / Stats, and Dataimport are the ones that I can see.
A list of collections should be available, with as many of those options that
can apply to a collection, If options specific to collections/SolrCloud can
be implemented, those should be there too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 13985 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13985/ Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: [/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_22CBE20B392C18E8-001/solr-instance-009/./collection1/data/index.20150824103145801, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_22CBE20B392C18E8-001/solr-instance-009/./collection1/data/index.20150824103145894, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_22CBE20B392C18E8-001/solr-instance-009/./collection1/data] expected:2 but was:3 Stack Trace: java.lang.AssertionError: [/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_22CBE20B392C18E8-001/solr-instance-009/./collection1/data/index.20150824103145801, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_22CBE20B392C18E8-001/solr-instance-009/./collection1/data/index.20150824103145894, /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_22CBE20B392C18E8-001/solr-instance-009/./collection1/data] expected:2 but was:3 at __randomizedtesting.SeedInfo.seed([22CBE20B392C18E8:D5B80C53FFC4B70E]: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.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:813) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at
[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2
[ https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709579#comment-14709579 ] Karl Wright commented on LUCENE-6759: - I wound up discovering that the delta between a shape and the XYZBounds that might be returned for a shape was more than 10x 1.5e-12. That's not a number I can increase MINIMUM_RESOLUTION to, unfortunately. The cause of the delta is that very same case of a very small circle on or about z=0. The delta between the geocircle's plane and the maxz value may only be 1e-16, but if the circle is small enough that delta translates to a delta in Z of 5e-11 or so, which is way outside the MINIMUM_RESOLUTION in z. The solution I'm exploring now is to simply add a fudge factor to all bounds values. This fudge factor is designed to cover any deltas due to error values being magnified in this way. So far (beasting round 20) it seems to be working. I may also reduce MINIMUM_RESOLUTION to a lower value if this seems to be effective for all of our test cases. Integrate lat/long BKD and spatial 3d, part 2 - Key: LUCENE-6759 URL: https://issues.apache.org/jira/browse/LUCENE-6759 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Attachments: LUCENE-6699.patch This is just a continuation of LUCENE-6699, which became too big. -- 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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709508#comment-14709508 ] Upayavira commented on SOLR-4316: - My take is ever so slightly different - I'd like to do the absolute minimum to make it worth people's time to switch over to the new one. To my mind, that is this ticket and SOLR-4388. If we have both of these in place as new features, and have covered SOLR-7856 then I'd be happy to proceed to make it default. Still aiming for all that for 5.4. i.e. if we're gonna make things worse for people (some lingering bugs) we might as well also make it a little better (new features). Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, collections menu open.png, cores menu open.png, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time
[
https://issues.apache.org/jira/browse/SOLR-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709496#comment-14709496
]
Steve Rowe commented on SOLR-5344:
--
My Jenkins found a seed on the 5.3 release branch with Java8
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.3-Java8/222/], reproduces
for me on OS X on lucene_solr_5_3, branch_5x and trunk with Java8 (all three
branches at r1697441):
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=SpellCheckCollatorTest -Dtests.method=testEstimatedHitCounts
-Dtests.seed=9F0E3D70573DAFC9 -Dtests.slow=true -Dtests.locale=en_CA
-Dtests.timezone=America/Dawson_Creek -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.71s | SpellCheckCollatorTest.testEstimatedHitCounts
[junit4] Throwable #1: java.lang.RuntimeException: Exception during
query
[junit4]at
__randomizedtesting.SeedInfo.seed([9F0E3D70573DAFC9:AEB58345F202BF19]:0)
[junit4]at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765)
[junit4]at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:732)
[junit4]at
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:530)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] Caused by: java.lang.RuntimeException: REQUEST FAILED:
xpath=//lst[@name='spellcheck']/lst[@name='collations']/lst[@name='collation']/int[@name='hits'
and 6 = . and . = 10]
[junit4]xml response was: ?xml version=1.0 encoding=UTF-8?
[junit4] response
[junit4] lst name=responseHeaderint name=status0/intint
name=QTime10/int/lstresult name=response numFound=0
start=0/resultlst name=spellchecklst name=suggestionslst
name=everotherint name=numFound1/intint
name=startOffset9/intint name=endOffset18/intarr
name=suggestionstreveryother/str/arr/lst/lstlst
name=collationslst name=collationstr
name=collationQueryteststop:everyother/strint name=hits12/intlst
name=misspellingsAndCorrectionsstr
name=everothereveryother/str/lst/lst/lst/lst
[junit4] /response
[junit4]request
was:spellcheck=truespellcheck.dictionary=directspellcheck.count=1spellcheck.collate=truespellcheck.maxCollationTries=1spellcheck.maxCollations=1spellcheck.collateExtendedResults=trueqt=spellCheckCompRHq=teststop%3Aeverotherspellcheck.collateMaxCollectDocs=5
[junit4]at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:758)
[junit4]... 41 more
{noformat}
SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to
time
Key: SOLR-5344
URL: https://issues.apache.org/jira/browse/SOLR-5344
Project: Solr
Issue Type: Bug
Reporter: Robert Muir
Doesn't happen very often, but maybe one I can fix. I'll look into it.
--
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-6629) Watch /collections zk node on all nodes
[ https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-6629: - Attachment: SOLR-6629-new.patch Nope, I screwed it up, sorry! Correct patch attached. Watch /collections zk node on all nodes --- Key: SOLR-6629 URL: https://issues.apache.org/jira/browse/SOLR-6629 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: Trunk Attachments: SOLR-6629-new.patch, SOLR-6629.patch, SOLR-6629.patch, SOLR-6629.patch, SOLR-6629.patch The main clusterstate.json is refreshed/used as a poor substitute for informing all nodes about new or deleted collections even when the collection being created or deleted has state format 1. When we move away from state format 1 then we should do away with this workaround and start watching the /collections zk node on all nodes. -- 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: [VOTE] 5.3.0 RC2
Hi Noble, I still see issues here: http://lucene.staging.apache.org/solr/resources.html#documentation The release documentation section is empty. I've also fixed The Apache Solr Reference Guide section to remove the solr version# from the download text label. It was set to the latest version but as the ref guide is yet to be released, wasn't really correct. It would have been an issue with every release unless we released the ref guide along with the code every time so I removed the number until we have a better process for maintaining it. and yes, thanks for taking up the 5.3 release. :-) On Mon, Aug 24, 2015 at 8:38 AM, Noble Paul noble.p...@gmail.com wrote: Thanks Uwe , fixed On Mon, Aug 24, 2015 at 8:54 PM, Uwe Schindler u...@thetaphi.de wrote: http://lucene.staging.apache.org/ = NOW looks OK, 10 mins ago, the last Solr item was on wrong line http://lucene.staging.apache.org/core/corenews.html = this one is completely unformatted http://lucene.staging.apache.org/solr/news.html = looks OK Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:12 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Lucene News (on Lucene sub page) completely unformatted which page exactly others fixed. Actually I was planning to release later that's why I kept it 25 August ;) On Mon, Aug 24, 2015 at 8:24 PM, Uwe Schindler u...@thetaphi.de wrote: Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0- RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0- RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul -- --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --- -- To unsubscribe, e-mail:
[jira] [Commented] (SOLR-7789) Introduce a ConfigSet management API
[
https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709658#comment-14709658
]
Shalin Shekhar Mangar commented on SOLR-7789:
-
bq. There is a ConfigSetsHandler because it operates on a separate end point –
it doesn't make sense to send ConfigSet-related commands to /admin/collections,
it makes more sense from the end user perspective to send ConfigSet-related
commands to /admin/configs. Given separate end points, separate handlers also
make sense.
Okay, that is reasonable.
bq. The point I am trying to make is that how the Overseer processes ConfigSet
operations is an implementation detail of the Overseer. The ConfigSetHandler
(which is not part of the Overseer) just needs an interface in order to tell
the Overseer that it wants a ConfigSet operation processed, it shouldn't be
concerned with the implementation details.
In my mind, it makes the opposite impression. The fact that we have a
ZkController.getOverseerCollectionQueue and a different
ZkController.getOverseerConfigSetQueue() suggests that the two queues are
different but they are not, at least not yet. So why does this feature try to
suggest that their implementation might be different at all? These things are
easily changed so lets refactor it when we actually need to have different
queues.
bq. Right now we happen to use the same queue under the covers, but maybe we
find in the future that's a bad idea (e.g. users have different QoS
expectations between ConfigSet and Collection operations and we add ConfigSet
operations that are long lived and block important Collection operations). If
the interface between the Overseer and the ConfigSet handler doesn't refer to
collections, we don't need to change anything outside of the Overseer if we
change the processing in the future.
There are already different QoS expectations within the existing operations.
For example, operations for different collections never block each other and
operations such as cluster status, overseer status and request status never
block. However, they are all managed by the same overseer and it can continue
to be the case. Yes, what operations block what is not formally defined or
enforced, which is something that can use some love.
{quote}
bq. The only reason why it is called a OverseerCollectionQueue is to indicate
that it is the queue for OverseerCollectionProcessor.
That can be indicated with a variable/method name, not the type name.
{quote}
Sure it could be if it is a generic queue but it is only used for the overseer
collection processor and I don't see the need for another queue in Solr right
now.
bq. I don't wish to make the API/tasks pluggable so I understand your concern.
That being said, there is a middle ground between API/tasks being pluggable and
putting everything in the collection processor. All I'm arguing for is clean
interfaces. Take SOLR-7855 as an example; because we had Overseer/role related
commands in the collection processor it made refactoring much more difficult.
Doing what you suggest in my opinion would have the same effect
I understand what you are saying. I did the same for Overseer in SOLR-6554
which grouped all related operations and moved them into their own classes
(ClusterStateMutator, SliceMutator etc). In fact, I'd argue that SOLR-7855
didn't go far enough -- it'd be great to have individual operations completely
separate from the message processor such that they can be easily unit tested. I
am very much on board with that.
I'm just a bit confused why we have an interface if we have just one
implementation (YAGNI!) e.g. OverseerMessageHandler and
OverseerMessageHandlerSelector. Similarily, OverseerCollectionProcessor doesn't
add much over OverseerProcessor except for the static
getOverseerMessageHandlerSelector method.
bq. I don't think the dispatching here is complex and it is completely
contained in the Overseer. After SOLR-7855 we have an
OverseerCollectionMessageHandler to handle overseer collection messages. If you
are suggesting throwing the ConfigSet related commands in there (from
OverseerConfigSetMessageHandler), you've just moved the dispatch code somewhere
else.
I was referring to the OverseerMessageHandlerSelector actually. I assumed that
you foresee more than one implementation in the future which would make the
dispatching more complex, hence the comment. So to dispatch a request, at level
1, you have the OverseerMessageHandlerSelector and at level 2, you have an
OverseerMessageHandler and at level 3, you have the processMessage inside the
OverseerMessageHandler which sends the request to the right handler method.
This is the complexity that I was referring to. Perhaps, we can get rid of
OverseerMessageHandlerSelector?
Sorry for the vague comment earlier. I don't want to block you anymore than I
already have. We can always
RE: [VOTE] 5.3.0 RC2
Hi Noble, there is still a text duplication problem on http://lucene.staging.apache.org/core/corenews.html. The first 2 sentences repeat. Also the Changes.html link is not highlighted, it should be a Link with title Changes and behind that the link. Also both links are there 2 times (the changes link and also a slightly different download link). On the Solr News page, not all links are duplicates, but CHANGES.txt is above and below the lists. Thanks for doing the release! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:39 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Thanks Uwe , fixed On Mon, Aug 24, 2015 at 8:54 PM, Uwe Schindler u...@thetaphi.de wrote: http://lucene.staging.apache.org/ = NOW looks OK, 10 mins ago, the last Solr item was on wrong line http://lucene.staging.apache.org/core/corenews.html = this one is completely unformatted http://lucene.staging.apache.org/solr/news.html = looks OK Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:12 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Lucene News (on Lucene sub page) completely unformatted which page exactly others fixed. Actually I was planning to release later that's why I kept it 25 August ;) On Mon, Aug 24, 2015 at 8:24 PM, Uwe Schindler u...@thetaphi.de wrote: Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr- 5.3.0- RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr- 5.3.0- RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul -- --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 13986 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13986/ Java: 32bit/jdk1.8.0_60 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([6ECA8400E63A6BF1:C98E3CA48B817848]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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
Re: svn commit: r1697131 - in /lucene/dev/trunk/lucene: JRE_VERSION_MIGRATION.txt test-framework/src/java/org/apache/lucene/util/TestUtil.java
Uwe: why did you change this from Assert.assertTrue to assert ?
In the old code the test would fail every time with a clear explanation of
hte problem -- in your new code, if assertions are randomly disabled by
the test framework, then the sanity check won't run and instead we'll get
a strange failure from whatever test called this method.
: ==
: ---
lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/util/TestUtil.java
(original)
: +++
lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/util/TestUtil.java
Sat Aug 22 21:33:47 2015
: @@ -35,6 +35,7 @@ import java.util.Collections;
: import java.util.HashMap;
: import java.util.Iterator;
: import java.util.List;
: +import java.util.Locale;
: import java.util.Map;
: import java.util.NoSuchElementException;
: import java.util.Random;
: @@ -1188,7 +1189,7 @@ public final class TestUtil {
:int offset = nextInt(r, 0, WHITESPACE_CHARACTERS.length-1);
:char c = WHITESPACE_CHARACTERS[offset];
:// sanity check
: - Assert.assertTrue(Not really whitespace? (@+offset+): + c,
Character.isWhitespace(c));
: + assert Character.isWhitespace(c) : String.format(Locale.ENGLISH, Not
really whitespace? WHITESPACE_CHARACTERS[%d] is '\\u%04X', offset, (int) c);
:out.append(c);
: }
: return out.toString();
: @@ -1307,9 +1308,9 @@ public final class TestUtil {
: '\u001E',
: '\u001F',
: '\u0020',
: -// '\u0085', faild sanity check?
: +// '\u0085', failed sanity check?
: '\u1680',
: -'\u180E',
: +// '\u180E', no longer whitespace in Unicode 7.0 (Java 9)!
: '\u2000',
: '\u2001',
: '\u2002',
:
:
:
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2
[ https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6759: Attachment: LUCENE-6699.patch [~mikemccand]: Here's a patch that allows beasting to succeed. Integrate lat/long BKD and spatial 3d, part 2 - Key: LUCENE-6759 URL: https://issues.apache.org/jira/browse/LUCENE-6759 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Attachments: LUCENE-6699.patch, LUCENE-6699.patch This is just a continuation of LUCENE-6699, which became too big. -- 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-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elaine Cario updated SOLR-7951: --- Attachment: SOLR-7951-4.x.patch Updated patch for 4.10: it is correct to cast exception as SolrException (NOT SolrServerException). Also added comments for clarity. LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951-4.x.patch, SOLR-7951-4.x.patch, SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709747#comment-14709747 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1697469 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1697469 ] LUCENE-6699: iterate Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- 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-6759) Integrate lat/long BKD and spatial 3d, part 2
[ https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709749#comment-14709749 ] Michael McCandless commented on LUCENE-6759: Thanks [~daddywri] I committed that last patch... bq. Hmm, I don't see that in my workarea (before synching anyway). Let me dig. Ugh sorry, when I did an ant clean then this test stopped failing ... Integrate lat/long BKD and spatial 3d, part 2 - Key: LUCENE-6759 URL: https://issues.apache.org/jira/browse/LUCENE-6759 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Attachments: LUCENE-6699.patch, LUCENE-6699.patch This is just a continuation of LUCENE-6699, which became too big. -- 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: [VOTE] 5.3.0 RC2
I have removed the repeated CHANGES.txt references. It is there only in the bottom now On Mon, Aug 24, 2015 at 11:13 PM, Uwe Schindler u...@thetaphi.de wrote: Hi Noble, there is still a text duplication problem on http://lucene.staging.apache.org/core/corenews.html. The first 2 sentences repeat. Also the Changes.html link is not highlighted, it should be a Link with title Changes and behind that the link. Also both links are there 2 times (the changes link and also a slightly different download link). On the Solr News page, not all links are duplicates, but CHANGES.txt is above and below the lists. Thanks for doing the release! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:39 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Thanks Uwe , fixed On Mon, Aug 24, 2015 at 8:54 PM, Uwe Schindler u...@thetaphi.de wrote: http://lucene.staging.apache.org/ = NOW looks OK, 10 mins ago, the last Solr item was on wrong line http://lucene.staging.apache.org/core/corenews.html = this one is completely unformatted http://lucene.staging.apache.org/solr/news.html = looks OK Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 5:12 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 Lucene News (on Lucene sub page) completely unformatted which page exactly others fixed. Actually I was planning to release later that's why I kept it 25 August ;) On Mon, Aug 24, 2015 at 8:24 PM, Uwe Schindler u...@thetaphi.de wrote: Homepage: Last item: * Smile . (at end of previous line) Lucene News (on Lucene sub page) completely unformatted Solr News (solr Sub page): OK Various items. By the way its August 24 NOW (UTC time). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 24, 2015 4:47 PM To: Lucene Dev Subject: Re: [VOTE] 5.3.0 RC2 I'm planning to announce the release of Lucene Solr 5.3 . Please check the site http://lucene.staging.apache.org/ --Noble On Thu, Aug 20, 2015 at 7:15 PM, Steve Rowe sar...@gmail.com wrote: Noble, FYI, I had already gone to bed when you sent this email, but at that point, it had been significantly less than 72 hours from the time you sent out the original RC2 VOTE email. There are three conditions required for a release VOTE to succeed: 1. At least 72 hours must have passed since the VOTE email was sent. 2. At least 3 PMC members must +1 the release. 3. A majority of PMC votes must be +1’s FYI, in Lucene/Solr land, we regularly respin if there are any -1’s (from any voter, including non-PMC), so #3 is rarely used. RMs should read through both the ASF release policy page http://www.apache.org/dev/release.html as well as Lucene/Solr’s ReleaseTodo http://wiki.apache.org/lucene-java/ReleaseTodo. If the above is not clear in those, we should fix them. Steve On Aug 19, 2015, at 11:41 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone. We now have enough votes for the RC2 to be released. I shall start the process of publishing and releasing this. On Thu, Aug 20, 2015 at 8:20 AM, Yonik Seeley ysee...@gmail.com wrote: +1 -Yonik On Mon, Aug 17, 2015 at 8:24 AM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr- 5.3.0- RC2 -rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr- 5.3.0- RC2 -rev1696229/ -- - Noble Paul --- -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul -- --- To
[jira] [Commented] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709743#comment-14709743 ] Elaine Cario commented on SOLR-7951: The original error code I was receiving was 500, and because it was an issue with the query, all the servers in the cluster were throwing the same error. LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951-4.x.patch, SOLR-7951-4.x.patch, SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- 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-6759) Integrate lat/long BKD and spatial 3d, part 2
[
https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709771#comment-14709771
]
Michael McCandless commented on LUCENE-6759:
206 beast iters then I hit:
{noformat}
[junit4:pickseed] Seed property 'tests.seed' already defined: DDC21670DAEA1F6B
[junit4] JUnit4 says ciao! Master seed: DDC21670DAEA1F6B
[junit4] Executing 1 suite with 1 JVM.
[junit4]
[junit4] Started J0 PID(16168@localhost).
[junit4] Suite: org.apache.lucene.bkdtree3d.TestGeo3DPointField
[junit4] 2 ago 24, 2015 8:15:51 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2 WARNING: Uncaught exception in thread:
Thread[T1,5,TGRP-TestGeo3DPointField]
[junit4] 2 java.lang.AssertionError: expected WITHIN (1) or OVERLAPS (2)
but got 0; shape=GeoCircle: {planetmodel=PlanetModel.SPHERE,
center=[lat=-0.004431288600558495, lon=-0.003687846671278374],
radius=1.704543429364245E-8(9.7663144499327E-7)}; XYZSolid=XYZSolid:
{planetmodel=PlanetModel.SPHERE, isWholeWorld=false, minXplane=[A=1.0, B=0.0,
C=0.0, D=-0.833816746712, side=1.0], maxXplane=[A=1.0, B=0.0, C=0.0,
D=-0.833819746712, side=-1.0], minYplane=[A=0.0, B=1.0, C=0.0,
D=0.00368780225430909, side=1.0], maxYplane=[A=0.0, B=1.0, C=0.0,
D=0.00368780195430909, side=-1.0], minZplane=[A=0.0, B=0.0, C=1.0,
D=0.004431274248206893, side=1.0], maxZplane=[A=0.0, B=0.0, C=1.0,
D=0.004431273948206893, side=-1.0]}
[junit4] 2at
__randomizedtesting.SeedInfo.seed([DDC21670DAEA1F6B]:0)
[junit4] 2at
org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1.scorer(PointInGeo3DShapeQuery.java:105)
[junit4] 2at
org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:581)
[junit4] 2at
org.apache.lucene.search.Weight.bulkScorer(Weight.java:135)
[junit4] 2at
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
[junit4] 2at
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
[junit4] 2at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:618)
[junit4] 2at
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:92)
[junit4] 2at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:425)
[junit4] 2at
org.apache.lucene.bkdtree3d.TestGeo3DPointField$4._run(TestGeo3DPointField.java:587)
[junit4] 2at
org.apache.lucene.bkdtree3d.TestGeo3DPointField$4.run(TestGeo3DPointField.java:521)
[junit4] 2
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestGeo3DPointField
-Dtests.method=testRandomMedium -Dtests.seed=DDC21670DAEA1F6B -Dtests.slow=true
-Dtests.linedocsfile=/lucenedata/hudson.enwiki.random.lines.txt.fixed
-Dtests.locale=it_CH -Dtests.timezone=Africa/Blantyre -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 1.08s | TestGeo3DPointField.testRandomMedium
[junit4] Throwable #1:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=16, name=T1, state=RUNNABLE,
group=TGRP-TestGeo3DPointField]
{noformat}
Looks like a miniscule radius?
Integrate lat/long BKD and spatial 3d, part 2
-
Key: LUCENE-6759
URL: https://issues.apache.org/jira/browse/LUCENE-6759
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Attachments: LUCENE-6699.patch, LUCENE-6699.patch
This is just a continuation of LUCENE-6699, which became too big.
--
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-7789) Introduce a ConfigSet management API
[
https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709774#comment-14709774
]
Gregory Chanan commented on SOLR-7789:
--
{quote}In my mind, it makes the opposite impression. The fact that we have a
ZkController.getOverseerCollectionQueue and a different
ZkController.getOverseerConfigSetQueue() suggests that the two queues are
different but they are not, at least not yet. So why does this feature try to
suggest that their implementation might be different at all? These things are
easily changed so lets refactor it when we actually need to have different
queues.{quote}
I think part of the difference of opinion here is you are viewing the interface
as this is the collection queue and this is the configset queue -- given that
the interface is a queue your line of thinking makes sense, but perhaps having
queue as part of the interface is leaking too many implementation details
already. I'm viewing the interface as this is where I send Collection
operation requests and this is where I send ConfigSet operation requests.
There's no same vs separate queue discussion if that is the interface. If that
were the interface, you would be arguing for a single this is where I send
Overseer operation requests.
To be honest, I don't think this makes a huge difference either way right now.
The central issue, imo, is how you the RequestHandler differentiates which
messages are intended for which MessageHandler. In the naive way of just
throwing everything in the OCP (not saying you are arguing for that), you'd
have conflicts with say, the Collection.CREATE and ConfigSet.CREATE and would
need to make sure all the names don't conflict (a mess). So, you'd either need
to differentiate the message at the Overseer interface level this is where I
send Collection requests and this is where I send ConfigSet operation requests
(this is essentially what I've chosen) or each handler puts enough content in
the message so that the overseer can differentiate itself. The later could
certainly be the right way to go -- I just didn't choose it because 1) it would
require changing the existing message format and we'd have to deal with
backwards incompatibility 2) we'd need to invent some grouping concept of
operations (what are CollectionActions vs ConfigSetActions -- groups of
actions? action sets?). If we solve #1 and #2 I certainly have no objection
to having a single this is where I send Overseer operation requests interface.
{quote}There are already different QoS expectations within the existing
operations. For example, operations for different collections never block each
other and operations such as cluster status, overseer status and request status
never block. However, they are all managed by the same overseer and it can
continue to be the case. Yes, what operations block what is not formally
defined or enforced, which is something that can use some love.{quote}
Sure, that's just a hypothetical. I think what I wrote above is the central
issue.
{quote}I understand what you are saying. I did the same for Overseer in
SOLR-6554 which grouped all related operations and moved them into their own
classes (ClusterStateMutator, SliceMutator etc). In fact, I'd argue that
SOLR-7855 didn't go far enough – it'd be great to have individual operations
completely separate from the message processor such that they can be easily
unit tested. I am very much on board with that.
I'm just a bit confused why we have an interface if we have just one
implementation (YAGNI!) e.g. OverseerMessageHandler and
OverseerMessageHandlerSelector. Similarily, OverseerCollectionProcessor doesn't
add much over OverseerProcessor except for the static
getOverseerMessageHandlerSelector method.{quote}
Well there are two OverseerMessageHandlers now :). I see below your concern is
mainly with the Selector.
{quote}I was referring to the OverseerMessageHandlerSelector actually. I
assumed that you foresee more than one implementation in the future which would
make the dispatching more complex, hence the comment. So to dispatch a request,
at level 1, you have the OverseerMessageHandlerSelector and at level 2, you
have an OverseerMessageHandler and at level 3, you have the processMessage
inside the OverseerMessageHandler which sends the request to the right handler
method. This is the complexity that I was referring to. Perhaps, we can get rid
of OverseerMessageHandlerSelector?{quote}
The OverseerMessageHandlerSelector was really just some scaffolding to help me
with the refactor. I don't have an objection to making a single non-interface
implementation of it. Or even a canonical implementation if we adopt the
single this is where I send Overseer operation requests interface (e.g. it
could just do some generic logic mapping the expanded info in the message with
the set of
[jira] [Resolved] (SOLR-6625) Add interceptor API for outgoing calls through HttpSolrClient
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-6625. -- Resolution: Fixed Fix Version/s: Trunk 5.3 Add interceptor API for outgoing calls through HttpSolrClient - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Fix For: 5.3, Trunk Attachments: SOLR-6625-revert.patch, SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- 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: VOTE: RC1 release of apache-solr-ref-guide-5.3.pdf
Thanks everyone for your help, it looks like this vote passed. I'll start
the release process in the next hour or so.
Cassandra
On Sun, Aug 23, 2015 at 2:42 PM, Cassandra Targett casstarg...@gmail.com
wrote:
Thanks, Jan.
Regarding the word breaks, it's not ideal but Steve Rowe I spent a lot
of time trying to only allow it in specific situations with little success.
If you want to give it a go, we'd be happy to have the improvement.
If you don't have a chance to fix the other typos and issues you mention,
can you add them to the TODO list or as comments on the pages so we don't
forget to fix them whenever someone has time?
Cassandra
On Fri, Aug 21, 2015 at 6:26 AM, Jan Høydahl jan@cominvent.com
wrote:
*Comments*
General:
* The line wrapping for linked and monospaced text breaks mid-word e.g.
p6 “Ta-king”. Realize that it is desired for lng http links etc, but
can we do better?
* Long CODE blocks starts on one page with only blank lines and continues
on the next. Would be better with white space than the grey background.
* The refGuide should not link to SearchHub.org (which now redirects to
LucidWorks.com) (p225,263,264,266,440). We could instead refer to
lucene.apache.org/solr/resources for more info
* Some places “Windows” is written with lowercase “w”
Specific:
* P5: In the “Got Java” chapter, should we start recommending (not
requiring) Java8 and update -version command print to the same (since 7 is
not supported)?
* P222, 4th paragraph in Overview of Searching in Solr: The default
query parser is the DisMax query parser.”. This is *wrong*, the default
query parser is “lucene”!
* P222: 3rd paragraph from bottom: Search parameters may also specify a
*query
filter*.” - The common terminology is “filter query”, not “query filter
* P223: Is the CNET screen shot property attributed? Should probably be
© CBS Interactive Inc. Also it is old, they have a completely new layout..
* P282: The example for pivot+range uses localparam {!query=q1} from
previous example, but correct is {!range=r1}
* P386: Reformat the code block with new line wrappings for readability
* P411: Font size of some of the URProcessor links are 11 instead of 10 :)
* P577: The “Errata” url link links to itself instead of opening a
browser to cwiki
-0 to release as is
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
20. aug. 2015 kl. 18.07 skrev Cassandra Targett casstarg...@gmail.com:
Please VOTE to release the following as apache-solr-ref-guide-5.3.pdf
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.3-RC1/
$cat apache-solr-ref-guide-5.3.pdf.sha1
1255cba4413023e30aff345d30bce33846189975 apache-solr-ref-guide-5.3.pdf
Here's my +1.
Thanks,
Cassandra
[jira] [Commented] (SOLR-7560) Parallel SQL Support
[ https://issues.apache.org/jira/browse/SOLR-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709862#comment-14709862 ] Joel Bernstein commented on SOLR-7560: -- Hi Susheel, The two queries you tried are not yet supported. They are both high priorities but might not be in the initial release. The documentation link (https://cwiki.apache.org/confluence/display/solr/Parallel+SQL+Interface) describes the types of queries currently supported in trunk. Joel Parallel SQL Support Key: SOLR-7560 URL: https://issues.apache.org/jira/browse/SOLR-7560 Project: Solr Issue Type: New Feature Components: clients - java, search Reporter: Joel Bernstein Fix For: Trunk Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch This ticket provides support for executing *Parallel SQL* queries across SolrCloud collections. The SQL engine will be built on top of the Streaming API (SOLR-7082), which provides support for *parallel relational algebra* and *real-time map-reduce*. Basic design: 1) A new SQLHandler will be added to process SQL requests. The SQL statements will be compiled to live Streaming API objects for parallel execution across SolrCloud worker nodes. 2) SolrCloud collections will be abstracted as *Relational Tables*. 3) The Presto SQL parser will be used to parse the SQL statements. 4) A JDBC thin client will be added as a Solrj client. This ticket will focus on putting the framework in place and providing basic SELECT support and GROUP BY aggregate support. Future releases will build on this framework to provide additional SQL features. -- 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-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure!
Hi, unfortunately, again a 32bit build of Java 9 b78 failed horribly last night. It looks identical like last time with b76 or b72. Suddenly one of the test fails with a NullPointerException or similar and afterwards all tests running in the same JVM fail (this time a total of 95 tests) with crazy error messages (number of found Lucene documents differ,...): http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13696/ So, unfortunately, the problem still exists (32 bit JDK, 64 bits did not fail until now). What should we do to get hold on this? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, August 23, 2015 11:43 AM To: 'dev@lucene.apache.org'; 'rory.odonn...@oracle.com'; 'Balchandra Vaidya' Cc: 'Dalibor Topic'; 'Vivek Theeyarath'; 'dawid.we...@cs.put.poznan.pl'; 'mark.reinh...@oracle.com' Subject: RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure! Hi Rory, hi Balchandra, I just wanted to keep you up-to-date: Yesterday I updated to JDK 9 build 78 and up to now, there was no total failure anymore (neither on 32 bits, nor on 64 bits). We had to only change one test on our side, because the change to Unicode version 7.0 for Java 9 caused some problems with our list of whitespace chars (the character properties of one char changed) - this was easy to fix. About the problems we have seen before: I checked the changes log, but I have no idea, which change could have fixed the problems we had seen. Did you do any internal checks and contacted some people? Maybe they fixed the bug, but because we did not know what was wrong, I cannot correlate the changes with what we have seen. But maybe it is not yet fixed at all, it could be that we just have not seen any failure up to now - so we have to wait a few days. So it would be good to get in contact with the right people to figure out, which change may have caused the problems we have seen (suddenly almost all tests failed, but not reproducible on all machines - my local laptop never hit it, only the Policeman Jenkins Server - which has a much newer Haswell CPU including Advanced Vector Instructions AVX2). I also had to change the signatures generator for deprecated signatures in Forbidden-APIs, because of the new layout of the FileSystem for the modules (jrt:/modules/java.base/... now). I am not really happy about this change, because it is also inconsistent with the class loader that still reports jrt:/java.base/... on Classloader.getResource(). Should we open an issue, maybe that was not wanted by Mark Reinhold? In addition I updated to Java 8u60. Please give me a note when new preview builds for Java 8u80 will be available. At the moment we only test the Java 9 preview builds. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Wednesday, August 19, 2015 1:05 AM To: dev@lucene.apache.org Cc: rory.odonn...@oracle.com; Balchandra Vaidya; Dalibor Topic; 'Vivek Theeyarath'; dawid.we...@cs.put.poznan.pl Subject: RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure! Hi Rory, hi Balchandra, Java 9 (now testing build 76) Hotspot implementation is still broken like hell (at least in the 32 bits Linux builds, 64 bits seems more stable - have not seen the same error)! We should really contact the hotspot people directly on the mailing list to get them on board, maybe they should have some test environment and run the tests of Lucene on their own machines. Just opening bug reports does not make sense here, because every failure looks different and we have no idea what's wrong. I will be on vacation the next days, so I cannot take care. I reverted back to build 60, so it does not fail all the time. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Wednesday, August 19, 2015 12:57 AM To: dev@lucene.apache.org Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure! Importance: Low Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13911/ Java: 32bit/jdk1.9.0-ea-b76 -server -XX:+UseSerialGC - Djava.locale.providers=JRE,SPI 177 tests failed. FAILED: org.apache.lucene.TestDemo.testDemo Error Message: expected:1 but was:0 Stack Trace: java.lang.AssertionError: expected:1 but was:0 at __randomizedtesting.SeedInfo.seed([37AED9B3EB35A2BD:48026506DAE888 AD]:0) at org.junit.Assert.fail(Assert.java:93)
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2615 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2615/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([B83FF5E5BA060706:3FBE4848BE267D02]: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.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler(TestMergeSchedulerExternal.java:116) 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.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 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) Build Log: [...truncated 911 lines...] [junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestMergeSchedulerExternal -Dtests.method=testSubclassConcurrentMergeScheduler -Dtests.seed=B83FF5E5BA060706 -Dtests.slow=true -Dtests.locale=ar_YE -Dtests.timezone=America/Denver -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.86s J0 | TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler [junit4] Throwable #1: java.lang.AssertionError [junit4]at
[jira] [Commented] (SOLR-7954) Exception while using {!cardinality=1.0}.
[
https://issues.apache.org/jira/browse/SOLR-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14708909#comment-14708909
]
Modassar Ather commented on SOLR-7954:
--
I tested following schema with the same data in field and field2. Both
reproduced the problem. Then I tried to find if it is value in cardinality
which is causing the issue. I tried with 10 to 12 document and both the
field returned cardinality but after increasing it to around 15 it caused
the exception.
{noformat}
?xml version=1.0 encoding=UTF-8 ?
schema name=collection version=1.5
types
fieldType name=string class=solr.StrField sortMissingLast=true
stored=false omitNorms=true/
fieldType name=string_dv class=solr.StrField sortMissingLast=true
stored=false indexed=false docValues=true/
fieldType name=long class=solr.TrieLongField precisionStep=0
omitNorms=true positionIncrementGap=0 stored=false/
/types
fields
field name=field type=string_dv multiValued=true /
field name=field1 type=string stored=true /
field name=field2 type=string multiValued=true /
field name=versiontype=long stored=true /
field name=colidtype=string stored=true /
/fields
uniqueKeycolid/uniqueKey
/schema
{noformat}
Following is the method to index data.
{noformat}
public void index() throws SolrServerException, IOException {
CloudSolrClient s = new CloudSolrClient(ZKHOST:ZKPORT);
int count = 0;
s.setDefaultCollection(COLECTION);
ListSolrInputDocument documents = new ArrayList();
for (int i = 1; i = 100; i++) {
SolrInputDocument doc = new SolrInputDocument();
doc.addField(field1, i);
doc.addField(colid, val!+i+!-+ref+i);
doc.addField(field, DATA+(12345+i));
doc.addField(field2, DATA+(12345+i));
documents.add(doc);
if((documents.size() % 1) == 0){
count = count + 1;
s.add(documents);
System.out.println(System.currentTimeMillis() + - Indexed
document # + NumberFormat.getInstance().format(count));
documents = new ArrayList();
}
}
System.out.println(Comitting.);
s.commit(true, true);
System.out.println(Optimizing.);
s.optimize(true, true, 1);
s.close();
System.out.println(Done.);
}
{noformat}
Exception while using {!cardinality=1.0}.
-
Key: SOLR-7954
URL: https://issues.apache.org/jira/browse/SOLR-7954
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Environment: SolrCloud 4 node cluster.
Ubuntu 12.04
OS Type 64 bit
Reporter: Modassar Ather
Assignee: Hoss Man
Following exception is thrown for the query :
bq. q=field1:*stats=truestats.field={!cardinality=1.0}field.
The exception is not seen once the cardinality is set to 0.9 or less.
The field is docValues enabled and indexed=false. The same exception I tried
to reproduce on non docValues field but could not.
ERROR - 2015-08-11 12:24:00.222; [core] org.apache.solr.common.SolrException;
null:java.lang.ArrayIndexOutOfBoundsException: 3
at
net.agkn.hll.serialization.BigEndianAscendingWordSerializer.writeWord(BigEndianAscendingWordSerializer.java:152)
at net.agkn.hll.util.BitVector.getRegisterContents(BitVector.java:247)
at net.agkn.hll.HLL.toBytes(HLL.java:917)
at net.agkn.hll.HLL.toBytes(HLL.java:869)
at
org.apache.solr.handler.component.AbstractStatsValues.getStatsValues(StatsValuesFactory.java:348)
at
org.apache.solr.handler.component.StatsComponent.convertToResponse(StatsComponent.java:151)
at
org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:62)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
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.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
[jira] [Commented] (SOLR-7955) Auto create .system collection on first start if it does not exist
[
https://issues.apache.org/jira/browse/SOLR-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14708923#comment-14708923
]
Jan Høydahl commented on SOLR-7955:
---
bq. may be lazily on first use (if possible) is a better alternative than on
first start..
First use in this context I guess is first data upload, e.g.
{noformat}
curl -X POST ... --data-binary @test1.jar
http://localhost:8983/solr/.system/blob/test
{noformat}
Is it even possible to intercept a POST to .system if it does not exist, or is
the special /blob handler only registered when collection is created?
Auto create .system collection on first start if it does not exist
--
Key: SOLR-7955
URL: https://issues.apache.org/jira/browse/SOLR-7955
Project: Solr
Issue Type: Improvement
Reporter: Jan Høydahl
Why should a user need to create the {{.system}} collection manually? It
would simplify instructions related to BLOB store if user could assume it is
always there.
--
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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14708883#comment-14708883
]
Jan Høydahl commented on SOLR-7888:
---
Sure, localparams can be a followup
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Assignee: Jan Høydahl
Fix For: 5.4
Attachments: SOLR-7888.patch, SOLR-7888.patch, SOLR-7888.patch,
SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
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-7790) Update Carrot2 clustering contrib to version 3.10.3
[ https://issues.apache.org/jira/browse/SOLR-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709084#comment-14709084 ] ASF subversion and git services commented on SOLR-7790: --- Commit 1697354 from [~dawidweiss] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1697354 ] SOLR-7790, SOLR-7792, SOLR-7791: Update Carrot2 clustering component to version 3.10.3. Upgrade HPPC library to version 0.7.1, morfologik-stemming to version 1.10.0. Update Carrot2 clustering contrib to version 3.10.3 --- Key: SOLR-7790 URL: https://issues.apache.org/jira/browse/SOLR-7790 Project: Solr Issue Type: Task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: Trunk, 5.4 Attachments: SOLR-7790.patch, SOLR-7790.patch This issue brings the clustering extension up to date and also involves upgrading a few other libraries (see sub-tasks or linked issues). -- 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-7792) Upgrade morfologik-stemming to version 1.10.0
[ https://issues.apache.org/jira/browse/SOLR-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709085#comment-14709085 ] ASF subversion and git services commented on SOLR-7792: --- Commit 1697354 from [~dawidweiss] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1697354 ] SOLR-7790, SOLR-7792, SOLR-7791: Update Carrot2 clustering component to version 3.10.3. Upgrade HPPC library to version 0.7.1, morfologik-stemming to version 1.10.0. Upgrade morfologik-stemming to version 1.10.0 - Key: SOLR-7792 URL: https://issues.apache.org/jira/browse/SOLR-7792 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk, 5.4 -- 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-7791) Upgrade HPPC to version 0.7.1
[ https://issues.apache.org/jira/browse/SOLR-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709086#comment-14709086 ] ASF subversion and git services commented on SOLR-7791: --- Commit 1697354 from [~dawidweiss] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1697354 ] SOLR-7790, SOLR-7792, SOLR-7791: Update Carrot2 clustering component to version 3.10.3. Upgrade HPPC library to version 0.7.1, morfologik-stemming to version 1.10.0. Upgrade HPPC to version 0.7.1 - Key: SOLR-7791 URL: https://issues.apache.org/jira/browse/SOLR-7791 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk, 5.4 -- 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-7955) Auto create .system collection on first request if it does not exist
[
https://issues.apache.org/jira/browse/SOLR-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7955:
--
Summary: Auto create .system collection on first request if it does not
exist (was: Auto create .system collection on first start if it does not exist)
Changed issue summary to Auto create .system collection on first request if it
does not exist. Agree this is a more elegant solution.
Auto create .system collection on first request if it does not exist
Key: SOLR-7955
URL: https://issues.apache.org/jira/browse/SOLR-7955
Project: Solr
Issue Type: Improvement
Reporter: Jan Høydahl
Why should a user need to create the {{.system}} collection manually? It
would simplify instructions related to BLOB store if user could assume it is
always there.
--
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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709099#comment-14709099 ] Upayavira commented on SOLR-4316: - I've mulled on this quite a bit. What you say makes a huge amount of sense - a collection focused schema tab and a core focused index tab. However, that's a reasonable amount of work, and I'd rather get this feature out *before* I engage with creating two very new panes, and all the issues of interlinking them. How's about, in the meantime, when in cloud mode, I add an annotation close to the load terms button saying terms will be loaded from the XYZ core and do not represent the whole collection. Would that work? Then, if people are happy with that, I can complete this task and get on with working on the collections API tab in SOLR-4388. Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, collections menu open.png, cores menu open.png, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-7949) Thers is a xss issue in plugins/stats page of Admin Web UI.
[
https://issues.apache.org/jira/browse/SOLR-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709018#comment-14709018
]
ASF subversion and git services commented on SOLR-7949:
---
Commit 1697341 from jan...@apache.org in branch 'dev/branches/lucene_solr_5_3'
[ https://svn.apache.org/r1697341 ]
SOLR-7949: Resolve XSS issue in Admin UI stats page (backport)
Thers is a xss issue in plugins/stats page of Admin Web UI.
---
Key: SOLR-7949
URL: https://issues.apache.org/jira/browse/SOLR-7949
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.9, 4.10.4, 5.2.1
Reporter: davidchiu
Assignee: Jan Høydahl
Fix For: Trunk, 5.4, 5.3.1
Open Solr Admin Web UI, select a core(such as collection1) and then click
Plugins/stats,and type a url like
http://127.0.0.1:8983/solr/#/collection1/plugins/cache?entry=score=img
src=1 onerror=alert(1); to the browser address, you will get alert box with
1.
I changed follow code to resolve this problem:
The Original code:
for( var i = 0; i entry_count; i++ )
{
$( 'a[data-bean=' + entries[i] + ']', frame_element )
.parent().addClass( 'expanded' );
}
The Changed code:
for( var i = 0; i entry_count; i++ )
{
$( 'a[data-bean=' + entries[i].esc() + ']', frame_element )
.parent().addClass( 'expanded' );
}
--
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] [Resolved] (SOLR-7949) Thers is a xss issue in plugins/stats page of Admin Web UI.
[
https://issues.apache.org/jira/browse/SOLR-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-7949.
---
Resolution: Fixed
Resolved and backported to 5.3.1.
If/when 5.3.1 is released, we should move changes entries for trunk and
branch_5x; they now say 5.4
Thers is a xss issue in plugins/stats page of Admin Web UI.
---
Key: SOLR-7949
URL: https://issues.apache.org/jira/browse/SOLR-7949
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.9, 4.10.4, 5.2.1
Reporter: davidchiu
Assignee: Jan Høydahl
Fix For: Trunk, 5.4, 5.3.1
Open Solr Admin Web UI, select a core(such as collection1) and then click
Plugins/stats,and type a url like
http://127.0.0.1:8983/solr/#/collection1/plugins/cache?entry=score=img
src=1 onerror=alert(1); to the browser address, you will get alert box with
1.
I changed follow code to resolve this problem:
The Original code:
for( var i = 0; i entry_count; i++ )
{
$( 'a[data-bean=' + entries[i] + ']', frame_element )
.parent().addClass( 'expanded' );
}
The Changed code:
for( var i = 0; i entry_count; i++ )
{
$( 'a[data-bean=' + entries[i].esc() + ']', frame_element )
.parent().addClass( 'expanded' );
}
--
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-7892) Allow storing ZK ACL credentials in solr.properties
[
https://issues.apache.org/jira/browse/SOLR-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7892:
--
Description:
See https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since
{{solr.xml}} now can live in ZK, we need to have a way to keep various ZK setup
and credentials elsewhere, e.g. in {{solr.properties}}. When SOLR-7909 is
solved, you could pass the provider through VM params and thus keep it in
{{solr.in.sh}}, but for consistency we should support solr.properties too.
was:
See https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since
{{solr.xml}} now can live in ZK, we need to have a way to keep various ZK setup
and credentials elsewhere, e.g. in {{solr.properties}}. Have not verified that
it does not work, but creating this issue to make sure it is tested and
documented.
Allow storing ZK ACL credentials in solr.properties
---
Key: SOLR-7892
URL: https://issues.apache.org/jira/browse/SOLR-7892
Project: Solr
Issue Type: Sub-task
Components: security
Reporter: Jan Høydahl
Fix For: Trunk
See https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since
{{solr.xml}} now can live in ZK, we need to have a way to keep various ZK
setup and credentials elsewhere, e.g. in {{solr.properties}}. When SOLR-7909
is solved, you could pass the provider through VM params and thus keep it in
{{solr.in.sh}}, but for consistency we should support solr.properties too.
--
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-Windows (32bit/jdk1.8.0_60) - Build # 5063 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5063/ Java: 32bit/jdk1.8.0_60 -server -XX:+UseG1GC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ERROR: SolrIndexSearcher opens=51 closes=50 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50 at __randomizedtesting.SeedInfo.seed([6B5E6A86B44E1B26]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=123, name=searcherExecutor-160-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=123, name=searcherExecutor-160-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([6B5E6A86B44E1B26]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie
[jira] [Commented] (SOLR-7955) Auto create .system collection on first start if it does not exist
[
https://issues.apache.org/jira/browse/SOLR-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709036#comment-14709036
]
Noble Paul commented on SOLR-7955:
--
Lazy cores is different. We can auto create the collection when the first
request comes. The core container has to be aware of this special collection
Auto create .system collection on first start if it does not exist
--
Key: SOLR-7955
URL: https://issues.apache.org/jira/browse/SOLR-7955
Project: Solr
Issue Type: Improvement
Reporter: Jan Høydahl
Why should a user need to create the {{.system}} collection manually? It
would simplify instructions related to BLOB store if user could assume it is
always there.
--
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-7790) Update Carrot2 clustering contrib to version 3.10.3
[ https://issues.apache.org/jira/browse/SOLR-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709038#comment-14709038 ] ASF subversion and git services commented on SOLR-7790: --- Commit 1697345 from [~dawidweiss] in branch 'dev/trunk' [ https://svn.apache.org/r1697345 ] SOLR-7790, SOLR-7792, SOLR-7791: Update Carrot2 clustering component to version 3.10.3. Upgrade HPPC library to version 0.7.1, morfologik-stemming to version 1.10.0. (Dawid Weiss) Update Carrot2 clustering contrib to version 3.10.3 --- Key: SOLR-7790 URL: https://issues.apache.org/jira/browse/SOLR-7790 Project: Solr Issue Type: Task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 5.3, Trunk Attachments: SOLR-7790.patch, SOLR-7790.patch This issue brings the clustering extension up to date and also involves upgrading a few other libraries (see sub-tasks or linked issues). -- 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-7792) Upgrade morfologik-stemming to version 1.10.0
[ https://issues.apache.org/jira/browse/SOLR-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709039#comment-14709039 ] ASF subversion and git services commented on SOLR-7792: --- Commit 1697345 from [~dawidweiss] in branch 'dev/trunk' [ https://svn.apache.org/r1697345 ] SOLR-7790, SOLR-7792, SOLR-7791: Update Carrot2 clustering component to version 3.10.3. Upgrade HPPC library to version 0.7.1, morfologik-stemming to version 1.10.0. (Dawid Weiss) Upgrade morfologik-stemming to version 1.10.0 - Key: SOLR-7792 URL: https://issues.apache.org/jira/browse/SOLR-7792 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk -- 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-7791) Upgrade HPPC to version 0.7.1
[ https://issues.apache.org/jira/browse/SOLR-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709040#comment-14709040 ] ASF subversion and git services commented on SOLR-7791: --- Commit 1697345 from [~dawidweiss] in branch 'dev/trunk' [ https://svn.apache.org/r1697345 ] SOLR-7790, SOLR-7792, SOLR-7791: Update Carrot2 clustering component to version 3.10.3. Upgrade HPPC library to version 0.7.1, morfologik-stemming to version 1.10.0. (Dawid Weiss) Upgrade HPPC to version 0.7.1 - Key: SOLR-7791 URL: https://issues.apache.org/jira/browse/SOLR-7791 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk -- 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-7792) Upgrade morfologik-stemming to version 1.10.0
[ https://issues.apache.org/jira/browse/SOLR-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-7792: -- Fix Version/s: 5.4 Upgrade morfologik-stemming to version 1.10.0 - Key: SOLR-7792 URL: https://issues.apache.org/jira/browse/SOLR-7792 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk, 5.4 -- 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-7790) Update Carrot2 clustering contrib to version 3.10.3
[ https://issues.apache.org/jira/browse/SOLR-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-7790: -- Fix Version/s: (was: 5.3) 5.4 Update Carrot2 clustering contrib to version 3.10.3 --- Key: SOLR-7790 URL: https://issues.apache.org/jira/browse/SOLR-7790 Project: Solr Issue Type: Task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: Trunk, 5.4 Attachments: SOLR-7790.patch, SOLR-7790.patch This issue brings the clustering extension up to date and also involves upgrading a few other libraries (see sub-tasks or linked issues). -- 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] [Resolved] (SOLR-7791) Upgrade HPPC to version 0.7.1
[ https://issues.apache.org/jira/browse/SOLR-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-7791. --- Resolution: Fixed Upgrade HPPC to version 0.7.1 - Key: SOLR-7791 URL: https://issues.apache.org/jira/browse/SOLR-7791 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk, 5.4 -- 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-7791) Upgrade HPPC to version 0.7.1
[ https://issues.apache.org/jira/browse/SOLR-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-7791: -- Fix Version/s: 5.4 Upgrade HPPC to version 0.7.1 - Key: SOLR-7791 URL: https://issues.apache.org/jira/browse/SOLR-7791 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk, 5.4 -- 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] [Resolved] (SOLR-7792) Upgrade morfologik-stemming to version 1.10.0
[ https://issues.apache.org/jira/browse/SOLR-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-7792. --- Resolution: Fixed Upgrade morfologik-stemming to version 1.10.0 - Key: SOLR-7792 URL: https://issues.apache.org/jira/browse/SOLR-7792 Project: Solr Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: Trunk, 5.4 -- 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] [Resolved] (SOLR-7790) Update Carrot2 clustering contrib to version 3.10.3
[ https://issues.apache.org/jira/browse/SOLR-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-7790. --- Resolution: Fixed Update Carrot2 clustering contrib to version 3.10.3 --- Key: SOLR-7790 URL: https://issues.apache.org/jira/browse/SOLR-7790 Project: Solr Issue Type: Task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: Trunk, 5.4 Attachments: SOLR-7790.patch, SOLR-7790.patch This issue brings the clustering extension up to date and also involves upgrading a few other libraries (see sub-tasks or linked issues). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 13981 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13981/ Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([5A760E747179A7E:A2E3D8432AAC89C7]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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] [Assigned] (SOLR-7909) ZK ACL credential provider cannot be set from JVM params as documented
[ https://issues.apache.org/jira/browse/SOLR-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-7909: - Assignee: Jan Høydahl ZK ACL credential provider cannot be set from JVM params as documented -- Key: SOLR-7909 URL: https://issues.apache.org/jira/browse/SOLR-7909 Project: Solr Issue Type: Bug Components: security Affects Versions: 5.2.1 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 5.4 In RefGuide https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control you are told to setup ZK security provider classes with system properties, but as noted in the comments to that page, that no longer works, and you need to set these in solr.xml. -- 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-7949) Thers is a xss issue in plugins/stats page of Admin Web UI.
[
https://issues.apache.org/jira/browse/SOLR-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14708985#comment-14708985
]
Upayavira commented on SOLR-7949:
-
Thanks! And, please note that there is a new instance of the UI, backed by
AngularJS that will at some point take over from the one you have been
reviewing. I would *love* to have your eye cast over that one too. It *should*
be feature-to-feature compatible with the old one. In Solr 5.3 it is at
http://localhost:8983/solr/index.html#
Thers is a xss issue in plugins/stats page of Admin Web UI.
---
Key: SOLR-7949
URL: https://issues.apache.org/jira/browse/SOLR-7949
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.9, 4.10.4, 5.2.1
Reporter: davidchiu
Assignee: Jan Høydahl
Fix For: Trunk, 5.4, 5.3.1
Open Solr Admin Web UI, select a core(such as collection1) and then click
Plugins/stats,and type a url like
http://127.0.0.1:8983/solr/#/collection1/plugins/cache?entry=score=img
src=1 onerror=alert(1); to the browser address, you will get alert box with
1.
I changed follow code to resolve this problem:
The Original code:
for( var i = 0; i entry_count; i++ )
{
$( 'a[data-bean=' + entries[i] + ']', frame_element )
.parent().addClass( 'expanded' );
}
The Changed code:
for( var i = 0; i entry_count; i++ )
{
$( 'a[data-bean=' + entries[i].esc() + ']', frame_element )
.parent().addClass( 'expanded' );
}
--
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
