You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-issues@apache.org by "Alexander Kanarsky (JIRA)" <ji...@apache.org> on 2010/07/27 09:53:20 UTC
[jira] Created: (INFRA-2903) spam filter overreacted - cannot post
to the solr-user emailing list
spam filter overreacted - cannot post to the solr-user emailing list
---------------------------------------------------------------------
Key: INFRA-2903
URL: https://issues.apache.org/jira/browse/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:
solr-user@lucene.apache.org
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 10.142.207.9 with SMTP id e9mr10010251wfg.111.1280216557931; Tue,
27 Jul 2010 00:42:37 -0700 (PDT)
Received: by 10.142.112.18 with HTTP; Tue, 27 Jul 2010 00:42:37 -0700 (PDT)
Date: Tue, 27 Jul 2010 00:42:37 -0700
Message-ID: <AA...@mail.gmail.com>
Subject: Solr 1.4.x does not close the searcher after the replication
From: Alexander Kanarsky <ka...@gmail.com>
To: solr-user@lucene.apache.org
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
index.properties), 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,
-Alexander
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (INFRA-2903) spam filter overreacted - cannot post
to the solr-user emailing list
Posted by "Tony Stevenson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tony Stevenson closed INFRA-2903.
---------------------------------
Resolution: Won't Fix
Alexander,
Sorry we have left this so long, as a result the logs as to why we would have classified this as spam are now long gone.
Often mails to the lists are blocked because of:
- Not sending in plain/text
- Sending from an RBL listed ip address
- Using keywords that have a higher spam weighting.
Regards,
Tony
> spam filter overreacted - cannot post to the solr-user emailing list
> ---------------------------------------------------------------------
>
> Key: INFRA-2903
> URL: https://issues.apache.org/jira/browse/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:
> solr-user@lucene.apache.org
> 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 10.142.207.9 with SMTP id e9mr10010251wfg.111.1280216557931; Tue,
> 27 Jul 2010 00:42:37 -0700 (PDT)
> Received: by 10.142.112.18 with HTTP; Tue, 27 Jul 2010 00:42:37 -0700 (PDT)
> Date: Tue, 27 Jul 2010 00:42:37 -0700
> Message-ID: <AA...@mail.gmail.com>
> Subject: Solr 1.4.x does not close the searcher after the replication
> From: Alexander Kanarsky <ka...@gmail.com>
> To: solr-user@lucene.apache.org
> 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
> index.properties), 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,
> -Alexander
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.