[
https://issues.apache.org/jira/browse/SOLR-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Kartsev updated SOLR-9493:
-------------------------------
Attachment: 400.png
200.png
> uniqueKey generation fails if content POSTed as "application/javabin".
> ----------------------------------------------------------------------
>
> Key: SOLR-9493
> URL: https://issues.apache.org/jira/browse/SOLR-9493
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Yury Kartsev
> Attachments: 200.png, 400.png
>
>
> I have faced a weird issue when the same application code (using SolrJ) fails
> indexing a document without a unique key (should be auto-generated by SOLR)
> in SolrCloud and succeeds indexing it in standalone SOLR instance (or even in
> cloud mode, but from web interface of one of the replicas). Difference is
> obviously only between clients (CloudSolrClient vs HttpSolrClient) and SOLR
> URLs (Zokeeper hostname+port vs standalone SOLR instance hostname and port).
> Failure is seen as "org.apache.solr.client.solrj.SolrServerException:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
> Document is missing mandatory uniqueKey field: id".
> I am using SOLR 5.1. In cloud mode I have 1 shard and 3 replicas.
> After lot of debugging and investigation (see my [StackOverflow
> post|http://stackoverflow.com/questions/39401792/uniquekey-generation-does-not-work-in-solrcloud-but-works-if-standalone])
> I came to a conclusion that the difference in failing and succeeding calls
> is simply content type of the POSTing requests. Local proxy clearly shows
> that the request fails if content is sent as "application/javabin" (see
> attached) and succeeds if content sent as "application/xml; charset=UTF-8"
> (see attached).
> Would you be able to please assist?
> Thank you very much in advance!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
