: We tried to post the same manually from SOLR ADMIN / documents UI. It got
: indexed successfully. We are sure that it's not duplicate issue. We are
: using default update handler and doesn't configure for custom one. We fire
: the request to index using direct HTTP request using <add> <doc> XML
: format. We are getting 200 OK response. But not getting indexed.
:
: This is the request we fired and got 200. But not getting indexed. Same
: request fired via SOLR ADMIN / Document UI, it's getting indexed
: successfully.
: <add>
: <doc>
: <CT_iscof>false</CT_iscof>
: <CT_ui116_s>55788327</CT_ui116_s>
: ...
... hold on, let's back up here -- the XML you've provided is not in any
format that solr understands natively at all -- what are these "CT_foo"
xml tags? are these intended to be the final field names?
If so, and if this type of XML document is working for you *sometimes*,
then you definitely have something non standard in your document pipeline
that's handling the XML parsing and then handing the documents to Solr --
either a proxy in between you and solr, or perhaps a custom update
processor or a custom RequestHandler .... nothing in SOLR would be able to
parse that XML in a sane way.
So please tell us more about your system, and how you index documents, and
all of your configs, etc...
https://wiki.apache.org/solr/UsingMailingLists
...in particular, please show us your solrconfig.xml and a sample "curl"
command for indexing a document, and the output of that curl command when
using --dump-header.
With that said, Let's back up some more and look at those logs you posted...
> All documents POST are seen in the localhost_access and 200 OK response
> is seen in local host access file. But in catalina, there are some
> difference in the logs for which are indexing properly, following is the logs.
>
> FINE: PRE_UPDATE add
> {,id=CUA0000004390000019223370564139207241C3LEA0000020769223370567404392838EXCC3000001}
> params(crid=CUA0000004390000019223370564139207241C3LEA0000020769223370567404392838EXCC3000001),defaults(wt=xml)
> ...
> org.apache.solr.update.processor.LogUpdateProcessor finish
> INFO: [IOB_shard1_replica1] webapp=/solr path=/update params=
> {crid=CUA0000004390000019223370564139207241C3LEA0000020769223370567404392838EXCC3000001}
> {add=[CUA0000004390000019223370564139207241C3LEA0000020769223370567404392838EXCC3000001
>
> (1544254202941800448)]}
> ...
...your copy paste cut off the important bit at the begining about what
method was logging that PRE_UPDATE, but it's not really critical for
analysis: what matters is that the LogUpdateProcessor reports that it's
processing an "add" of "id=CUA000000..." which has a "crid=CUA00000"
request param (which is not something solr cares about, but is something
your software is sending which contains the same value as the uniqueKey of
the document) and then later it loggs that it finished processing the
request which included one "add" ... if the request had included multiple
update operations (ie: multiple adds, or adds mixed with deletes, or a
commit) then LogUpdateProcessor would have recorded a PRE_UPDATE for each
of them, but only one "finish" sumarising all of them.
Now let's look at your next log snipped...
> For the one which document is not getting indexed, we could see only
> following log in catalina.out. Not sure whether it's getting added to SOLR.
>
> Sep 01, 2016 7:39:56 AM org.apache.solr.update.processor.LogUpdateProcessor
> finish
> FINE: PRE_UPDATE FINISH
> params(crid=CUA0000004390000019223370564139182810C3LEA0000020179223370567061972057EXCC1000002),defaults(wt=xml)
> Sep 01, 2016 7:39:56 AM org.apache.solr.update.processor.LogUpdateProcessor
> finish
> INFO: [IOB_shard1_replica1] webapp=/solr path=/update
> params={crid=CUA0000004390000019223370564139182810C3LEA0000020179223370567061972057EXCC1000002}
>
> {} 0 1
> ...
If that's really every thing in your log for the request that doesn't
work, then what that tells us is that a request was sent to the /update
handler which did not contain any udpate commands -- ie: no documents to
add, no deletes, no commit, etc... that's why there are no "PRE_UPDATE
add" log messages, and no ids listed in the "finish" log message.
that's the logs i would expect to see from something like this curl
request -- which triggers the update handler with a request to do
nothing...
curl --dump-header - -H 'Content-Type: application/json'
http://localhost:8983/solr/techproducts/update --data-binary '[]'
HTTP/1.1 200 OK
Content-Type: text/plain;charset=utf-8
Content-Length: 42
{"responseHeader":{"status":0,"QTime":0}}
-Hoss
http://www.lucidworks.com/
