: We have looked through the shards trying to find a value which is greater : than radix 10 which would throw this exception. We did not find any. We have
Grant's guess doesn't make much sense to me ... it would explain why a "large" short might appear that way, but not why a "short" short would trigger that -- every value is evaluated on it's own. : values between 0 and 100 in that field. Would not SOLR complain if we tried : to index a "non-short" like for example a float or am integer size number ? Nope ... for hte simple primitave types, Solr trusts you to give it what you say you are giving it. : without the "shards" parameter ? It only spits out the string version when : we use sharding. My first guess would be that this may be a problem with the JavaBin format, which is probably getting used when the aggregator talks to each of hte shards -- if hte JavaBin format doesn't support a type, then that's what it does as a fallback: it uses the java classnam concatted to the toString vlaue as a "String" object. The only problem with this theory is that the JavaBinCodec *does* support Short ... so I'm really not sure what's going on here. -Hoss
