lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject RE: Spurious _version_ conflict?
Date Fri, 17 Apr 2015 16:50:12 GMT

you still haven't provided any details on what your client code looks like 
-- ie: what code is talking to solr? what response format is it asking 
for? is it JSON? what is parsing that JSON?

as for the admin UI: if you are looking at a JSON response in the "Query" 
screen of the Admin UI, then the Javascript engine of your webbrowser is 
being use to parse the JSON and prettty print it for you.

what does the _version_ in the *RAW* response from your /get or /select 
request return when you use something like curl that does *NO* processing 
of the response data?

: Date: Fri, 17 Apr 2015 15:37:21 +0000
: From: "Reitzel, Charles" <>
: Reply-To:
: To: "" <>
: Subject: RE: Spurious _version_ conflict?
: Thanks for getting back.   Something like that crossed my mind but I checked the values
on the way into SolrJ SolrInputDocument match the values printed in the Admin Query interface
and they both match the expected value in the error message exactly.
: Besides the difference is only in the last few bits ...
: Error executing update: version conflict for 553d0f5d320c4321b13f4312ff907218 expected=1498643112821522400
: Note, all my _version_ values have zeroes in the last two digits.  But, again, there is
agreement between the Admin UI and every stage of my client (from query in my REST service,
to REST client in browser, back to update in my REST service).
: -----Original Message-----
: From: Chris Hostetter [] 
: Sent: Thursday, April 16, 2015 5:04 PM
: To:
: Subject: Re: Spurious _version_ conflict?
: : I notice that the expected value in the error message matches both what
: : I pass in and the index contents.  But the actual value in the error
: : message is different only in the last (low order) two digits.  
: : Consistently.
: what does your client code look like?  Are you sure you aren't being bit by a JSON parsing
library that can't handle long values and winds up truncating them?
: -Hoss
: *************************************************************************
: This e-mail may contain confidential or privileged information.
: If you are not the intended recipient, please notify the sender immediately and then delete
: *************************************************************************


View raw message