[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153872#comment-15153872
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit 55162f2255a1f707603cc81134996cfb2a5968ec in lucene-solr's branch 
refs/heads/branch_5x from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=55162f2 ]

SOLR-8677: Fix broken build


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153873#comment-15153873
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit 9b9a64a9d6a6b334c93ae18dbc8da534f4198b22 in lucene-solr's branch 
refs/heads/branch_5x from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b9a64a ]

SOLR-8677: Fix broken build


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153871#comment-15153871
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit 96c01a2c885871f7d80beddc6e019547639ef71e in lucene-solr's branch 
refs/heads/branch_5x from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=96c01a2 ]

SOLR-8677: Restrict creation of shards with invalid names


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153874#comment-15153874
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit e8acc04c68ac74ca5757285581c42457100c990c in lucene-solr's branch 
refs/heads/branch_5x from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e8acc04 ]

SOLR-8677: Fix assert statement


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7036) nio.Paths and nio.Files package are used in StringHelper, but they are restricted in many infrastructure and platforms

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153856#comment-15153856
 ] 

Uwe Schindler edited comment on LUCENE-7036 at 2/19/16 7:35 AM:


Can you explain your problem? Lucene 5.x requires Java 7 at minimum and all 
file IO uses java.nio.files.* APIs.
StringHelper uses the file /dev/urandom only if it is available. If the 
environment restricts access, another hasing is used.


was (Author: thetaphi):
Can you explain your problem? Lucene 5.x requires Java 7 at minimum and all 
file IO uses java.nio.files.* APIs.
StringHelper uses the file /dev/urandom only if it is available.

> nio.Paths and nio.Files package are used in StringHelper, but they are 
> restricted in many infrastructure and platforms
> --
>
> Key: LUCENE-7036
> URL: https://issues.apache.org/jira/browse/LUCENE-7036
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.1, 5.2, 5.3, 5.4, 5.5
>Reporter: Forrest Sun
>
> nio.Paths and nio.Files package are used in StringHelper, but they are 
> restricted in many infrastructure and platforms like Google App Engine.
> The use of Paths and Fiiles are not related to the main function of Lucene.
> It's better to provide an interface to store system properties instead of 
> using File API in String Helper directly.



--
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-7036) nio.Paths and nio.Files package are used in StringHelper, but they are restricted in many infrastructure and platforms

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153856#comment-15153856
 ] 

Uwe Schindler commented on LUCENE-7036:
---

Can you explain your problem? Lucene 5.x requires Java 7 at minimum and all 
file IO uses java.nio.files.* APIs.
StringHelper uses the file /dev/urandom only if it is available.

> nio.Paths and nio.Files package are used in StringHelper, but they are 
> restricted in many infrastructure and platforms
> --
>
> Key: LUCENE-7036
> URL: https://issues.apache.org/jira/browse/LUCENE-7036
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.1, 5.2, 5.3, 5.4, 5.5
>Reporter: Forrest Sun
>
> nio.Paths and nio.Files package are used in StringHelper, but they are 
> restricted in many infrastructure and platforms like Google App Engine.
> The use of Paths and Fiiles are not related to the main function of Lucene.
> It's better to provide an interface to store system properties instead of 
> using File API in String Helper directly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 412 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/412/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 68507 lines...]
changes-to-html:
[mkdir] Created dir: 
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build/docs/changes
  [get] Getting: https://issues.apache.org/jira/rest/api/2/project/SOLR
  [get] To: 
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build/docs/changes/jiraVersionList.json
 [exec] Section 'Other Changes' appears more than once under release 
'6.0.0' at 
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/lucene/site/changes/changes2html.pl
 line 135.

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:740: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:101: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build.xml:632: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build.xml:607: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/lucene/common-build.xml:2522:
 exec returned: 255

Total time: 91 minutes 19 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated LUCENE-6993:
--
Attachment: LUCENE-6993.patch

Ok, making progress...

To recap what I've done so far (so that it's easier next time)
{noformat}
* ant gen-tlds
copy affected analyzers to a stdX directory
update affected factories
update jflex-legacy task in build.xml
update test data to use valid domains
* ANT_OPTS='-Xmx5g' ant jflex
* perl generateJavaUnicodeWordBreakTest.pl -v 8.0.0
* sed 's/6_3/8_0/g' TestStandardAnalyzer.java TestUAX29URLEmailTokenizer.java
{noformat}
(starred entries are verbatim commands)

I also had to add a special case to the perl script where if there is a double 
quote inside of output string text to add a java escape. I saw this in one of 
the other Unicode release notes relating to hebrew text. The specific test this 
is necessary for is א"א

I was not able to figure out how to install jflex snapshot locally -- I thought 
by running mvn install on master it would work but turns out I don't understand 
the nuances of ivy. Consequentially, I have not updated the unicode directives 
to 8.0 for any of the parsers, but all the analyzer/tokenizer tests still seem 
to pass so we might be ok?

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
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-8371) Try and prevent too many recovery requests from stacking up and clean up some faulty logic.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153714#comment-15153714
 ] 

Mark Miller commented on SOLR-8371:
---

Thanks [~andyetitmoves]. I'll open a new issue shortly and ping those 
interested.

> Try and prevent too many recovery requests from stacking up and clean up some 
> faulty logic.
> ---
>
> Key: SOLR-8371
> URL: https://issues.apache.org/jira/browse/SOLR-8371
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.5, master
>
> Attachments: SOLR-8371-2.patch, SOLR-8371.patch, SOLR-8371.patch, 
> SOLR-8371.patch, SOLR-8371.patch, SOLR-8371.patch, SOLR-8371.patch, 
> SOLR-8371.patch, SOLR-8371.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3274) ZooKeeper related SolrCloud problems

[Nitin Sharma (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153691#comment-15153691
 ] 

Nitin Sharma commented on SOLR-3274:


I also ran into this issue with solr 4.6.1. The main issue is that updates go 
through fine in solr but solr-zk interactions are broken and few shards are 
marked as down. They never recover/reconnect to zk unless force solr restart. I 
even tried bumping up zk ensemble to 7 and upto 9 nodes but did not help. 

Any suggestions on how to deal with this? 

> ZooKeeper related SolrCloud problems
> 
>
> Key: SOLR-3274
> URL: https://issues.apache.org/jira/browse/SOLR-3274
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-ALPHA
> Environment: Any
>Reporter: Per Steffensen
>
> Same setup as in SOLR-3273. Well if I have to tell the entire truth we have 7 
> Solr servers, running 28 slices of the same collection (collA) - all slices 
> have one replica (two shards all in all - leader + replica) - 56 cores all in 
> all (8 shards on each solr instance). But anyways...
> Besides the problem reported in SOLR-3273, the system seems to run fine under 
> high load for several hours, but eventually errors like the ones shown below 
> start to occur. I might be wrong, but they all seem to indicate some kind of 
> unstability in the collaboration between Solr and ZooKeeper. I have to say 
> that I havnt been there to check ZooKeeper "at the moment where those 
> exception occur", but basically I dont believe the exceptions occur because 
> ZooKeeper is not running stable - at least when I go and check ZooKeeper 
> through other "channels" (e.g. my eclipse ZK plugin) it is always accepting 
> my connection and generally seems to be doing fine.
> Exception 1) Often the first error we see in solr.log is something like this
> {code}
> Mar 22, 2012 5:06:43 AM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot talk to ZooKeeper - 
> Updates are disabled.
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.zkCheck(DistributedUpdateProcessor.java:678)
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:250)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:80)
> at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:407)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
> at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
> at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
> at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
> at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
> at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> I believe this error basically occurs because SolrZkClient.isConnected 
> reports false, which means that its internal "keeper.getState" does not 
> return ZooKeeper.States.CONNECTED. Im pretty sure that it has been CONNECTED 
> for a long time, since this error starts occuring after several hours of 
> processing without this problem showing. But why is it suddenly not connected 
> anymore?!
> Exception 

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 15924 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15924/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseParallelGC

6 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamExpressionTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([9F596A2F464D5A7D]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamExpressionTest

Error Message:
Captured an uncaught exception in thread: Thread[id=1529, name=Thread-386, 
state=RUNNABLE, group=TGRP-StreamExpressionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1529, name=Thread-386, state=RUNNABLE, 
group=TGRP-StreamExpressionTest]
Caused by: org.apache.solr.common.SolrException: Could not load collection from 
ZK: parallelDestinationCollection1
at __randomizedtesting.SeedInfo.seed([9F596A2F464D5A7D]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:959)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:517)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:189)
at 
org.apache.solr.common.cloud.ClusterState.hasCollection(ClusterState.java:119)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1110)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:833)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at 
org.apache.solr.client.solrj.io.stream.UpdateStream.uploadBatchToCollection(UpdateStream.java:256)
at 
org.apache.solr.client.solrj.io.stream.UpdateStream.read(UpdateStream.java:118)
at 
org.apache.solr.client.solrj.io.stream.DaemonStream$StreamRunner.run(DaemonStream.java:245)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1342)
at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1153)
at 
org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
at 
org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:350)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:350)
at 
org.apache.solr.common.cloud.ZkStateReader.fetchCollectionState(ZkStateReader.java:967)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:954)
... 12 more


FAILED:  org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([9F596A2F464D5A7D]:0)


FAILED:  
org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNamesRejectedWhenCreatingCollection

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([9F596A2F464D5A7D:D529D509F4081A1D]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNamesRejectedWhenCreatingCollection(TestCollectionAdminRequest.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 

[JENKINS] Solr-Artifacts-trunk - Build # 2795 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2795/

No tests ran.

Build Log:
[...truncated 33 lines...]
package-src-tgz:
   [delete] Deleting directory 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/solr/build/solr/src-export/lucene/tools/javadoc/java8
   [delete] Deleting directory 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/solr/build/solr/src-export/lucene/tools/clover
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/solr/build/solr/src-export/solr/docs/changes
  [get] Getting: https://issues.apache.org/jira/rest/api/2/project/SOLR
  [get] To: 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/solr/build/solr/src-export/solr/docs/changes/jiraVersionList.json
 [exec] Section 'Other Changes' appears more than once under release 
'6.0.0' at 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/lucene/site/changes/changes2html.pl
 line 135.

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/solr/build.xml:467: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:2522:
 exec returned: 255

Total time: 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3095 - Still Failing!

[Anshum Gupta]

This should be fixed now.

On Thu, Feb 18, 2016 at 6:46 PM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3095/
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
>
> 3 tests failed.
> FAILED:
> org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNameRejectedWhenCreatingShard
>
> Error Message:
>
>
> Stack Trace:
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([3EFB1D09BAADAB76:94E19C3D086C8C90]:0)
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at
> org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNameRejectedWhenCreatingShard(TestCollectionAdminRequest.java:82)
> 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:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> 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:53)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at java.lang.Thread.run(Thread.java:745)
>
>
> FAILED:
> org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNamesRejectedWhenCreatingCollection
>
> Error Message:
>
>
> Stack Trace:
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([3EFB1D09BAADAB76:748BA22F08E8EB16]:0)
> at 

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3095 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3095/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNameRejectedWhenCreatingShard

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([3EFB1D09BAADAB76:94E19C3D086C8C90]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNameRejectedWhenCreatingShard(TestCollectionAdminRequest.java:82)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNamesRejectedWhenCreatingCollection

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([3EFB1D09BAADAB76:748BA22F08E8EB16]: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 

[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153596#comment-15153596
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit eb0e270043f7e83c06683043a4fb642b4f04b485 in lucene-solr's branch 
refs/heads/master from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb0e270 ]

SOLR-8677: Fix assert statement


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1101 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1101/

3 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=25279, name=collection5, 
state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=25279, name=collection5, state=RUNNABLE, 
group=TGRP-HdfsCollectionsAPIDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([811581C0E9C440B0:941BE1A47382D48]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54423/c_/l: collection already exists: 
awholynewstresscollection_collection5_0
at __randomizedtesting.SeedInfo.seed([811581C0E9C440B0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:576)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
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:1099)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1573)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1594)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:960)


FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload

Error Message:
expected:<[{indexVersion=1455845237037,generation=2,filelist=[_77.fdt, _77.fdx, 
_77.fnm, _77.nvd, _77.nvm, _77.si, _77_Direct_0.doc, _77_Direct_0.tim, 
_77_Direct_0.tip, _ee.cfe, _ee.cfs, _ee.si, _fl.cfe, _fl.cfs, _fl.si, _gs.cfe, 
_gs.cfs, _gs.si, _gz.cfe, _gz.cfs, _gz.si, _h6.cfe, _h6.cfs, _h6.si, _hc.cfe, 
_hc.cfs, _hc.si, _hd.cfe, _hd.cfs, _hd.si, _he.cfe, _he.cfs, _he.si, _hf.cfe, 
_hf.cfs, _hf.si, _hg.cfe, _hg.cfs, _hg.si, _hh.cfe, _hh.cfs, _hh.si, _hi.cfe, 
_hi.cfs, _hi.si, segments_2]}]> but 
was:<[{indexVersion=1455845237037,generation=3,filelist=[_77.fdt, _77.fdx, 
_77.fnm, _77.nvd, _77.nvm, _77.si, _77_Direct_0.doc, _77_Direct_0.tim, 
_77_Direct_0.tip, _ee.cfe, _ee.cfs, _ee.si, _fl.cfe, _fl.cfs, _fl.si, _gs.cfe, 
_gs.cfs, _gs.si, _gz.cfe, _gz.cfs, _gz.si, _h6.cfe, _h6.cfs, _h6.si, _hd.cfe, 
_hd.cfs, _hd.si, _hj.cfe, _hj.cfs, _hj.si, segments_3]}, 
{indexVersion=1455845237037,generation=2,filelist=[_77.fdt, _77.fdx, _77.fnm, 
_77.nvd, _77.nvm, _77.si, _77_Direct_0.doc, _77_Direct_0.tim, _77_Direct_0.tip, 
_ee.cfe, _ee.cfs, _ee.si, _fl.cfe, _fl.cfs, _fl.si, _gs.cfe, _gs.cfs, _gs.si, 
_gz.cfe, _gz.cfs, _gz.si, _h6.cfe, _h6.cfs, _h6.si, _hc.cfe, _hc.cfs, _hc.si, 
_hd.cfe, _hd.cfs, _hd.si, _he.cfe, _he.cfs, _he.si, _hf.cfe, _hf.cfs, _hf.si, 
_hg.cfe, _hg.cfs, _hg.si, _hh.cfe, _hh.cfs, _hh.si, _hi.cfe, _hi.cfs, _hi.si, 
segments_2]}]>

Stack Trace:
java.lang.AssertionError: 
expected:<[{indexVersion=1455845237037,generation=2,filelist=[_77.fdt, _77.fdx, 
_77.fnm, _77.nvd, _77.nvm, _77.si, _77_Direct_0.doc, _77_Direct_0.tim, 
_77_Direct_0.tip, _ee.cfe, _ee.cfs, _ee.si, _fl.cfe, _fl.cfs, _fl.si, _gs.cfe, 
_gs.cfs, _gs.si, _gz.cfe, _gz.cfs, _gz.si, _h6.cfe, _h6.cfs, _h6.si, _hc.cfe, 
_hc.cfs, _hc.si, _hd.cfe, _hd.cfs, _hd.si, _he.cfe, _he.cfs, _he.si, _hf.cfe, 
_hf.cfs, _hf.si, _hg.cfe, _hg.cfs, _hg.si, _hh.cfe, _hh.cfs, _hh.si, _hi.cfe, 
_hi.cfs, _hi.si, segments_2]}]> but 
was:<[{indexVersion=1455845237037,generation=3,filelist=[_77.fdt, _77.fdx, 
_77.fnm, _77.nvd, _77.nvm, _77.si, _77_Direct_0.doc, _77_Direct_0.tim, 
_77_Direct_0.tip, _ee.cfe, _ee.cfs, _ee.si, _fl.cfe, _fl.cfs, _fl.si, _gs.cfe, 
_gs.cfs, _gs.si, _gz.cfe, _gz.cfs, _gz.si, _h6.cfe, _h6.cfs, _h6.si, _hd.cfe, 
_hd.cfs, _hd.si, _hj.cfe, _hj.cfs, _hj.si, segments_3]}, 
{indexVersion=1455845237037,generation=2,filelist=[_77.fdt, _77.fdx, _77.fnm, 
_77.nvd, _77.nvm, _77.si, _77_Direct_0.doc, _77_Direct_0.tim, _77_Direct_0.tip, 
_ee.cfe, _ee.cfs, _ee.si, _fl.cfe, _fl.cfs, _fl.si, _gs.cfe, _gs.cfs, _gs.si, 
_gz.cfe, _gz.cfs, _gz.si, _h6.cfe, _h6.cfs, _h6.si, _hc.cfe, _hc.cfs, _hc.si, 
_hd.cfe, _hd.cfs, _hd.si, _he.cfe, _he.cfs, _he.si, _hf.cfe, _hf.cfs, _hf.si, 
_hg.cfe, _hg.cfs, _hg.si, _hh.cfe, _hh.cfs, _hh.si, _hi.cfe, _hi.cfs, 

[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153545#comment-15153545
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit c7c5b8fe498408fb28911272986b119fc3ab563f in lucene-solr's branch 
refs/heads/master from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c7c5b8f ]

SOLR-8677: Fix broken build


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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-8700) Move the ImplicitPlugins definitions to a json file

[Noble Paul (JIRA)]

Noble Paul created SOLR-8700:


 Summary: Move the ImplicitPlugins definitions to a json file
 Key: SOLR-8700
 URL: https://issues.apache.org/jira/browse/SOLR-8700
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor


ImplicitPlugins.java is all about constructing the datastructures 
programmatically. it's much better if they were represented in a proper json 
file



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153460#comment-15153460
 ] 

Scott Blum commented on SOLR-8696:
--

Okay, I can't figure this out after digging for quite a while.  I need more 
help with this!  I can't figure out how the cluster state is getting update in 
legacy mode.  I've tried putting breakpoints in ZkStateWriter, 
SliceMutator.addReplica, etc, and run the following tests:

CollectionsAPISolrJTests.testAddAndDeleteReplica
CollectionsAPIDistributedZkTest.addReplicaTest

But I'm not getting a hit.  What gives?

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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] (LUCENE-7036) nio.Paths and nio.Files package are used in StringHelper, but they are restricted in many infrastructure and platforms

[Forrest Sun (JIRA)]

Forrest Sun created LUCENE-7036:
---

 Summary: nio.Paths and nio.Files package are used in StringHelper, 
but they are restricted in many infrastructure and platforms
 Key: LUCENE-7036
 URL: https://issues.apache.org/jira/browse/LUCENE-7036
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/other
Affects Versions: 5.4, 5.3, 5.2, 5.1, 5.5
Reporter: Forrest Sun


nio.Paths and nio.Files package are used in StringHelper, but they are 
restricted in many infrastructure and platforms like Google App Engine.
The use of Paths and Fiiles are not related to the main function of Lucene.
It's better to provide an interface to store system properties instead of using 
File API in String Helper directly.



--
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-7984) totally bogus and missleading "no default request handler is registered" logged by RequestHandlers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153433#comment-15153433
 ] 

ASF subversion and git services commented on SOLR-7984:
---

Commit 2977efa922b92500cef424139306fc04e08b65a7 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2977efa ]

updatd the test in according with SOLR-7984


> totally bogus and missleading "no default request handler is registered" 
> logged by RequestHandlers 
> ---
>
> Key: SOLR-7984
> URL: https://issues.apache.org/jira/browse/SOLR-7984
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Hoss Man
>Assignee: Noble Paul
> Fix For: 5.4, master
>
> Attachments: SOLR-7988.patch
>
>
> As noted on the user list by Scott Hollenbeck the following warning can be 
> logged by solr...
> bq. no default request handler is registered (either '/select' or 'standard')
> ...even if there is both a handler named "standard" and a handler (in his 
> case named "pinkPony") defined as default="true".
> The code in question appears to be total nonsense...
> {code}
> if(!handlers.alias( "/select","")){
>   if(!handlers.alias( "standard","")){
> log.warn("no default request handler is registered (either '/select' 
> or 'standard')");
>   }
> }
> {code}
> * PluginBag.alias is not documented, but appears to be a mutating operation 
> that _adds_ an alias if and only if the first arg is aname of something that 
> exists, and the second arg is a name that does not already exist -- returning 
> true if the alias is added
> * if an alias already exists with the (default) name "" (which 
> initHandlersFromConfig takes care of registring before this code) then 
> neither of these can be made the new default.
> * just because neither of these aren't made the default here, doesn't mean 
> there isn't already a default handler -- it actually means the exact oposite
> * if the goal was to log an error when there is no default, then that should 
> have just been checked directly



--
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-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8697:
-
Attachment: SOLR-8697.patch

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
> Attachments: SOLR-8697.patch, SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153422#comment-15153422
 ] 

Ishan Chattopadhyaya edited comment on SOLR-8687 at 2/19/16 12:23 AM:
--

bq. it's also disconcerting if it's not air-tight and our tests don't catch it
With [~steve_rowe]'s help, I stress tested 1000 rounds (16 at a time) of the 
StressReorderTest and it didn't fail.
However, the above mentioned test, which is similar to StressReorderTest, but 
on a 3 node cluster instead of a simulated replica, failed around 10 times 
(each with this exact failure). Also, I had increased the number of read 
operations within each test from 50k to 200k. That means 10 failures out of 3.2 
billion reads (which includes both searches and RTGs). At this time, I am 
reasonably sure that the test had nothing to do with my other changes. Next up, 
I shall isolate the test from the other changes and try to run it on a fresh 
master so as to be sure I can reproduce.


was (Author: ichattopadhyaya):
bq. it's also disconcerting if it's not air-tight and our tests don't catch it
With [~steve_rowe]'s help, I stress tested 1000 rounds (16 at a time) of the 
StressReorderTest and it didn't fail.
However, the above mentioned test, which is similar to StressReorderTest, but 
on a 3 node cluster instead of a simulated replica, failed around 10 times 
(each with this exact failure). Also, I had increased the number of read 
operations within each test from 50k to 200k. At this time, I am reasonably 
sure that the test had nothing to do with my other changes. Next up, I shall 
isolate the test from the other changes and try to run it on a fresh master so 
as to be sure I can reproduce.

> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till 
> now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: map={}, prevMap=null, prevMap2=null
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153422#comment-15153422
 ] 

Ishan Chattopadhyaya edited comment on SOLR-8687 at 2/19/16 12:20 AM:
--

bq. it's also disconcerting if it's not air-tight and our tests don't catch it
With [~steve_rowe]'s help, I stress tested 1000 rounds (16 at a time) of the 
StressReorderTest and it didn't fail.
However, the above mentioned test, which is similar to StressReorderTest, but 
on a 3 node cluster instead of a simulated replica, failed around 10 times 
(each with this exact failure). Also, I had increased the number of read 
operations within each test from 50k to 200k. At this time, I am reasonably 
sure that the test had nothing to do with my other changes. Next up, I shall 
isolate the test from the other changes and try to run it on a fresh master so 
as to be sure I can reproduce.


was (Author: ichattopadhyaya):
bq. it's also disconcerting if it's not air-tight and our tests don't catch it
With [~sar...@syr.edu]'s help, I stress tested 1000 rounds (16 at a time) of 
the StressReorderTest and it didn't fail.
However, the above mentioned test, which is similar to StressReorderTest, but 
on a 3 node cluster instead of a simulated replica, failed around 10 times 
(each with this exact failure). Also, I had increased the number of read 
operations within each test from 50k to 200k. At this time, I am reasonably 
sure that the test had nothing to do with my other changes. Next up, I shall 
isolate the test from the other changes and try to run it on a fresh master so 
as to be sure I can reproduce.

> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till 
> now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: map={}, prevMap=null, prevMap2=null
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



--
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-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153422#comment-15153422
 ] 

Ishan Chattopadhyaya commented on SOLR-8687:


bq. it's also disconcerting if it's not air-tight and our tests don't catch it
With [~sar...@syr.edu]'s help, I stress tested 1000 rounds (16 at a time) of 
the StressReorderTest and it didn't fail.
However, the above mentioned test, which is similar to StressReorderTest, but 
on a 3 node cluster instead of a simulated replica, failed around 10 times 
(each with this exact failure). Also, I had increased the number of read 
operations within each test from 50k to 200k. At this time, I am reasonably 
sure that the test had nothing to do with my other changes. Next up, I shall 
isolate the test from the other changes and try to run it on a fresh master so 
as to be sure I can reproduce.

> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till 
> now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: map={}, prevMap=null, prevMap2=null
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



--
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-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153418#comment-15153418
 ] 

Scott Blum commented on SOLR-8697:
--

Found another bug in ShardLeaderElectionContextBase.

cancelElection() and runLeaderProcess() can race with each other.  If the local 
process is trying to cancel right as it becomes leader, cancelElection() won't 
see a leaderZkNodeParentVersion yet, so it won't try to delete the leader 
registration.  Meanwhile, runLeaderProcess() still succeeds in creating the 
leader registration.  The call to super.cancelElection() does remove us from 
the queue, but the dead leader registration is left there.

I think moving the call to super.cancelElection() to the start of 
ShardLeaderElectionContextBase.cancelElection() should resolve the race, 
because actually removing the election node will cause the multi to fail with a 
NoNode rather than a NodeExists, and it won't get stuck in a retry loop.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
> Attachments: SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
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-8687) Race condition with RTGs during soft commit

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153413#comment-15153413
 ] 

Yonik Seeley commented on SOLR-8687:


Hmmm, RTG should be air-tight (I always hate changes to synchronization in this 
area because it's hard to re-validate).  We have stress tests for this, so it's 
also disconcerting if it's not air-tight and our tests don't catch it.
I'll review the related code again...


> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till 
> now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: map={}, prevMap=null, prevMap2=null
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



--
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-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153402#comment-15153402
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit a54e819a6272830098cb50ec1abd75f2501d4993 in lucene-solr's branch 
refs/heads/master from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a54e819 ]

SOLR-8677: Fix broken build


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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: lucene-solr git commit: SOLR-8677: Restrict creation of shards with invalid names

[Anshum Gupta]

Sorry, seems like I broke the build. I'll fix.

On Thu, Feb 18, 2016 at 3:19 PM,  wrote:

> Repository: lucene-solr
> Updated Branches:
>   refs/heads/master 8bcac81a2 -> d01230d63
>
>
> SOLR-8677: Restrict creation of shards with invalid names
>
>
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/d01230d6
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/d01230d6
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/d01230d6
>
> Branch: refs/heads/master
> Commit: d01230d6394b29fa6fd42377404c0c03d6e8a4d9
> Parents: 8bcac81
> Author: anshum 
> Authored: Thu Feb 18 14:00:10 2016 -0800
> Committer: anshum 
> Committed: Thu Feb 18 15:18:44 2016 -0800
>
> --
>  solr/CHANGES.txt|  6 +-
>  .../org/apache/solr/core/CoreContainer.java | 12 ++-
>  .../solr/handler/admin/CollectionsHandler.java  | 31 ++-
>  .../solr/util/SolrIdentifierValidator.java  | 47 ---
>  .../apache/solr/cloud/TestCollectionAPI.java| 71 ++--
>  .../handler/admin/CoreAdminHandlerTest.java |  4 +-
>  .../solrj/request/CollectionAdminRequest.java   | 79 --
>  .../client/solrj/request/CoreAdminRequest.java  | 33 +++-
>  .../solrj/util/SolrIdentifierValidator.java | 51 
>  .../request/TestCollectionAdminRequest.java | 85 
>  .../client/solrj/request/TestCoreAdmin.java | 38 -
>  11 files changed, 380 insertions(+), 77 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/d01230d6/solr/CHANGES.txt
> --
> diff --git a/solr/CHANGES.txt b/solr/CHANGES.txt
> index e6635f1..3fba69d 100644
> --- a/solr/CHANGES.txt
> +++ b/solr/CHANGES.txt
> @@ -266,6 +266,11 @@ Other Changes
>  * SOLR-5730: Make Lucene's SortingMergePolicy and
> EarlyTerminatingSortingCollector configurable in Solr.
>(Christine Poerschke, hossmann, Tomás Fernández Löbbe, Shai Erera)
>
> +Other Changes
> +--
> +* SOLR-8677: Prevent shards containing invalid characters from being
> created.  Checks added server-side
> +  and in SolrJ.  (Shai Erera, Jason Gerlowski, Anshum Gupta)
> +
>  === 5.5.0 ===
>
>  Consult the LUCENE_CHANGES.txt file for additional, low level, changes in
> this release
> @@ -1018,7 +1023,6 @@ Bug Fixes
>
>  * SOLR-8355: update permissions were failing node recovery (noble ,
> Anshum Gupta)
>
> -
>  Optimizations
>  --
>
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/d01230d6/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> --
> diff --git a/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> b/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> index 426a493..7703721 100644
> --- a/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> +++ b/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> @@ -36,6 +36,7 @@ import com.google.common.collect.ImmutableMap;
>  import com.google.common.collect.Maps;
>  import org.apache.solr.client.solrj.impl.HttpClientConfigurer;
>  import org.apache.solr.client.solrj.impl.HttpClientUtil;
> +import org.apache.solr.client.solrj.util.SolrIdentifierValidator;
>  import org.apache.solr.cloud.Overseer;
>  import org.apache.solr.cloud.ZkController;
>  import org.apache.solr.common.SolrException;
> @@ -63,7 +64,6 @@ import org.apache.solr.security.PKIAuthenticationPlugin;
>  import org.apache.solr.security.SecurityPluginHolder;
>  import org.apache.solr.update.UpdateShardHandler;
>  import org.apache.solr.util.DefaultSolrThreadFactory;
> -import org.apache.solr.util.SolrIdentifierValidator;
>  import org.apache.zookeeper.KeeperException;
>  import org.slf4j.Logger;
>  import org.slf4j.LoggerFactory;
> @@ -804,7 +804,10 @@ public class CoreContainer {
>  SolrCore core = null;
>  try {
>MDCLoggingContext.setCore(core);
> -  SolrIdentifierValidator.validateCoreName(dcore.getName());
> +  if (!SolrIdentifierValidator.validateCoreName(dcore.getName())) {
> +throw new SolrException(ErrorCode.BAD_REQUEST, "Invalid core: " +
> dcore.getName()
> ++ ". Core names must consist entirely of periods,
> underscores, and alphanumerics");
> +  }
>if (zkSys.getZkController() != null) {
>  zkSys.getZkController().preRegister(dcore);
>}
> @@ -1007,7 +1010,10 @@ public class CoreContainer {
>}
>
>public void rename(String name, String toName) {
> -SolrIdentifierValidator.validateCoreName(toName);
> +

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153343#comment-15153343
 ] 

Mark Miller commented on SOLR-7339:
---

If it's not isolated test fails and a lot fail it's prob the above issue. 

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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-8687) Race condition with RTGs during soft commit

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153329#comment-15153329
 ] 

Shalin Shekhar Mangar commented on SOLR-8687:
-

This does look like a genuine bug, Ishan. We wait for the new searcher outside 
of the synchronized block and so as you said, a concurrent RTG request can miss 
updates. Perhaps [~ysee...@gmail.com] has a suggestion for us?

> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till 
> now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: map={}, prevMap=null, prevMap2=null
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



--
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-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul resolved SOLR-8692.
--
   Resolution: Fixed
Fix Version/s: 6.0

> Move out embedded  json in ConfigOverlay and RuleBasedAuthorizationPlugin 
> --
>
> Key: SOLR-8692
> URL: https://issues.apache.org/jira/browse/SOLR-8692
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8692.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-8698) Solr's params.json should have a way to specify appends and invariants

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-8698:
-
Description: 
params.json only supports defaults today. It should be possible to add 
{{appends}} and {{invariants}}

for example

{code}
{
"params":{

"my_param_set" : {
"a":"A",
"b" :"B",
"_appends_" : {
"c": "C"
},
"_invariants_":{
"d" : "D"
}}
}
{code}

In this case variables {{a}} and {{b}} are defaults, {{c}} is appends and {{d}} 
is invariants


> Solr's params.json should have a way to specify appends and invariants
> --
>
> Key: SOLR-8698
> URL: https://issues.apache.org/jira/browse/SOLR-8698
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>
> params.json only supports defaults today. It should be possible to add 
> {{appends}} and {{invariants}}
> for example
> {code}
> {
> "params":{
> "my_param_set" : {
> "a":"A",
> "b" :"B",
> "_appends_" : {
> "c": "C"
> },
> "_invariants_":{
> "d" : "D"
> }}
> }
> {code}
> In this case variables {{a}} and {{b}} are defaults, {{c}} is appends and 
> {{d}} is invariants



--
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-8677) SOLR allows creation of shards with invalid names.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153325#comment-15153325
 ] 

ASF subversion and git services commented on SOLR-8677:
---

Commit d01230d6394b29fa6fd42377404c0c03d6e8a4d9 in lucene-solr's branch 
refs/heads/master from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d01230d ]

SOLR-8677: Restrict creation of shards with invalid names


> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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-8698) Solr's params.json should have a way to specify appends and invariants

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-8698:
-
Environment: (was: params.json only supports defaults today. It should 
be possible to add {{appends}} and {{invariants}}

for example

{code}
{
"params":{

"my_param_set" : {
"a":"A",
"b" :"B",
"_appends_" : {
"c": "C"
},
"_invariants_":{
"d" : "D"
}}
}
{code}

In this case variables {{a}} and {{b}} are defaults, {{c}} is appends and {{d}} 
is invariants
)

> Solr's params.json should have a way to specify appends and invariants
> --
>
> Key: SOLR-8698
> URL: https://issues.apache.org/jira/browse/SOLR-8698
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153322#comment-15153322
 ] 

Steve Rowe commented on SOLR-7339:
--

I'm seeing an uptick in master test failures on my Jenkins, e.g. this run with 
21 test failures; skimming they're mostly caused by connection resets: 
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/5743/].

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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-8699) Components in solrconfig.xml must be reloadable

[Noble Paul (JIRA)]

Noble Paul created SOLR-8699:


 Summary: Components in solrconfig.xml must be reloadable
 Key: SOLR-8699
 URL: https://issues.apache.org/jira/browse/SOLR-8699
 Project: Solr
  Issue Type: Improvement
  Components: config-api
Reporter: Noble Paul
Assignee: Noble Paul


If we update a component in solrconfig.xml , the entire core is reloaded . This 
is undesirable in a large cluster. If a component is updated , it should be 
possible to update just that plugin without reloading the core. To achieve this 
, we should version the data of of each component and call a {{reload()}} on 
that component only.



--
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-8696) Optimize overseer + startup

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153321#comment-15153321
 ] 

Shalin Shekhar Mangar commented on SOLR-8696:
-

Yeah but that only happens for clusters configured with legacyCloud=false.

To give you some context behind this: the default is legacyCloud=true which 
means that any core admin create command can create corresponding replica in 
clusterstate. This also means that if you deleted a replica which was down at 
the time, it may re-create itself in the cluster state once it comes back up. 
To avoid such problems, a new cluster property called 'legacyCloud' was 
introduced which required all cluster state modifications to be from the 
overseer only. The idea was that this "Zookeeper as truth" mode would 
eventually become the default but we haven't made much progress since.

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153309#comment-15153309
 ] 

Scott Blum commented on SOLR-8696:
--

[~shalinmangar] Am I crazy or doesn't the call to 
{{waitToSeeReplicasInState()}} do what you're talking about?  Loop until the 
new replica appears in the local cluster state?

I tried to find a way to step through, but I don't actually see an 
AddReplicaTest

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153306#comment-15153306
 ] 

Steve Rowe commented on LUCENE-6993:


I think you're right, Mike, I don't see any default word break rule 
modifications in that list between versions 6.3 and 8.0.

The test data is here: 
http://www.unicode.org/Public/8.0.0/ucd/auxiliary/WordBreakTest.txt

Here's the full TODO item from LUCENE-5357 (after {{s/6.3/8.0/g}} and 
{{s/6.1/6.3/g}}):

* Test the new scanners against the Unicode 8.0 word break test data
** -Update {{generateJavaUnicodeWordBreakTest.pl}} to handle above-BMP 
characters in the Unicode character database's 
{{ucd/auxiliary/WordBreakTest.txt}} (previous Unicode versions included only 
BMP characters in that file).- (one time operation, already done.)
** Using {{generateJavaUnicodeWordBreakTest.pl}}, generate 
{{WordBreakTestUnicode_8_0_0.java}} under 
{{modules/analysis/common/src/test/org/apache/lucene/analysis/core/}}.
** Update {{TestStandardAnalyzer.java}} and {{TestUAX29URLEmailTokenizer.java}} 
to invoke {{WordBreakTestUnicode_8_0_0}} rather than 
{{WordBreakTestUnicode_6_3_0}}.
** Remove {{WordBreakTestUnicode_6_3_0.java}}.

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
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-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153305#comment-15153305
 ] 

ASF subversion and git services commented on SOLR-8692:
---

Commit 8bcac81a219f685ea2e92901e9bec05954de90df in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8bcac81 ]

SOLR-8692 moved the embedded json out to resources dir


> Move out embedded  json in ConfigOverlay and RuleBasedAuthorizationPlugin 
> --
>
> Key: SOLR-8692
> URL: https://issues.apache.org/jira/browse/SOLR-8692
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-8692.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8693:
-
Attachment: SOLR-8693.patch

> Improve ZkStateReader logging
> -
>
> Key: SOLR-8693
> URL: https://issues.apache.org/jira/browse/SOLR-8693
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, logging
> Attachments: SOLR-8693.patch, SOLR-8693.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Tweaking a couple of log levels and logging in ZkStateReader, we've been 
> trying to debug a rare issue where certain solr nodes will have an 
> inconsistent view of live_ 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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8697:
-
Attachment: SOLR-8697.patch

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
> Attachments: SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
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-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153294#comment-15153294
 ] 

Scott Blum commented on SOLR-8697:
--

[~markrmil...@gmail.com] [~erickerickson]

I think there is a potential problem with how OverseerTest is constructed, that 
perhaps caused us to write some code into LeaderElector in the past that 
doesn't make any sense for live code.

I'm looking at the implementation of MockZkController.publishState() (it's kind 
of a beast) and I notice that when it creates an ElectionContext, it never 
actually adds it to the map, checks whether one already exists, etc.  As a 
result, MockZkController does something the real ZkController never does -- it 
tries to register two different election contexts for the same core on the same 
ZK session.

My question is, what's the right fix?  I can either make MockZkController not 
setup a new electionContext on subsequent invocations, or I could make it 
simply cancel the previous election context before creating a new one.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
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-8698) Solr's params.json should have a way to specify appends and invariants

[Noble Paul (JIRA)]

Noble Paul created SOLR-8698:


 Summary: Solr's params.json should have a way to specify appends 
and invariants
 Key: SOLR-8698
 URL: https://issues.apache.org/jira/browse/SOLR-8698
 Project: Solr
  Issue Type: Improvement
 Environment: params.json only supports defaults today. It should be 
possible to add {{appends}} and {{invariants}}

for example

{code}
{
"params":{

"my_param_set" : {
"a":"A",
"b" :"B",
"_appends_" : {
"c": "C"
},
"_invariants_":{
"d" : "D"
}}
}
{code}

In this case variables {{a}} and {{b}} are defaults, {{c}} is appends and {{d}} 
is invariants

Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8696) Optimize overseer + startup

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153270#comment-15153270
 ] 

Shalin Shekhar Mangar commented on SOLR-8696:
-

That'd be great, thanks!

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153267#comment-15153267
 ] 

Scott Blum commented on SOLR-8696:
--

Great!  Would you like me to include a fix for ADDREPLICA in this patch?  Seems 
like a good thing to have regardless.

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153258#comment-15153258
 ] 

Mike Drob commented on LUCENE-6993:
---

Looking at http://unicode.org/reports/tr29/#Modifications I see

{noformat}
Revision 27 [KW, LI]

Reissued for Unicode 8.0.
Modified rule SB7 to prevent sentence breaks within a word segment such as 
“Mr.Hamster”.
Updated notes on tailoring using CLDR boundary suppressions.
Recast rule tables to use macros for compactness.
Updated table styles, removed inconsistently applied styles on character 
names and code points, and adjusted layout of various tables and figures.
Section 3.1 Default Grapheme Cluster Boundary Specification
Removed the New Tai Lue characters U+19B0..U+19B4, U+19B8..U+19B9, 
U+19BB..U+19C0, U+19C8..U+19C9 from the exception list for SpacingMark in Table 
2, Grapheme_Cluster_Break Property Values.
Added U+11720 AHOM VOWEL SIGN A and U+11721 AHOM VOWEL SIGN AA to the 
same exception list for SpacingMark.

Revision 26 being a proposed update, only changes between versions 27 and 25 
are noted here.
Revision 25

Reissued for Unicode 7.0.
General text cleanup, including “_” in property and property value names, 
use of curly-quotes and italics.
Section 3.1 Default Grapheme Cluster Boundary Specification
Added U+AA7D MYANMAR SIGN TAI LAING TONE-5 to the exception list for 
SpacingMark in Table 2, Grapheme_Cluster_Break Property Values.
Section 5.1 Default Sentence Boundary Specification
Added note to clarify that Format and Extend characters are not joined 
to separators like LF.
Added note about the fact that words can span a sentence break.
{noformat}

I am by no means an expert in Unicode, but it looks like the Sentence Break 
rules are not relevant to us, right? But the Spacing Mark // Grapheme Cluster 
changes are relevant?
When you refer to the word break test data, is that something that the Unicode 
Consortium publishes or do you mean our internal data?

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
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-6594) deprecate the one action only APIs for schema editing

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-6594:
-
Description: 
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
* Create new field type(s): POST to {{/_collection_/schema/fieldtypes}} or PUT 
to {{/_collection_/schema/fieldtypes/_name_}}
* Create new copyField rule(s): POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields, fieldTypes, and copyField rules, respectively.

  was:
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
* Create new field type(s): POST to {{/_collection_/schema/fieldtypes}} or PUT 
to {{/_collection_/schema/fieldtypes/_name_}}
* Create new copyField rule(s): POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields and copyField rules.


> deprecate the one action only APIs for schema editing
> -
>
> Key: SOLR-6594
> URL: https://issues.apache.org/jira/browse/SOLR-6594
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
> Fix For: 5.5, 6.0
>
>
> with SOLR-6476 done and committed , we have more than one way of writing to 
> schema . Having two different ways of doing the same thing is counter 
> productive . 
> I would like to mark them as deprecated and the calls to those APIs will 
> succeed but will give a deprecation message in the output.  The read APIs 
> would continue to be the same , though .
> Details: the following operations have been deprecated as of Solr 5.5, and 
> support for them will be removed in Solr 6.0: 
> * Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
> {{/_collection_/schema/fields/_fieldname_}}
> * Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
> or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
> * Create new field type(s): POST to {{/_collection_/schema/fieldtypes}} or 
> PUT to {{/_collection_/schema/fieldtypes/_name_}}
> * Create new copyField rule(s): POST to {{/_collection_/schema/copyfields}}.
> Note that all of the above operations can instead be performed using the bulk 
> schema API, documented since the 5.0 Solr ref guide here: 
> https://cwiki.apache.org/confluence/display/solr/Schema+API
> To be clear, read-only GET operations on the above-mentioned endpoints will 
> not be changed, deprecated or removed - they will continue to return 
> information about fields, dynamicFields, fieldTypes, and copyField rules, 
> respectively.



--
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-8696) Optimize overseer + startup

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153226#comment-15153226
 ] 

Shalin Shekhar Mangar commented on SOLR-8696:
-

Thanks Scott.

The ZkStateReader refresh is a safe guard to ensure that before processing any 
operation, the effects of previous operations are reflected in the local 
cluster state. This is less important now because most operations do wait for 
the cluster state to reflect their results (e.g. collection creation/deletion) 
etc.

I audited all overseer operations and the following operations do not have such 
a wait loop:
# ADDREPLICA does not wait for the replica to show up in the local cluster 
state (which may cause the same core name to be assigned again for a subsequent 
addReplica operation)
# ADDREPLICAPROP
# DELETEREPLICAPROP
# BALANCESHARDUNIQUE
# MODIFYCOLLECTION

Of all these only add replica should be fixed. I don't foresee any damage for 
the others.

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153209#comment-15153209
 ] 

Steve Rowe edited comment on LUCENE-6993 at 2/18/16 10:07 PM:
--

[~mdrob], I haven't looked at your patch yet but there is a non-rote Unicode 
upgrade item that needs to be dealt with - from LUCENE-5357's TODO list:

* Upgrade the UAX#29-based grammars to the Unicode -6.3- _8.0_ word break 
rules, in StandardTokenizerImpl.jflex and UAX29URLEmailTokenizer.jflex.

UAX#29 word break rules can (and usually do) change with each Unicode release, 
so we'll need to review the changes between 6.3 and 8.0 and see what, if 
anything, needs changing in the tokenizer grammars.  Another item from the 
LUCENE-5357 TODO list will confirm that this has been done correctly:

* Test the new scanners against the Unicode -6.3- _8.0_ word break test data
** \[...]


was (Author: steve_rowe):
[~mdrob], I haven't looked at your patch yet but there is a non-rote Unicode 
upgrade item that needs to be dealt with - from LUCENE-5357's TODO list:

* Upgrade the UAX#29-based grammars to the Unicode -6.3- _8.0_ word break 
rules, in StandardTokenizerImpl.jflex and UAX29URLEmailTokenizer.jflex.

UAX#29 word break rules can (and usually do) change with each Unicode release, 
so we'll need to review the changes between 6.3 and 8.0 and see what, if 
anything, needs changing in the tokenizer grammars.  Another item from the 
LUCENE-5357 TODO list will confirm that this has been done correctly:

* Test the new scanners against the Unicode 6.3 word break test data
** \[...]

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
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-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153209#comment-15153209
 ] 

Steve Rowe commented on LUCENE-6993:


[~mdrob], I haven't looked at your patch yet but there is a non-rote Unicode 
upgrade item that needs to be dealt with - from LUCENE-5357's TODO list:

* Upgrade the UAX#29-based grammars to the Unicode -6.3- _8.0_ word break 
rules, in StandardTokenizerImpl.jflex and UAX29URLEmailTokenizer.jflex.

UAX#29 word break rules can (and usually do) change with each Unicode release, 
so we'll need to review the changes between 6.3 and 8.0 and see what, if 
anything, needs changing in the tokenizer grammars.  Another item from the 
LUCENE-5357 TODO list will confirm that this has been done correctly:

* Test the new scanners against the Unicode 6.3 word break test data
** \[...]

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
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-8677) SOLR allows creation of shards with invalid names.

[Anshum Gupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta updated SOLR-8677:
---
Attachment: SOLR-8677.patch

There were a few issues with the last patch. Here's an updated patch.
I'll commit once the entire test suite passes. Thanks everyone.

> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
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-8690) make fingerprinting optional

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153194#comment-15153194
 ] 

Yonik Seeley commented on SOLR-8690:


Sounds good to me, I'll go with a system property of solr.disableFingerprint

> make fingerprinting optional
> 
>
> Key: SOLR-8690
> URL: https://issues.apache.org/jira/browse/SOLR-8690
> Project: Solr
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>Priority: Minor
>
> Given that the new index fingerprinting code that happens during peersync has 
> some performance cost, perhaps it should be made configurable?



--
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-3818) TermVectorComponent tfidf is not tf/idf by anyone's definition

[Robert Tupelo-Schneck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153187#comment-15153187
 ] 

Robert Tupelo-Schneck commented on SOLR-3818:
-

This is at least a documentation bug in 
https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component and 
https://wiki.apache.org/solr/TermVectorComponent .  

The source code makes it clear:   // TODO: this is not TF/IDF by anyone's 
definition!

The documentation should make it just as clear, so people don't stumble into 
using it incorrectly.

> TermVectorComponent tfidf is not tf/idf by anyone's definition
> --
>
> Key: SOLR-3818
> URL: https://issues.apache.org/jira/browse/SOLR-3818
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>
> {quote}
> tv.tf_idf - Calculates tf*idf for each term. Requires the parameters tv.tf 
> and tv.df to be "true". This can be expensive. (not shown in example output) 
> {quote}
> But the current computation is tf/docFreq



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153164#comment-15153164
 ] 

Scott Blum commented on SOLR-8696:
--

Actually on second thought, to become the new Overseer, you would have had to 
observe the ephemeral node disappear for the previous overseer.  If you've 
observed that, and subsequently updated yourself as overseer leader, you would 
have had to observe all previous cluster state changes committed by the 
previous Overseer.  So I think it's actually fine in that case.

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-8621) solrconfig.xml: deprecate/replace with

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153148#comment-15153148
 ] 

Hoss Man commented on SOLR-8621:


bq. Shouldn't the index config reference page still list  but with 
a "Deprecated" notice?

No.

The ref guide is not a living document, there are specific versions for each 
release that show the *current* way of doing things (not the old way).  When 
users lookup how to do something we don't want to confuse them by telling them 
how to do something that is no longer supported.  If you want to know how to 
edit older configs, look at older versions of the ref guide.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, master
>
> Attachments: SOLR-8621-example_contrib_configs.patch, 
> SOLR-8621-example_contrib_configs.patch, SOLR-8621.patch, 
> explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * Lucene's SortingMergePolicy can be configured in Solr (with SOLR-5730)
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5 deprecates (but maintains)  support
> * SOLR-8668 in solr 6.0(\?) will remove  support 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-6993:
---
Description: 
We did this once before in LUCENE-5357, but it might be time to update the list 
of TLDs again. Comparing our old list with a new list indicates 800+ new 
domains, so it would be nice to include them.

Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.

  was:We did this once before in LUCENE-5357, but it might be time to update 
the list of TLDs again. Comparing our old list with a new list indicates 800+ 
new domains, so it would be nice to include them.


> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-6993:
---
Summary: Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
JFlex-based tokenizers to support Unicode 8.0  (was: Update TLDs to latest list)

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
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-6993) Update TLDs to latest list

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153131#comment-15153131
 ] 

Steve Rowe commented on LUCENE-6993:


bq. JFlex 1.6.1 currently only supports Unicode 7.0, not 8.0 - Steve Rowe, do 
you know what the jflex timeline for upgrading looks like?

Unicode 8.0 support is committed on JFlex master, but no release includes it 
yet. (So if you want to test I think you could build JFlex locally, change the 
JFlex dependency in Lucene to use the snapshot, then run the Lucene build.) No 
timeline for release has been set.  I'll ping JFlex founder Gerwin Klein, who 
has done all the releases, and get back to you here.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-6993) Update TLDs to latest list

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated LUCENE-6993:
--
Attachment: LUCENE-6993.patch

Ok, switched to 6_0_0 in the next patch.

JFlex 1.6.1 currently only supports Unicode 7.0, not 8.0 - [~steve_rowe], do 
you know what the jflex timeline for upgrading looks like?

I changed jflex-legacy to be a public target and ran it individually, and it 
generated public accessors like we need, so I'm still not sure what's going on, 
but we can move past it at this point. The jflex target still screws it up, 
though, so I'm going to take jflex-legacy out of it.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
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-6594) deprecate the one action only APIs for schema editing

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-6594:
-
Description: 
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
* Create new field type(s): POST to {{/_collection_/schema/fieldtypes}} or PUT 
to {{/_collection_/schema/fieldtypes/_name_}}
* Create new copyField rule(s): POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields and copyField rules.

  was:
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
* Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields and copyField rules.


> deprecate the one action only APIs for schema editing
> -
>
> Key: SOLR-6594
> URL: https://issues.apache.org/jira/browse/SOLR-6594
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
> Fix For: 5.5, 6.0
>
>
> with SOLR-6476 done and committed , we have more than one way of writing to 
> schema . Having two different ways of doing the same thing is counter 
> productive . 
> I would like to mark them as deprecated and the calls to those APIs will 
> succeed but will give a deprecation message in the output.  The read APIs 
> would continue to be the same , though .
> Details: the following operations have been deprecated as of Solr 5.5, and 
> support for them will be removed in Solr 6.0: 
> * Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
> {{/_collection_/schema/fields/_fieldname_}}
> * Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
> or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
> * Create new field type(s): POST to {{/_collection_/schema/fieldtypes}} or 
> PUT to {{/_collection_/schema/fieldtypes/_name_}}
> * Create new copyField rule(s): POST to {{/_collection_/schema/copyfields}}.
> Note that all of the above operations can instead be performed using the bulk 
> schema API, documented since the 5.0 Solr ref guide here: 
> https://cwiki.apache.org/confluence/display/solr/Schema+API
> To be clear, read-only GET operations on the above-mentioned endpoints will 
> not be changed, deprecated or removed - they will continue to return 
> information about fields, dynamicFields and copyField rules.



--
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-6594) deprecate the one action only APIs for schema editing

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-6594:
-
Description: 
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
* Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields and copyField rules.

  was:
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or {{/_collection_/schema/dynamicfields/_glob_}}
* Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields and copyField rules.


> deprecate the one action only APIs for schema editing
> -
>
> Key: SOLR-6594
> URL: https://issues.apache.org/jira/browse/SOLR-6594
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
> Fix For: 5.5, 6.0
>
>
> with SOLR-6476 done and committed , we have more than one way of writing to 
> schema . Having two different ways of doing the same thing is counter 
> productive . 
> I would like to mark them as deprecated and the calls to those APIs will 
> succeed but will give a deprecation message in the output.  The read APIs 
> would continue to be the same , though .
> Details: the following operations have been deprecated as of Solr 5.5, and 
> support for them will be removed in Solr 6.0: 
> * Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
> {{/_collection_/schema/fields/_fieldname_}}
> * Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
> or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
> * Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.
> Note that all of the above operations can instead be performed using the bulk 
> schema API, documented since the 5.0 Solr ref guide here: 
> https://cwiki.apache.org/confluence/display/solr/Schema+API
> To be clear, read-only GET operations on the above-mentioned endpoints will 
> not be changed, deprecated or removed - they will continue to return 
> information about fields, dynamicFields and copyField rules.



--
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-8621) solrconfig.xml: deprecate/replace with

[Jack Krupansky (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153085#comment-15153085
 ] 

Jack Krupansky commented on SOLR-8621:
--

Shouldn't the index config reference page still list  but with a 
"Deprecated" notice? Ditto for .

The Upgrading Solr ref page does give an example of how to migrate from MP to 
MPF (and for MF) - it would be nice to link to that from a deprecated notice on 
the index config page.

See:
https://cwiki.apache.org/confluence/display/solr/IndexConfig+in+SolrConfig
https://cwiki.apache.org/confluence/display/solr/Upgrading+Solr


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, master
>
> Attachments: SOLR-8621-example_contrib_configs.patch, 
> SOLR-8621-example_contrib_configs.patch, SOLR-8621.patch, 
> explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * Lucene's SortingMergePolicy can be configured in Solr (with SOLR-5730)
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5 deprecates (but maintains)  support
> * SOLR-8668 in solr 6.0(\?) will remove  support 



--
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-6594) deprecate the one action only APIs for schema editing

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-6594:
-
Description: 
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or {{/_collection_/schema/dynamicfields/_glob_}}
* Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, read-only GET operations on the above-mentioned endpoints will not 
be changed, deprecated or removed - they will continue to return information 
about fields, dynamicFields and copyField rules.

  was:
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or {{/_collection_/schema/dynamicfields/_glob_}}
* Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, GET operations on the above-mentioned endpoints will not be 
deprecated or removed.


> deprecate the one action only APIs for schema editing
> -
>
> Key: SOLR-6594
> URL: https://issues.apache.org/jira/browse/SOLR-6594
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
> Fix For: 5.5, 6.0
>
>
> with SOLR-6476 done and committed , we have more than one way of writing to 
> schema . Having two different ways of doing the same thing is counter 
> productive . 
> I would like to mark them as deprecated and the calls to those APIs will 
> succeed but will give a deprecation message in the output.  The read APIs 
> would continue to be the same , though .
> Details: the following operations have been deprecated as of Solr 5.5, and 
> support for them will be removed in Solr 6.0: 
> * Create new field(s): POST to {{/_collection_/schema/fields}} or 
> {{/_collection_/schema/fields/_fieldname_}}
> * Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
> or {{/_collection_/schema/dynamicfields/_glob_}}
> * Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.
> Note that all of the above operations can instead be performed using the bulk 
> schema API, documented since the 5.0 Solr ref guide here: 
> https://cwiki.apache.org/confluence/display/solr/Schema+API
> To be clear, read-only GET operations on the above-mentioned endpoints will 
> not be changed, deprecated or removed - they will continue to return 
> information about fields, dynamicFields and copyField rules.



--
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-6594) deprecate the one action only APIs for schema editing

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-6594:
-
Description: 
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .

Details: the following operations have been deprecated as of Solr 5.5, and 
support for them will be removed in Solr 6.0: 
* Create new field(s): POST to {{/_collection_/schema/fields}} or 
{{/_collection_/schema/fields/_fieldname_}}
* Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
or {{/_collection_/schema/dynamicfields/_glob_}}
* Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.

Note that all of the above operations can instead be performed using the bulk 
schema API, documented since the 5.0 Solr ref guide here: 
https://cwiki.apache.org/confluence/display/solr/Schema+API

To be clear, GET operations on the above-mentioned endpoints will not be 
deprecated or removed.

  was:
with SOLR-6476 done and committed , we have more than one way of writing to 
schema . Having two different ways of doing the same thing is counter 
productive . 

I would like to mark them as deprecated and the calls to those APIs will 
succeed but will give a deprecation message in the output.  The read APIs would 
continue to be the same , though .


> deprecate the one action only APIs for schema editing
> -
>
> Key: SOLR-6594
> URL: https://issues.apache.org/jira/browse/SOLR-6594
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
> Fix For: 5.5, 6.0
>
>
> with SOLR-6476 done and committed , we have more than one way of writing to 
> schema . Having two different ways of doing the same thing is counter 
> productive . 
> I would like to mark them as deprecated and the calls to those APIs will 
> succeed but will give a deprecation message in the output.  The read APIs 
> would continue to be the same , though .
> Details: the following operations have been deprecated as of Solr 5.5, and 
> support for them will be removed in Solr 6.0: 
> * Create new field(s): POST to {{/_collection_/schema/fields}} or 
> {{/_collection_/schema/fields/_fieldname_}}
> * Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
> or {{/_collection_/schema/dynamicfields/_glob_}}
> * Create new copyField rules: POST to {{/_collection_/schema/copyfields}}.
> Note that all of the above operations can instead be performed using the bulk 
> schema API, documented since the 5.0 Solr ref guide here: 
> https://cwiki.apache.org/confluence/display/solr/Schema+API
> To be clear, GET operations on the above-mentioned endpoints will not be 
> deprecated or removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 15613 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15613/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 12348 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/temp/junit4-J2-20160218_202045_364.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/heapdumps/java_pid31157.hprof ...
   [junit4] Heap dump file created [291660726 bytes in 0.530 secs]
   [junit4] <<< JVM J2: EOF 

[...truncated 10078 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:750: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:702: Some of the tests 
produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? 
Dumps created:
* java_pid31157.hprof

Total time: 61 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153048#comment-15153048
 ] 

Scott Blum commented on SOLR-8697:
--

TBH, the code is pretty hard to follow in its existing form, and a lot of the 
theory of operation and design is difficult to distill.  There is code that 
looks like it's trying to do what you're talking about, but it's buggy.

Take this analysis with like 70% confidence: The existing code has a very hazy 
definition of "myself" and "previous registration", from what I can tell.  The 
previous elect node from a different process qualifies as "myself" in some 
cases, so the new process thinks it's already registered when it's not.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153041#comment-15153041
 ] 

Scott Blum commented on SOLR-8696:
--

bq. It keeps itself up to date, but with some delay. Are we sure we don't need 
to know we have the latest state at that point? What about the case when we 
just took over for another Overseer? No races?

Forcing a refresh for that case (just took over) seems totally reasonable to me.

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153017#comment-15153017
 ] 

Robert Muir commented on LUCENE-6993:
-

I can't even imagine us releasing a 5.6 after a 6.0, I really do not think we 
should drag that idea into this issue. Its a bad one.

Lets target 6.0 here for all this stuff: these are major changes that impact 
backwards compatibility. The logic should be:

{code}
if (version.onOrAfter(LUCENE_6_0_0)) {
  // new tokenizer
} else {
  // old tokenizer
}
{code}

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
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-8696) Optimize overseer + startup

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153015#comment-15153015
 ] 

Mark Miller commented on SOLR-8696:
---

In one of the leader election improvement patches, I think I took the wait out 
altogether. Starting the Overseer election first makes sense though.

bq. Additionally, we're doing an unnecessary ZkStateReader forced refresh on 
all Overseer operations. This isn't necessary because ZkStateReader keeps 
itself up to date.

It keeps itself up to date, but with some delay. Are we sure we don't need to 
know we have the latest state at that point? What about the case when we just 
took over for another Overseer? No races?

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-8619) A new replica should not become leader when all current replicas are down as it leads to data loss

[Anshum Gupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta updated SOLR-8619:
---
Attachment: SOLR-8619-test.patch

A test that shows what's going on.

> A new replica should not become leader when all current replicas are down as 
> it leads to data loss
> --
>
> Key: SOLR-8619
> URL: https://issues.apache.org/jira/browse/SOLR-8619
> Project: Solr
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.5
>
> Attachments: SOLR-8619-test.patch
>
>
> Here's what I'm talking about:
> * Start a 2 node solrcloud cluster
> * Create a 1 shard/1 replica collection
> * Add documents
> * Shut down the node that has the only active shard
> * ADDREPLICA for the shard/collection, so Solr would attempt to add a new 
> replica on the other node
> * Solr waits for a while before this replica becomes an active leader.
> * Index a few new docs
> * Bring up the old node
> * The replica comes up, with it's old index and then syncs to only contain 
> the docs from the new leader.
> All old documents are lost in this case
> Here are a few things that might work here:
> 1. Reject an ADDREPLICA call if all current replicas for the shard are down. 
> Considering the new replica can not sync from anyone, it doesn't make sense 
> for this replica to even come up
> 2. The replica shouldn't become active/leader unless either it was the last 
> known leader or active before it went into recovering state
> unless there are no other replicas in the clusterstate.
> This might very well be related to SOLR-8173 but we should add a check to 
> ADDREPLICA as well.



--
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-8697) Fix LeaderElector issues

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153011#comment-15153011
 ] 

Mark Miller commented on SOLR-8697:
---

bq. The old process's ZK leader elect node has not yet disappeared, and the new 
process fails to set appropriate watches.

I thought we waited for a while for the old one to go away...is that missing in 
the Overseer election code and just in the shard election code?

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-6993) Update TLDs to latest list

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated LUCENE-6993:
--
Attachment: LUCENE-6993.patch

Attaching a new version of the patch that differentiates between the new and 
old tokenizers. A couple of notes...

I used LUCENE_5_6 as the cutoff, since this could conceivably be backported to 
the 5.x branch. I know there aren't any plans for a 5.6 release ever, but this 
seems like a low cost change.

The {{UAX29URLEmailTokenizerImpl50.java}} currently shows up with private 
methods, which breaks compilation. I can't figure out how to make those public, 
even though the old and new jflex files look almost identical. Would appreciate 
a second set of eyes here.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
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-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152995#comment-15152995
 ] 

Scott Blum commented on SOLR-8697:
--

[~shalinmangar] [~erickerickson] [~markrmil...@gmail.com]

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability, solrcloud
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
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-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

Scott Blum created SOLR-8697:


 Summary: Fix LeaderElector issues
 Key: SOLR-8697
 URL: https://issues.apache.org/jira/browse/SOLR-8697
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum


This patch is still somewhat WIP for a couple of reasons:

1) Still debugging test failures.
2) This will more scrutiny from knowledgable folks!

There are some subtle bugs with the current implementation of LeaderElector, 
best demonstrated by the following test:

1) Start up a small single-node solrcloud.  it should be become Overseer.
2) kill -9 the solrcloud process and immediately start a new one.
3) The new process won't become overseer.  The old process's ZK leader elect 
node has not yet disappeared, and the new process fails to set appropriate 
watches.

NOTE: this is only reproducible if the new node is able to start up and join 
the election quickly.



--
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: Solr Ref Guide for 5.5

[Chris Hostetter]

It looks like we're in pretty good shape -- only a few more crucial 
changes in 5.5 need documented and it looks like folks are actively 
working on those. 

I talked to cassandra a bit offline -- She's about to leave on vacation 
for a few days, so i'll take responsibility for cutting the first RC -- I 
plan to do that tomorow morning my time (roughly 20 hours from now) and 
I'll be available on sunday to do a re-spin if anyone spots any problems.


: Date: Tue, 16 Feb 2016 15:54:10 -0600
: From: Cassandra Targett 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: Solr Ref Guide for 5.5
: 
: With the Lucene/Solr 5.5 release vote underway, I've started getting the
: Solr Ref Guide ready for release. I'll release manage it again, possibly
: with some help from Hoss since I have a little bit of time off planned the
: next couple of weeks.
: 
: Uwe, will you update the CWIKI javadocs to point to the 5_4_0 paths? As
: described here:
: 
https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Javadoc+Links+Work
: .
: 
: As always, if you introduced new features or change to 5.5 that should be
: in the Ref Guide, please take a few moments to make updates. I've taken a
: stab at the TODO list from CHANGES.txt here:
: https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List.
: Please mark your name next to any you plan to work on so we don't overlap
: efforts.
: 
: I hope to get an RC out by the end of this week; by Monday morning US-time
: at the latest. If anyone needs any help with content or more time, please
: just let me know.
: 
: Cassandra
: 

-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] (SOLR-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8696:
-
Description: 
ZkController.publishAndWaitForDownStates() occurs before overseer election.  
That means if there is currently no overseer, there is ironically no one to 
actually service the down state changes it's waiting on.  This particularly 
affects a single-node cluster such as you might run locally for development.

Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
up to date.

  was:
ZkController.publishAndWaitForDownStates() occurs before overseer election.  
That means if there is currently no overseer, there is ironically no one to 
actually service the down state changes it's waiting on.  This particularly 
affects a single-node cluster such as you might run locally for development.

Additionally, we're doing an unnecessary ZkStateReader forced refresh on over 
Overseer operation.  This isn't necessary because ZkStateReader keeps itself up 
to date.


> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8696:
-
Attachment: SOLR-8696.patch

[~shalinmangar]

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on over 
> Overseer operation.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
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-8696) Optimize overseer + startup

[Scott Blum (JIRA)]

Scott Blum created SOLR-8696:


 Summary: Optimize overseer + startup
 Key: SOLR-8696
 URL: https://issues.apache.org/jira/browse/SOLR-8696
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum


ZkController.publishAndWaitForDownStates() occurs before overseer election.  
That means if there is currently no overseer, there is ironically no one to 
actually service the down state changes it's waiting on.  This particularly 
affects a single-node cluster such as you might run locally for development.

Additionally, we're doing an unnecessary ZkStateReader forced refresh on over 
Overseer operation.  This isn't necessary because ZkStateReader keeps itself up 
to date.



--
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-8695) Consistent process(WatchedEvent) handling

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8695:
-
Description: Audited implementations of process(WatchedEvent) for 
consistency in treatment of connection state events, and comment.  This does 
NOT include fixes for DistributedMap/DistributedQueue.  See SOLR-8694.  (was: 
Audited implementations of process(WatchedEvent) for consistency in treatment 
of connection state events.)

> Consistent process(WatchedEvent) handling
> -
>
> Key: SOLR-8695
> URL: https://issues.apache.org/jira/browse/SOLR-8695
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, patch
> Attachments: SOLR-8695.patch
>
>
> Audited implementations of process(WatchedEvent) for consistency in treatment 
> of connection state events, and comment.  This does NOT include fixes for 
> DistributedMap/DistributedQueue.  See SOLR-8694.



--
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-8695) Consistent process(WatchedEvent) handling

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8695:
-
Attachment: SOLR-8695.patch

[~shalinmangar]


> Consistent process(WatchedEvent) handling
> -
>
> Key: SOLR-8695
> URL: https://issues.apache.org/jira/browse/SOLR-8695
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, patch
> Attachments: SOLR-8695.patch
>
>
> Audited implementations of process(WatchedEvent) for consistency in treatment 
> of connection state events.



--
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-8695) Consistent process(WatchedEvent) handling

[Scott Blum (JIRA)]

Scott Blum created SOLR-8695:


 Summary: Consistent process(WatchedEvent) handling
 Key: SOLR-8695
 URL: https://issues.apache.org/jira/browse/SOLR-8695
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum
Priority: Minor


Audited implementations of process(WatchedEvent) for consistency in treatment 
of connection state events.



--
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-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8693:
-
Description: Tweaking a couple of log levels and logging in ZkStateReader, 
we've been trying to debug a rare issue where certain solr nodes will have an 
inconsistent view of live_ nodes.

> Improve ZkStateReader logging
> -
>
> Key: SOLR-8693
> URL: https://issues.apache.org/jira/browse/SOLR-8693
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, logging
> Attachments: SOLR-8693.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Tweaking a couple of log levels and logging in ZkStateReader, we've been 
> trying to debug a rare issue where certain solr nodes will have an 
> inconsistent view of live_ 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

[jira] [Updated] (SOLR-8694) DistributedMap/Queue simplifications and fixes.

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8694:
-
Description: 
Bugfix in DistributedQueue, it could add too many watchers since it assumed the 
watcher was cleared on connection events.

Huge simplification to DistributedMap; it implemented a lot of tricky stuff 
that no one is actually using.

> DistributedMap/Queue simplifications and fixes.
> ---
>
> Key: SOLR-8694
> URL: https://issues.apache.org/jira/browse/SOLR-8694
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability
> Attachments: SOLR-8694.patch
>
>
> Bugfix in DistributedQueue, it could add too many watchers since it assumed 
> the watcher was cleared on connection events.
> Huge simplification to DistributedMap; it implemented a lot of tricky stuff 
> that no one is actually using.



--
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-8694) DistributedMap/Queue simplifications and fixes.

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8694:
-
Attachment: SOLR-8694.patch

[~shalinmangar]

> DistributedMap/Queue simplifications and fixes.
> ---
>
> Key: SOLR-8694
> URL: https://issues.apache.org/jira/browse/SOLR-8694
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, reliability
> Attachments: SOLR-8694.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-8694) DistributedMap/Queue simplifications and fixes.

[Scott Blum (JIRA)]

Scott Blum created SOLR-8694:


 Summary: DistributedMap/Queue simplifications and fixes.
 Key: SOLR-8694
 URL: https://issues.apache.org/jira/browse/SOLR-8694
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum






--
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-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8693:
-
Attachment: (was: SOLR-8693.patch)

> Improve ZkStateReader logging
> -
>
> Key: SOLR-8693
> URL: https://issues.apache.org/jira/browse/SOLR-8693
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, logging
> Attachments: SOLR-8693.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>




--
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-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8693:
-
Attachment: SOLR-8693.patch

> Improve ZkStateReader logging
> -
>
> Key: SOLR-8693
> URL: https://issues.apache.org/jira/browse/SOLR-8693
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, logging
> Attachments: SOLR-8693.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>




--
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-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Blum updated SOLR-8693:
-
Attachment: SOLR-8693.patch

> Improve ZkStateReader logging
> -
>
> Key: SOLR-8693
> URL: https://issues.apache.org/jira/browse/SOLR-8693
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, logging
> Attachments: SOLR-8693.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>




--
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-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152899#comment-15152899
 ] 

Scott Blum commented on SOLR-8693:
--

[~shalinmangar]

> Improve ZkStateReader logging
> -
>
> Key: SOLR-8693
> URL: https://issues.apache.org/jira/browse/SOLR-8693
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easy, logging
> Attachments: SOLR-8693.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>




--
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-8693) Improve ZkStateReader logging

[Scott Blum (JIRA)]

Scott Blum created SOLR-8693:


 Summary: Improve ZkStateReader logging
 Key: SOLR-8693
 URL: https://issues.apache.org/jira/browse/SOLR-8693
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-8692:
-
Attachment: SOLR-8692.patch

 Moves the json to individual json files in the core/src/resources dir


> Move out embedded  json in ConfigOverlay and RuleBasedAuthorizationPlugin 
> --
>
> Key: SOLR-8692
> URL: https://issues.apache.org/jira/browse/SOLR-8692
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-8692.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3094 - Failure!

[Michael McCandless]

Sorry for the noise!

Mike McCandless

http://blog.mikemccandless.com


On Thu, Feb 18, 2016 at 11:01 AM, Uwe Schindler  wrote:
> Ah I see, fixed already :-)
>
> Thanks Mike!
>
> -
> 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: Thursday, February 18, 2016 4:58 PM
>> To: dev@lucene.apache.org
>> Subject: RE: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build #
>> 3094 - Failure!
>>
>> OH.
>>
>> This is caused by this:
>> > volatile static InfoStream infoStream;
>>
>> You should null static vars on afterClass(). Or alternatively convert to a 
>> non-
>> static field.
>>
>> 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: Thursday, February 18, 2016 4:13 PM
>> > To: mikemcc...@apache.org; u...@thetaphi.de; dev@lucene.apache.org
>> > Subject: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build #
>> 3094
>> > - Failure!
>> >
>> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3094/
>> > Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -
>> XX:+UseConcMarkSweepGC
>> >
>> > 1 tests failed.
>> > FAILED:
>> >
>> junit.framework.TestSuite.org.apache.lucene.TestMergeSchedulerExternal
>> >
>> > Error Message:
>> > access denied ("java.lang.RuntimePermission"
>> > "accessClassInPackage.sun.nio.cs")
>> >
>> > Stack Trace:
>> > java.security.AccessControlException: access denied
>> > ("java.lang.RuntimePermission" "accessClassInPackage.sun.nio.cs")
>> > at __randomizedtesting.SeedInfo.seed([12244950C6C73109]:0)
>> > at
>> >
>> java.security.AccessControlContext.checkPermission(AccessControlContext.j
>> > ava:472)
>> > at
>> > java.security.AccessController.checkPermission(AccessController.java:884)
>> > at
>> > java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>> > at
>> >
>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1564)
>> > at java.lang.Class.checkPackageAccess(Class.java:2372)
>> > at java.lang.Class.checkMemberAccess(Class.java:2351)
>> > at java.lang.Class.getDeclaredFields(Class.java:1915)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.RamUsageEstimator$2.run(RamU
>> > sageEstimator.java:585)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.RamUsageEstimator$2.run(RamU
>> > sageEstimator.java:582)
>> > at java.security.AccessController.doPrivileged(Native Method)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.RamUsageEstimator.createCache
>> > Entry(RamUsageEstimator.java:582)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.RamUsageEstimator.measureSize
>> > Of(RamUsageEstimator.java:545)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.RamUsageEstimator.sizeOfAll(Ra
>> > mUsageEstimator.java:387)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterA
>> > lways(StaticFieldsInvariantRule.java:127)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> > ementAdapter.java:43)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> > ementAdapter.java:36)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> > ementAdapter.java:36)
>> > at
>> >
>> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAss
>> > ertionsRequired.java:53)
>> > at
>> >
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
>> > .java:47)
>> > at
>> >
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
>> > IgnoreAfterMaxFailures.java:64)
>> > at
>> >
>> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnore
>> > TestSuites.java:54)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> > ementAdapter.java:36)
>> > at
>> >
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
>> > run(ThreadLeakControl.java:367)
>> > at java.lang.Thread.run(Thread.java:745)
>> >
>> >
>> >
>> >
>> > Build Log:
>> > [...truncated 459 lines...]
>> >[junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal
>> >[junit4]   2> NOTE: test params are: codec=Asserting(Lucene60):
>> > {id=Lucene50(blocksize=128)}, docValues:{},
>> > sim=RandomSimilarity(queryNorm=false,coord=no): {}, locale=es,
>> > timezone=Asia/Urumqi
>> >[junit4]   2> NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.8.0_72
>> (64-
>> > bit)/cpus=3,threads=1,free=45295032,total=54853632
>> >[junit4]   2> NOTE: All tests run in this JVM: [TestForceMergeForever,
>> > TestNumericRangeQuery32, TestStringHelper, TestSortRescorer,
>> > 

[jira] [Created] (SOLR-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin

[Noble Paul (JIRA)]

Noble Paul created SOLR-8692:


 Summary: Move out embedded  json in ConfigOverlay and 
RuleBasedAuthorizationPlugin 
 Key: SOLR-8692
 URL: https://issues.apache.org/jira/browse/SOLR-8692
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8690) make fingerprinting optional

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152732#comment-15152732
 ] 

Mark Miller commented on SOLR-8690:
---

Feels to me like at most it should not be first class config, but a simple 
system prop. The old behavior is buggy with the current system. I can see 
wanting a safety valve to disable it in case you hit something that is worse 
for you then the bug and don't have time to wait for a fix, but I'd hate to 
support this with first class configuration.

> make fingerprinting optional
> 
>
> Key: SOLR-8690
> URL: https://issues.apache.org/jira/browse/SOLR-8690
> Project: Solr
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>Priority: Minor
>
> Given that the new index fingerprinting code that happens during peersync has 
> some performance cost, perhaps it should be made configurable?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-8690) make fingerprinting optional

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152710#comment-15152710
 ] 

Yonik Seeley edited comment on SOLR-8690 at 2/18/16 6:01 PM:
-

So assuming that people want this to be configurable, the config could either 
go in
solr.xml or solrconfig.xml

It's also super-expert enough (this is really only an escape hatch in case 
something goes wrong and fingerprinting overhead turns out to be an issue for 
someone) that another option is it could just be system property w/o any 
corresponding entry in solr.xml or solrconfig.xml?

Thoughts?



was (Author: ysee...@gmail.com):
So assuming that people want this to be configurable, the config could either 
go in
solr.xml or solrconfig.xml
Thoughts?

> make fingerprinting optional
> 
>
> Key: SOLR-8690
> URL: https://issues.apache.org/jira/browse/SOLR-8690
> Project: Solr
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>Priority: Minor
>
> Given that the new index fingerprinting code that happens during peersync has 
> some performance cost, perhaps it should be made configurable?



--
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-8690) make fingerprinting optional

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152710#comment-15152710
 ] 

Yonik Seeley commented on SOLR-8690:


So assuming that people want this to be configurable, the config could either 
go in
solr.xml or solrconfig.xml
Thoughts?

> make fingerprinting optional
> 
>
> Key: SOLR-8690
> URL: https://issues.apache.org/jira/browse/SOLR-8690
> Project: Solr
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>Priority: Minor
>
> Given that the new index fingerprinting code that happens during peersync has 
> some performance cost, perhaps it should be made configurable?



--
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-8621) solrconfig.xml: deprecate/replace with

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152699#comment-15152699
 ] 

Hoss Man commented on SOLR-8621:


[~cpoerschke] & [~shaie] ... can you guys please spot check the edits i made to 
the ref guide for this issue...

https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=32604214=31=32

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, master
>
> Attachments: SOLR-8621-example_contrib_configs.patch, 
> SOLR-8621-example_contrib_configs.patch, SOLR-8621.patch, 
> explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * Lucene's SortingMergePolicy can be configured in Solr (with SOLR-5730)
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5 deprecates (but maintains)  support
> * SOLR-8668 in solr 6.0(\?) will remove  support 



--
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-8691) cache index fingerprint

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-8691:
--

 Summary: cache index fingerprint
 Key: SOLR-8691
 URL: https://issues.apache.org/jira/browse/SOLR-8691
 Project: Solr
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor


When there are a high number of replicas, there may be many PeerSync calls 
(with fingerprinting).  We can cache the current fingerprint with the current 
SolrIndexSearcher so it can be reused if the index hasn't changed.



--
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