infra-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Kanarsky (JIRA)" <>
Subject [jira] Created: (INFRA-2903) spam filter overreacted - cannot post to the solr-user emailing list
Date Tue, 27 Jul 2010 07:53:20 GMT
spam filter overreacted - cannot post to the solr-user emailing list 

                 Key: INFRA-2903
             Project: Infrastructure
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: Mailing Lists
         Environment: gmail / ie (windows xp)
            Reporter: Alexander Kanarsky

I cannot send this message (as a plain text) to the solr-user mailing list (I am subscribed
to the list). Please investigate. Thanks!


Delivery to the following recipient failed permanently:

Technical details of permanent failure:

Google tried to deliver your message, but it was rejected by the recipient domain. We recommend
contacting the other email provider for further information about the cause of this error.
The error that the other server returned was: 552 552 spam score (5.8) exceeded threshold
(state 18).

----- Original message -----

MIME-Version: 1.0

Received: by with SMTP id e9mr10010251wfg.111.1280216557931; Tue,
       27 Jul 2010 00:42:37 -0700 (PDT)
Received: by with HTTP; Tue, 27 Jul 2010 00:42:37 -0700 (PDT)
Date: Tue, 27 Jul 2010 00:42:37 -0700
Message-ID: <>
Subject: Solr 1.4.x does not close the searcher after the replication
From: Alexander Kanarsky <>

Content-Type: text/plain; charset=ISO-8859-1

- Hide quoted text -

Hi everyone,

I am curious if anyone else seen this problem (searched the archives,
but did not find anything relevant): the Solr (1.4.0, 1.4.1) does not
close the previous searcher(s) after the replication on slave(s).

The setup is the following: both master and slave are set in
multi-core configuration. The replication is enabled on slaves, but
polling is disabled. Config files are not replicated. To propagate the changes,
the master index gets updated, and then after the commit the
replication on slave is triggered by external http call (fetchindex call).
Sometimes the index is completely replaced on master so the Solr
creates a new "index.timestamp" folder (since the generation on master is less
or equal the number on slave), and because of this the slave
index is always in "index.timestamp" folder (the location specified in, not in "index" folder - as I understand,
this is not a typical setup.

The problem is that when the replication finishes OK but all the
previous Searchers are still sit there with their caches filling up
the memory (and also holding non-used file handles when the SnapPuller creates a
new index folder).

Any ideas on why this could happen? What could hold the Searchers of
the previous snapshots? The are not serving the traffic, at least this
is my impression based on query results (always reflect the data in
latest snapshot).

Your help is greatly appreciated!

Thank you,

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message