[SOLR-9230] Change of default to BinaryRequestWriter breaks some use cases

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 6.0
• Assignee: Unassigned
• Reporter: Eirik Lygre
• Created: 20/Jun/16 16:40
• Updated: 22/Jun/16 05:02

Description

From Solr 6.0 onwards, SOLR-8595 changes the default writer in HttpSolrClient (et al) from RequestWriter to BinaryRequestWriter.

The RequestWriter writes java.math.BigDecimal values using a simple toString() on the value. This means that a BigDecimal-value is passed to the server using its text representation, which is then mapped into whatever the server wants. (The RequestWriter probably uses toString() on anything it sees)

The BinaryRequestWriter instead handles unknown value types by writing a string containing the class name, a colon, and then the toString() value. This means that a BigDecimal-value is passed to the server as a text representation "java.math.BigDecimal:12345", which the server cannot convert to a number, and which then stops indexing.

I'm not entirely sure that this behaviour is a bug, but I'm fairly sure that the quiet change of behaviour qualifies. The "Trivial Patch" (quote from SOLR-8595) isn't, when straight forward indexing scenarios quietly stop working.

There are several possible paths forward:

• Have the BinaryRequestWriter (really the JavaBinCodec) encode java.lang.Numbers as Strings, the way the RequestWriter does
• Add something in release notes to inform users about the change

SOLR-4021 describes the problem, but the change of default writer increases problem visibility. SOLR-6165 somehow seems relevant.

Issue Links

• is related to: SOLR-4021 JavaBinCodec has poor default behavior for unrecognized classes of objects
• is related to: SOLR-8866 UpdateLog should throw an exception when serializing unknown types