[jira] [Commented] (SOLR-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700638#comment-16700638 ] Frank Kelly commented on SOLR-5211: --- Many thanks to all who contributed to this fix - it is very welcome! > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: master (8.0) > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10030) SolrClient.getById() method in Solrj doesn't retrieve child documents
[
https://issues.apache.org/jira/browse/SOLR-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204619#comment-16204619
]
Frank Kelly commented on SOLR-10030:
We are using nested / child documents in Solr 5.3.1, any idea how "bad" this
issue is in v6? Sounds like nested documents don't work at all.
> SolrClient.getById() method in Solrj doesn't retrieve child documents
> -
>
> Key: SOLR-10030
> URL: https://issues.apache.org/jira/browse/SOLR-10030
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, SolrJ
>Affects Versions: 6.2.1
>Reporter: Masoud Kiaeeha
>
> I have this code in my program which uses solrj:
> SolrDocument document = solrClient.getById(idString);
> List children = document.getChildDocuments();
> which returns null for document.getChildDocuments() although the document I
> am referring to has children. I can easily confirm that this document has
> children by running the following query:
> q={!child of="path:1.document"}path:1.document
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9830) Once IndexWriter is closed due to some RunTimeException like FileSystemException, It never return to normal unless restart the Solr JVM
[ https://issues.apache.org/jira/browse/SOLR-9830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161930#comment-16161930 ] Frank Kelly commented on SOLR-9830: --- I have seen this in Solr 5.3.1 Our ulimit is confirmed as "unlimited" And the solution is always the same - restart the JVM. > Once IndexWriter is closed due to some RunTimeException like > FileSystemException, It never return to normal unless restart the Solr JVM > --- > > Key: SOLR-9830 > URL: https://issues.apache.org/jira/browse/SOLR-9830 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: update >Affects Versions: 6.2 > Environment: Red Hat 4.4.7-3,SolrCloud >Reporter: Daisy.Yuan > > 1. Collection coll_test, has 9 shards, each has two replicas in different > solr instances. > 2. When update documens to the collection use Solrj, inject the exhausted > handle fault to one solr instance like solr1. > 3. Update to col_test_shard3_replica1(It's leader) is failed due to > FileSystemException, and IndexWriter is closed. > 4. And clear the fault, the col_test_shard3_replica1 (is leader) is always > cannot be updated documens and the numDocs is always less than the standby > replica. > 5. After Solr instance restart, It can update documens and the numDocs is > consistent between the two replicas. > I think in this case in Solr Cloud mode, it should recovery itself and not > restart to recovery the solrcore update function. > 2016-12-01 14:13:00,932 | INFO | http-nio-21101-exec-20 | > [DWPT][http-nio-21101-exec-20]: now abort | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,932 | INFO | http-nio-21101-exec-20 | > [DWPT][http-nio-21101-exec-20]: done abort | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,932 | INFO | http-nio-21101-exec-20 | > [IW][http-nio-21101-exec-20]: hit exception updating document | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,933 | INFO | http-nio-21101-exec-20 | > [IW][http-nio-21101-exec-20]: hit tragic FileSystemException inside > updateDocument | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,933 | INFO | http-nio-21101-exec-20 | > [IW][http-nio-21101-exec-20]: rollback | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,933 | INFO | http-nio-21101-exec-20 | > [IW][http-nio-21101-exec-20]: all running merges have aborted | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,934 | INFO | http-nio-21101-exec-20 | > [IW][http-nio-21101-exec-20]: rollback: done finish merges | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,934 | INFO | http-nio-21101-exec-20 | > [DW][http-nio-21101-exec-20]: abort | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,939 | INFO | commitScheduler-46-thread-1 | > [DWPT][commitScheduler-46-thread-1]: flush postings as segment _4h9 > numDocs=3798 | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,940 | INFO | commitScheduler-46-thread-1 | > [DWPT][commitScheduler-46-thread-1]: now abort | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,940 | INFO | commitScheduler-46-thread-1 | > [DWPT][commitScheduler-46-thread-1]: done abort | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,940 | INFO | http-nio-21101-exec-20 | > [DW][http-nio-21101-exec-20]: done abort success=true | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,940 | INFO | commitScheduler-46-thread-1 | > [DW][commitScheduler-46-thread-1]: commitScheduler-46-thread-1 > finishFullFlush success=false | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,940 | INFO | http-nio-21101-exec-20 | > [IW][http-nio-21101-exec-20]: rollback: > infos=_4g7(6.2.0):C59169/23684:delGen=4 _4gq(6.2.0):C67474/11636:delGen=1 > _4gg(6.2.0):C64067/15664:delGen=2 _4gr(6.2.0):C13131 _4gs(6.2.0):C966 > _4gt(6.2.0):C4543 _4gu(6.2.0):C6960 _4gv(6.2.0):C2544 | > org.apache.solr.update.LoggingInfoStream.message(LoggingInfoStream.java:34) > 2016-12-01 14:13:00,940 | INFO | commitScheduler-46-thread-1 | > [IW][commitScheduler-46-thread-1]: hit exception during NRT reader | >
[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10
[ https://issues.apache.org/jira/browse/SOLR-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894836#comment-15894836 ] Frank Kelly commented on SOLR-9386: --- Is it rude of my to suggest we look at SOLR-8346 and focus efforts on Zookeeper 3.5? There are a number of DNS issues fixed since 3.4.8 apparently that would be really awesome for our Production Solr Clusters https://issues.apache.org/jira/browse/ZOOKEEPER-1576 fixed in 3.5.0 https://issues.apache.org/jira/browse/ZOOKEEPER-2171 fixed in 3.5.1 (dupe of https://issues.apache.org/jira/browse/ZOOKEEPER-2367) Alternatively is there any way to request those bugs be back ported? > Upgrade Zookeeper to 3.4.10 > --- > > Key: SOLR-9386 > URL: https://issues.apache.org/jira/browse/SOLR-9386 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe > Attachments: SOLR-9386.patch, > zookeeper-3.4.8-upgrade-tests-pass.patch, > zookeeper-3.4.9-upgrade-tests-fail.patch > > > Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue > blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted > patch that fixes the test failures problem noted on SOLR-8724. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894832#comment-15894832 ] Frank Kelly commented on SOLR-8346: --- There are a number of DNS issues fixed since 3.4.8 apparently that would be really awesome for our Production Solr Clusters https://issues.apache.org/jira/browse/ZOOKEEPER-1576 fixed in 3.5.0 https://issues.apache.org/jira/browse/ZOOKEEPER-2171 fixed in 3.5.1 (dupe of https://issues.apache.org/jira/browse/ZOOKEEPER-2367) > Upgrade Zookeeper to version 3.5.1 > -- > > Key: SOLR-8346 > URL: https://issues.apache.org/jira/browse/SOLR-8346 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Jan Høydahl > Labels: security, zookeeper > Fix For: 6.0 > > Attachments: SOLR_8346.patch > > > Investigate upgrading ZooKeeper to 3.5.1, once released. Primary motivation > for this is SSL support. Currently a 3.5.1-alpha is released. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8173) CLONE - Leader recovery process can select the wrong leader if all replicas for a shard are down and trying to recover as well as lose updates that should have been reco
[ https://issues.apache.org/jira/browse/SOLR-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894821#comment-15894821 ] Frank Kelly commented on SOLR-8173: --- I agree. This is a critical problem when ZooKeeper and Solr disagree as who the leader there needs to be a winner rather stay in some unrecoverable state. Even if it just randomly picked one shard - a fully operational but slightly "off" search index is better than no index at all. > CLONE - Leader recovery process can select the wrong leader if all replicas > for a shard are down and trying to recover as well as lose updates that > should have been recovered. > --- > > Key: SOLR-8173 > URL: https://issues.apache.org/jira/browse/SOLR-8173 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Matteo Grolla >Assignee: Mark Miller >Priority: Critical > Labels: leader, recovery > Attachments: solr_8983.log, solr_8984.log > > > I'm doing this test > collection test is replicated on two solr nodes running on 8983, 8984 > using external zk > initially both nodes are empty > 1)turn on solr 8983 > 2)add,commit a doc x con solr 8983 > 3)turn off solr 8983 > 4)turn on solr 8984 > 5)shortly after (leader still not elected) turn on solr 8983 > 6)8984 is elected as leader > 7)doc x is present on 8983 but not on 8984 (check issuing a query) > In attachment are the solr.log files of both instances -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6392) If run Solr having two collections configured but only one config delivered to Zookeeper causes that config is applied for all collections
[ https://issues.apache.org/jira/browse/SOLR-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035192#comment-15035192 ] Frank Kelly commented on SOLR-6392: --- Was there ever a resolution to this - either a code issue or a user error. I think I am seeing this also (working through the user list right now) > If run Solr having two collections configured but only one config delivered > to Zookeeper causes that config is applied for all collections > -- > > Key: SOLR-6392 > URL: https://issues.apache.org/jira/browse/SOLR-6392 > Project: Solr > Issue Type: Bug >Affects Versions: 4.4 >Reporter: Ilya Meleshkov > > I have simplest Solr cloud configured locally. Thus I have single Solr and > Zookeeper nodes. > Steps to reproduce an error: > # have stopped Solr+ZK with two collections > # run ZK > # deliver config to one collection only > # run Solr - Solr running without any complains or errors > # deliver config to second collection - doesn't have an effect > But if I deliver configs for both collections before start Solr - it work > perfectly. > So I would say that Solr should fail with meaningful error if there is no > config for some collection. -- This message was sent by Atlassian JIRA (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-5129) If zookeeper is down, SolrCloud nodes will not start correctly, even if zookeeper is started later
[ https://issues.apache.org/jira/browse/SOLR-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026031#comment-15026031 ] Frank Kelly commented on SOLR-5129: --- My 2 cents - An Enterprise-class service should be "self-healing" when the problem (ZooKeeper state) is resolved. > If zookeeper is down, SolrCloud nodes will not start correctly, even if > zookeeper is started later > -- > > Key: SOLR-5129 > URL: https://issues.apache.org/jira/browse/SOLR-5129 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.4 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 4.9, Trunk > > > Summary of report from user on mailing list: > If zookeeper is down or doesn't have quorum when you start Solr nodes, they > will not function correctly, even if you later start zookeeper. While > zookeeper is down, the log shows connection failures as expected. When > zookeeper comes back, the log shows: > INFO - 2013-08-09 15:48:41.528; > org.apache.solr.common.cloud.ConnectionManager; Client->ZooKeeper status > change trigger but we are already closed > At that point, Solr (admin UI and all other functions) does not work, and > won't work until it is restarted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
