Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Nitin Kumar]

Please check doc's unique key(Id). All keys shd be unique. Else docs having
same id will be replaced.

On 04-Sep-2016 12:13 PM, "Ganesh M"  wrote:

> Hi,
> we are keep sending documents to Solr from our app server. Single document
> per request, but in parallel of 10 request hits solr cloud in a second.
>
> We could see our post request ( update request ) hitting our solr 5.4 in
> localhost_access logs, and it's response as 200 Ok response. And also we
> get HTTP 200 OK response to our app servers as well for out HTTP request we
> fired to SOLR Cloud.
>
> But few documents are not getting indexed. Out of 2000 documents we sent
> 10 documents are getting missed. Thought there is not error, few documents
> are getting missed.
>
> We use autoSoftcommit as 2 secs and autohardcommit as 30 secs.
>
> Why is that 10 documents not getting indexed and also no error getting
> thrown back if server is not able to index it ?
>
> Regards,
>
>
>
>

Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Ganesh M]

Nitin, Thanks for reply. Our each document has unique id and its hbase rowkey 
id. So it will be unique only. So there is no chance of duplicates id being 
send.



On Sun 4 Sep, 2016 12:41 pm Nitin Kumar, 
mailto:nitinkumar.i...@gmail.com>> wrote:
Please check doc's unique key(Id). All keys shd be unique. Else docs having
same id will be replaced.

On 04-Sep-2016 12:13 PM, "Ganesh M" mailto:mgane...@live.in>> 
wrote:

> Hi,
> we are keep sending documents to Solr from our app server. Single document
> per request, but in parallel of 10 request hits solr cloud in a second.
>
> We could see our post request ( update request ) hitting our solr 5.4 in
> localhost_access logs, and it's response as 200 Ok response. And also we
> get HTTP 200 OK response to our app servers as well for out HTTP request we
> fired to SOLR Cloud.
>
> But few documents are not getting indexed. Out of 2000 documents we sent
> 10 documents are getting missed. Thought there is not error, few documents
> are getting missed.
>
> We use autoSoftcommit as 2 secs and autohardcommit as 30 secs.
>
> Why is that 10 documents not getting indexed and also no error getting
> thrown back if server is not able to index it ?
>
> Regards,
>
>
>
>

Re: Indexed columns not visible on schema browser in Solr Admin console

[subinalex]

Thanks a lot alex.
The issue was because as u said it did not match the definition

:-)

On 4 Sep 2016 8:35 a.m., "Alexandre Rafalovitch [via Lucene]" <
ml-node+s472066n4294558...@n3.nabble.com> wrote:

It should show up in the Admin UI, even if it matches the dynamic
field. So, I would focus on that. Perhaps you did not run commit. Or
it did not match the definition the way you thought it did.

I would do a manual record that matches that dynamic field and see if
_that_ shows up.

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 3 September 2016 at 15:55, subinalex <[hidden email]
> wrote:

> Hi All,
>
> I have indexed a json with columns that arenot defined in
schema.xml,reason
> being i have a dynamicfield defined to catch them.
>
> The indexing completes without error,even the index and tlog folders in
> collection root are created.
>
> However,when i login to solr admin console,i am not able to see the newly
> indexed field names in schema browser for the particular collection.
>
> Why is it so?,,,
>
> Please help on this.
>
>
>
> --
> View this message in context: http://lucene.472066.n3.
nabble.com/Indexed-columns-not-visible-on-schema-browser-
in-Solr-Admin-console-tp4294523.html
> Sent from the Solr - User mailing list archive at Nabble.com.


--
If you reply to this email, your message will be added to the discussion
below:
http://lucene.472066.n3.nabble.com/Indexed-columns-
not-visible-on-schema-browser-in-Solr-Admin-console-tp4294523p4294558.html
To unsubscribe from Indexed columns not visible on schema browser in Solr
Admin console, click here

.
NAML





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Indexed-columns-not-visible-on-schema-browser-in-Solr-Admin-console-tp4294523p4294561.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: failed to load core

[Rajendra Gaikwad]

Hi KRIS,
I noticed three issue with your schema.xml as follows:
1. enablePositionIncrements is not a valid option, please remove it from
all StopFilter defination.
2. invalid multivalued="true" attribute to "text_general" fieldType, remove
it.
3. Two fields metatag.description and metatag.keywords are of fieldType
"text", which is missing in schema.xml

Removing invalid attributes and add missing field type,will work for you.

Thanks,
Rajendra Gaikwad



Thanks,
Rajendra Gaikwad




On Fri, Sep 2, 2016 at 11:10 PM, KRIS MUSSHORN 
wrote:

>
> I am unable to start a core due to an error and can't seem to fix it.
>
> i am using solr 5.4.1 in schema mode.
>
>  is enabled and managed
> schema is commented out in solrconfig.xml
> 
>
> When starting the solr server I get error for something wrong with
> solr.StopFilterFactory definition for text_general
> Please see attached console log.
> My schema.xml and solrconfig file are also attached.
>
> I have tried enablePositionIncrements="true" , 
> enablePositionIncrements="false'
> and removed it entirely from the filters and analyzers of the text_general
> type definition with no change in the error.
>
> How can i fix this?
>
> TIA
>
> Kris
>
>

Function query. Not in range

[EbSolutions EbSolutions]

Hi,
I'm using function query to query on range using sum function.
{!frange l=0 u=100} sum(Field1,Ffield2)

this is working well. However, I'm not able to have the document not in the
range. I've tested
NOT({!frange l=0 u=100} sum(Field1,Ffield2)) but it's not working.

Do you have any idea to do it.

Regards,
NKI.

Re: Nested documents: deleting the whole subtree

[Alexandre Rafalovitch]

 I can get this to:

"q":"(+${parent_match} +${condition_match}) {!child
of=${parent_match}}${condition_match}",

"parent_match":"type:release",

"condition_match":"release_name:\"6.1.0\"",

But I am not sure that's "smarter".

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 4 September 2016 at 13:16, Alexandre Rafalovitch  wrote:
> Right.
>
> But how do I structure the query to say to match all root values that
> correspond to the parent entries selected by query.
>
> Maybe I am just blanking here but how do I form the query:
> q=_root_:[set of id values from query (+type:release +release_name:"6.1.0")]
>
> Regards,
>Alex.
>
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
>
> On 4 September 2016 at 12:43, Mikhail Khludnev  wrote:
>> Hello Alex,
>> Internally, _root_ field is assigned across whole block. You can use it in
>> deleteByQuery. The value for this field is equal to parent's uniqueKey.
>>
>> On Sun, Sep 4, 2016 at 5:51 AM, Alexandre Rafalovitch 
>> wrote:
>>
>>> Hello,
>>>
>>> If I am correct, deleting parent document still keeps the child
>>> documents in the index. Which means they now have dangling _root_
>>> references and what not.
>>>
>>> What's the easiest delete command to take out the parent and all its
>>> multilevel children, when I find the parents themselves with a query?
>>>
>>> So far, I got:
>>> (+type:release +release_name:"6.1.0") {!child
>>> of=type:release}release_name:"6.1.0"
>>>
>>> Is there a better way I missed?
>>>
>>> Regards,
>>>Alex.
>>> P.s. Interestingly, the above query will still match children after
>>> the parent record is still gone. Until the merge/optimize anyway.
>>> Which shows that the deleted record filtering happens after all the
>>> matching, not just parent's matching.
>>>
>>> 
>>> Newsletter and resources for Solr beginners and intermediates:
>>> http://www.solr-start.com/
>>>
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev

Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Ganesh M]

Some more information on this... Most of documents get indexed properly. Few 
documents are not getting indexed.

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=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301}
params(crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301),defaults(wt=xml)
Sep 01, 2016 7:39:31 AM org.apache.solr.update.TransactionLog 
FINE: New TransactionLog 
file=/ebdata2/solrdata/IOB_shard1_replica1/data/tlog/tlog.0220856, 
exists=false, size=0, openExisting=false
Sep 01, 2016 7:39:31 AM org.apache.solr.update.SolrCmdDistributor submit
FINE: sending update to http://xx.xx.xx.xx:7070/solr/IOB_shard1_replica2/ 
retry:0 
add{version=1544254202941800448,id=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301}
 
params:update.distrib=FROMLEADER&distrib.from=http%3A%2F%2Fxx.xx.xx.xx%3A7070%2Fsolr%2FIOB_shard1_replica1%2F
Sep 01, 2016 7:39:31 AM 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner run
FINE: starting runner: 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner@3fb794b2
Sep 01, 2016 7:39:31 AM org.apache.solr.update.processor.LogUpdateProcessor 
finish
FINE: PRE_UPDATE FINISH 
params(crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301),defaults(wt=xml)
Sep 01, 2016 7:39:31 AM 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner run
FINE: finished: 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner@3fb794b2
Sep 01, 2016 7:39:31 AM org.apache.solr.update.processor.LogUpdateProcessor 
finish
INFO: [IOB_shard1_replica1] webapp=/solr path=/update params=
{crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301}
{add=[CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301
 (1544254202941800448)]}
Sep 01, 2016 7:39:31 AM org.apache.solr.servlet.SolrDispatchFilter doFilter
FINE: Closing out SolrRequest: 
params(crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301),defaults(wt=xml)
-

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=CUA00439019223370564139182810C3LEA020179223370567061972057EXCC102),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=CUA00439019223370564139182810C3LEA020179223370567061972057EXCC102}
{} 0 1
Sep 01, 2016 7:39:56 AM org.apache.solr.servlet.SolrDispatchFilter doFilter
FINE: Closing out SolrRequest: 
params(crid=CUA00439019223370564139182810C3LEA020179223370567061972057EXCC102),defaults(wt=xml)

--

You can see that in above log for missing documents ( which is not indexed), in 
catalina log, we are not seeing "PRE UPDATE ADD". Is that causing / reason for 
document not getting indexed ?

We have set autosoftcommit to 1 seconds and autohardcommit to 30 seconds.

We are not getting any errors or exceptions in the log.

This issue is becoming very critical and sort of reliable factor. Though we get 
200 OK response from SOLR for update HTTP POST request, nothing happens on the 
SOLR side. If SOLR is not able to process, isn't it we get error from SOLR 
instead of giving 200 OK response.

Anybody has faced this sort of issue or any sort of help would be very much 
appreciated.




On Sun, Sep 4, 2016 at 12:59 PM Ganesh M 
mailto:mgane...@live.in>> wrote:
Nitin, Thanks for reply. Our each document has unique id and its hbase rowkey 
id. So it will be unique only. So there is no chance of duplicates id being 
send.



On Sun 4 Sep, 2016 12:41 pm Nitin Kumar, 
mailto:nitinkumar.i...@gmail.com>> wrote:
Please check doc's unique key(Id). All keys shd be unique. Else docs having
same id will be replaced.

On 04-Sep-2016 12:13 PM, "Ganesh M" mailto:mgane...@live.in>> 
wrote:

> Hi,
> we are keep sending documents to Solr from our app server. Single document
> per request, but in parallel of 10 request hits solr cloud in a second.
>
> We could see our post request ( update request ) hitting our solr 5.4 in
> localhost_access logs, and it's response as 200 Ok response. And also we
> get HTTP 200 OK response to our app servers as well for out HTTP request we
> fired to SOLR Cloud.
>
> But few documents are not getting indexed. Out of 2000 documents we sent
> 10 documents are getting missed. Thought there is not error, few documents
> are g

Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Alexandre Rafalovitch]

Can you identify the specific documents that 'fail'? What happens if
you post them manually? Try posting them manually but with one field
super-distinct to see whether it made it in. What happens if you post
it to an empty index (copy definition and try).

Also, what's your request handler's parameters look like. Perhaps you
have a signature processor, in which case it may be triggering
duplicates avoidance with different calculation from just an id.

My guess is still that it is some sort of duplicate issue.

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 4 September 2016 at 23:10, Ganesh M  wrote:
> Some more information on this... Most of documents get indexed properly. Few 
> documents are not getting indexed.
>
> 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=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301}
> params(crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301),defaults(wt=xml)
> Sep 01, 2016 7:39:31 AM org.apache.solr.update.TransactionLog 
> FINE: New TransactionLog 
> file=/ebdata2/solrdata/IOB_shard1_replica1/data/tlog/tlog.0220856,
>  exists=false, size=0, openExisting=false
> Sep 01, 2016 7:39:31 AM org.apache.solr.update.SolrCmdDistributor submit
> FINE: sending update to http://xx.xx.xx.xx:7070/solr/IOB_shard1_replica2/ 
> retry:0 
> add{version=1544254202941800448,id=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301}
>  
> params:update.distrib=FROMLEADER&distrib.from=http%3A%2F%2Fxx.xx.xx.xx%3A7070%2Fsolr%2FIOB_shard1_replica1%2F
> Sep 01, 2016 7:39:31 AM 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner run
> FINE: starting runner: 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner@3fb794b2
> Sep 01, 2016 7:39:31 AM org.apache.solr.update.processor.LogUpdateProcessor 
> finish
> FINE: PRE_UPDATE FINISH 
> params(crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301),defaults(wt=xml)
> Sep 01, 2016 7:39:31 AM 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner run
> FINE: finished: 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner@3fb794b2
> Sep 01, 2016 7:39:31 AM org.apache.solr.update.processor.LogUpdateProcessor 
> finish
> INFO: [IOB_shard1_replica1] webapp=/solr path=/update params=
> {crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301}
> {add=[CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301
>  (1544254202941800448)]}
> Sep 01, 2016 7:39:31 AM org.apache.solr.servlet.SolrDispatchFilter doFilter
> FINE: Closing out SolrRequest: 
> params(crid=CUA00439019223370564139207241C3LEA020769223370567404392838EXCC301),defaults(wt=xml)
> -
>
> 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=CUA00439019223370564139182810C3LEA020179223370567061972057EXCC102),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=CUA00439019223370564139182810C3LEA020179223370567061972057EXCC102}
> {} 0 1
> Sep 01, 2016 7:39:56 AM org.apache.solr.servlet.SolrDispatchFilter doFilter
> FINE: Closing out SolrRequest: 
> params(crid=CUA00439019223370564139182810C3LEA020179223370567061972057EXCC102),defaults(wt=xml)
>
> --
>
> You can see that in above log for missing documents ( which is not indexed), 
> in catalina log, we are not seeing "PRE UPDATE ADD". Is that causing / reason 
> for document not getting indexed ?
>
> We have set autosoftcommit to 1 seconds and autohardcommit to 30 seconds.
>
> We are not getting any errors or exceptions in the log.
>
> This issue is becoming very critical and sort of reliable factor. Though we 
> get 200 OK response from SOLR for update HTTP POST request, nothing happens 
> on the SOLR side. If SOLR is not able to process, isn't it we get error from 
> SOLR instead of giving 200 OK response.
>
> Anybody has faced this sort of issue or any sort of help would be very much 
> appreciated.
>
>
>
>
> On Sun, Sep 4, 2016 at 12:59 PM Ganesh M 
> mailto:mgane...@live.in>> wrote:
> Nitin, Thanks for reply. Our each document has unique id and its hbase rowkey 
> id. So it will be unique only. So there is no chance of duplicates id being 
> sen

Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Ganesh M]

Hi Alex,
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   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.


false
55788327
false
Factuur _PERF29161663_Voor _Va Bene.pdf
55788327-PERF29161663
3.00
2916847
STCUA02150011472808279078
EUR
50.00
VAT
50.00
UA0215001:VB1
VB1:A02150:vbgroupnft+1:1472808278137
RA02150AT009428
10,false
62440101
UNKNOWN
 RA02150AT009424#Factuur _PERF29161663_Voor _Va Bene.pdf#
http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278632.png#f
RA02150AT009425#pdf.pdf#
http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278843.png#f
1472808279002
CLEA021509223370564294689844EXCC1019223370564046496793C1LEA021509223370564294752110EXCC201
PERF2020916145437 LEA021509223370564294752110EXCC201 Va Bene VA
Beheer B.V. LEA021509223370564294689844EXCC101 VA Beheer B.V. VA
Beheer B.V.null null null  2.1null  urn:www.cenbii.eu:
transaction:biicoretrdm010:ver1.0:#urn:www.peppol.eu:
bis:peppol4a:ver1.0#urn:www.simplerinvoicing.org:si:si-ubl:ver1.1.xnull
 urn:www.cenbii.eu:profile:bii04:ver2.0null  PERF20209161454372  null
 147275460null  3806 UNCL1001 null  EUR6 ISO 4217 Alpha null null
 29168472  null null  pdf.pdf2  null null  RA02150AT009425#pdf.pdf#
http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278843.png#fpdf.pdf
application/pdf null null  Factuur _PERF29161663_Voor _Va Bene.pdf2  null
 PrimaryImagenull null  RA02150AT009424#Factuur _PERF29161663_Voor _Va
Bene.pdf#
http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278632.png#fFactuur
_PERF29161663_Voor _Va Bene.pdf application/pdf null null null  62440101ZZZ
NL:KVK null null  2916847ZZZ NL:VAT null null  VA Beheer B.V.null null
 Schurinkstraatnull  23null  Ommennull  7731GCnull null  NL6
ISO3166-1:Alpha2 null null  2916847ZZZ NL:VAT null null  VAT6 UN/ECE 5153
null null  62440101ZZZ NL:KVK null null null  55788327ZZZ NL:KVK null null
 55788327ZZZ NL:KVK null null  Va Benenull null  Voorstraatnull  26null
 Voorschotennull  2251BNnull null  NL6 ISO3166-1:Alpha2 null null
 2916847ZZZ NL:VAT null null  VAT6 UN/ECE 5153 null null  55788327ZZZ
NL:KVK null null  147517380null null null null  NL6 ISO3166-1:Alpha2
null null  316 UNCL4461 null  147508740null  55788327-PERF29161663null
null  29168472 IBAN null  UNKNOWNBIC null  Betaling?binnen?14?dagen op
bankrekening?2916847?onder vermelding van?55788327/PERF29161663null null
 3.00EUR null null  50.00EUR null  3.00EUR null null  S6 UNCL5305 null
 6.00null null  VAT6 UN/ECE 5153 null null  50.00EUR null  50.00EUR null
 53.00EUR null  53.00EUR null null  102  null  5.00BX null  50.00EUR null
null  PERF2020916145437null  PERF2020916145437null null  12  null null  S6
UNCL5305 null  6.00null null  VAT6 UN/ECE 5153 null null  10.00EUR null
 RA02150AT009424#Factuur _PERF29161663_Voor _Va Bene.pdf#
http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278632.png#f
DM001 XCNIN199751 NL:KVK:62440101 false false false false 10
UA0215001:VB1 VB1:A02150:vbgroupnft+1:1472808278137 Ontvangen
1472808279002 Factuur GLDT9223370666504283001RA6DTP201 VB1 VB1
UA0215001 RA02150AT009428 vbgroupnft+1 A02150 Group
55788327 Va Bene XCNL034435 Va Bene
LEA021509223370564294752110EXCC201 vbgroupnft+1 A02150
PERF2020916145437 Group 62440101 VA Beheer B.V. XCNL034436 VA Beheer B.V.
LEA021509223370564294689844EXCC101
STCUA02150011472808279078 VB1 VB1 VB1 VB1 UA0215001 true
Factuur GLDT9223370666504283001RA6DTP201 EM0001
NL:KVK:55788327
vbgroupnft+1
10
Va Bene
true
50.00
NL
10,false
62440101
XCNL034436
147508740
Factuur
2916847
VB1 VB1
31
NL
53.00
Ontvangen
26
CLEA021509223370564294689844EXCC1019223370564046496793C1LEA021509223370564294752110EXCC201
XCNL034435
VAT
VA Beheer B.V.
VA Beheer B.V.
2251BN
Va Bene
false
VB1 VB1
55788327
2.1
PERF2020916145437
147517380
EM0001
PERF2020916145437
PERF2020916145437
urn:www.cenbii.eu:profile:bii04:ver2.0
Betaling?binnen?14?dagen op bankrekening?2916847?onder
vermelding van?55788327/PERF29161663
147275460
urn:www.cenbii.eu:
transaction:biicoretrdm010:ver1.0:#urn:www.peppol.eu:
bis:peppol4a:ver1.0#urn:www.simplerinvoicing.org:
si:si-ubl:ver1.1.x
5.00
UA0215001
55788327
Group
NL:KVK:55788327
LEA021509223370564294752110EXCC201
LEA021509223370564294689844EXCC101
CLEA021509223370564294689844EXCC1

Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Dheerendra Kulkarni]

Can you try this:

1. Add the document
2. Follow up by optimize in the core admin ui,

If above works then you may need to check your commit.

Regards,
Dheerendra

On Sun, Sep 4, 2016 at 10:47 PM, Ganesh M 
wrote:

> Hi Alex,
> 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   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.
> 
> 
> false
> 55788327
> false
> Factuur _PERF29161663_Voor _Va Bene.pdf
> 55788327-PERF29161663
> 3.00
> 2916847
> STCUA02150011472808279078
> EUR
> 50.00
> VAT
> 50.00
> UA0215001:VB1
> VB1:A02150:vbgroupnft+1:1472808278137
> RA02150AT009428
> 10,false
> 62440101
> UNKNOWN
>  RA02150AT009424#Factuur _PERF29161663_Voor _Va Bene.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/
> UA0215001/1472808278632.png#f
> RA02150AT009425#pdf.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/
> UA0215001/1472808278843.png#f
> 1472808279002
> CLEA021509223370564294689844EXCC10192233705640464967
> 93C1LEA021509223370564294752110EXCC201
> PERF2020916145437 LEA021509223370564294752110EXCC201 Va Bene VA
> Beheer B.V. LEA021509223370564294689844EXCC101 VA Beheer B.V. VA
> Beheer B.V.null null null  2.1null  urn:www.cenbii.eu:
> transaction:biicoretrdm010:ver1.0:#urn:www.peppol.eu:
> bis:peppol4a:ver1.0#urn:www.simplerinvoicing.org:si:si-ubl:ver1.1.xnull
>  urn:www.cenbii.eu:profile:bii04:ver2.0null  PERF20209161454372  null
>  147275460null  3806 UNCL1001 null  EUR6 ISO 4217 Alpha null null
>  29168472  null null  pdf.pdf2  null null  RA02150AT009425#pdf.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/
> UA0215001/1472808278843.png#fpdf.pdf
> application/pdf null null  Factuur _PERF29161663_Voor _Va Bene.pdf2  null
>  PrimaryImagenull null  RA02150AT009424#Factuur _PERF29161663_Voor _Va
> Bene.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/
> UA0215001/1472808278632.png#fFactuur
> _PERF29161663_Voor _Va Bene.pdf application/pdf null null null
> 62440101ZZZ
> NL:KVK null null  2916847ZZZ NL:VAT null null  VA Beheer B.V.null null
>  Schurinkstraatnull  23null  Ommennull  7731GCnull null  NL6
> ISO3166-1:Alpha2 null null  2916847ZZZ NL:VAT null null  VAT6 UN/ECE 5153
> null null  62440101ZZZ NL:KVK null null null  55788327ZZZ NL:KVK null null
>  55788327ZZZ NL:KVK null null  Va Benenull null  Voorstraatnull  26null
>  Voorschotennull  2251BNnull null  NL6 ISO3166-1:Alpha2 null null
>  2916847ZZZ NL:VAT null null  VAT6 UN/ECE 5153 null null  55788327ZZZ
> NL:KVK null null  147517380null null null null  NL6 ISO3166-1:Alpha2
> null null  316 UNCL4461 null  147508740null  55788327-PERF29161663null
> null  29168472 IBAN null  UNKNOWNBIC null  Betaling?binnen?14?dagen op
> bankrekening?2916847?onder vermelding van?55788327/PERF29161663null null
>  3.00EUR null null  50.00EUR null  3.00EUR null null  S6 UNCL5305 null
>  6.00null null  VAT6 UN/ECE 5153 null null  50.00EUR null  50.00EUR null
>  53.00EUR null  53.00EUR null null  102  null  5.00BX null  50.00EUR null
> null  PERF2020916145437null  PERF2020916145437null null  12  null null  S6
> UNCL5305 null  6.00null null  VAT6 UN/ECE 5153 null null  10.00EUR null
>  RA02150AT009424#Factuur _PERF29161663_Voor _Va Bene.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/
> UA0215001/1472808278632.png#f
> DM001 XCNIN199751 NL:KVK:62440101 false false false false 10
> UA0215001:VB1 VB1:A02150:vbgroupnft+1:1472808278137 Ontvangen
> 1472808279002 Factuur GLDT9223370666504283001RA6DTP201 VB1 VB1
> UA0215001 RA02150AT009428 vbgroupnft+1 A02150 Group
> 55788327 Va Bene XCNL034435 Va Bene
> LEA021509223370564294752110EXCC201 vbgroupnft+1 A02150
> PERF2020916145437 Group 62440101 VA Beheer B.V. XCNL034436 VA Beheer B.V.
> LEA021509223370564294689844EXCC101
> STCUA02150011472808279078 VB1 VB1 VB1 VB1 UA0215001 true
> Factuur GLDT9223370666504283001RA6DTP201 EM0001
> NL:KVK:55788327
> vbgroupnft+1
> 10
> Va Bene
> true
> 50.00
> NL
> 10,false _s_RU_O_LEA021509223370564294689844EXCC101>
> 62440101
> XCNL034436
> 147508740
> Factuur
> 2916847
> VB1 VB1
> 31
> NL
> 53.00
> Ontvangen
> 26
> CLEA021509223370564294689844EXCC10192233705640464967
> 93C1LEA021509223370564294752110EXCC201
> XCNL034435
> VAT
> VA Beheer B.V.
> VA Beheer B.V.
> 2251BN
> Va Bene
> false
> VB1 VB1
> 55788327
> 2.1
> PERF2020916145437
> 147517380

Re: Feedback on Match Query Parser (for fixing multiterm synonyms and other things)

[Alexandre Rafalovitch]

Looks interesting.

I especially like "we analyze it" and then "we analyze/space-split it
again" as the last tutorial example.

Regards,
   Alex.
P.s. Cool enough for http://solr.cool/ ?

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 2 September 2016 at 07:45, Doug Turnbull
 wrote:
> I wanted to solicit feedback on my query parser, the match query parser (
> https://github.com/o19s/match-query-parser). It's a work in progress, so
> any thoughts from the community would be welcome.
>
> The point of this query parser is that it's not a query parser!
>
> Instead, it's a way of selecting any analyzer to apply to the query string. I
> use it for all kinds of things, finely controlling a bigram phrase search,
> searching with stemmed vs exact variants of the query.
>
> But it's biggest value to me is as a fix for multiterm synonyms. Because
> I'm not giving the user's query to any underlying query parser -- I'm
> always just doing analysis. So I know my selected analyzer will not be
> disrupted by whitespace-based query parsing prior to query analysis.
>
> Those of you also in the Elasticsearch community may be familiar with the
> match query (
> https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html
> ). This is similar, except it also lets you select whether to turn the
> resulting tokens into a term query body:(sea\ biscuit likes to fish) or a
> phrase query body:"sea biscuit" likes to fish. See the examples above for
> more.
>
> It's also similar to Solr's field query parser. However the field query
> parser tries to turn the fully analyzed token stream into a phrase query.
> Moreover, the field query parser can only select the field's own query-time
> analyzer, while the match query parser let's you select an arbitrary
> analyzer. So match has more bells and whistles and acts as a compliment to
> the field qp.
>
> Thanks for any thoughts, feedback, or critiques
>
> Best,
> -Doug

Re: Solr document missing or not getting indexed though we get 200 ok status from server

[Alexandre Rafalovitch]

I can't tell anything from the document provided. So, here would be my thoughts:

If what you see is some sort of concurrency issues, the documents
missed/dropped would unlikely be exactly the same ones. So, if you see
the same documents dropped, it is much more likely to be something to
do with documents, with handler end-points, with sharding, etc.

If this is easily reproducible, I would run a network analyzer such as
Wireshark and compare your Admin UI session with your client session
and verify that everything expected is absolutely identical.

You could also temporarily turn on Debug via Admin console (under
logs). You could turn individual elements to Trace to get low-level
information on what's happening.

Finally, I am assuming this is all happening with latest Solr? If not,
it may be worth trying that and/or checking Jira for bugs. Lots of
things have been fixed/improved in more recent Solr related to
multi-threaded, multi-server setups.

Regards,
   Alex.


Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 5 September 2016 at 00:17, Ganesh M  wrote:
> Hi Alex,
> 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   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.
> 
> 
> false
> 55788327
> false
> Factuur _PERF29161663_Voor _Va Bene.pdf
> 55788327-PERF29161663
> 3.00
> 2916847
> STCUA02150011472808279078
> EUR
> 50.00
> VAT
> 50.00
> UA0215001:VB1
> VB1:A02150:vbgroupnft+1:1472808278137
> RA02150AT009428
> 10,false
> 62440101
> UNKNOWN
>  RA02150AT009424#Factuur _PERF29161663_Voor _Va Bene.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278632.png#f
> RA02150AT009425#pdf.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278843.png#f
> 1472808279002
> CLEA021509223370564294689844EXCC1019223370564046496793C1LEA021509223370564294752110EXCC201
> PERF2020916145437 LEA021509223370564294752110EXCC201 Va Bene VA
> Beheer B.V. LEA021509223370564294689844EXCC101 VA Beheer B.V. VA
> Beheer B.V.null null null  2.1null  urn:www.cenbii.eu:
> transaction:biicoretrdm010:ver1.0:#urn:www.peppol.eu:
> bis:peppol4a:ver1.0#urn:www.simplerinvoicing.org:si:si-ubl:ver1.1.xnull
>  urn:www.cenbii.eu:profile:bii04:ver2.0null  PERF20209161454372  null
>  147275460null  3806 UNCL1001 null  EUR6 ISO 4217 Alpha null null
>  29168472  null null  pdf.pdf2  null null  RA02150AT009425#pdf.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278843.png#fpdf.pdf
> application/pdf null null  Factuur _PERF29161663_Voor _Va Bene.pdf2  null
>  PrimaryImagenull null  RA02150AT009424#Factuur _PERF29161663_Voor _Va
> Bene.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278632.png#fFactuur
> _PERF29161663_Voor _Va Bene.pdf application/pdf null null null  62440101ZZZ
> NL:KVK null null  2916847ZZZ NL:VAT null null  VA Beheer B.V.null null
>  Schurinkstraatnull  23null  Ommennull  7731GCnull null  NL6
> ISO3166-1:Alpha2 null null  2916847ZZZ NL:VAT null null  VAT6 UN/ECE 5153
> null null  62440101ZZZ NL:KVK null null null  55788327ZZZ NL:KVK null null
>  55788327ZZZ NL:KVK null null  Va Benenull null  Voorstraatnull  26null
>  Voorschotennull  2251BNnull null  NL6 ISO3166-1:Alpha2 null null
>  2916847ZZZ NL:VAT null null  VAT6 UN/ECE 5153 null null  55788327ZZZ
> NL:KVK null null  147517380null null null null  NL6 ISO3166-1:Alpha2
> null null  316 UNCL4461 null  147508740null  55788327-PERF29161663null
> null  29168472 IBAN null  UNKNOWNBIC null  Betaling?binnen?14?dagen op
> bankrekening?2916847?onder vermelding van?55788327/PERF29161663null null
>  3.00EUR null null  50.00EUR null  3.00EUR null null  S6 UNCL5305 null
>  6.00null null  VAT6 UN/ECE 5153 null null  50.00EUR null  50.00EUR null
>  53.00EUR null  53.00EUR null null  102  null  5.00BX null  50.00EUR null
> null  PERF2020916145437null  PERF2020916145437null null  12  null null  S6
> UNCL5305 null  6.00null null  VAT6 UN/ECE 5153 null null  10.00EUR null
>  RA02150AT009424#Factuur _PERF29161663_Voor _Va Bene.pdf#
> http://srv-cbe-col1.everbinding.com/thumbs/2016/9/2/A02150/UA0215001/1472808278632.png#f
> DM001 XCNIN199751 NL:KVK:62440101 false false false false 10
> UA0215001:VB1 VB1:A02150:vbgroupnft+1:1472808278137 Ontvangen
> 1472808279002 Factuur GLDT9223370666504283001RA6DTP201 VB1 VB1
> UA0215001 RA02150AT0094