-user@lucene.apache.org
Subject: Re: java.lang.NumberFormatException: For input string:
"string;#-6.872515521, 53.28853084"
It looks like the data is, literally,
string;#-6.872515521, 53.28853084
or maybe
#-6.872515521, 53.28853084
either way the data isn't in anything like the format
.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
> at
>
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
> at
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThrea
.run(Unknown Source)
Caused by: java.lang.NumberFormatException: For input string:
"string;#-6.872515521, 53.28853084"
at sun.misc.FloatingDecimal.readJavaFormatString(Unknown
Source)
at java.lang.Double.parseDouble(Unknown Source)
at
org.
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 1
: 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 -
ache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>> at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>> at
>> org.apache.coyo
dapter.java:330)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> at
> org.apache.tomcat.util.net.JIo
yote.http11.Http11Processor.process(Http11Processor.java:829)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run
11Processor.java:829)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NumberFormatExcepti
A big thanks to Yonik and Mark. Using the raw term query I was able
to find the range(!) of documents that had bad integer field values.
Deleting those documents, committing and optimizing cleared up the
issue.
Still not sure how the bad values were inserted in the first place,
but that is anothe
On Fri, Feb 26, 2010 at 10:59 AM, Mark Miller wrote:
> You have to find the document with the bad value somehow.
>
> In the past I have used Luke to help with this.
>
> Then you need to delete the document.
You can also find the document with a raw term query.
q={!raw f=myfield}104708<
-Yonik
h
eturn 0 results, but still has a sort
parameter the exception is raised. The stack trace is the same no
matter what the query.
I need help troubleshooting this issue. Any clues, or suggested
approaches would be helpful. Thank you in advance!.
The stack trace is as follows:
SEVERE: java.la
but still has a sort
>> parameter the exception is raised. The stack trace is the same no
>> matter what the query.
>>
>> I need help troubleshooting this issue. Any clues, or suggested
>> approaches would be helpful. Thank you in advance!.
>>
&
till has a sort
> parameter the exception is raised. The stack trace is the same no
> matter what the query.
>
> I need help troubleshooting this issue. Any clues, or suggested
> approaches would be helpful. Thank you in advance!.
>
> The stack trace is as fol
: java.lang.NumberFormatException: For input string: "104708<"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:456)
at java.lang.Integer.parseInt(Integer.java:49
s" so we could prevent code that doesn't catch
NumberFormatException from ever getting committed.
I've got a patch that will improve the error message on this in the
future...
https://issues.apache.org/jira/browse/SOLR-1635
: >> SEVERE: java.lang.NumberFormatE
t; Cant figure out which field is causing the problem
>>
>> SEVERE: java.lang.NumberFormatException: For input string: ""
>> at
>> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>> at java.lang.
ments in our index.
> Still we get this error, any idea
> Cant figure out which field is causing the problem
>
> SEVERE: java.lang.NumberFormatException: For input string: ""
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>
is causing the problem
SEVERE: java.lang.NumberFormatException: For input string: ""
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.valueOf(Integer.java:553)
19 matches
Mail list logo
