[jira] [Commented] (SOLR-14034) remove deprecated min_rf references
[
https://issues.apache.org/jira/browse/SOLR-14034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248530#comment-17248530
]
Gaurav Agarwal commented on SOLR-14034:
---
Hello Christine,
I am new here and looking to contribute. Just wondering if this issue is still
open and available to be worked on? Seems like a good place to start.
> remove deprecated min_rf references
> ---
>
> Key: SOLR-14034
> URL: https://issues.apache.org/jira/browse/SOLR-14034
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Blocker
> Labels: newdev
> Fix For: master (9.0)
>
>
> * {{min_rf}} support was added under SOLR-5468 in version 4.9
> (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.9.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L50)
> and deprecated under SOLR-12767 in version 7.6
> (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.6.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L57-L61)
> * http://lucene.apache.org/solr/7_6_0/changes/Changes.html and
> https://lucene.apache.org/solr/guide/8_0/major-changes-in-solr-8.html#solr-7-6
> both clearly mention the deprecation
> This ticket is to fully remove {{min_rf}} references in code, tests and
> documentation.
--
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] [Created] (SOLR-15045) Commit through curl command is causing delay in issuing commit
Raj Yadav created SOLR-15045:
Summary: Commit through curl command is causing delay in issuing
commit
Key: SOLR-15045
URL: https://issues.apache.org/jira/browse/SOLR-15045
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud
Affects Versions: 8.5.2
Environment: Operating system: Linux (centos 7.7.1908)
Reporter: Raj Yadav
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 similar setup), we use similar command curl command
to issue commit and there all the shards are getting `start commit` request
at same time. Including the one used in curl command.
--
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) Commit through curl command is causing delay in issuing commit
[
https://issues.apache.org/jira/browse/SOLR-15045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raj Yadav updated SOLR-15045:
-
Description:
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 similar setup), we use the similar curl command to
issue commit, and there all the shards are getting `start commit` request at
same time. Including the one used in curl command.
was:
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://sol
[jira] [Comment Edited] (SOLR-14848) Demonstrate how Solr 8, master, or any version previous Solr version before pales next to the reference branch.
[ https://issues.apache.org/jira/browse/SOLR-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248722#comment-17248722 ] Mark Robert Miller edited comment on SOLR-14848 at 12/14/20, 2:58 AM: -- Well, I’ve slept all weekend, this kind of life style came much easier with a teenage body and natural inclination vs forced march. I’m essentially ready here, but I’m tired, blown out, etc etc. And I hate to look, but I’m guessing Xmas is tomorrow or something. So likely nothing to show until the new year. was (Author: markrmiller): Well, I’ve slept all weekend, this kind of life style came much easier with a teenage body and natural inclination for forced march. I’m essentially ready here, but I’m tired, blown out, etc etc. And I hate to look, but I’m guessing Xmas is tomorrow or something. So likely nothing to show until the new year. > Demonstrate how Solr 8, master, or any version previous Solr version before > pales next to the reference branch. > --- > > Key: SOLR-14848 > URL: https://issues.apache.org/jira/browse/SOLR-14848 > Project: Solr > Issue Type: Sub-task >Reporter: Mark Robert Miller >Priority: Major > > I've got a lot of code here and I have and will be claiming that it's an > order of magnitude better than what has come before. > I've been too busy and will be busy for a bit, so I have not been too > concerned about backing that up really at all. Most people have no clue what > I have here, some people have an inkling, some people are just totally > confused, some people think I maybe have some fast tests, or a slightly more > stable system, or maybe some neato performance changes, or even maybe some > poorly coded speed hacks. Maybe one or two has a more hope filled guess. > Almost everyone will think, "all that new code, mostly done by a single > person? I know a lot of smart and smarter devs, who cares what this guy is up > to. Why would I leave the safety of the branch I know and feel safe with? By > definition, the existing stuff is the battle hardened, tried and true leader, > and how are you going to come in here without disrupting our comfortable > thing?" > Well, fair enough. I won't try to come and disrupt anything. Instead, there > will be benchmarks, stress tests, chaos monkeys, long term endurance tests, > and all sorts of fun competitions. Spy vs Spy. I mean Solr vs Solr. > And while this vanilla version of my previous work has avoided a lot of great > changes and improvements I can make (a "remastered" Solr sensible, initial > mandate that puts a hand or two behind my back) ... > ... The reference branch will trounce previous versions of Solr in benchmark > after benchmark. It will keep pumping through endurance tests and performance > challenges at impressive speed while Solr proper will struggle to finish in a > reasonable time or almost certainly, often enough, simply fail to complete > the task. The reference branch will devour available resources and fly > through work. Solr master will struggle and meander, sometimes in the wrong > direction, while leaving the hardware with gobs of idle cpu to chill with > (unless it's using most of the cpu for garbage collection at some points). > This is not meant to brag or dis previous versions of Solr. I was heavily > involved in building them. This is the result of dedication and time more > than any of my brilliance - the above is simply meant to state the path that > I see coming. As this comparison information and other experiences and > stories start to emerge, that master branch won't look nearly so safe or > comfortable anymore. And it's at that point that we will find out if anyone > is interested in testing our tolerance for disruption by trying to figure out > how to get master into the reference branch as opposed to the other way > around. > > -- 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] [Commented] (SOLR-14848) Demonstrate how Solr 8, master, or any version previous Solr version before pales next to the reference branch.
[ https://issues.apache.org/jira/browse/SOLR-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248722#comment-17248722 ] Mark Robert Miller commented on SOLR-14848: --- Well, I’ve slept all weekend, this kind of life style came much easier with a teenage body and natural inclination for forced march. I’m essentially ready here, but I’m tired, blown out, etc etc. And I hate to look, but I’m guessing Xmas is tomorrow or something. So likely nothing to show until the new year. > Demonstrate how Solr 8, master, or any version previous Solr version before > pales next to the reference branch. > --- > > Key: SOLR-14848 > URL: https://issues.apache.org/jira/browse/SOLR-14848 > Project: Solr > Issue Type: Sub-task >Reporter: Mark Robert Miller >Priority: Major > > I've got a lot of code here and I have and will be claiming that it's an > order of magnitude better than what has come before. > I've been too busy and will be busy for a bit, so I have not been too > concerned about backing that up really at all. Most people have no clue what > I have here, some people have an inkling, some people are just totally > confused, some people think I maybe have some fast tests, or a slightly more > stable system, or maybe some neato performance changes, or even maybe some > poorly coded speed hacks. Maybe one or two has a more hope filled guess. > Almost everyone will think, "all that new code, mostly done by a single > person? I know a lot of smart and smarter devs, who cares what this guy is up > to. Why would I leave the safety of the branch I know and feel safe with? By > definition, the existing stuff is the battle hardened, tried and true leader, > and how are you going to come in here without disrupting our comfortable > thing?" > Well, fair enough. I won't try to come and disrupt anything. Instead, there > will be benchmarks, stress tests, chaos monkeys, long term endurance tests, > and all sorts of fun competitions. Spy vs Spy. I mean Solr vs Solr. > And while this vanilla version of my previous work has avoided a lot of great > changes and improvements I can make (a "remastered" Solr sensible, initial > mandate that puts a hand or two behind my back) ... > ... The reference branch will trounce previous versions of Solr in benchmark > after benchmark. It will keep pumping through endurance tests and performance > challenges at impressive speed while Solr proper will struggle to finish in a > reasonable time or almost certainly, often enough, simply fail to complete > the task. The reference branch will devour available resources and fly > through work. Solr master will struggle and meander, sometimes in the wrong > direction, while leaving the hardware with gobs of idle cpu to chill with > (unless it's using most of the cpu for garbage collection at some points). > This is not meant to brag or dis previous versions of Solr. I was heavily > involved in building them. This is the result of dedication and time more > than any of my brilliance - the above is simply meant to state the path that > I see coming. As this comparison information and other experiences and > stories start to emerge, that master branch won't look nearly so safe or > comfortable anymore. And it's at that point that we will find out if anyone > is interested in testing our tolerance for disruption by trying to figure out > how to get master into the reference branch as opposed to the other way > around. > > -- 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] [Commented] (SOLR-14827) Refactor schema loading to not use XPath
[ https://issues.apache.org/jira/browse/SOLR-14827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248784#comment-17248784 ] Noble Paul commented on SOLR-14827: --- I added a simple testcase to load multiple schema objects The time taken has come down from ~540ms to ~270ms > Refactor schema loading to not use XPath > > > Key: SOLR-14827 > URL: https://issues.apache.org/jira/browse/SOLR-14827 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Labels: perfomance > Time Spent: 2h 20m > Remaining Estimate: 0h > > XPath is slower compared to DOM. -- 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
