www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Stevenson (JIRA)" <j...@apache.org>
Subject [jira] Closed: (INFRA-2903) spam filter overreacted - cannot post to the solr-user emailing list
Date Tue, 19 Oct 2010 08:04:26 GMT

     [ 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


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. 


> 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 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: <AANLkTimG3PC16GFKw3g1kuEaUe0h35ug0Wkq=dpx4HrL@mail.gmail.com>
> Subject: Solr 1.4.x does not close the searcher after the replication
> From: Alexander Kanarsky <kanarsky2010@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.

View raw message