[Migration Solr5 to Solr6] Unwanted deleted files references

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Migration Solr5 to Solr6] Unwanted deleted files references

Elodie Sannier
Hello,

We have migrated from Solr 5.4.1 to Solr 6.4.0 and the disk usage has increased.
We found hundreds of references to deleted index files being held by solr.
Before the migration, we had 15-30% of disk space used, after the migration we have 60-90% of disk space used.

We are using Solr Cloud with 2 collections.

The commands applied on the collections are:
- for incremental indexation mode: add, deleteById with commitWithin of 30 minutes
- for full indexation mode: add, deleteById, commit
- for switch between incremental and full mode: deleteByQuery, createAlias, reload
- there is also an autocommit every 15 minutes

We have seen the email "Solr leaking references to deleted files"  2016-05-31 which describe the same problem but the mentioned bugs are fixed.

We manually tried to force a commit, a reload and an optimize on the collections without effect.

Is a problem of configuration (merge / delete policy) or a possible regression in the Solr code ?

Thank you


Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Erick Erickson
Just as a sanity check, if you restart the Solr JVM, do the files
disappear from disk?

Do you have any custom code anywhere in this chain? If so, do you open
any searchers but
fail to close them? Although why 6.4 would manifest the problem but
other code wouldn't
is a mystery, just another sanity check.

Best,
Erick

On Tue, Mar 7, 2017 at 6:44 AM, Elodie Sannier <[hidden email]> wrote:

> Hello,
>
> We have migrated from Solr 5.4.1 to Solr 6.4.0 and the disk usage has
> increased.
> We found hundreds of references to deleted index files being held by solr.
> Before the migration, we had 15-30% of disk space used, after the migration
> we have 60-90% of disk space used.
>
> We are using Solr Cloud with 2 collections.
>
> The commands applied on the collections are:
> - for incremental indexation mode: add, deleteById with commitWithin of 30
> minutes
> - for full indexation mode: add, deleteById, commit
> - for switch between incremental and full mode: deleteByQuery, createAlias,
> reload
> - there is also an autocommit every 15 minutes
>
> We have seen the email "Solr leaking references to deleted files"
> 2016-05-31 which describe the same problem but the mentioned bugs are fixed.
>
> We manually tried to force a commit, a reload and an optimize on the
> collections without effect.
>
> Is a problem of configuration (merge / delete policy) or a possible
> regression in the Solr code ?
>
> Thank you
>
>
> Kelkoo SAS
> Société par Actions Simplifiée
> Au capital de € 4.168.964,30
> Siège social : 158 Ter Rue du Temple 75003 Paris
> 425 093 069 RCS Paris
>
> Ce message et les pièces jointes sont confidentiels et établis à l'attention
> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
> message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Alexandre Rafalovitch
More sanity checks: what are the extensions/types of the files that
are not deleted?

If they are index files, optimize command (even if no longer
recommended for production) should really blow all the old ones away.
So, are they other kinds of files?

Regards,
   Alex.
----
http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 7 March 2017 at 09:55, Erick Erickson <[hidden email]> wrote:

> Just as a sanity check, if you restart the Solr JVM, do the files
> disappear from disk?
>
> Do you have any custom code anywhere in this chain? If so, do you open
> any searchers but
> fail to close them? Although why 6.4 would manifest the problem but
> other code wouldn't
> is a mystery, just another sanity check.
>
> Best,
> Erick
>
> On Tue, Mar 7, 2017 at 6:44 AM, Elodie Sannier <[hidden email]> wrote:
>> Hello,
>>
>> We have migrated from Solr 5.4.1 to Solr 6.4.0 and the disk usage has
>> increased.
>> We found hundreds of references to deleted index files being held by solr.
>> Before the migration, we had 15-30% of disk space used, after the migration
>> we have 60-90% of disk space used.
>>
>> We are using Solr Cloud with 2 collections.
>>
>> The commands applied on the collections are:
>> - for incremental indexation mode: add, deleteById with commitWithin of 30
>> minutes
>> - for full indexation mode: add, deleteById, commit
>> - for switch between incremental and full mode: deleteByQuery, createAlias,
>> reload
>> - there is also an autocommit every 15 minutes
>>
>> We have seen the email "Solr leaking references to deleted files"
>> 2016-05-31 which describe the same problem but the mentioned bugs are fixed.
>>
>> We manually tried to force a commit, a reload and an optimize on the
>> collections without effect.
>>
>> Is a problem of configuration (merge / delete policy) or a possible
>> regression in the Solr code ?
>>
>> Thank you
>>
>>
>> Kelkoo SAS
>> Société par Actions Simplifiée
>> Au capital de € 4.168.964,30
>> Siège social : 158 Ter Rue du Temple 75003 Paris
>> 425 093 069 RCS Paris
>>
>> Ce message et les pièces jointes sont confidentiels et établis à l'attention
>> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
>> message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Elodie Sannier
In reply to this post by Erick Erickson
Thank you Erick for your answer.

The files are deleted even without JVM restart but they are still seen
as DELETED by the kernel.

We have a custom code and for the migration to Solr 6.4.0 we have added
a new code with req.getSearcher() but without "close".
We will decrement the reference count on a resource for the Searcher
(prevent the Searcher remains open after a commit) and see if it fixes
the problem.

Elodie

On 03/07/2017 03:55 PM, Erick Erickson wrote:

> Just as a sanity check, if you restart the Solr JVM, do the files
> disappear from disk?
>
> Do you have any custom code anywhere in this chain? If so, do you open
> any searchers but
> fail to close them? Although why 6.4 would manifest the problem but
> other code wouldn't
> is a mystery, just another sanity check.
>
> Best,
> Erick
>
> On Tue, Mar 7, 2017 at 6:44 AM, Elodie Sannier <[hidden email]> wrote:
>> Hello,
>>
>> We have migrated from Solr 5.4.1 to Solr 6.4.0 and the disk usage has
>> increased.
>> We found hundreds of references to deleted index files being held by solr.
>> Before the migration, we had 15-30% of disk space used, after the migration
>> we have 60-90% of disk space used.
>>
>> We are using Solr Cloud with 2 collections.
>>
>> The commands applied on the collections are:
>> - for incremental indexation mode: add, deleteById with commitWithin of 30
>> minutes
>> - for full indexation mode: add, deleteById, commit
>> - for switch between incremental and full mode: deleteByQuery, createAlias,
>> reload
>> - there is also an autocommit every 15 minutes
>>
>> We have seen the email "Solr leaking references to deleted files"
>> 2016-05-31 which describe the same problem but the mentioned bugs are fixed.
>>
>> We manually tried to force a commit, a reload and an optimize on the
>> collections without effect.
>>
>> Is a problem of configuration (merge / delete policy) or a possible
>> regression in the Solr code ?
>>
>> Thank you
>>
>>
>> Kelkoo SAS
>> Société par Actions Simplifiée
>> Au capital de € 4.168.964,30
>> Siège social : 158 Ter Rue du Temple 75003 Paris
>> 425 093 069 RCS Paris
>>
>> Ce message et les pièces jointes sont confidentiels et établis à l'attention
>> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
>> message, merci de le détruire et d'en avertir l'expéditeur.


--

Elodie Sannier
Software engineer

<http://www.kelkoo.com/>

*E*[hidden email]*    Skype*kelkooelodies
*T*+33 (0)4 56 09 07 55
*A*Parc Sud Galaxie, 6, rue des Méridiens, 38130 Echirolles


Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Elodie Sannier
In reply to this post by Alexandre Rafalovitch
Thank you Alex for your answer.

The reference on deleted files are only on index files (with .fdt, .doc.
dvd, ... extensions).

sudo lsof | grep DEL
java       1366    kookel  DEL       REG 253,8               15360013
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_2508z.cfs
java       1366    kookel  DEL       REG 253,8               15360035
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_25091.fdt
java       1366    kookel  DEL       REG 253,8               15425603
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_25091_Lucene50_0.tim
java       1366    kookel  DEL       REG 253,8               11624982
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_2508y.fdt
...

We have tested to optimize the collection with Solr Admin but without
effect on it.

Elodie

On 03/07/2017 04:11 PM, Alexandre Rafalovitch wrote:

> More sanity checks: what are the extensions/types of the files that
> are not deleted?
>
> If they are index files, optimize command (even if no longer
> recommended for production) should really blow all the old ones away.
> So, are they other kinds of files?
>
> Regards,
>     Alex.
> ----
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
>
> On 7 March 2017 at 09:55, Erick Erickson <[hidden email]> wrote:
>> Just as a sanity check, if you restart the Solr JVM, do the files
>> disappear from disk?
>>
>> Do you have any custom code anywhere in this chain? If so, do you open
>> any searchers but
>> fail to close them? Although why 6.4 would manifest the problem but
>> other code wouldn't
>> is a mystery, just another sanity check.
>>
>> Best,
>> Erick
>>
>> On Tue, Mar 7, 2017 at 6:44 AM, Elodie Sannier <[hidden email]> wrote:
>>> Hello,
>>>
>>> We have migrated from Solr 5.4.1 to Solr 6.4.0 and the disk usage has
>>> increased.
>>> We found hundreds of references to deleted index files being held by solr.
>>> Before the migration, we had 15-30% of disk space used, after the migration
>>> we have 60-90% of disk space used.
>>>
>>> We are using Solr Cloud with 2 collections.
>>>
>>> The commands applied on the collections are:
>>> - for incremental indexation mode: add, deleteById with commitWithin of 30
>>> minutes
>>> - for full indexation mode: add, deleteById, commit
>>> - for switch between incremental and full mode: deleteByQuery, createAlias,
>>> reload
>>> - there is also an autocommit every 15 minutes
>>>
>>> We have seen the email "Solr leaking references to deleted files"
>>> 2016-05-31 which describe the same problem but the mentioned bugs are fixed.
>>>
>>> We manually tried to force a commit, a reload and an optimize on the
>>> collections without effect.
>>>
>>> Is a problem of configuration (merge / delete policy) or a possible
>>> regression in the Solr code ?
>>>
>>> Thank you
>>>
>>>
>>> Kelkoo SAS
>>> Société par Actions Simplifiée
>>> Au capital de € 4.168.964,30
>>> Siège social : 158 Ter Rue du Temple 75003 Paris
>>> 425 093 069 RCS Paris
>>>
>>> Ce message et les pièces jointes sont confidentiels et établis à l'attention
>>> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
>>> message, merci de le détruire et d'en avertir l'expéditeur.


--

Elodie Sannier
Software engineer

<http://www.kelkoo.com/>

*E*[hidden email]*    Skype*kelkooelodies
*T*+33 (0)4 56 09 07 55
*A*Parc Sud Galaxie, 6, rue des Méridiens, 38130 Echirolles


Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Gerald Reinhart
In reply to this post by Elodie Sannier

Hi,

    The custom code we have is something like this :

public class MySearchHandlerextends SearchHandler {


@Override public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp)throws Exception {

         SolrIndexSearcher  searcher =req.getSearcher();

         try{

                  // Do stuff with the searcher....


         }finally {
             req.close();
         }



     }

}

      Despite the fact that we always close the request each time we get
a SolrIndexSearcher from the request, the number of SolrIndexSearcher
instances is increasing. Each time a new commit is done on the index, a
new Searcher is created (this is normal) but the old one remains.     Is
there something wrong with this custom code ?     Shall we try something
explained there :
http://stackoverflow.com/questions/20515493/solr-huge-number-of-open-searchers
? Thanks, Gérald Reinhart (working with Elodie on the subject) On
03/07/2017 05:45 PM, Elodie Sannier wrote:

> Thank you Erick for your answer.
>
> The files are deleted even without JVM restart but they are still seen
> as DELETED by the kernel.
>
> We have a custom code and for the migration to Solr 6.4.0 we have added
> a new code with req.getSearcher() but without "close".
> We will decrement the reference count on a resource for the Searcher
> (prevent the Searcher remains open after a commit) and see if it fixes
> the problem.
>
> Elodie
>
> On 03/07/2017 03:55 PM, Erick Erickson wrote:
>> Just as a sanity check, if you restart the Solr JVM, do the files
>> disappear from disk?
>>
>> Do you have any custom code anywhere in this chain? If so, do you open
>> any searchers but
>> fail to close them? Although why 6.4 would manifest the problem but
>> other code wouldn't
>> is a mystery, just another sanity check.
>>
>> Best,
>> Erick
>>
>> On Tue, Mar 7, 2017 at 6:44 AM, Elodie Sannier <[hidden email]> wrote:
>>> Hello,
>>>
>>> We have migrated from Solr 5.4.1 to Solr 6.4.0 and the disk usage has
>>> increased.
>>> We found hundreds of references to deleted index files being held by solr.
>>> Before the migration, we had 15-30% of disk space used, after the migration
>>> we have 60-90% of disk space used.
>>>
>>> We are using Solr Cloud with 2 collections.
>>>
>>> The commands applied on the collections are:
>>> - for incremental indexation mode: add, deleteById with commitWithin of 30
>>> minutes
>>> - for full indexation mode: add, deleteById, commit
>>> - for switch between incremental and full mode: deleteByQuery, createAlias,
>>> reload
>>> - there is also an autocommit every 15 minutes
>>>
>>> We have seen the email "Solr leaking references to deleted files"
>>> 2016-05-31 which describe the same problem but the mentioned bugs are fixed.
>>>
>>> We manually tried to force a commit, a reload and an optimize on the
>>> collections without effect.
>>>
>>> Is a problem of configuration (merge / delete policy) or a possible
>>> regression in the Solr code ?
>>>
>>> Thank you
>>>
>>>
>>> Kelkoo SAS
>>> Société par Actions Simplifiée
>>> Au capital de € 4.168.964,30
>>> Siège social : 158 Ter Rue du Temple 75003 Paris
>>> 425 093 069 RCS Paris
>>>
>>> Ce message et les pièces jointes sont confidentiels et établis à l'attention
>>> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
>>> message, merci de le détruire et d'en avertir l'expéditeur.
>
> --
>
> Elodie Sannier
> Software engineer
>
> <http://www.kelkoo.com/>
>
> *E*[hidden email]*    Skype*kelkooelodies
> *T*+33 (0)4 56 09 07 55
> *A*Parc Sud Galaxie, 6, rue des Méridiens, 38130 Echirolles
>
>
> Kelkoo SAS
> Société par Actions Simplifiée
> Au capital de € 4.168.964,30
> Siège social : 158 Ter Rue du Temple 75003 Paris
> 425 093 069 RCS Paris
>
> Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
--

Gérald ReinhartSoftware Engineer

<http://www.kelkoo.com/>

*E*[hidden email]*A*Parc Sud Galaxie, 6, rue des Méridiens,
38130 Echirolles, FR


Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Shawn Heisey-2
On 3/14/2017 3:08 AM, Gerald Reinhart wrote:

> Hi,
>    The custom code we have is something like this :
> public class MySearchHandlerextends SearchHandler {
> @Override public void handleRequestBody(SolrQueryRequest req,
> SolrQueryResponse rsp)throws Exception {
>         SolrIndexSearcher  searcher =req.getSearcher();
>         try{
>                  // Do stuff with the searcher....
>         }finally {
>             req.close();
>         }
<snip>
>      Despite the fact that we always close the request each time we get
> a SolrIndexSearcher from the request, the number of SolrIndexSearcher
> instances is increasing. Each time a new commit is done on the index, a
> new Searcher is created (this is normal) but the old one remains.     Is
> there something wrong with this custom code ?

My understanding of Solr and Lucene internals is rudimentary, but I
might know what's happening here.

The code closes the request, but never closes the searcher.  Searcher
objects include a Lucene object that holds onto the index files that
pertain to that view of the index.  The searcher must be closed.

It does look like if you close the searcher and then close the request,
that might be enough to fully decrement all the reference counters
involved, but I do not know the code well enough to be sure of that.

Thanks,
Shawn

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Elodie Sannier
The request close() method decrements the reference count on the searcher.

public abstract class SolrQueryRequestBase implements SolrQueryRequest,
Closeable {

   // The index searcher associated with this request
   protected RefCounted<SolrIndexSearcher> searcherHolder;

   public void close() {
     if(this.searcherHolder != null) {
       this.searcherHolder.decref();
       this.searcherHolder = null;
     }
   }
}

RefCounted keeps track of a reference count on the searcher and closes
it when the count hits zero.

public abstract class RefCounted<Type> {
   ...
   public void decref() {
     if (refcount.decrementAndGet() == 0) {
       close();
     }
   }
}

We asume that when we call req.getSearcher() - this increases the
reference count, after we are done with the searcher, we have to call
close() to call decref() to decrease the reference count.

But it does not seem enough or maybe there is a bug in Solr in this case ?

Elodie

On 03/14/2017 03:02 PM, Shawn Heisey wrote:

> On 3/14/2017 3:08 AM, Gerald Reinhart wrote:
>> Hi,
>>     The custom code we have is something like this :
>> public class MySearchHandlerextends SearchHandler {
>> @Override public void handleRequestBody(SolrQueryRequest req,
>> SolrQueryResponse rsp)throws Exception {
>>          SolrIndexSearcher  searcher =req.getSearcher();
>>          try{
>>                   // Do stuff with the searcher....
>>          }finally {
>>              req.close();
>>          }
> <snip>
>>       Despite the fact that we always close the request each time we get
>> a SolrIndexSearcher from the request, the number of SolrIndexSearcher
>> instances is increasing. Each time a new commit is done on the index, a
>> new Searcher is created (this is normal) but the old one remains.     Is
>> there something wrong with this custom code ?
> My understanding of Solr and Lucene internals is rudimentary, but I
> might know what's happening here.
>
> The code closes the request, but never closes the searcher.  Searcher
> objects include a Lucene object that holds onto the index files that
> pertain to that view of the index.  The searcher must be closed.
>
> It does look like if you close the searcher and then close the request,
> that might be enough to fully decrement all the reference counters
> involved, but I do not know the code well enough to be sure of that.
>
> Thanks,
> Shawn
>


Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Erick Erickson
Yeah, it's a little confusing. But SolrQueryReqeustBase.getSearcher
calls, in turn, core.getSearcher which explicitly says in the
javadocs:

* If returnSearcher==true</tt> then a SolrIndexSearcher will be returned with
* the reference count incremented.  It must be decremented when no
longer needed.

See a similar pattern in IndexFetcher:

  searcher = core.getSearcher(true, true, waitSearcher, true);
try {
   blah blah blah
} finally {
  if (searcher != null) {
    searcher.decref();
  }
  core.close();
}

This is so fundamental to Solr operating at _all_ that I'd lay long
odds this is just confusing, not a bug or everybody would be running
out of file handles.

Best,
Erick

On Tue, Mar 14, 2017 at 9:23 AM, Elodie Sannier
<[hidden email]> wrote:

> The request close() method decrements the reference count on the searcher.
>
> public abstract class SolrQueryRequestBase implements SolrQueryRequest,
> Closeable {
>
>   // The index searcher associated with this request
>   protected RefCounted<SolrIndexSearcher> searcherHolder;
>
>   public void close() {
>     if(this.searcherHolder != null) {
>       this.searcherHolder.decref();
>       this.searcherHolder = null;
>     }
>   }
> }
>
> RefCounted keeps track of a reference count on the searcher and closes
> it when the count hits zero.
>
> public abstract class RefCounted<Type> {
>   ...
>   public void decref() {
>     if (refcount.decrementAndGet() == 0) {
>       close();
>     }
>   }
> }
>
> We asume that when we call req.getSearcher() - this increases the
> reference count, after we are done with the searcher, we have to call
> close() to call decref() to decrease the reference count.
>
> But it does not seem enough or maybe there is a bug in Solr in this case ?
>
> Elodie
>
> On 03/14/2017 03:02 PM, Shawn Heisey wrote:
>>
>> On 3/14/2017 3:08 AM, Gerald Reinhart wrote:
>>>
>>> Hi,
>>>     The custom code we have is something like this :
>>> public class MySearchHandlerextends SearchHandler {
>>> @Override public void handleRequestBody(SolrQueryRequest req,
>>> SolrQueryResponse rsp)throws Exception {
>>>          SolrIndexSearcher  searcher =req.getSearcher();
>>>          try{
>>>                   // Do stuff with the searcher....
>>>          }finally {
>>>              req.close();
>>>          }
>>
>> <snip>
>>>
>>>       Despite the fact that we always close the request each time we get
>>> a SolrIndexSearcher from the request, the number of SolrIndexSearcher
>>> instances is increasing. Each time a new commit is done on the index, a
>>> new Searcher is created (this is normal) but the old one remains.     Is
>>> there something wrong with this custom code ?
>>
>> My understanding of Solr and Lucene internals is rudimentary, but I
>> might know what's happening here.
>>
>> The code closes the request, but never closes the searcher.  Searcher
>> objects include a Lucene object that holds onto the index files that
>> pertain to that view of the index.  The searcher must be closed.
>>
>> It does look like if you close the searcher and then close the request,
>> that might be enough to fully decrement all the reference counters
>> involved, but I do not know the code well enough to be sure of that.
>>
>> Thanks,
>> Shawn
>>
>
>
> Kelkoo SAS
> Société par Actions Simplifiée
> Au capital de € 4.168.964,30
> Siège social : 158 Ter Rue du Temple 75003 Paris
> 425 093 069 RCS Paris
>
> Ce message et les pièces jointes sont confidentiels et établis à l'attention
> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
> message, merci de le détruire et d'en avertir l'expéditeur.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Shawn Heisey-2
In reply to this post by Elodie Sannier
On 3/14/2017 10:23 AM, Elodie Sannier wrote:
> The request close() method decrements the reference count on the
> searcher.

From what I could tell, that method decrements the reference counter,
but does not actually close the searcher object.  I cannot tell you what
the correct procedure is to make sure that all resources are properly
closed at the proper time.  This might be a bug, or there might be
something missing from your code.  I do not know which.

Thanks,
Shawn

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Migration Solr5 to Solr6] Unwanted deleted files references

Elodie Sannier
We have found a workaround to close the searchers checking the current
index version.
And now the SolrCore does not have many open searchers.

However, we have less unwanted deleted files references but we still
have some.

We have two collections fr_blue, fr_green with aliases:
fr -> fr_blue
fr_temp -> fr_green

The fr collection receives the queries, the fr_temp collection does not
receive the queries.

The problem occurs when we are doing the following sequence:
1- swap aliases (create alias fr -> fr_green and fr_temp -> fr_blue for
example)
2- reload collection with fr_temp alias (fr_blue for example)

We suspect that there is a problem with the reload of a collection that
has received traffic so far but doesn't receive anymore since the
aliases swap.
A problem with the increment / decrement of the searcher perhaps ?

Elodie

On 03/14/2017 06:42 PM, Shawn Heisey wrote:

> On 3/14/2017 10:23 AM, Elodie Sannier wrote:
>> The request close() method decrements the reference count on the
>> searcher.
>  From what I could tell, that method decrements the reference counter,
> but does not actually close the searcher object.  I cannot tell you what
> the correct procedure is to make sure that all resources are properly
> closed at the proper time.  This might be a bug, or there might be
> something missing from your code.  I do not know which.
>
> Thanks,
> Shawn
>


Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.
Loading...