lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chantal Ackermann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2020) HttpComponentsSolrServer
Date Fri, 30 Jul 2010 20:48:20 GMT

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

Chantal Ackermann commented on SOLR-2020:
-----------------------------------------

Hi Yonik,

I had a look at the sources of SearchHandler and ResponseBuilder. It think it would work replacing
the CommonsHttpSolrServer with the HttpComponentsSolrServer and replace the part where the
HttpClient is initialized with the new initialization procedure for version 4.

While contemplating these comments from SearchHandler/HttpCommComponent I wonder whether upgrading
to Http Components would not be a good time to address these TODOs:
"""
// TODO: generalize how a comm component can fit into search component framework
// TODO: statics should be per-core singletons

class HttpCommComponent {

  // We want an executor that doesn't take up any resources if
  // it's not used, so it could be created statically for
  // the distributed search component if desired.
"""

Have there already been ideas on how to generalize that comm component? I'm not sure I understand
that comment correctly.
I also wondered why there aren't specialized classes for the shard requests? Something like:

-> subclass ShardSearchHandler extends SearchHandler
-> subclass ShardResponseBuilder extends ResponseBuilder
containing all code handling distributed requests, including the HttpCommComponent.

Maybe the plugin framework does not allow these subclasses without breaking a lot - if at
all possible?

Or some kind of "ShardingService" that takes over the work for the SearchHandler when it comes
to distributed requests. Maybe this could be what is called generalized comm component in
the comment?
If a request is distributed the SearchHandler (and others?) delegates to the ShardingService.
This ShardingService could be configurable to use any implementation of SolrServer. (Does
that make sense? Using an embedded SolrServer for distributed requests? Not really - but maybe
using their own SolrServer implementations?)

> HttpComponentsSolrServer
> ------------------------
>
>                 Key: SOLR-2020
>                 URL: https://issues.apache.org/jira/browse/SOLR-2020
>             Project: Solr
>          Issue Type: New Feature
>          Components: clients - java
>    Affects Versions: 1.4.1
>         Environment: Any
>            Reporter: Chantal Ackermann
>            Priority: Minor
>         Attachments: HttpComponentsSolrServer.java, HttpComponentsSolrServerTest.java
>
>
> Implementation of SolrServer that uses the Apache Http Components framework.
> Http Components (http://hc.apache.org/) is the successor of Commons HttpClient and thus
HttpComponentsSolrServer would be a successor of CommonsHttpSolrServer, in the future.

-- 
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