Re: Connection Established but waiting for response for a long time.

Set name=ThreadPool New class=org.eclipse.jetty.util.thread.QueuedThreadPool Set name=minThreads10/Set Set name=maxThreads1/Set Set name=detailedDumpfalse/Set /New /Set Call name=addConnector Arg New

Connection Established but waiting for response for a long time.

Hi, I'm runing solr 4.0 but using legacy distributed search set up. I set the shards parameter for search, but indexing into each solr shards directly. The problem I have been experiencing is building connection with solr shards. If I run a query, by using wget, to get number of records from each

Re: ConcurrentUpdateSolrServer hanging

Hi, BlockUntilFinish block indefinitely sometimes. But if I send a commit from another thread to the instance, the concurrentUpdateServer unblock and send the rest of the documents and commit. So the squence look like this: 1. adding documents as usual... 2. finish adding documents... 3. block

ConcurrentUpdateSolrServer hanging

Hi, I'm using concurrentUpdateSolrServer to do my incremental indexing nightly. I have 50 shards to index into, about 10,000 documents each night. I start one concurrentUpdateSolrServer on each shards and start to send documents. The queue size for concurrentUpdateSolrServer is 100, and 4

Re: ConcurrentUpdateSolrServer hanging

Hi Michael, I realized that I might have to use blockUntilFinished before commit, but do I have to use shutdown as well?? Thanks, Qun -- View this message in context: http://lucene.472066.n3.nabble.com/ConcurrentUpdateSolrServer-hanging-tp4073620p4073651.html Sent from the Solr - User

Slow performance on distributed search

Hi, I have 40 shards running on 48 core machine with 256GB RAM (The data is about 40 GB). I am using legacy distributed method as setup. So I have one additional shard with no data. Queries would go to this shard and the shard would merge result from the rest of the 40 shards. From the log, I see

Re: Slow performance on distributed search

Thank you for reply. Queries do need to go to all 40 shards, though 40 shards is not a final number, my setup can be changed if search time decreases. Im using 40 shards because we have a tool that can index faster with more shards. -- View this message in context:

RE: Slow performance on distributed search

for start=100,000row=10. event though each individual shard take only 10ms to query, the merging process done by controller would take about a minutes. By looking at logs, each shard is giving the controller shard 100,010 rows of data, and because there are 40 shards in total, the controller is