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.

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

[Shawn Heisey]

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

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 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
 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 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 {
>   ...
>   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();
>>>  }
>>
>> 
>>>
>>>   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.

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 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 {
  ...
  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();
 }



  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.

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

[Shawn Heisey]

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();
> }

>  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

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

[Gerald Reinhart]

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  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



*E*elodie.sann...@kelkoo.fr*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



*E*gerald.reinh...@kelkoo.com*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.

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

[Elodie Sannier]

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   1366kookel  DEL   REG 253,8   15360013
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_2508z.cfs
java   1366kookel  DEL   REG 253,8   15360035
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_25091.fdt
java   1366kookel  DEL   REG 253,8   15425603
/opt/kookel/data/searchSolrNode/solrindex/fr1_green/index/_25091_Lucene50_0.tim
java   1366kookel  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  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  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



*E*elodie.sann...@kelkoo.fr*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.

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

[Elodie Sannier]

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  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



*E*elodie.sann...@kelkoo.fr*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.

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  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  
> 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.

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  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.

[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.