Re: Connection Pool
On Fri, May 14, 2010 at 3:35 PM, Anderson vasconcelos anderson.v...@gmail.com wrote: Hi I wanna to know if has any connection pool client to manage the connections with solr. In my system, we have a lot of concurrency index request. I cant shared my connection, i need to create one per transaction. But if i create one per transaction, i think the performance will down. How you resolve this problem? The commonsHttpSolrServer class does connection pooling, and IIRC also the StreamingUpdateSolrServer. -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com
Query or FilterQuery for exact field match
Hi everyone, in our app we sometimes use solr programmatically to retrieve all the elements that have a certain value in a single-valued single-token field ( brand:xxx). Since we are not interested in scoring this results, I was thinking that maybe this should be performed as a filterQuery (fq=brand:xxx), and in that case I guess I shall be using a wildcard for the query (q=*:*), as I'd get an NPE on the missing parameter otherwise. Does something like this even make sense? Is there a proper way to do a query like this, or is the normal route of using q=brand:xxx already the best way? Thanks in advance for any answer. -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com
Re: Query or FilterQuery for exact field match
On Tue, Feb 16, 2010 at 2:04 PM, NarasimhaRaju rajux...@yahoo.com wrote: Hi, using filterQuery(fq) is more efficient because SolrIndexSearcher will make use of filterCache and in your case it returns entire set from the cache instead of searching from the entire index. more info about solrCaches at http://wiki.apache.org/solr/SolrCaching#filterCache I read that, but I'm outside of the typical usage I believe (as I have no additional parameters so I'm not getting a subset): in my case it seems the result would be in the queryResultCache anyway if I do a normal search , or am I missing something? Anyway, thanks for your answer. -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com
slave java replication connection issue in nightly (wrong url?)
hi everyone and sorry if this question is dumb, but I seem to be
unable to connect from a slave, with both are in a multicore setup
I configured the replication like
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=enable${enable.master:false}/str
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str name=backupAfteroptimize/str
str name=confFilesschema.xml/str
/lst
lst name=slave
str name=enable${enable.slave:false}/str
str
name=masterUrlhttp://master.solr.lan:8080/solr/core/replication/str
str name=pollInterval00:00:60/str
/lst
/requestHandler
And it seems that both master and slave loaded the configuration
correctly e.g. in the admin interface I see
* /replication added
* my config values correctly loaded
* replicationEnabled = true in master
* isSlave and isMaster correctly set on both
* the http://master.solr.lan:8080/solr/core/replication gives me
status ok when accessed as a GET (curl) from the slave machine
yet, when I check from the slave's admin interface it says that
http://master.solr.lan:8080/solr/core/replication is unreachable, and
from the statistics I see
isReplicating : false
and in the logs
SEVERE: Master at: http://master.solr.lan:8080/solr/core/replication
is not available. Index fetch failed. Exception: Request failed
for the url org.apache.commons.httpclient.methods.postmet...@48f3d27
I'm thinking maybe I should have configured the url differently, but
frankly I don't have a clue.
Could someone point out what is the obvious error I'm doing ? :)
Additional informations:
* slave nightly is from today, master from a few days ago
* both machines are 64 bit and running on linux
* java -version is
Java version 1.6.0_16
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
* solr is deployed in a tomcat6 container
Re: slave java replication connection issue in nightly (wrong url?)
ah, problem solved, it was due (apparently) caching an old dns entry sorry for the noise :)
Re: Solr 1.4 (RC) performance on multi-CPU system
On Tue, Oct 27, 2009 at 3:41 PM, Yonik Seeley yo...@lucidimagination.com wrote: is there a reason why StreamingUpdateSolrServer does not accept a connection manager argument as CommonsHttpSolrServer does? I don't see any reason why it shouldn't... can you open a JIRA issue and optionally provide a patch? great, will do both later today (GMT+1 lunch time :) ) Its buffering feature seems kind of disjoint from the self-management of a connection pool Does this just refer to the missing constructor allowing for HttpClient to be passed, or is there another potential improvement you see? the former, I just meant I did not see any dependency between the two that forbid allowing custom managers.
Re: Solr 1.4 (RC) performance on multi-CPU system
2009/10/28 gabriele renzi rff@gmail.com: On Tue, Oct 27, 2009 at 3:41 PM, Yonik Seeley yo...@lucidimagination.com wrote: is there a reason why StreamingUpdateSolrServer does not accept a connection manager argument as CommonsHttpSolrServer does? I don't see any reason why it shouldn't... can you open a JIRA issue and optionally provide a patch? great, will do both later today (GMT+1 lunch time :) ) done, I hope I have not done anything stupid. No new tests attached but old ones still pass and testing an inherited ctor seems moot. While I'm at it, FindBugs has a few issues with the solr code base (a few hundreds, but most seem false positives) but it does have a few concurrency related issues that appear reasonable to me, is it of any use if I submit patches for those too? -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com
Re: Solr 1.4 (RC) performance on multi-CPU system
On Mon, Oct 26, 2009 at 10:43 PM, Yonik Seeley yo...@lucidimagination.com wrote: On Mon, Oct 26, 2009 at 4:32 PM, Teruhiko Kurosaka k...@basistech.com wrote: Are multiple CPUs utilized at indexing time as well, or just by searcher? Yes, multiple CPUs are utilized for indexing. If you're using SolrJ, and easy way to exploit this parallelism is to use http://lucene.apache.org/solr/api/org/apache/solr/client/solrj/impl/StreamingUpdateSolrServer.html is there a reason why StreamingUpdateSolrServer does not accept a connection manager argument as CommonsHttpSolrServer does? Its buffering feature seems kind of disjoint from the self-management of a connection pool, and source-wise it seems to me that it relies on the superclass' getHttpClient() but I'm probably missing something :).
