[jira] [Commented] (SOLR-16872) Support split shards in distributed join

[Ilan Ginzburg (Jira)]

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

Ilan Ginzburg commented on SOLR-16872:
--

If before split the colocation constraint holds (i.e. "from" replicas covering 
the range of "to" replicas on every node where there are "to" replicas), right 
after split of a shard of either collection it still holds given split occurs 
on the node and does not change the total range on that node nor on other nodes.
Moving replicas around post split can be considered separate from the split, 
and such moves should only be allowed for such collections if they do not break 
the constraint above.
This might mean not being able to delete "from" replicas from a node if 
coverage would be missing for an existing "to" replica on that node (but a new 
"from" replica can always be added to another node), and not allowing a "to" 
replica to be added to a new node if that new node doesn't already have the 
required "from" replicas to cover the "to" replica being added.

> Support split shards in distributed join 
> -
>
> Key: SOLR-16872
> URL: https://issues.apache.org/jira/browse/SOLR-16872
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Priority: Major
>
> SOLR-16717 introduced join of collocated multishard collections
> Here I want to support this operation after shard was split
> cc [~ilan]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[GitHub] [solr] epugh commented on pull request #1784: SOLR-16842: Make "version" just another Tool.

[via GitHub]

epugh commented on PR #1784:
URL: https://github.com/apache/solr/pull/1784#issuecomment-1643679668

   Ouch!That makes sense now that I look.   I thought that the PostTool
   had been back ported to 9x….  I need to look again at the discussion thread
   on what we decided, maybe 10x only….
   
   I have minimal laptop access till Saturday.  If you want to revert this
   commit that would be great and I can redo when I get online.
   
   On Wed, Jul 19, 2023 at 1:15 PM patsonluk ***@***.***> wrote:
   
   > 👋🏼 @epugh  it seems like this change
   > 
https://github.com/apache/solr/blob/branch_9x/solr/core/src/java/org/apache/solr/cli/SolrCLI.java#L243
   > has been merged into branch_9x as b37bf8f
   > 

   > but the actual PostTool.java (from #1634
   > ) is missing in branch_9x
   >
   > —
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Mark Robert Miller (Jira)]

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

Mark Robert Miller commented on SOLR-16812:
---

If you took these benchmarks and data points for this case into a serious room, 
you’d be ignored or kicked out; it’s worth noting since I don’t see any comment 
acknowledging awareness of how misleading a cherry-pick they are. Not that 
you’d JSON complain, it comes off looking relatively fabulous. 

It’s never really the work itself that scares you, either terrible or 
excellent, it’s when there is a lack of communication that indicates one has 
some grasp and idea about what there is to be done and what they have done. You 
lay out those cards, and even the most rushed code or worst implementation 
becomes palatable. 

It’s when you just say, I’ve benchmarked this thing, here is a little data 
point, here is a big one, (two synthetic benchmarks that I’m happy to extend as 
a given for the sake of argument, as being of the type the JMH team themselves 
gold star review), conclusion therefore ABC. You can find the little code here 
and the big code there and try it yourself if you need.  Case closed, ship. 

Now that’s scary. 

Wait what? No mention at all about a realistic gauge of what should be done 
here and what was? Even the mention, and it’s like all the work saved but still 
the ghosts die. “Ok, at least they know what they are doing. I may not agree 
with it, but they know what they are doing.”

You could just go look at how someone involved in a real binary protocol 
project would approach any kind of even minimal comparison around performance, 
and this comparison would look like 99% of those Elastic vs Solr shootouts 
where a super fan pits a formula one-car against a NASCAR and does some super 
fan mechanical tweaking to make a “fair” comparison. We loaded each one up, we 
pulled back hard, let her rip, and you won’t believe what one defaults to a 
straight-up query cache. The winner of course.”

If you took this as a PR to anyone involved in any of these protocols, you 
would get back a Hossman level of bullet points and a professors level of 
projected content.

Don’t need benchmarks reasonable to the change to be on board with Solr getting 
out of the binary protocol business though. You could tell me it’s to something 
you properly benchmarked slower and I’d still be +1 on CBOR, CaptainJackProto 
Hack, or anything you named. 

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-16812:
---

It's an opt-in format which should have zero impact on the rest of Solr.. If 
you think the performance is slower, please share your findings. 

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya commented on SOLR-16812:
-


> If you took these benchmarks and data points for this case into a serious 
> room, you’d be ignored or kicked out

Noble is thick skinned and I love you, Mark. But you might not get away with 
all this with others, since they might deem it a code of conduct violation. I 
welcome strong criticism and immune to rough language being used, but I don't 
want you to be targeted by other soft people for using language like this. You 
are too valuable a member of Solr community to fall prey to political 
correctness strikes that PMC threatens to take for COC violations. 

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Comment Edited] (SOLR-16812) Support CBOR format for update/query

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya edited comment on SOLR-16812 at 7/20/23 1:40 PM:
--

bq. If you took these benchmarks and data points for this case into a serious 
room, you’d be ignored or kicked out

Noble is thick skinned and I love you, Mark. But you might not get away with 
all this with others, since they might deem it a code of conduct violation. I 
welcome strong criticism and immune to rough language being used, but I don't 
want you to be targeted by other soft people for using language like this. You 
are too valuable a member of Solr community to fall prey to political 
correctness strikes that PMC threatens to take for COC violations. 


was (Author: ichattopadhyaya):

> If you took these benchmarks and data points for this case into a serious 
> room, you’d be ignored or kicked out

Noble is thick skinned and I love you, Mark. But you might not get away with 
all this with others, since they might deem it a code of conduct violation. I 
welcome strong criticism and immune to rough language being used, but I don't 
want you to be targeted by other soft people for using language like this. You 
are too valuable a member of Solr community to fall prey to political 
correctness strikes that PMC threatens to take for COC violations. 

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-16812:
---

Yes, anyone else would have reported such a comment for CoC violations. 

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Jason Gerlowski (Jira)]

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

Jason Gerlowski commented on SOLR-16812:


bq. If you think the performance is slower, please share your findings.

I don't think Mark is making a claim about the performance one way or another; 
I think his concern is more around "process".

There was no attempt here to reach consensus on what should be tested  (e.g. 
the range of data sizes, numDocs, distribution of field types, etc.) prior to 
doing the tests.  There was no real detailed description of what the tests did 
(beyond a "I used this batch size and here's the code if you'd like").  And 
when folks did read the code and had questions/concerns, they [mostly went 
ignored|https://github.com/apache/solr/pull/1655#discussion_r1218294026].

I think CBOR is a Great Thing for Solr, because it gets us closer to getting 
out of the custom-binary-format business.  I'm all for it.  But I think there 
were real process lapses that Mark is gesturing towards here.

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Comment Edited] (SOLR-16812) Support CBOR format for update/query

[Jason Gerlowski (Jira)]

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

Jason Gerlowski edited comment on SOLR-16812 at 7/20/23 2:07 PM:
-

bq. If you think the performance is slower, please share your findings.

I don't think Mark is making a claim about the performance one way or another; 
I think his concern is more around "process".

There was no attempt here to reach consensus on what should be tested  (e.g. 
the range of data sizes, numDocs, distribution of field types, etc.) prior to 
doing the tests.  There was no real detailed description of what the tests did 
(beyond a "I used this batch size and here's the code if you'd like").  And 
when folks did read the code and had questions/concerns, they [weren't ever 
addressed|https://github.com/apache/solr/pull/1655#discussion_r1218294026].

I think CBOR is a Great Thing for Solr, because it gets us closer to getting 
out of the custom-binary-format business.  I'm all for it.  But I think there 
were real process lapses that Mark is gesturing towards here.


was (Author: gerlowskija):
bq. If you think the performance is slower, please share your findings.

I don't think Mark is making a claim about the performance one way or another; 
I think his concern is more around "process".

There was no attempt here to reach consensus on what should be tested  (e.g. 
the range of data sizes, numDocs, distribution of field types, etc.) prior to 
doing the tests.  There was no real detailed description of what the tests did 
(beyond a "I used this batch size and here's the code if you'd like").  And 
when folks did read the code and had questions/concerns, they [mostly went 
ignored|https://github.com/apache/solr/pull/1655#discussion_r1218294026].

I think CBOR is a Great Thing for Solr, because it gets us closer to getting 
out of the custom-binary-format business.  I'm all for it.  But I think there 
were real process lapses that Mark is gesturing towards here.

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Comment Edited] (SOLR-16812) Support CBOR format for update/query

[Jason Gerlowski (Jira)]

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

Jason Gerlowski edited comment on SOLR-16812 at 7/20/23 2:10 PM:
-

bq. If you think the performance is slower, please share your findings.

I don't think Mark is making a claim about the performance one way or another; 
I think his concern is more around "process".

There was no attempt here to reach consensus on what should be tested  (e.g. 
the range of data sizes, numDocs, distribution of field types, etc.) prior to 
doing the tests.  There was no real detailed description of what the tests did 
(beyond a "I used this batch size and here's the code if you'd like").  And 
when folks did read the code and had questions/concerns, they [weren't ever 
addressed|https://github.com/apache/solr/pull/1655#discussion_r1218294026].

I think CBOR is a Great Thing for Solr, because it gets us closer to getting 
out of the custom-binary-format business.  I'm all for it.  But I think there 
were real process lapses that Mark is gesturing towards here that we should aim 
to improve on future performance-related tickets.


was (Author: gerlowskija):
bq. If you think the performance is slower, please share your findings.

I don't think Mark is making a claim about the performance one way or another; 
I think his concern is more around "process".

There was no attempt here to reach consensus on what should be tested  (e.g. 
the range of data sizes, numDocs, distribution of field types, etc.) prior to 
doing the tests.  There was no real detailed description of what the tests did 
(beyond a "I used this batch size and here's the code if you'd like").  And 
when folks did read the code and had questions/concerns, they [weren't ever 
addressed|https://github.com/apache/solr/pull/1655#discussion_r1218294026].

I think CBOR is a Great Thing for Solr, because it gets us closer to getting 
out of the custom-binary-format business.  I'm all for it.  But I think there 
were real process lapses that Mark is gesturing towards here.

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[GitHub] [solr-operator] anilkhichar opened a new issue, #593: Could not find a backup repository with name `solr-backup-s3-repo`

[via GitHub]

anilkhichar opened a new issue, #593:
URL: https://github.com/apache/solr-operator/issues/593

   Please suggest any pointers for debugging. 
   
   Is there any API where we can get the list of SolrOperator registered backup 
repositories?
   Also, for S3 backup, does the Operator first download the backup data on 
disk and then execute the S3 cp/sync? 
   
   Any internal detail would be helpful to debug the core issue.
   
   **Error:**
   ```
   2023-07-18T23:18:54.905Z
   ERROR   controller-runtime.manager.controller.solrbackup
   Error while taking SolrCloud backup 
   {"reconciler group": "solr.apache.org", 
   "reconciler kind": "SolrBackup",
"name": "solr-backup", 
   "namespace": "ns-solrcloud-int", 
   "error": "Received bad response code of 500 from solr with response: 
   {\n  \"responseHeader\":
   {\n\"status\":500,\n\"QTime\":0},\n  \"error\":{\n
   \"msg\":\"Could not find a backup repository with name solr-backup-s3-repo\",
   \n\"trace\":\"java.lang.NullPointerException: 
   Could not find a backup repository with name solr-backup-s3-repo\\
   n\\tat 
   java.base/java.util.Objects.requireNonNull(Unknown Source)\\n\\
   tat org.apache.solr.core.backup.repository.
   BackupRepositoryFactory.newInstance(BackupRepositoryFactory.java:74)
   ```
   
   
   - **Solrbackup Setup**
   `kubectl edit solrcloud solrsetup`
   
 ```
 backupRepositories:
 - name: "solr-backup-s3-repo"
   s3:
 region: "us-west-2"
 bucket: ""
 ```
   
   - **SolrBackup**
 ```
 ---
 apiVersion: solr.apache.org/v1beta1
 kind: SolrBackup
 metadata:
   name: "solr-backup"
 spec:
   repositoryName: "solr-backup-s3-repo"
   solrCloud: "solrsetup"
   collections:
 - mycollection
 ```


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr-operator] HoustonPutman commented on issue #593: Could not find a backup repository with name `solr-backup-s3-repo`

[via GitHub]

HoustonPutman commented on issue #593:
URL: https://github.com/apache/solr-operator/issues/593#issuecomment-1644070170

   What version of Solr are you running? The Solr Operator just enables use of 
the existing Solr Backup repositories: 
https://solr.apache.org/guide/solr/latest/deployment-guide/backup-restore.html#backuprestore-storage-repositories
   
   The S3 Backup Repository was added in 8.10 or 8.9, and is not supported for 
versions before that.


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr-operator] anilkhichar commented on issue #593: Could not find a backup repository with name `solr-backup-s3-repo`

[via GitHub]

anilkhichar commented on issue #593:
URL: https://github.com/apache/solr-operator/issues/593#issuecomment-1644229419

   Thank you @HoustonPutman for looking into this.
   
   We are using Solr 9.2.0 with SolrOperator 0.5.1.


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr-operator] HoustonPutman commented on issue #593: Could not find a backup repository with name `solr-backup-s3-repo`

[via GitHub]

HoustonPutman commented on issue #593:
URL: https://github.com/apache/solr-operator/issues/593#issuecomment-1644233084

   Can you provide your full SolrCloud specification? Are you using a custom 
solr xml, if so then you will need to add the backup repository yourself.


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr] patsonluk commented on pull request #1784: SOLR-16842: Make "version" just another Tool.

[via GitHub]

patsonluk commented on PR #1784:
URL: https://github.com/apache/solr/pull/1784#issuecomment-1644334031

   @epugh Would it work if we have this PR to remove it from branch_9x? 😊  
https://github.com/apache/solr/pull/1799


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr] patsonluk opened a new pull request, #1799: SOLR-16842: Remove reference to PostTool for branch_9x

[via GitHub]

patsonluk opened a new pull request, #1799:
URL: https://github.com/apache/solr/pull/1799

   # Description
   
   A merge from master to branch_9x includes reference to `PostTool` which is 
not available in 9x
   
   
   # Solution
   
   Removed the reference to `PostTool`. This branch is based on branch_9x
   
   


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya commented on SOLR-16812:
-

Reasonable benchmarks are posted here: 
https://issues.apache.org/jira/browse/SOLR-16812?focusedCommentId=17729700&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17729700

and here: 
https://issues.apache.org/jira/browse/SOLR-16841?focusedCommentId=17731859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17731859

These should've been sufficient to address your concerns. Total of three 
different types of benchmarks were performed all together, for an optional 
format! Feel free to add more benchmarks, it is an open source project.

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Comment Edited] (SOLR-16812) Support CBOR format for update/query

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya edited comment on SOLR-16812 at 7/20/23 7:02 PM:
--

Reasonable benchmarks are posted here: Solr-bench: 
https://issues.apache.org/jira/browse/SOLR-16812?focusedCommentId=17729700&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17729700

and here: JMH:https://github.com/apache/solr/pull/1705#issue-1753984681 and 
 
https://issues.apache.org/jira/browse/SOLR-16841?focusedCommentId=17731859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17731859

These should've been sufficient to address your concerns. Total of three 
different types of benchmarks were performed all together, for an optional 
format! Feel free to add more benchmarks, it is an open source project.


was (Author: ichattopadhyaya):
Reasonable benchmarks are posted here: 
https://issues.apache.org/jira/browse/SOLR-16812?focusedCommentId=17729700&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17729700

and here: 
https://issues.apache.org/jira/browse/SOLR-16841?focusedCommentId=17731859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17731859

These should've been sufficient to address your concerns. Total of three 
different types of benchmarks were performed all together, for an optional 
format! Feel free to add more benchmarks, it is an open source project.

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[GitHub] [solr] HoustonPutman merged pull request #1799: SOLR-16842: Remove reference to PostTool for branch_9x

[via GitHub]

HoustonPutman merged PR #1799:
URL: https://github.com/apache/solr/pull/1799


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[jira] [Commented] (SOLR-16842) Eliminate special case code in solrCLI by introducing VersionTool

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-16842:


Commit 84c2c3e1bd986bff87de56a6667323a85ce1e2d5 in solr's branch 
refs/heads/branch_9x from patsonluk
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=84c2c3e1bd9 ]

SOLR-16842: Remove reference to PostTool for branch_9x (#1799)



> Eliminate special case code in solrCLI by introducing VersionTool
> -
>
> Key: SOLR-16842
> URL: https://issues.apache.org/jira/browse/SOLR-16842
> Project: Solr
>  Issue Type: Sub-task
>  Components: cli
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: main (10.0), 9.4
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[GitHub] [solr] HoustonPutman commented on pull request #1799: SOLR-16842: Remove reference to PostTool for branch_9x

[via GitHub]

HoustonPutman commented on PR #1799:
URL: https://github.com/apache/solr/pull/1799#issuecomment-1644473617

   Ran precommit and integration tests locally, which both passed. Thanks 
@patsonluk !


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr] epugh commented on pull request #1799: SOLR-16842: Remove reference to PostTool for branch_9x

[via GitHub]

epugh commented on PR #1799:
URL: https://github.com/apache/solr/pull/1799#issuecomment-1644646005

   Thank you @HoustonPutman and @patsonluk for this!   


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[jira] [Commented] (SOLR-16812) Support CBOR format for update/query

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-16812:
---

{quote} I think his concern is more around "process".{quote}

Which process? Please point me to a documented process that was not followed.

> Support CBOR format for update/query
> 
>
> Key: SOLR-16812
> URL: https://issues.apache.org/jira/browse/SOLR-16812
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.3
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Javabin is quite efficient and fast . But non-java users have to use JSON 
> exclusively
>  
> [CBOR |http://example.com/] is a widely used format that is supported by most 
> languages. 
>  
> Here is a benchmark of updating using CBOR vs. JSON our films.json
> {code:java}
> Payload Size (bytes)
> 
>  
> json : 633600
> cbor : 210439  
> javabin: 234520
> time taken to index
> 
> JSON: 330ms
> JAVABIN: 216ms
> CBOR: 200ms
> time takes to query *:* 1100 docs
> ==
> json: 85 ms
> javabin : 64ms 
> cbor : 53ms{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[GitHub] [solr] dsmiley commented on a diff in pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

[via GitHub]

dsmiley commented on code in PR #1793:
URL: https://github.com/apache/solr/pull/1793#discussion_r1270167635


##
solr/solrj-model/src/test/org/apache/solr/model/DummyTest.java:
##
@@ -0,0 +1,11 @@
+package org.apache.solr.model;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.junit.Test;
+
+public class DummyTest extends SolrTestCaseJ4 {

Review Comment:
   Why was this added?



##
solr/solrj/build.gradle:
##
@@ -15,13 +15,82 @@
  * limitations under the License.
  */
 
+plugins {
+  id "org.openapi.generator" version "6.6.0"
+}
 
 apply plugin: 'java-library'
+apply plugin: 'com.diffplug.spotless'
+
+import com.diffplug.gradle.spotless.JavaExtension
+
 
 description = 'Solrj - Solr Java Client'
 
+configurations {
+  openApiSpecFile {
+canBeConsumed = false
+  }
+  generatedCode
+}
+
+tasks.register("copySpec", Copy) {
+  from("../solrj-model/build/generated/openapi")
+  into(layout.buildDirectory.dir("openapispec"))
+}
+
+def generatedExt = new JavaExtension(spotless)
+project.ext.spotlessJavaSetup.execute(generatedExt)
+generatedExt.target("build/generated/src/**/*.java")
+def generatedSpotlessTask = 
generatedExt.createIndependentApplyTask("generatedSpotless")
+generatedSpotlessTask.group("build")
+generatedSpotlessTask.description("Apply formatting for generated code")
+
+openApiGenerate {
+  generatorName = "java"
+  // TODO - pretty hacky to specify inputSpec this way...ideally I'd just rely 
on a property defined in
+  // solrj-model, as below, but it doesn't appear to be working
+  //inputSpec = project(":solr:solrj-model").ext.openapispecfile
+  inputSpec = "${buildDir}/openapispec/openapi.json"
+
+  // Add 'debugModels: ""' or 'debugOperations: ""' to get the JSON input to 
mustache templating for those components
+  globalProperties.set([modelDocs: "false", apis: "", models: ""])
+  templateDir = "$projectDir/src/resources/java-template"
+  apiPackage = "org.apache.solr.client.solrj.request"
+  modelPackage = "org.apache.solr.client.solrj.model"
+  outputDir = "${buildDir}/generated/"
+  generateApiTests = false
+  generateModelTests = false
+}
+
+tasks.getByName("copySpec").dependsOn 
configurations.getByName("openApiSpecFile")

Review Comment:
   Why do this in a dynamic/reflection-like way; why not explicitly do this at 
the point that copySpec is declared?



##
solr/solrj/src/java/org/apache/solr/common/util/ModelConstants.java:
##
@@ -0,0 +1,30 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.util;
+
+// TODO This probably shouldn't exist in a final product, but it's fine for a 
POC

Review Comment:
   Out practice has been the magic string "nocommit" which we prevent merging 
but I see you use "TODO"... could go unnoticed as we don't have tooling to 
point these out.  I use "TODO" in a loose way but here you meant nocommit I 
think



##
solr/solrj/build.gradle:
##
@@ -15,13 +15,82 @@
  * limitations under the License.
  */
 
+plugins {
+  id "org.openapi.generator" version "6.6.0"
+}
 
 apply plugin: 'java-library'
+apply plugin: 'com.diffplug.spotless'
+
+import com.diffplug.gradle.spotless.JavaExtension
+
 
 description = 'Solrj - Solr Java Client'
 
+configurations {
+  openApiSpecFile {
+canBeConsumed = false
+  }
+  generatedCode
+}
+
+tasks.register("copySpec", Copy) {
+  from("../solrj-model/build/generated/openapi")
+  into(layout.buildDirectory.dir("openapispec"))
+}
+
+def generatedExt = new JavaExtension(spotless)
+project.ext.spotlessJavaSetup.execute(generatedExt)
+generatedExt.target("build/generated/src/**/*.java")
+def generatedSpotlessTask = 
generatedExt.createIndependentApplyTask("generatedSpotless")
+generatedSpotlessTask.group("build")
+generatedSpotlessTask.description("Apply formatting for generated code")
+
+openApiGenerate {
+  generatorName = "java"
+  // TODO - pretty hacky to specify inputSpec this way...ideally I'd just rely 
on a property defined in
+  // solrj-model, as below, but it doesn't appear to be working
+  //inputSpec = project(":solr:solrj-model").ext.openapispecfile
+  inputSpec = "${buildDir}/openapispec/openapi.json"
+
+  // Add 'debugModels: ""' or 'debugOperations: ""' to

[GitHub] [solr] dsmiley commented on a diff in pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

[via GitHub]

dsmiley commented on code in PR #1793:
URL: https://github.com/apache/solr/pull/1793#discussion_r1270165715


##
solr/solrj/src/java/org/apache/solr/common/util/ModelConstants.java:
##
@@ -0,0 +1,30 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.util;
+
+// TODO This probably shouldn't exist in a final product, but it's fine for a 
POC

Review Comment:
   Our norm has been the magic string "nocommit" which we prevent merging but I 
see you use "TODO"... could go unnoticed as we don't have tooling to point 
these out.  I use "TODO" in a loose way but here you meant nocommit I think



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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [solr] patsonluk opened a new pull request, #1800: SOLR-16871: Synchronize on a larger block to avoid race condition in CoordinatorHttpSolrCall init

[via GitHub]

patsonluk opened a new pull request, #1800:
URL: https://github.com/apache/solr/pull/1800

   https://issues.apache.org/jira/browse/SOLR-16871
   
   
   # Description
   
   While the previous fix #1762  does seem to avoid race condition, 
unfortunately, it was still happening on some test runs, for example 
https://github.com/cowpaths/fullstory-solr/actions/runs/5616774664/job/15219717699
   
   The issue is that even we sync the `addReplica` block, we could still run 
into race condition if:
   1. Request 1 in Thread 1 hits node 1 and attempt to create synthetic 
collection
   2. Request 2 in Thread 2 also hits node 1, due to race condition it might 
attempt to create the synthetic collection too, but in this case it's fine as 
we ignore the creation exception if it's "already exists collection"
   3. Request 2 in Thread 2 can proceed and claim the synchronize block, it 
scans for replica and it might not see any, since Thread 1 might have only 
created the collection state.json but have not pushed the replica/shard update 
yet. Request 2 in this case would proceed and create replica on node 1
   4. Request 1 might continue with the synthetic collection creation and 
create a replica as well, now we have 2 replicas
   
   # Solution
   
   Synchronize on a larger block, this will likely be fine as it's still a very 
rare case that the synthetic collection does not exist.
   
   # Tests
   
   Unfortunately I cannot reliable reproduce the issue locally even without 
this current fix. I ran `./gradlew :solr:core:beast -Ptests.dups=50 --tests 
"org.apache.solr.search.TestCoordinatorRole.testConcurrentAccess" 
-Ptests.jvms=1 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC 
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" 
-Ptests.seed=D78D41A5AAFAB451 -Ptests.file.encoding=US-ASCII` and it ran around 
3x runs successfully, i interrupted it as it took too long
   
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [x] I have developed this patch against the `main` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


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

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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