lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Timm (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-457) A multi threaded implementation for solrJ
Date Mon, 21 Jan 2008 15:27:34 GMT

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

timmsc edited comment on SOLR-457 at 1/21/08 7:26 AM:
---------------------------------------------------------

Currently with Solrj, if you want to take advantage of the connection pooling, I think you
need to create a single instance of CommonsHttpSolrServer in your application (and if you
aren't, you are better off using SimpleHttpConnectionManager).  So, it seems to make sense
to make it easier to use in this fashion.  This could be made more general purpose though
if process just took a single request and returned a single response and you called it once
for each server.  This would abstract out the threading and connection pooling while not constraining
the class to something designed primarily for SOLR-303.

A couple of other comments:

The threads should probably be pooled rather than creating and destroying on each request.
 While creating and destroying threads has gotten faster, pooling is usually beneficial.

Unless I'm mistaken, it appears that your connectionManager is different from the _connectionManager
in CommonsHttpSolrServer, so the methods that you didn't override will not work correctly,
e.g., setConnectionTimeout().

Neither the CommonsHttpSolrServer currently in Solrj nor this patch appear to allow setting
of the read timeout: setSoTimeout(int timeout) or the connection manager timeout: setConnectionManagerTimeout(long
timeout).  Other HttpClient options such as disabling Nagle's algorithm are probably not as
important.  This should probably be opened as a separate JIRA issue (edit: see SOLR-462).

      was (Author: timmsc):
    Currently with Solrj, if you want to take advantage of the connection pooling, I think
you need to create a single instance of CommonsHttpSolrServer in your application (and if
you aren't, you are better off using SimpleHttpConnectionManager).  So, it seems to make sense
to make it easier to use in this fashion.  This could be made more general purpose though
if process just took a single request and returned a single response and you called it once
for each server.  This would abstract out the threading and connection pooling while not constraining
the class to something designed primarily for SOLR-303.

A couple of other comments:

The threads should probably be pooled rather than creating and destroying on each request.
 While creating and destroying threads has gotten faster, pooling is usually beneficial.

Unless I'm mistaken, it appears that your connectionManager is different from the _connectionManager
in CommonsHttpSolrServer, so the methods that you didn't override will not work correctly,
e.g., setConnectionTimeout().

Neither the CommonsHttpSolrServer currently in Solrj nor this patch appear to allow setting
of the read timeout: setSoTimeout(int timeout) or the connection manager timeout: setConnectionManagerTimeout(long
timeout).  Other HttpClient options such as disabling Nagle's algorithm are probably not as
important.  This should probably be opened as a separate JIRA issue.
  
> A multi threaded implementation for solrJ
> -----------------------------------------
>
>                 Key: SOLR-457
>                 URL: https://issues.apache.org/jira/browse/SOLR-457
>             Project: Solr
>          Issue Type: New Feature
>          Components: clients - java
>    Affects Versions: 1.3
>            Reporter: patrick o'leary
>            Priority: Minor
>             Fix For: 1.3
>
>         Attachments: multithreaded-solrj.patch
>
>
> Provide a multi threaded implementation of CommonsHttpSolrServer
> For usage with distributed searching in solr-303

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


Mime
View raw message