[
https://issues.apache.org/jira/browse/SOLR-12803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski reassigned SOLR-12803:
--------------------------------------
Assignee: Jason Gerlowski
Attachment: SOLR-12803.patch
> ConcurrentUpdateSolrClient doesn't obey "collection" when streaming updates
> ---------------------------------------------------------------------------
>
> Key: SOLR-12803
> URL: https://issues.apache.org/jira/browse/SOLR-12803
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Affects Versions: 7.5
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Attachments: SOLR-12803.patch, SOLR-12803.patch
>
>
> ConcurrentUpdateSolrClient spins up background threads that pull documents
> from a queue and feed them into open HTTP connections. Before writing each
> UpdateRequest on the connection, CUSC checks that the SolrParams match the
> params used when originally opening the connection. But it doesn't check
> that the collection is the same.
> If a user is using the same ConcurrentUpdateSolrClient to send documents to
> multiple collections simultaneously, each of their UpdateRequest might go to
> the wrong collection entirely, based on what connections are already open.
> The problem can be reproduced with the snippet below. The correct behavior
> would be for 500 docs to go to each collection. But instead, on most runs
> all 1000 go to collection1.
> {code:java}
> @Test
> public void cusc_test() throws Exception {
> try (SolrClient client = new
> ConcurrentUpdateSolrClient.Builder("http://localhost:8983/solr";).build()) {
> for (int i = 0; i < 1000; i++) {
> SolrInputDocument doc = new SolrInputDocument();
> doc.setField("id", "value" + i);
> if (i%2 == 0) {
> client.add("collection1", doc);
> } else {
> client.add("collection2", doc);
> }
> }
> client.commit("collection1");
> client.commit("collection2");
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
