Solr index clearing

[Bineesh]

Team,

We use solr 7.3.1 and Nucth 1.15.

I created two collections in solr and data successfully indexed from Nutch
after crawling. Up on the third collection index in solr, i see that first
collecion indexed data automatically clears.Pls suggest



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Solr Import

[Yasufumi Mizoguchi]

Hi,

I do not have a good idea about No. 1, but No. 2 is clear.

> 2. Delta indexing of xml file.
> We would be provided with an xml file and that would be imported to Solr
> using full-import during the first import. Subsequently we would be
> provided with changes made to the xml file (will be provided as an delta
> file) and I would need to import just the changes to the Solr using
> delta-import. When I click on delta-import, I do not see any update to the
> Solr response.
> Please guide us how we can achieve delta-import for *xml *file.

Solr itself can not detect which documents are updated from the last import
operation.
So, delta import is only supported in SqlEntityProcessor because Solr can
detect the difference
by appropriate SQL.

>From Solr ref. guide.
> For incremental imports and change detection. Only the SqlEntityProcessor
supports delta imports.
(
https://lucene.apache.org/solr/guide/7_4/uploading-structured-data-store-data-with-the-data-import-handler.html#uploading-structured-data-store-data-with-the-data-import-handler
)

So, if you use delta import, you should use SqlEntityProcessor by saving
data into RDB.

Thanks,
Yasufumi

2018年9月24日(月) 3:48 Sebastian Aswin :

> Hi Experts,
> Good Day!
>
> We are having Solr 7.4 installed in our premise and we are planning to do
> indexing of xml file. I am using data import handler to do the indexing,
> but I had few queries on the indexing.
> 1.  Within a doc tag, there are multiple store, but the Solr response
> contains only one *store value.*  With the below structure, Solr is not
> accepting the xml, so when I changed the xml structure, I was able to
> import the xml file to the Solr using the post tool and got *all *the value
> of store which was comma separated.
>
> *Snippet of the xml import file. *
>
> 
>  
>   FS4120
>   MCUS
>   
>  
>   FS4122
>   MCIN
>   MFAU
>   MCUS
>   
>  
>   FS4123
>   MFAU
>   
>   
>
> *Snippet of the data-config.xml *
>
>fileName="ProductFeed20180924-001434-719.xml$" recursive="true"
> rootEntity="false" dataSource="null" transformer="DateFormatTransformer"
> baseDir="/dataimport/ISR">
>
>   
>forEach="/ProductFeedRetailToSOLR   |  ProductFeedRetailToSOLR/doc |
> /metadata" url="${f.fileAbsolutePath}" >
>xpath="/ProductFeedRetailToSOLR/doc/sku"/>
>   
> 
>
>   What changes needs to be done to the data-config.xml so that we
> have the response similar to the output that we get while using the post
> script, that is to get *all the values of the store* that is comma
> separated in the Solr response for each document.
>
>
> 2. Delta indexing of xml file.
> We would be provided with an xml file and that would be imported to Solr
> using full-import during the first import. Subsequently we would be
> provided with changes made to the xml file (will be provided as an delta
> file) and I would need to import just the changes to the Solr using
> delta-import. When I click on delta-import, I do not see any update to the
> Solr response.
> Please guide us how we can achieve delta-import for *xml *file.
>
> Thanks for the time and advice in advance.
>
> --
> Regards,
> Ashwin
>

Re: Metrics

[Erick Erickson]

The other caches (filterCache, queryResultCache) only have meaning for
the current searcher opened. Whenever a soft or
hard-commit-with-opensearcher-true, those caches are all reset to 0
and stats start accumulating until the _next_ commit. So depending on
when you look you might see a cache that's just been cleared because a
new searcher has been opened or one that's been in use for a long
time.

However, there is a cumulative section for those two caches. The
cumulative section accumulates the statistics since Solr was started.
That section should be much more stable on a system that's been
running for a while. Of course those all start out at zero when you
start Solr.

Whether the HDFS cache stats follow the same pattern, I don't know.

Best,
Erick
On Mon, Sep 24, 2018 at 3:22 PM Jean-Marc Spaggiari
 wrote:
>
> It might be similar to the other cache.. Do you have any pointer the the
> LRUCache documentation? I want to see what kind of metrics it uses and see
> if it's similar or not
> to solr/core/src/java/org/apache/solr/core/HdfsDirectoryFactory.java,,,
>
> Le lun. 24 sept. 2018 à 18:04, Shawn Heisey  a écrit :
>
> > On 9/24/2018 3:43 PM, Jean-Marc Spaggiari wrote:
> > > Thanks for taking a look. My indexes are on HDFS. And I configured all
> > the
> > > solr parameters for that. The "shard page" is when I click on a SOLR
> > server
> > > to go to the UI, then in the dropdown on the left I select a shard (a
> > > leader one), then I click on "plugins/stats". And then I open
> > > "HdfsBlockCache".  There from time to time I can see some numbers, but
> > when
> > > I keep refreshing it comes back to 0 always, and I have no clues what is
> > > into the cache, or even if it just work :(
> >
> > Apologies for jumping into a world where I can't offer any help.  I have
> > never used HDFS, so things like this that are related to it are an
> > unknown to me.  I understand most of the other things in Plugins/Stats,
> > but not that one.
> >
> > Thanks,
> > Shawn
> >
> >

Re: Metrics

[Jean-Marc Spaggiari]

It might be similar to the other cache.. Do you have any pointer the the
LRUCache documentation? I want to see what kind of metrics it uses and see
if it's similar or not
to solr/core/src/java/org/apache/solr/core/HdfsDirectoryFactory.java,,,

Le lun. 24 sept. 2018 à 18:04, Shawn Heisey  a écrit :

> On 9/24/2018 3:43 PM, Jean-Marc Spaggiari wrote:
> > Thanks for taking a look. My indexes are on HDFS. And I configured all
> the
> > solr parameters for that. The "shard page" is when I click on a SOLR
> server
> > to go to the UI, then in the dropdown on the left I select a shard (a
> > leader one), then I click on "plugins/stats". And then I open
> > "HdfsBlockCache".  There from time to time I can see some numbers, but
> when
> > I keep refreshing it comes back to 0 always, and I have no clues what is
> > into the cache, or even if it just work :(
>
> Apologies for jumping into a world where I can't offer any help.  I have
> never used HDFS, so things like this that are related to it are an
> unknown to me.  I understand most of the other things in Plugins/Stats,
> but not that one.
>
> Thanks,
> Shawn
>
>

Re: Metrics

[Shawn Heisey]

On 9/24/2018 3:43 PM, Jean-Marc Spaggiari wrote:

Thanks for taking a look. My indexes are on HDFS. And I configured all the
solr parameters for that. The "shard page" is when I click on a SOLR server
to go to the UI, then in the dropdown on the left I select a shard (a
leader one), then I click on "plugins/stats". And then I open
"HdfsBlockCache".  There from time to time I can see some numbers, but when
I keep refreshing it comes back to 0 always, and I have no clues what is
into the cache, or even if it just work :(


Apologies for jumping into a world where I can't offer any help.  I have 
never used HDFS, so things like this that are related to it are an 
unknown to me.  I understand most of the other things in Plugins/Stats, 
but not that one.


Thanks,
Shawn

Re: Metrics

[Jean-Marc Spaggiari]

Hi Shawn,

Thanks for taking a look. My indexes are on HDFS. And I configured all the
solr parameters for that. The "shard page" is when I click on a SOLR server
to go to the UI, then in the dropdown on the left I select a shard (a
leader one), then I click on "plugins/stats". And then I open
"HdfsBlockCache".  There from time to time I can see some numbers, but when
I keep refreshing it comes back to 0 always, and I have no clues what is
into the cache, or even if it just work :(

Thanks,

JMS

Le lun. 24 sept. 2018 à 17:39, Shawn Heisey  a écrit :

> On 9/24/2018 2:05 PM, Jean-Marc Spaggiari wrote:
> > I'm running a fairly old version of SOLR (4.x) and I found the metrics on
> > the shard page. However, sometimes there is numbers, sometimes it's all
> 0.
> > Just hitting the refresh button shows this.
> >
> > I'm aware of https://issues.apache.org/jira/browse/SOLR-10214
> > so
> > I'm not concerned about the empty number, but I'm wondering what the
> > reasoning in the others. As an example, when I keep refreshing, the hit
> > ratio varies between 0 and 0.9 with almost all possible values :-/
> >
> > So how are those metrics working?
>
> What specifically are you looking at?  You mention "the shard page" but
> I really have no idea what that means.
>
> The code touched by SOLR-10214 is only used in Solr's HDFS support.  If
> you're not running with indexes in HDFS, then that will have no impact
> on your system.
>
> Thanks,
> Shawn
>
>

Re: Metrics

[Shawn Heisey]

On 9/24/2018 2:05 PM, Jean-Marc Spaggiari wrote:

I'm running a fairly old version of SOLR (4.x) and I found the metrics on
the shard page. However, sometimes there is numbers, sometimes it's all 0.
Just hitting the refresh button shows this.

I'm aware of https://issues.apache.org/jira/browse/SOLR-10214
so
I'm not concerned about the empty number, but I'm wondering what the
reasoning in the others. As an example, when I keep refreshing, the hit
ratio varies between 0 and 0.9 with almost all possible values :-/

So how are those metrics working?


What specifically are you looking at?  You mention "the shard page" but 
I really have no idea what that means.


The code touched by SOLR-10214 is only used in Solr's HDFS support.  If 
you're not running with indexes in HDFS, then that will have no impact 
on your system.


Thanks,
Shawn

Metrics

[Jean-Marc Spaggiari]

Hi,

I'm running a fairly old version of SOLR (4.x) and I found the metrics on
the shard page. However, sometimes there is numbers, sometimes it's all 0.
Just hitting the refresh button shows this.

I'm aware of https://issues.apache.org/jira/browse/SOLR-10214

so
I'm not concerned about the empty number, but I'm wondering what the
reasoning in the others. As an example, when I keep refreshing, the hit
ratio varies between 0 and 0.9 with almost all possible values :-/

So how are those metrics working?

Thanks,

JMS

[ANNOUNCE] Solr Reference Guide for 7.5 released

[Cassandra Targett]

The Lucene PMC is pleased to announce that the Solr Reference Guide for
Solr 7.5 is now available.

This 1,389 page PDF is the definitive guide to Apache Solr, the search
server built on Apache Lucene.

The PDF can be downloaded from:
https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide/apache-solr-ref-guide-7.5.pdf

The Guide is also available online, at
https://lucene.apache.org/solr/guide/7_5.

Regards,
Lucene PMC

Re: checksum failed (hardware problem?)

[Susheel Kumar]

Got it. I'll have first hardware folks check and if they don't see/find
anything suspicious then i'll return here.

Wondering if any body has seen similar error and if they were able to
confirm if it was hardware fault or so.

Thnx

On Mon, Sep 24, 2018 at 1:01 PM Erick Erickson 
wrote:

> Mind you it could _still_ be Solr/Lucene, but let's check the hardware
> first ;)
> On Mon, Sep 24, 2018 at 9:50 AM Susheel Kumar 
> wrote:
> >
> > Hi Erick,
> >
> > Thanks so much for your reply.  I'll now look mostly into any possible
> > hardware issues than Solr/Lucene.
> >
> > Thanks again.
> >
> > On Mon, Sep 24, 2018 at 12:43 PM Erick Erickson  >
> > wrote:
> >
> > > There are several of reasons this would "suddenly" start appearing.
> > > 1> Your disk went bad and some sector is no longer faithfully
> > > recording the bits. In this case the checksum will be wrong
> > > 2> You ran out of disk space sometime and the index was corrupted.
> > > This isn't really a hardware problem.
> > > 3> Your disk controller is going wonky and not reading reliably.
> > >
> > > The "possible hardware issue" message is to alert you that this is
> > > highly unusual and you should at leasts consider doing integrity
> > > checks on your disk before assuming it's a Solr/Lucene problem
> > >
> > > Best,
> > > Erick
> > > On Mon, Sep 24, 2018 at 9:26 AM Susheel Kumar 
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > I am still trying to understand the corrupt index exception we saw
> in our
> > > > logs. What does the hardware problem comment indicates here?  Does
> that
> > > > mean it caused most likely due to hardware issue?
> > > >
> > > > We never had this problem in last couple of months. The Solr is
> 6.6.2 and
> > > > ZK: 3.4.10.
> > > >
> > > > Please share your thoughts.
> > > >
> > > > Thanks,
> > > > Susheel
> > > >
> > > > Caused by: org.apache.lucene.index.CorruptIndexException: checksum
> > > > failed *(hardware
> > > > problem?)* : expected=db243d1a actual=7a00d3d2
> > > >
> > >
> (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard1_replica1/data/index/_i27s.cfs")
> > > > [slice=_i27s_Lucene50_0.tim])
> > > >
> > > > It suddenly started in the logs and before which there was no such
> error.
> > > > Searches & ingestions all seems to be working prior to that.
> > > >
> > > > 
> > > >
> > > > 2018-09-03 17:16:49.056 INFO  (qtp834133664-519872) [c:COLL s:shard1
> > > > r:core_node1 x:COLL_shard1_replica1]
> > > > o.a.s.u.p.StatelessScriptUpdateProcessorFactory
> update-script#processAdd:
> > > >
> newid=G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US
> > > > 2018-09-03 17:16:49.057 ERROR (qtp834133664-519872) [c:COLL s:shard1
> > > > r:core_node1 x:COLL_shard1_replica1] o.a.s.h.RequestHandlerBase
> > > > org.apache.solr.common.SolrException: Exception writing document id
> > > > G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US
> to
> > > the
> > > > index; possible analysis error.
> > > > at
> > > >
> > >
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> > > > at
> > > >
> > >
> org.apache.solr.update.processor.StatelessScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(StatelessScriptUpdateProcessorFactory.java:380)
> > > > at
> > > >
> > >
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
> > > > at
> > > >
> > >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
> > > > at
> > > >
> > >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
> > > > at
> > > >
> > >
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
> > > > at
> > > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> > > > at
> > > >
> > >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:122)
> > > > at
> > > >
> > >
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271)
> > > > at
> > > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> > > > at

Re: checksum failed (hardware problem?)

[Erick Erickson]

Mind you it could _still_ be Solr/Lucene, but let's check the hardware first ;)
On Mon, Sep 24, 2018 at 9:50 AM Susheel Kumar  wrote:
>
> Hi Erick,
>
> Thanks so much for your reply.  I'll now look mostly into any possible
> hardware issues than Solr/Lucene.
>
> Thanks again.
>
> On Mon, Sep 24, 2018 at 12:43 PM Erick Erickson 
> wrote:
>
> > There are several of reasons this would "suddenly" start appearing.
> > 1> Your disk went bad and some sector is no longer faithfully
> > recording the bits. In this case the checksum will be wrong
> > 2> You ran out of disk space sometime and the index was corrupted.
> > This isn't really a hardware problem.
> > 3> Your disk controller is going wonky and not reading reliably.
> >
> > The "possible hardware issue" message is to alert you that this is
> > highly unusual and you should at leasts consider doing integrity
> > checks on your disk before assuming it's a Solr/Lucene problem
> >
> > Best,
> > Erick
> > On Mon, Sep 24, 2018 at 9:26 AM Susheel Kumar 
> > wrote:
> > >
> > > Hello,
> > >
> > > I am still trying to understand the corrupt index exception we saw in our
> > > logs. What does the hardware problem comment indicates here?  Does that
> > > mean it caused most likely due to hardware issue?
> > >
> > > We never had this problem in last couple of months. The Solr is 6.6.2 and
> > > ZK: 3.4.10.
> > >
> > > Please share your thoughts.
> > >
> > > Thanks,
> > > Susheel
> > >
> > > Caused by: org.apache.lucene.index.CorruptIndexException: checksum
> > > failed *(hardware
> > > problem?)* : expected=db243d1a actual=7a00d3d2
> > >
> > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard1_replica1/data/index/_i27s.cfs")
> > > [slice=_i27s_Lucene50_0.tim])
> > >
> > > It suddenly started in the logs and before which there was no such error.
> > > Searches & ingestions all seems to be working prior to that.
> > >
> > > 
> > >
> > > 2018-09-03 17:16:49.056 INFO  (qtp834133664-519872) [c:COLL s:shard1
> > > r:core_node1 x:COLL_shard1_replica1]
> > > o.a.s.u.p.StatelessScriptUpdateProcessorFactory update-script#processAdd:
> > > newid=G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US
> > > 2018-09-03 17:16:49.057 ERROR (qtp834133664-519872) [c:COLL s:shard1
> > > r:core_node1 x:COLL_shard1_replica1] o.a.s.h.RequestHandlerBase
> > > org.apache.solr.common.SolrException: Exception writing document id
> > > G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US to
> > the
> > > index; possible analysis error.
> > > at
> > >
> > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
> > > at
> > >
> > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> > > at
> > >
> > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> > > at
> > >
> > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
> > > at
> > >
> > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
> > > at
> > >
> > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
> > > at
> > >
> > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> > > at
> > >
> > org.apache.solr.update.processor.StatelessScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(StatelessScriptUpdateProcessorFactory.java:380)
> > > at
> > >
> > org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
> > > at
> > >
> > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
> > > at
> > >
> > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
> > > at
> > >
> > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
> > > at
> > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> > > at
> > >
> > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:122)
> > > at
> > >
> > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271)
> > > at
> > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> > > at
> > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:173)
> > > at
> > >
> > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:187)
> > > at
> > >
> > org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108)
> > > at
> > org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)
> > > at
> > >
> > org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
> > > at
> > >
> > org.apache.solr.handler.ContentStreamHandlerBa

Re: checksum failed (hardware problem?)

[Susheel Kumar]

Hi Erick,

Thanks so much for your reply.  I'll now look mostly into any possible
hardware issues than Solr/Lucene.

Thanks again.

On Mon, Sep 24, 2018 at 12:43 PM Erick Erickson 
wrote:

> There are several of reasons this would "suddenly" start appearing.
> 1> Your disk went bad and some sector is no longer faithfully
> recording the bits. In this case the checksum will be wrong
> 2> You ran out of disk space sometime and the index was corrupted.
> This isn't really a hardware problem.
> 3> Your disk controller is going wonky and not reading reliably.
>
> The "possible hardware issue" message is to alert you that this is
> highly unusual and you should at leasts consider doing integrity
> checks on your disk before assuming it's a Solr/Lucene problem
>
> Best,
> Erick
> On Mon, Sep 24, 2018 at 9:26 AM Susheel Kumar 
> wrote:
> >
> > Hello,
> >
> > I am still trying to understand the corrupt index exception we saw in our
> > logs. What does the hardware problem comment indicates here?  Does that
> > mean it caused most likely due to hardware issue?
> >
> > We never had this problem in last couple of months. The Solr is 6.6.2 and
> > ZK: 3.4.10.
> >
> > Please share your thoughts.
> >
> > Thanks,
> > Susheel
> >
> > Caused by: org.apache.lucene.index.CorruptIndexException: checksum
> > failed *(hardware
> > problem?)* : expected=db243d1a actual=7a00d3d2
> >
> (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard1_replica1/data/index/_i27s.cfs")
> > [slice=_i27s_Lucene50_0.tim])
> >
> > It suddenly started in the logs and before which there was no such error.
> > Searches & ingestions all seems to be working prior to that.
> >
> > 
> >
> > 2018-09-03 17:16:49.056 INFO  (qtp834133664-519872) [c:COLL s:shard1
> > r:core_node1 x:COLL_shard1_replica1]
> > o.a.s.u.p.StatelessScriptUpdateProcessorFactory update-script#processAdd:
> > newid=G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US
> > 2018-09-03 17:16:49.057 ERROR (qtp834133664-519872) [c:COLL s:shard1
> > r:core_node1 x:COLL_shard1_replica1] o.a.s.h.RequestHandlerBase
> > org.apache.solr.common.SolrException: Exception writing document id
> > G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US to
> the
> > index; possible analysis error.
> > at
> >
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
> > at
> >
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> > at
> >
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> > at
> >
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
> > at
> >
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
> > at
> >
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
> > at
> >
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> > at
> >
> org.apache.solr.update.processor.StatelessScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(StatelessScriptUpdateProcessorFactory.java:380)
> > at
> >
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
> > at
> >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
> > at
> >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
> > at
> >
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
> > at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> > at
> >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:122)
> > at
> >
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271)
> > at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> > at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:173)
> > at
> >
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:187)
> > at
> >
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108)
> > at
> org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)
> > at
> >
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
> > at
> >
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
> > at
> >
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
> > at
> >
> o

Re: checksum failed (hardware problem?)

[Erick Erickson]

There are several of reasons this would "suddenly" start appearing.
1> Your disk went bad and some sector is no longer faithfully
recording the bits. In this case the checksum will be wrong
2> You ran out of disk space sometime and the index was corrupted.
This isn't really a hardware problem.
3> Your disk controller is going wonky and not reading reliably.

The "possible hardware issue" message is to alert you that this is
highly unusual and you should at leasts consider doing integrity
checks on your disk before assuming it's a Solr/Lucene problem

Best,
Erick
On Mon, Sep 24, 2018 at 9:26 AM Susheel Kumar  wrote:
>
> Hello,
>
> I am still trying to understand the corrupt index exception we saw in our
> logs. What does the hardware problem comment indicates here?  Does that
> mean it caused most likely due to hardware issue?
>
> We never had this problem in last couple of months. The Solr is 6.6.2 and
> ZK: 3.4.10.
>
> Please share your thoughts.
>
> Thanks,
> Susheel
>
> Caused by: org.apache.lucene.index.CorruptIndexException: checksum
> failed *(hardware
> problem?)* : expected=db243d1a actual=7a00d3d2
> (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard1_replica1/data/index/_i27s.cfs")
> [slice=_i27s_Lucene50_0.tim])
>
> It suddenly started in the logs and before which there was no such error.
> Searches & ingestions all seems to be working prior to that.
>
> 
>
> 2018-09-03 17:16:49.056 INFO  (qtp834133664-519872) [c:COLL s:shard1
> r:core_node1 x:COLL_shard1_replica1]
> o.a.s.u.p.StatelessScriptUpdateProcessorFactory update-script#processAdd:
> newid=G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US
> 2018-09-03 17:16:49.057 ERROR (qtp834133664-519872) [c:COLL s:shard1
> r:core_node1 x:COLL_shard1_replica1] o.a.s.h.RequestHandlerBase
> org.apache.solr.common.SolrException: Exception writing document id
> G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US to the
> index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.StatelessScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(StatelessScriptUpdateProcessorFactory.java:380)
> at
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:122)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
> at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:173)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:187)
> at
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108)
> at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> a

Re: Is there an easy way to compare schemas?

[Shawn Heisey]

On 9/24/2018 9:28 AM, Michael Joyner wrote:

Is there an easy way to compare schemas?

When upgrading nodes, we are wanting to compare the "core" and 
"automatically mapped" data types between our existing schema and the 
new manage-schema available as part of the upgraded distrubtion.


There is no difference in the format between schema.xml with the Classic 
schema factory and managed-schema with the new factory. The difference 
is that managed-schema can be changed by Solr, and schema.xml could only 
be changed externally to Solr.


And for the most part, the format for new versions is the same as the 
format for old versions.  At some point the  and  tags 
became optional - they are no longer required.


Because the basic format hasn't changed, if the two files are mostly 
similar, you can simply diff the schema.xml in your older version with 
the managed-schema in the newer version.  It might be a good idea to use 
the option for diff that ignores differences in whitespace.  If the 
files are substantially different in how they are laid out, then you 
might need to manually compare them.


Thanks,
Shawn

checksum failed (hardware problem?)

[Susheel Kumar]

Hello,

I am still trying to understand the corrupt index exception we saw in our
logs. What does the hardware problem comment indicates here?  Does that
mean it caused most likely due to hardware issue?

We never had this problem in last couple of months. The Solr is 6.6.2 and
ZK: 3.4.10.

Please share your thoughts.

Thanks,
Susheel

Caused by: org.apache.lucene.index.CorruptIndexException: checksum
failed *(hardware
problem?)* : expected=db243d1a actual=7a00d3d2
(resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard1_replica1/data/index/_i27s.cfs")
[slice=_i27s_Lucene50_0.tim])

It suddenly started in the logs and before which there was no such error.
Searches & ingestions all seems to be working prior to that.



2018-09-03 17:16:49.056 INFO  (qtp834133664-519872) [c:COLL s:shard1
r:core_node1 x:COLL_shard1_replica1]
o.a.s.u.p.StatelessScriptUpdateProcessorFactory update-script#processAdd:
newid=G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US
2018-09-03 17:16:49.057 ERROR (qtp834133664-519872) [c:COLL s:shard1
r:core_node1 x:COLL_shard1_replica1] o.a.s.h.RequestHandlerBase
org.apache.solr.common.SolrException: Exception writing document id
G31MXMRZESC0CYPR!A-G31MXMRZESC0CYPR.2552019802_1-2552008480_1-en_US to the
index; possible analysis error.
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.StatelessScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(StatelessScriptUpdateProcessorFactory.java:380)
at
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
at
org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:122)
at
org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271)
at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:173)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:187)
at
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108)
at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at
org.eclipse.jetty.server.h

Re: Is there an easy way to compare schemas?

[Alexandre Rafalovitch]

I think the easiest would be to create two instances using those
schemas and then see what comes back from schema API:
http://lucene.apache.org/solr/guide/7_4/schema-api.html#retrieve-schema-information

That will give you the outputs in the consistent format, you can just
run diff on.

However, if you want to actually do a graph analysis on
explicit+dynamic fields -> definitions, then it is a bit more work.
Doable, but is a mini-project. I did something similar before, but the
code is not open-source at this moment. And it really depends on what
_very specific_ question you are trying to answer. For example, it is
not clear whether any example schema dynamic field should be part of
the "used" calculation just because it exists...

Regards,
   Alex.

On 24 September 2018 at 11:28, Michael Joyner  wrote:
> Is there an easy way to compare schemas?
>
> When upgrading nodes, we are wanting to compare the "core" and
> "automatically mapped" data types between our existing schema and the new
> manage-schema available as part of the upgraded distrubtion.

Is there an easy way to compare schemas?

[Michael Joyner]

Is there an easy way to compare schemas?

When upgrading nodes, we are wanting to compare the "core" and 
"automatically mapped" data types between our existing schema and the 
new manage-schema available as part of the upgraded distrubtion.

Re: Query with exact number of tokens

[Sergio García Maroto]

Thanks all for your ideas. It was very useful information.

On Fri, 21 Sep 2018 at 19:04, Jan Høydahl  wrote:

> I have made a FieldType specially for this
> https://github.com/cominvent/exactmatch/ <
> https://github.com/cominvent/exactmatch/>
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 21. sep. 2018 kl. 18:14 skrev Steve Rowe :
> >
> > Link correction - wrong fragment identifier in ref #5 - should be:
> >
> > [5]
> https://lucene.apache.org/solr/guide/7_4/other-parsers.html#function-range-query-parser
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> >> On Sep 21, 2018, at 12:04 PM, Steve Rowe  wrote:
> >>
> >> Hi Sergio,
> >>
> >> Chris “Hoss” Hostetter has a solution to this kind of problem here:
> https://lists.apache.org/thread.html/6b0f0cb864aa55f0a9eadfd92d27d374ab8deb16e8131ed2b7234463@%3Csolr-user.lucene.apache.org%3E
> . See also the suggestions in comments on SOLR-12673[1], which include a
> version of Hoss’ss solution.
> >>
> >> Hoss’ss solution assumes a multivalued StrField with values counted
> using CountFieldValuesUpdateProcessorFactory, which doesn’t apply to you.
> You could instead count unique tokens in an analyzed field using the
> StatelessScriptUpdateProcessorFactory[2][3], e.g. see slides 10&11 of Erik
> Hatcher’s Lucene/Solr Revolution 2013 talk[4].
> >>
> >> Your script could look something like this (untested; replace " type>” with your field type):
> >>
> >> =
> >> function getUniqueTokenCount(analyzer, fieldName, fieldValue) {
> >> var uniqueTokens = {};
> >> var stream = analyzer.tokenStream(fieldName, fieldValue);
> >> var termAttr =
> stream.getAttribute(Packages.org.apache.lucene.analysis.tokenattributes.CharTermAttribute);
> >> stream.reset();
> >> while (stream.incrementToken()) { uniqueTokens[termAttr.toString()] =
> 1; }
> >> stream.end();
> >> stream.close();
> >> return Object.keys(uniqueTokens).length;
> >> }
> >> function processAdd(cmd) {
> >> var analyzer =
> req.getCore().getLatestSchema().getFieldTypeByName(" type>").getIndexAnalyzer();
> >> doc.setField(“unique_token_count_i", getUniqueTokenCount(analyzer,
> null, content));
> >> }
> >> function processDelete(cmd) { }
> >> function processMergeIndexes(cmd) { }
> >> function processCommit(cmd) { }
> >> function processRollback(cmd) { }
> >> function finish() { }
> >> =
> >>
> >> And your query could then look something like (replace "” with
> your field name)[5][6]:
> >>
> >> =
> >> fq={!frange l=0
> h=0}sub(unique_token_count_i,sum(termfreq(,’CENTURY’),termfreq(,’BANCORP’),termfreq(,‘INC’)))
> >> =
> >>
> >> Note that to construct the query ^^ you’ll need to tokenize and
> uniquify terms on the client side - if tokenization is non-trivial, you
> could use Solr's Field Analysis API[8] to perform tokenization for you.
> >>
> >> [1] https://issues.apache.org/jira/browse/SOLR-12673
> >> [2] https://wiki.apache.org/solr/ScriptUpdateProcessor
> >> [3]
> https://lucene.apache.org/solr/7_4_0/solr-core/org/apache/solr/update/processor/StatelessScriptUpdateProcessorFactory.html
> >> [4]
> https://www.slideshare.net/erikhatcher/solr-indexing-and-analysis-tricks
> >> [5]
> https://lucene.apache.org/solr/guide/7_4/other-parsers.html#OtherParsers-FunctionRangeQueryParser
> >> [6]
> https://lucene.apache.org/solr/guide/7_4/function-queries.html#termfreq-function
> >> [7]
> https://lucene.apache.org/solr/guide/7_4/function-queries.html#sub-function
> >> [8]
> https://lucene.apache.org/solr/guide/7_4/implicit-requesthandlers.html#analysis-handlers
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >>> On Sep 21, 2018, at 10:45 AM, Erick Erickson 
> wrote:
> >>>
> >>> A variant on Alexandre's approach is:
> >>> at index time, count the tokens that will be produced yourself (this
> >>> may be a little tricky, you shouldn't have WordDelimiterFilterFactory
> >>> in your analysis for instance).
> >>> Put the number of tokens in a separate field
> >>> At query time, you'd search q=+company_name:(+century +bancorp +inc)
> >>> +tokens_in_company_name_field:3
> >>>
> >>> You don't need phrase queries with this approach, order doesn't matter.
> >>>
> >>> It can get tricky though, should "CENTURY BANCORP, INC." and "CENTURY
> >>> BANCORP, INCORPORATED." match?
> >>>
> >>> Again, though, this means your indexing code has to do the same thing
> >>> as your analysis chain. Which isn't very hard if the analysis chain is
> >>> simple. I might use a char _filter_ factory to remove all
> >>> non-alphanumeric characters, then a whitespace tokenizer and
> >>> (probably) a lowercasefilter. That's pretty easy to replicate in order
> >>> to count tokens.
> >>>
> >>> Best,
> >>> Erick
> >>> On Fri, Sep 21, 2018 at 7:18 AM Alexandre Rafalovitch
> >>>  wrote:
> 
>  I think you can match everything in the query to the field using
> either
>  1) disMax/eDisMax with mm=100%
> 
> https://lucene.apache.org/solr/guide/7_4/the-dismax-query-parser.html#mm-minimum-should-match-par

Solr Import

[Sebastian Aswin]

Hi Experts,
Good Day!

We are having Solr 7.4 installed in our premise and we are planning to do
indexing of xml file. I am using data import handler to do the indexing,
but I had few queries on the indexing.
1.  Within a doc tag, there are multiple store, but the Solr response
contains only one *store value.*  With the below structure, Solr is not
accepting the xml, so when I changed the xml structure, I was able to
import the xml file to the Solr using the post tool and got *all *the value
of store which was comma separated.

*Snippet of the xml import file. *


 
  FS4120
  MCUS
  
 
  FS4122
  MCIN
  MFAU
  MCUS
  
 
  FS4123
  MFAU
  
  

*Snippet of the data-config.xml *

  

  
  
  
  


  What changes needs to be done to the data-config.xml so that we
have the response similar to the output that we get while using the post
script, that is to get *all the values of the store* that is comma
separated in the Solr response for each document.


2. Delta indexing of xml file.
We would be provided with an xml file and that would be imported to Solr
using full-import during the first import. Subsequently we would be
provided with changes made to the xml file (will be provided as an delta
file) and I would need to import just the changes to the Solr using
delta-import. When I click on delta-import, I do not see any update to the
Solr response.
Please guide us how we can achieve delta-import for *xml *file.

Thanks for the time and advice in advance.

-- 
Regards,
Ashwin

[ANNOUNCE] Apache Solr 7.5.0 released

[jim ferenczi]

24 September 2018, Apache Solr™ 7.5.0 available

The Lucene PMC is pleased to announce the release of Apache Solr 7.5.0

Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search, dynamic clustering, database
integration, rich document (e.g., Word, PDF) handling, and geospatial
search. Solr is highly scalable, providing fault tolerant distributed
search and indexing, and powers the search and navigation features of many
of the world's largest internet sites.

Solr 7.5.0 is available for immediate download at:
http://lucene.apache.org/solr/downloads.html

See http://lucene.apache.org/solr/7_5_0/changes/Changes.html for a full
list of details.

Solr 7.5.0 Release Highlights:

  Nested/child documents may now be supplied as a field value instead of
stand-off. Future releases will leverage this semantic information.
  Enhance Autoscaling policy support to equally distribute replicas on the
basis of arbitrary properties.
  Nodes are now visible inside a view of the Admin UI "Cloud" tab, listing
nodes and key metrics.
  The status of zookeeper ensemble is now accessible under the Admin UI
Cloud tab.
  The new Korean morphological analyzer ("nori") has been added to default
distribution.

You are encouraged to thoroughly read the "Upgrade Notes" at
http://lucene.apache.org/solr/7_5_0/changes/Changes.html or in the
CHANGES.txt file accompanying the release.

Solr 7.5 also includes many other new features as well as numerous
optimizations and bugfixes of the corresponding Apache Lucene release.

Please report any feedback to the mailing lists (
http://lucene.apache.org/solr/community.html#mailing-lists-irc)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also goes for Maven access.