[GitHub] [lucene-solr] deanpearce commented on pull request #2456: SOLR-15216 Fix for Invalid Reference to data.followers in Admin UI
deanpearce commented on pull request #2456: URL: https://github.com/apache/lucene-solr/pull/2456#issuecomment-791980444 Thanks for the reminder, done. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9027) Add GraphTermsQuery to limit traversal on high frequency nodes
[
https://issues.apache.org/jira/browse/SOLR-9027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17296594#comment-17296594
]
David Smiley commented on SOLR-9027:
I was looking back at {{GraphTermsQuery}} today during the course analyzing
usages of non-cached filters. It occurred to me that we didn't need yet
another query parser to name. To the user, this is semantically equivalent as
the existing {{terms}} query parser with the added feature of an optional
{{maxDocFreq}}. We still need the code that was written here, however. Also,
the name "graph" in this QP seems a bit strange. Yes, it's useful for higher
level graph operations but that doesn't mean the query itself (low level) is
doing any graph traversal -- it isn't.
> Add GraphTermsQuery to limit traversal on high frequency nodes
> --
>
> Key: SOLR-9027
> URL: https://issues.apache.org/jira/browse/SOLR-9027
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9027.patch, SOLR-9027.patch, SOLR-9027.patch,
> SOLR-9027.patch
>
>
> The gatherNodes() Streaming Expression is currently using a basic disjunction
> query to perform the traversals. This ticket is to create a specific
> GraphTermsQuery for performing the traversals.
> The GraphTermsQuery will be based off of the TermsQuery, but will also
> include an option for a docFreq cutoff. Terms that are above the docFreq
> cutoff will not be included in the query. This will help users do a more
> precise and efficient traversal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15223) Deprecate HttpSolrClient, mark httpcomponents dep as "optional" in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-15223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-15223: Priority: Blocker (was: Major) > Deprecate HttpSolrClient, mark httpcomponents dep as "optional" in SolrJ > > > Key: SOLR-15223 > URL: https://issues.apache.org/jira/browse/SOLR-15223 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: David Smiley >Priority: Blocker > Fix For: master (9.0) > > > Solr has had an HTTP/2 based SolrClient since 8.0. Maintaining both HTTP/1 > and HTTP/2 clients is a pain for maintenance of the project as it sometimes > means duplicative (or partially implemented) work, especially for > authentication but also sometimes metrics or tracing. Both adds extra > dependencies for SolrJ and thus our users. It's difficult to grok a codebase > using two different HTTP client frameworks. > In this issue, mark HttpSolrClient (and related ones) as deprecated; point to > HTTP/2 equivalents. Furthermore, mark the Apache "httpcomponents" libs as > "optional" in the produced Maven pom.xml so that users have to explicitly > opt-in to use it. Announce this in the Solr users list as well. > Out of scope to this issue is completely cutting over within Solr itself. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15045) 2x latency of synchronous commits due to serial execution on local and distributed leaders
[
https://issues.apache.org/jira/browse/SOLR-15045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-15045:
Summary: 2x latency of synchronous commits due to serial execution on local
and distributed leaders (was: Commit through curl command is causing delay in
issuing commit)
> 2x latency of synchronous commits due to serial execution on local and
> distributed leaders
> --
>
> Key: SOLR-15045
> URL: https://issues.apache.org/jira/browse/SOLR-15045
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 8.5.2
> Environment: Operating system: Linux (centos 7.7.1908)
>Reporter: Raj Yadav
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi All,
> When we issue commit through curl command, not all the shards are getting
> `start commit` requests at the same time.
> *Solr Setup Detail : (Running in solrCloud mode)*
> It has 6 shards, and each shard has only one replica (which is also a
> leader) and the replica type is NRT.
> Each shards are hosted on the separate physical host.
> Zookeeper => We are using external zookeeper ensemble (3 separate node
> cluster)
> *Shard and Host name*
> shard1_0=>solr_199
> shard1_1=>solr_200
> shard2_0=> solr_254
> shard2_1=> solr_132
> shard3_0=>solr_133
> shard3_1=>solr_198
> *Request rate on the system is currently zero and only hourly indexing*
> *running on it.*
> We are using curl command to issue commit.
> {code:java}
> curl
> "http://solr_254:8389/solr/my_collection/update?openSearcher=true&commit=true&wt=json"{code}
> (Using solr_254 host to issue commit)
> On using the above command all the shards have started processing commit (i.e
> getting `start commit` request) except the one used in curl command (i.e
> shard2_0 which is hosted on solr_254). Individually each shards takes around
> 10 to 12 min to process hard commit (most of this time is spent on reloading
> external files).
> As per logs, shard2_0 is getting `start commit` request after 10 minutes
> (approx). This leads to following timeout error.
> {code:java}
> 2020-12-06 18:47:47.013 ERROR
> org.apache.solr.client.solrj.SolrServerException: Timeout occured while
> waiting response from server at:
> http://solr_132:9744/solr/my_collection_shard2_1_replica_n21/update?update.distrib=TOLEADER&distrib.from=http%3A%2F%2Fsolr_254%3A9744%2Fsolr%2Fmy_collection_shard2_0_replica_n11%2F
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:407)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:753)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient.request(ConcurrentUpdateHttp2SolrClient.java:369)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1290)
> at
> org.apache.solr.update.SolrCmdDistributor.doRequest(SolrCmdDistributor.java:344)
> at
> org.apache.solr.update.SolrCmdDistributor.lambda$submit$0(SolrCmdDistributor.java:333)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:180)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.concurrent.TimeoutException
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:216)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:398)
> ... 13 more{code}
> Above timeout error is between solr_254 and solr_132. Similar errors are
> there between solr_254 and other 4 shards
> Since query load is zero, mostly CPU utilization is around 3%.
> After issuing curl commit command, CPU goes up to 14% on all shards except
> shard2_0 (host: solr_254, the one used in curl command).
> And after 10 minutes (i.e after getting the `start commit` request) CPU on
> shard2_0 also goes up to 14%.
> As I mentioned earlier each shards take around 10-12 mins to process commit
> and due to delay in starting commit process on one shard (shard2_0) our
> overall commit time is doubled now. (22-24 minutes approx).
> *We are observing this delay in both hard and soft commit.*
> In our solr-5.4.0(having sim
[jira] [Resolved] (SOLR-14840) Convert Overseer Google doc to asciidoc for addition to Git repo
[
https://issues.apache.org/jira/browse/SOLR-14840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilan Ginzburg resolved SOLR-14840.
--
Resolution: Fixed
Doc is
[here|https://github.com/apache/lucene-solr/blob/master/solr/dev-docs/overseer/overseer.adoc]
> Convert Overseer Google doc to asciidoc for addition to Git repo
>
>
> Key: SOLR-14840
> URL: https://issues.apache.org/jira/browse/SOLR-14840
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Back in April [~ilan] shared via the mailing list a Google doc he had written
> which provided extensive documentation of the Overseer. It's an impressive
> document, and one we should preserve in the repo for other developers to use.
> I recently offered to convert the Google doc to Asciidoc format to add it to
> the {{solr/dev-docs}} directory, so this issue is mostly so I can make a
> branch for Ilan (and others) to review.
> Mailing list thread:
> https://lists.apache.org/thread.html/rf41ae1356bd2e4e68b3c3d835c5e368493ae0ee14a024402c88c795e%40%3Cdev.lucene.apache.org%3E
> Original Google doc:
> https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/edit
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
