[jira] [Comment Edited] (SOLR-14354) HttpShardHandler send requests in async
[
https://issues.apache.org/jira/browse/SOLR-14354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202700#comment-17202700
]
Amrit Sarkar edited comment on SOLR-14354 at 9/26/20, 11:03 PM:
Hi [~caomanhdat], absolutely. Allow me to catch up with the comments above.
Please note - the toolbox built runs within Kubernetes on GCP (I will run
comparable tests on vanilla Solr docker the and patched version), hope that's
ok with everyone. Dat, I will sync with you on the ASF slack further if I have
specific questions.
was (Author: sarkaramr...@gmail.com):
Hi [~caomanhdat], absolutely. Allow me to catch up with the comments above.
Please note - the toolbox built runs within Kubernetes on GCP (I will run
comparable tests on vanilla Solr docker the and patched version), hope that's
ok with everyone. Dat, I will sync with you on the ASF slack further if I have
specific numbers.
> HttpShardHandler send requests in async
> ---
>
> Key: SOLR-14354
> URL: https://issues.apache.org/jira/browse/SOLR-14354
> Project: Solr
> Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (9.0), 8.7
>
> Attachments: image-2020-03-23-10-04-08-399.png,
> image-2020-03-23-10-09-10-221.png, image-2020-03-23-10-12-00-661.png
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> h2. 1. Current approach (problem) of Solr
> Below is the diagram describe the model on how currently handling a request.
> !image-2020-03-23-10-04-08-399.png!
> The main-thread that handles the search requests, will submit n requests (n
> equals to number of shards) to an executor. So each request will correspond
> to a thread, after sending a request that thread basically do nothing just
> waiting for response from other side. That thread will be swapped out and CPU
> will try to handle another thread (this is called context switch, CPU will
> save the context of the current thread and switch to another one). When some
> data (not all) come back, that thread will be called to parsing these data,
> then it will wait until more data come back. So there will be lots of context
> switching in CPU. That is quite inefficient on using threads.Basically we
> want less threads and most of them must busy all the time, because threads
> are not free as well as context switching. That is the main idea behind
> everything, like executor
> h2. 2. Async call of Jetty HttpClient
> Jetty HttpClient offers async API like this.
> {code:java}
> httpClient.newRequest("http://domain.com/path;)
> // Add request hooks
> .onRequestQueued(request -> { ... })
> .onRequestBegin(request -> { ... })
> // Add response hooks
> .onResponseBegin(response -> { ... })
> .onResponseHeaders(response -> { ... })
> .onResponseContent((response, buffer) -> { ... })
> .send(result -> { ... }); {code}
> Therefore after calling {{send()}} the thread will return immediately without
> any block. Then when the client received the header from other side, it will
> call {{onHeaders()}} listeners. When the client received some {{byte[]}} (not
> all response) from the data it will call {{onContent(buffer)}} listeners.
> When everything finished it will call {{onComplete}} listeners. One main
> thing that will must notice here is all listeners should finish quick, if the
> listener block, all further data of that request won’t be handled until the
> listener finish.
> h2. 3. Solution 1: Sending requests async but spin one thread per response
> Jetty HttpClient already provides several listeners, one of them is
> InputStreamResponseListener. This is how it is get used
> {code:java}
> InputStreamResponseListener listener = new InputStreamResponseListener();
> client.newRequest(...).send(listener);
> // Wait for the response headers to arrive
> Response response = listener.get(5, TimeUnit.SECONDS);
> if (response.getStatus() == 200) {
> // Obtain the input stream on the response content
> try (InputStream input = listener.getInputStream()) {
> // Read the response content
> }
> } {code}
> In this case, there will be 2 thread
> * one thread trying to read the response content from InputStream
> * one thread (this is a short-live task) feeding content to above
> InputStream whenever some byte[] is available. Note that if this thread
> unable to feed data into InputStream, this thread will wait.
> By using this one, the model of HttpShardHandler can be written into
> something like this
> {code:java}
> handler.sendReq(req, (is) -> {
> executor.submit(() ->
> try (is) {
> // Read the content from InputStream
> }
> )
> }) {code}
> The first diagram will be changed into this
>
[jira] [Commented] (SOLR-14354) HttpShardHandler send requests in async
[
https://issues.apache.org/jira/browse/SOLR-14354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202700#comment-17202700
]
Amrit Sarkar commented on SOLR-14354:
-
Hi [~caomanhdat], absolutely. Allow me to catch up with the comments above.
Please note - the toolbox built runs within Kubernetes on GCP (I will run
comparable tests on vanilla Solr docker the and patched version), hope that's
ok with everyone. Dat, I will sync with you on the ASF slack further on this.
> HttpShardHandler send requests in async
> ---
>
> Key: SOLR-14354
> URL: https://issues.apache.org/jira/browse/SOLR-14354
> Project: Solr
> Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (9.0), 8.7
>
> Attachments: image-2020-03-23-10-04-08-399.png,
> image-2020-03-23-10-09-10-221.png, image-2020-03-23-10-12-00-661.png
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> h2. 1. Current approach (problem) of Solr
> Below is the diagram describe the model on how currently handling a request.
> !image-2020-03-23-10-04-08-399.png!
> The main-thread that handles the search requests, will submit n requests (n
> equals to number of shards) to an executor. So each request will correspond
> to a thread, after sending a request that thread basically do nothing just
> waiting for response from other side. That thread will be swapped out and CPU
> will try to handle another thread (this is called context switch, CPU will
> save the context of the current thread and switch to another one). When some
> data (not all) come back, that thread will be called to parsing these data,
> then it will wait until more data come back. So there will be lots of context
> switching in CPU. That is quite inefficient on using threads.Basically we
> want less threads and most of them must busy all the time, because threads
> are not free as well as context switching. That is the main idea behind
> everything, like executor
> h2. 2. Async call of Jetty HttpClient
> Jetty HttpClient offers async API like this.
> {code:java}
> httpClient.newRequest("http://domain.com/path;)
> // Add request hooks
> .onRequestQueued(request -> { ... })
> .onRequestBegin(request -> { ... })
> // Add response hooks
> .onResponseBegin(response -> { ... })
> .onResponseHeaders(response -> { ... })
> .onResponseContent((response, buffer) -> { ... })
> .send(result -> { ... }); {code}
> Therefore after calling {{send()}} the thread will return immediately without
> any block. Then when the client received the header from other side, it will
> call {{onHeaders()}} listeners. When the client received some {{byte[]}} (not
> all response) from the data it will call {{onContent(buffer)}} listeners.
> When everything finished it will call {{onComplete}} listeners. One main
> thing that will must notice here is all listeners should finish quick, if the
> listener block, all further data of that request won’t be handled until the
> listener finish.
> h2. 3. Solution 1: Sending requests async but spin one thread per response
> Jetty HttpClient already provides several listeners, one of them is
> InputStreamResponseListener. This is how it is get used
> {code:java}
> InputStreamResponseListener listener = new InputStreamResponseListener();
> client.newRequest(...).send(listener);
> // Wait for the response headers to arrive
> Response response = listener.get(5, TimeUnit.SECONDS);
> if (response.getStatus() == 200) {
> // Obtain the input stream on the response content
> try (InputStream input = listener.getInputStream()) {
> // Read the response content
> }
> } {code}
> In this case, there will be 2 thread
> * one thread trying to read the response content from InputStream
> * one thread (this is a short-live task) feeding content to above
> InputStream whenever some byte[] is available. Note that if this thread
> unable to feed data into InputStream, this thread will wait.
> By using this one, the model of HttpShardHandler can be written into
> something like this
> {code:java}
> handler.sendReq(req, (is) -> {
> executor.submit(() ->
> try (is) {
> // Read the content from InputStream
> }
> )
> }) {code}
> The first diagram will be changed into this
> !image-2020-03-23-10-09-10-221.png!
> Notice that although “sending req to shard1” is wide, it won’t take long time
> since sending req is a very quick operation. With this operation, handling
> threads won’t be spin up until first bytes are sent back. Notice that in this
> approach we still have active threads waiting for more data from InputStream
> h2. 4. Solution 2: Buffering data and handle it inside jetty’s thread.
> Jetty have another listener called
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151128#comment-17151128 ] Amrit Sarkar commented on SOLR-14022: - FWIW I apologize for not able to fix issues and improve the CDCR module in Apache Solr. I vouch to contribute and assist respected committers to build and implement the best possible design with the capabilities I possess. > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- 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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014987#comment-17014987 ] Amrit Sarkar commented on SOLR-13845: - Generated PR request with the latest code, and documentation. > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Assignee: Shalin Shekhar Mangar >Priority: Major > Attachments: SOLR-13845.patch > > Time Spent: 10m > Remaining Estimate: 0h > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amrit Sarkar updated SOLR-13845: Attachment: SOLR-13845.patch > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Priority: Major > Attachments: SOLR-13845.patch > > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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] [Comment Edited] (SOLR-13843) MOVEREPLICA API in Solr doesn't respect Replica Type.
[
https://issues.apache.org/jira/browse/SOLR-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951171#comment-16951171
]
Amrit Sarkar edited comment on SOLR-13843 at 10/17/19 1:24 PM:
---
Thanks [~ctargett], I should have look for existing jiras before creating a new
one. We can safely close either one as duplicagte and patch is ready to serve
the fix for the problem.
was (Author: sarkaramr...@gmail.com):
Thanks [~ctargett], I should have look for existing jiras before creating a new
one. We can safely close either one as delete and patch is ready to serve the
fix for the problem.
> MOVEREPLICA API in Solr doesn't respect Replica Type.
> -
>
> Key: SOLR-13843
> URL: https://issues.apache.org/jira/browse/SOLR-13843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13843.patch
>
>
> MOVEREPLICA API in Solr creates NRT type replica in the target node always,
> no matter what type the source replica is. This leads to an inconsistent
> cluster state.
> MoveReplicaCmd
> {code}
> ZkNodeProps addReplicasProps = new ZkNodeProps(
> COLLECTION_PROP, coll.getName(),
> SHARD_ID_PROP, slice.getName(),
> CoreAdminParams.NODE, targetNode,
> CoreAdminParams.NAME, newCoreName);
> {code}
--
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] [Comment Edited] (SOLR-13843) MOVEREPLICA API in Solr doesn't respect Replica Type.
[
https://issues.apache.org/jira/browse/SOLR-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951171#comment-16951171
]
Amrit Sarkar edited comment on SOLR-13843 at 10/17/19 1:24 PM:
---
Thanks [~ctargett], I should have look for existing jiras before creating a new
one. We can safely close either one as duplicate and patch is ready to serve
the fix for the problem.
was (Author: sarkaramr...@gmail.com):
Thanks [~ctargett], I should have look for existing jiras before creating a new
one. We can safely close either one as duplicagte and patch is ready to serve
the fix for the problem.
> MOVEREPLICA API in Solr doesn't respect Replica Type.
> -
>
> Key: SOLR-13843
> URL: https://issues.apache.org/jira/browse/SOLR-13843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13843.patch
>
>
> MOVEREPLICA API in Solr creates NRT type replica in the target node always,
> no matter what type the source replica is. This leads to an inconsistent
> cluster state.
> MoveReplicaCmd
> {code}
> ZkNodeProps addReplicasProps = new ZkNodeProps(
> COLLECTION_PROP, coll.getName(),
> SHARD_ID_PROP, slice.getName(),
> CoreAdminParams.NODE, targetNode,
> CoreAdminParams.NAME, newCoreName);
> {code}
--
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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952956#comment-16952956 ] Amrit Sarkar commented on SOLR-13845: - Uploaded clean PATCH for the improvement. Requesting feedback. > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Priority: Major > Attachments: SOLR-13845.patch > > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amrit Sarkar updated SOLR-13845: Attachment: (was: STAR-13845.patch) > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Priority: Major > Attachments: SOLR-13845.patch > > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amrit Sarkar updated SOLR-13845: Attachment: SOLR-13845.patch > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Priority: Major > Attachments: SOLR-13845.patch, STAR-13845.patch > > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951287#comment-16951287 ] Amrit Sarkar commented on SOLR-13845: - Draft patch, I am working on creating a clean patch that can be applied on the master. > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Priority: Major > Attachments: STAR-13845.patch > > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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-13845) DELETEREPLICA API by "count" and "type"
[ https://issues.apache.org/jira/browse/SOLR-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amrit Sarkar updated SOLR-13845: Attachment: STAR-13845.patch > DELETEREPLICA API by "count" and "type" > --- > > Key: SOLR-13845 > URL: https://issues.apache.org/jira/browse/SOLR-13845 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Amrit Sarkar >Priority: Major > Attachments: STAR-13845.patch > > > SOLR-9319 added support for deleting replicas by count. It would be great to > have the feature with added functionality the type of replica we want to > delete like we add replicas by count and type. -- 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-13845) DELETEREPLICA API by "count" and "type"
Amrit Sarkar created SOLR-13845: --- Summary: DELETEREPLICA API by "count" and "type" Key: SOLR-13845 URL: https://issues.apache.org/jira/browse/SOLR-13845 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Amrit Sarkar SOLR-9319 added support for deleting replicas by count. It would be great to have the feature with added functionality the type of replica we want to delete like we add replicas by count and type. -- 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-13843) MOVEREPLICA API in Solr doesn't respect Replica Type.
[
https://issues.apache.org/jira/browse/SOLR-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951171#comment-16951171
]
Amrit Sarkar commented on SOLR-13843:
-
Thanks [~ctargett], I should have look for existing jiras before creating a new
one. We can safely close either one as delete and patch is ready to serve the
fix for the problem.
> MOVEREPLICA API in Solr doesn't respect Replica Type.
> -
>
> Key: SOLR-13843
> URL: https://issues.apache.org/jira/browse/SOLR-13843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-13843.patch
>
>
> MOVEREPLICA API in Solr creates NRT type replica in the target node always,
> no matter what type the source replica is. This leads to an inconsistent
> cluster state.
> MoveReplicaCmd
> {code}
> ZkNodeProps addReplicasProps = new ZkNodeProps(
> COLLECTION_PROP, coll.getName(),
> SHARD_ID_PROP, slice.getName(),
> CoreAdminParams.NODE, targetNode,
> CoreAdminParams.NAME, newCoreName);
> {code}
--
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-13843) MOVEREPLICA API in Solr doesn't respect Replica Type.
[
https://issues.apache.org/jira/browse/SOLR-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950902#comment-16950902
]
Amrit Sarkar commented on SOLR-13843:
-
Attached patch with tests, which make sure same type of replica is moved with
MOVEREPLICA API. Feedback welcome.
> MOVEREPLICA API in Solr doesn't respect Replica Type.
> -
>
> Key: SOLR-13843
> URL: https://issues.apache.org/jira/browse/SOLR-13843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-13843.patch
>
>
> MOVEREPLICA API in Solr creates NRT type replica in the target node always,
> no matter what type the source replica is. This leads to an inconsistent
> cluster state.
> MoveReplicaCmd
> {code}
> ZkNodeProps addReplicasProps = new ZkNodeProps(
> COLLECTION_PROP, coll.getName(),
> SHARD_ID_PROP, slice.getName(),
> CoreAdminParams.NODE, targetNode,
> CoreAdminParams.NAME, newCoreName);
> {code}
--
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-13843) MOVEREPLICA API in Solr doesn't respect Replica Type.
[
https://issues.apache.org/jira/browse/SOLR-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-13843:
Attachment: SOLR-13843.patch
> MOVEREPLICA API in Solr doesn't respect Replica Type.
> -
>
> Key: SOLR-13843
> URL: https://issues.apache.org/jira/browse/SOLR-13843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-13843.patch
>
>
> MOVEREPLICA API in Solr creates NRT type replica in the target node always,
> no matter what type the source replica is. This leads to an inconsistent
> cluster state.
> MoveReplicaCmd
> {code}
> ZkNodeProps addReplicasProps = new ZkNodeProps(
> COLLECTION_PROP, coll.getName(),
> SHARD_ID_PROP, slice.getName(),
> CoreAdminParams.NODE, targetNode,
> CoreAdminParams.NAME, newCoreName);
> {code}
--
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-13843) MOVEREPLICA API in Solr doesn't respect Replica Type.
Amrit Sarkar created SOLR-13843:
---
Summary: MOVEREPLICA API in Solr doesn't respect Replica Type.
Key: SOLR-13843
URL: https://issues.apache.org/jira/browse/SOLR-13843
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Amrit Sarkar
MOVEREPLICA API in Solr creates NRT type replica in the target node always,
no matter what type the source replica is. This leads to an inconsistent
cluster state.
MoveReplicaCmd
{code}
ZkNodeProps addReplicasProps = new ZkNodeProps(
COLLECTION_PROP, coll.getName(),
SHARD_ID_PROP, slice.getName(),
CoreAdminParams.NODE, targetNode,
CoreAdminParams.NAME, newCoreName);
{code}
--
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
