lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jilles van Gurp (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-861) SOLRJ Client does not release connections 'nicely' by default
Date Thu, 10 Jun 2010 14:27:13 GMT

    [ https://issues.apache.org/jira/browse/SOLR-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877430#action_12877430
] 

Jilles van Gurp commented on SOLR-861:
--------------------------------------

We ran into exactly this issue with resteasy, which was not releasing connections properly
(a problem that has since been addressed as far as I know). Eventually your pool will stop
providing new connections and nothing short of killing the process will resolve this. Basically
the connections are kept open while httpclient has lost track of them.

Httpclient 4.0 has a nice ResponseHandler interface that you use like this:

httpClient.execute(request, new ResponseHandler<Integer>() {

                    @Override
                    public Integer handleResponse(HttpResponse response) throws ClientProtocolException,
IOException {                        
                        return response.getStatusLine().getStatusCode();
                    }
                });

httpclient basically takes care of cleaning up after you return from handleResponse. Additionally,
you can/should configure a cleanup thread.

    public static class IdleConnectionMonitor implements Runnable {

        private final ClientConnectionManager connMgr;

        public IdleConnectionMonitor(final ClientConnectionManager connMgr) {
            this.connMgr = connMgr;
        }

        @Override
        public final void run() {
            // Close expired connections
            this.connMgr.closeExpiredConnections();
            // Optionally, close connections
            // that have been idle longer than 120 sec
            this.connMgr.closeIdleConnections(120, TimeUnit.SECONDS);
        }
    }

ScheduledExecutorService idleConnectionMonitorExecutor = Executors.newSingleThreadScheduledExecutor()
IdleConnectionMonitor idleConnectionMonitor = new IdleConnectionMonitor(connectionManager);
idleConnectionMonitorExecutor.scheduleWithFixedDelay(idleConnectionMonitor, 5, 5, TimeUnit.MINUTES);

Finally, you need to take care about defaults for socket and connection timeouts:

        HttpParams params = new BasicHttpParams();

        ConnManagerParams.setTimeout(params, 1000);
        params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, 1000);
        params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, 1000);

In httpclient 3, the solution is to guarantee releaseConnection gets called in a finally block.
We had servers hanging in production because of connections in the close wait state so I did
a lot of digging around in the code. Basically any place where this is not done in a finally
block is a problem waiting to happen. If you consistently call releaseConnection, you should
not be seeing this issue.

What I propose is that you offer both httpclient 3 and 4 implementation (so people can choose)
and make sure they do the right thing by using release connection / a response handler. As
mentioned, I'm willing to help here.

> SOLRJ Client does not release connections 'nicely' by default
> -------------------------------------------------------------
>
>                 Key: SOLR-861
>                 URL: https://issues.apache.org/jira/browse/SOLR-861
>             Project: Solr
>          Issue Type: Bug
>          Components: clients - java
>    Affects Versions: 1.3
>         Environment: linux
>            Reporter: Ian Holsman
>         Attachments: SimpleClient.patch
>
>
> as-is the SolrJ Commons HttpServer uses the multi-threaded http connection manager. This
manager seems to keep the connection alive for the client and does not close it when the object
is dereferenced.
> When you keep on opening new CommonsHttpSolrServer instances it results in a socket that
is stuck in the CLOSE_WAIT state. Eventually this will use up all your available file handles,
causing your client to die a painful death.
> The solution I propose is that it uses a 'Simple' HttpConnectionManager which is set
to not reuse connections if you don't specify a HttpClient.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message