[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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
[ https://issues.apache.org/jira/browse/LUCENE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/LUCENE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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!
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
[ 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.
[ https://issues.apache.org/jira/browse/SOLR-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > anymor
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 15924 - Failure!
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 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.
[JENKINS] Solr-Artifacts-trunk - Build # 2795 - Failure
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!
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 org.junit.Assert.
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3095 - Still Failing!
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 org.apache.solr.client.solrj.request.TestCollectionAdminRequest.testInvalidShardNamesRejectedWhenCreatingCollection(TestCollec
[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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
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, _hi
[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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 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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/SOLR-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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
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); > +if(!SolrIdentifierValidator.validateCoreName(toName)) { > + throw new SolrException(ErrorC
[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3
[ https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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.
[ https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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&name=coll1&router.name=implicit&numShards=1&shards=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&wt=json&indent=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
[ https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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!
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
[ https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
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
[ 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
[ 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 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
[ 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
[ 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 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
[ 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.
[ 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.
[ 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 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/SOLR-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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!
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, >> > TestFieldCacheRewriteM
[jira] [Created] (SOLR-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin
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
[ https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&selectedPageVersions=31&selectedPageVersions=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 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