Thanks for adding this issue to JIRA.
I tried to find the exact problem using debugger step by step
analysis, but do to lack of SOLR internals knowledge and time I didn't
find anything fishy. I only found that when we were feeding SOLR
directly with BigDecimal objects, class JavaBinCodec at line
Welcome all,
We have a very strange problem with SOLR 3.5. It SOMETIMES throws exceptions:
2012-10-31 10:20:06,408 SEVERE [org.apache.solr.core.SolrCore:185]
(http-10.205.49.74-8080-155) org.apache.solr.common.SolrException:
ERROR: [doc=MyDoc # d3mo1351674222122-1 # 2012-10-31 08:03:42.122]
Hello!
Look at what Solr returns in the error - you send the following value
java.math.BigDecimal:1848.66 - remove the java.math.BigDecimal:
and your problem should be gone.
--
Regards,
Rafał Kuć
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - ElasticSearch
Welcome all,
We
It _looks_ like somehow the string you're sending as a BigDecimal is,
literally, java.math.BigDecimal:1848.66 rather than 1848.66. How are
you generating the field value? I'm guessing that your (SolrJ?) program is
somehow messing this up...
Best
Erick
On Wed, Oct 31, 2012 at 7:28 AM, Marcin
First we were adding BigDecimal object to SolrInputDocument directly
as field value.
Now we are adding BigDecimal.toPlainString() as field value.
SOLR relies on JavaBinCodec class which does de/serialization in it's
own way - some kind of bug in there?
I don't know what is the proper way to
: SOLR relies on JavaBinCodec class which does de/serialization in it's
: own way - some kind of bug in there?
:
: I don't know what is the proper way to handle BigDecimal values in
: SOLR 3.5 after all?
The safe thing to do is only add primitive java objects that Solr
understands natively -
