I upgraded one of my solrj clients to 4.2.0, and am testing using it
with a 3.4 server. We generally use a BinaryRequestWriter (ie
javabin). With the 3.4 solrj client, this caused update requests to be
directed to /update/javabin. However, in 4.2, the dispatch seems to be
getting handled using the content-type header, rather than a distinct
url path, but the 3.4 server isn't set up to understand the difference -
in the standard config that everone seems to use, it interprets requests
at /update as XML format requests. This leads to errors, naturally.
By the way the errors themselves are quite difficult to comprehend,
because of the format mismatch I guess -- you end up with a mysterious
"Invalid version (expected 2, but 1) or the data in not in 'javabin'
format" ... at least there is an indication this might be
javabin-related in some way, maybe just by coincidence. On the server
side, the error you get is a bad UTF8 character - "Invalid UTF-8 middle
byte 0xe0 (at char #1, byte #-1)" - since it is trying to parse javabin
as XML.
My question is: is this intentional? It's unfortunate that we don't
seem to be able to update the client and have it continue to work with
(ie send updates to) the old servers. We have a centralized client
library that we share across a large number of different installations,
and getting all the servers upgraded is going to take some time. It
would be really nice if we could decouple the upgrade efforts.
I guess as a workaround we can enforce that the clients send requests to
/update/javabin as they used to (new UpdateRequest("/update/javabin"),
but am I missing a straightforward out-of-the-box way? - I don't think I
saw anything about this in the release notes.
-Mike
- Solr 4.x/3.x update javabin incompatibility? Michael Sokolov
-
