Invalid XML in response

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Invalid XML in response

brzozek
Hi
I don't understand why SOLR returns and invalid XML file as a response
in case when we insert a document with a field that is not defined
in the Solr configuration. Is there any purpose for that?

It would be nice if it returns a valid xml....

regards
Przemek Brzozowski




<result status="400">ERROR:unknown field 'aaa'</result><result
status="1">org.xmlpull.v1.XmlPullParserException: expected START_TAG or
END_TAG not END_DOCUMENT (position: END_DOCUMENT seen
...&lt;/doc&gt;\n&lt;/add&gt;\n... @9:1)
    at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1083)
   at org.apache.solr.core.SolrCore.update(SolrCore.java:681)
    at
org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:52)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
   at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
    at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
    at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
    at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
    at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
 at java.lang.Thread.run(Thread.java:595)
</result>


----------------------------------------------------------------------
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e

Reply | Threaded
Open this post in threaded view
|

Re: Invalid XML in response

Chris Hostetter-3

: I don't understand why SOLR returns and invalid XML file as a response
: in case when we insert a document with a field that is not defined
: in the Solr configuration. Is there any purpose for that?
:
: It would be nice if it returns a valid xml....

i think if you were adding only one doc, and it had a field problem, then
the response would be valid XML ... but it looks like you are adding
multiple docs, in which case even a success isn't valid XML at the
moment...

        http://issues.apache.org/jira/browse/SOLR-2

...can you verify that this is really the same bug (two seperate <result>
blocks because of adding two seperate docs in a single request) ... or is
there something i'm missing in your example error besides that?

: <result status="400">ERROR:unknown field 'aaa'</result><result
: status="1">org.xmlpull.v1.XmlPullParserException: expected START_TAG or
: END_TAG not END_DOCUMENT (position: END_DOCUMENT seen
: ...&lt;/doc&gt;\n&lt;/add&gt;\n... @9:1)
:     at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1083)
:    at org.apache.solr.core.SolrCore.update(SolrCore.java:681)
:     at
: org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:52)
:     at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
:     at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
:    at
: org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
:     at
: org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
:    at
: org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
:     at
: org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
:     at
: org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
:     at
: org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
:     at
: org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
:     at
: org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
:    at
: org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
:     at
: org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
:     at
: org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
:     at
: org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
:     at
: org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
:  at java.lang.Thread.run(Thread.java:595)
: </result>
:
:
: ----------------------------------------------------------------------
: Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
:



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: Invalid XML in response

brzozek


Chris Hostetter napisaƂ(a):

> : I don't understand why SOLR returns and invalid XML file as a response
> : in case when we insert a document with a field that is not defined
> : in the Solr configuration. Is there any purpose for that?
> :
> : It would be nice if it returns a valid xml....
>
> i think if you were adding only one doc, and it had a field problem, then
> the response would be valid XML ... but it looks like you are adding
> multiple docs, in which case even a success isn't valid XML at the
> moment...
>
> http://issues.apache.org/jira/browse/SOLR-2
>
> ...can you verify that this is really the same bug (two seperate <result>
> blocks because of adding two seperate docs in a single request) ... or is
> there something i'm missing in your example error besides that?
>
>  
No, it is not the same bug. Not to the end. I'm inserting one new
document in one request:


<add>
  <doc>
    <field name="level_0">invoice</field>
    <field name="aaa">bbb</field>
    <field
name="internal_id">10E3B793A84559081D1EF0BA6BD0BB5E1417573EC5D</field>
  </doc>
</add>

The field "aaa" doesn't exist and I get an error:

<result status="400">ERROR:unknown field 'aaa'</result><result
status="1">org.xmlpull.v1.XmlPullParserException: expected START_TAG or
END_TAG not END_DOCUMENT (position: END_DOCUMENT seen
...&lt;/doc&gt;\n&lt;/add&gt;\n... @9:1)
    at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1083)
    at org.apache.solr.core.SolrCore.update(SolrCore.java:681)
    at
org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:52)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
    at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
    at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
    at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
    at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
    at java.lang.Thread.run(Thread.java:595)
</result>

The same stacktrace is shown in Tomcat output console.

Generally, there are problems with error messages coming from SOLR.
Sometimes they come with 400 HTTP code and in error stream. e.g. when we
specify
a field that doesn't exist in a query. Sometimes they come with no HTTP
error code using
normal stream ( the stack trace above).
Additionally it is hard to find out what kind of error happend... Maybe
the status varialble should
tell something about the type of error...

regards
Przemek


> : <result status="400">ERROR:unknown field 'aaa'</result><result
> : status="1">org.xmlpull.v1.XmlPullParserException: expected START_TAG or
> : END_TAG not END_DOCUMENT (position: END_DOCUMENT seen
> : ...&lt;/doc&gt;\n&lt;/add&gt;\n... @9:1)
> :     at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1083)
> :    at org.apache.solr.core.SolrCore.update(SolrCore.java:681)
> :     at
> : org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:52)
> :     at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> :     at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> :    at
> : org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> :     at
> : org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> :    at
> : org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> :     at
> : org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> :     at
> : org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> :     at
> : org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> :     at
> : org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> :     at
> : org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> :    at
> : org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> :     at
> : org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> :     at
> : org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> :     at
> : org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> :     at
> : org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> :  at java.lang.Thread.run(Thread.java:595)
> : </result>
> :
> :
> : ----------------------------------------------------------------------
> : Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
> :
>
>
>
> -Hoss
>
>
>
>  

----------------------------------------------------------------------
Czas pozegnac finansowe problemy.
Kredyt Citibank - prosty kredyt na wszystkie potrzeby.
Sprawdz: http://link.interia.pl/f19a5

Reply | Threaded
Open this post in threaded view
|

Re: Invalid XML in response

Chris Hostetter-3

: No, it is not the same bug. Not to the end. I'm inserting one new
: document in one request:

Hmmm ... would you mind opening a bug for this in Jira?

: Generally, there are problems with error messages coming from SOLR.
: Sometimes they come with 400 HTTP code and in error stream. e.g. when we
: specify
: a field that doesn't exist in a query. Sometimes they come with no HTTP
: error code using
: normal stream ( the stack trace above).

I agree ... comments various people have made over the last few weeks or
so have gotten me thinking that standardizing the way errors are
returned to the HTTP client (for both updates and selects) is one of the
biggest "API problems" in SOlr right now.



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: Invalid XML in response

Erik Hatcher

On Oct 12, 2006, at 11:26 AM, Chris Hostetter wrote:
> I agree ... comments various people have made over the last few  
> weeks or
> so have gotten me thinking that standardizing the way errors are
> returned to the HTTP client (for both updates and selects) is one  
> of the
> biggest "API problems" in SOlr right now.

I believe it is also the case that Solr sends a 200 OK response  
status when there are errors also... when it would be more  
appropriate for it to be a 500 level status.  Just another bit of  
trivia to add to this issue.

        Erik


Reply | Threaded
Open this post in threaded view
|

Indexing API

Walter Underwood, Netflix
In reply to this post by Chris Hostetter-3
On 10/12/06 8:26 AM, "Chris Hostetter" <[hidden email]> wrote:

> I agree ... comments various people have made over the last few weeks or
> so have gotten me thinking that standardizing the way errors are
> returned to the HTTP client (for both updates and selects) is one of the
> biggest "API problems" in SOlr right now.

This is a complicated issue. We sent zillions of messages about it
on the Atom Publishing Protocol list. The end result was to use
HTTP request methods and response codes and be religiously
correct about the HTTP behavior.

We should take a look at the APP spec to see what we can learn
from that. Atom got *lots* of review, all the way to Roy Fielding.

The current APP draft is here. This is in IETF Last Call, so it
is nearly finished.

  http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html

One option would be to implement APP rather than designing something
new. When I was at HP, one of the design principles was "standard is
better than better." APP will not be an exact match to Solr, but
it is very well designed and it is probably worth the effort to
build on the vast amount of work and review that went into APP.
If you want to dig in further, the mailing list is here:

  http://www.imc.org/atom-protocol/index.html

If we have APP for indexing, results in Atom format would help a lot.
Google GData is a pretty good Atom search API.

wunder
--
Walter Underwood
Search Guru, Netflix

Reply | Threaded
Open this post in threaded view
|

Re: Indexing API

Erik Hatcher
Walter - I'm curious what your thoughts are on the OpenSearch  
standard as well.  Do you think Solr should support that natively as  
well?

I'm a proponent of the Atom Publishing Protocol as well, for the record.

        Erik


On Oct 12, 2006, at 1:09 PM, Walter Underwood wrote:

> On 10/12/06 8:26 AM, "Chris Hostetter" <[hidden email]>  
> wrote:
>
>> I agree ... comments various people have made over the last few  
>> weeks or
>> so have gotten me thinking that standardizing the way errors are
>> returned to the HTTP client (for both updates and selects) is one  
>> of the
>> biggest "API problems" in SOlr right now.
>
> This is a complicated issue. We sent zillions of messages about it
> on the Atom Publishing Protocol list. The end result was to use
> HTTP request methods and response codes and be religiously
> correct about the HTTP behavior.
>
> We should take a look at the APP spec to see what we can learn
> from that. Atom got *lots* of review, all the way to Roy Fielding.
>
> The current APP draft is here. This is in IETF Last Call, so it
> is nearly finished.
>
>   http://bitworking.org/projects/atom/draft-ietf-atompub- 
> protocol-11.html
>
> One option would be to implement APP rather than designing something
> new. When I was at HP, one of the design principles was "standard is
> better than better." APP will not be an exact match to Solr, but
> it is very well designed and it is probably worth the effort to
> build on the vast amount of work and review that went into APP.
> If you want to dig in further, the mailing list is here:
>
>   http://www.imc.org/atom-protocol/index.html
>
> If we have APP for indexing, results in Atom format would help a lot.
> Google GData is a pretty good Atom search API.
>
> wunder
> --
> Walter Underwood
> Search Guru, Netflix

Reply | Threaded
Open this post in threaded view
|

Re: Indexing API

Erik Hatcher

On Oct 12, 2006, at 2:32 PM, Erik Hatcher wrote:
> Walter - I'm curious what your thoughts are on the OpenSearch  
> standard as well.  Do you think Solr should support that natively  
> as well?

However, I find the error handling "suggestion" in the OpenSearch  
developer docs unsettling:

        <http://www.opensearch.org/Documentation/ 
Developer_how_to_guide#How_to_indicate_errors>

Make a fake search result?  That's ridiculous.

        Erik

Reply | Threaded
Open this post in threaded view
|

Re: Indexing API

Walter Underwood, Netflix
In reply to this post by Erik Hatcher
I'm not impressed with OpenSearch. It is a sloppy design and not
well-documented. It is heavily slanted toward what A9.com wanted
to do on their website, and that stuff is all dead. Essentially,
OpenSearch is a proprietary format that was published in an
open manner.

If you compare OpenSearch to Atom, there is a huge difference in
the quality of the design and the spec.

GData is a much better design.

wunder

On 10/12/06 11:32 AM, "Erik Hatcher" <[hidden email]> wrote:

> Walter - I'm curious what your thoughts are on the OpenSearch
> standard as well.  Do you think Solr should support that natively as
> well?
>
> I'm a proponent of the Atom Publishing Protocol as well, for the record.
>
> Erik
>
>
> On Oct 12, 2006, at 1:09 PM, Walter Underwood wrote:
>
>> On 10/12/06 8:26 AM, "Chris Hostetter" <[hidden email]>
>> wrote:
>>
>>> I agree ... comments various people have made over the last few
>>> weeks or
>>> so have gotten me thinking that standardizing the way errors are
>>> returned to the HTTP client (for both updates and selects) is one
>>> of the
>>> biggest "API problems" in SOlr right now.
>>
>> This is a complicated issue. We sent zillions of messages about it
>> on the Atom Publishing Protocol list. The end result was to use
>> HTTP request methods and response codes and be religiously
>> correct about the HTTP behavior.
>>
>> We should take a look at the APP spec to see what we can learn
>> from that. Atom got *lots* of review, all the way to Roy Fielding.
>>
>> The current APP draft is here. This is in IETF Last Call, so it
>> is nearly finished.
>>
>>   http://bitworking.org/projects/atom/draft-ietf-atompub-
>> protocol-11.html
>>
>> One option would be to implement APP rather than designing something
>> new. When I was at HP, one of the design principles was "standard is
>> better than better." APP will not be an exact match to Solr, but
>> it is very well designed and it is probably worth the effort to
>> build on the vast amount of work and review that went into APP.
>> If you want to dig in further, the mailing list is here:
>>
>>   http://www.imc.org/atom-protocol/index.html
>>
>> If we have APP for indexing, results in Atom format would help a lot.
>> Google GData is a pretty good Atom search API.
>>
>> wunder
>> --
>> Walter Underwood
>> Search Guru, Netflix
>