[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 24234 - Failure!

[builder]

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/24234/

1 tests failed.
REGRESSION:  
org.apache.lucene.search.TestTimeLimitingCollector.testSearchMultiThreaded

Error Message:
Captured an uncaught exception in thread: Thread[id=162, name=Thread-101, 
state=RUNNABLE, group=TGRP-TestTimeLimitingCollector]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=162, name=Thread-101, state=RUNNABLE, 
group=TGRP-TestTimeLimitingCollector]
Caused by: java.lang.OutOfMemoryError: Java heap space
at __randomizedtesting.SeedInfo.seed([11CD979C9CE3DF6]:0)
at 
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:269)
at 
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:51)
at org.apache.lucene.store.DataInput.readVInt(DataInput.java:108)
at 
org.apache.lucene.store.BufferedIndexInput.readVInt(BufferedIndexInput.java:219)
at 
org.apache.lucene.store.MockIndexInputWrapper.readVInt(MockIndexInputWrapper.java:161)
at 
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.loadBlock(BlockTreeTermsReader.java:2357)
at 
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.next(BlockTreeTermsReader.java:2080)
at org.apache.lucene.index.MultiTermsEnum.reset(MultiTermsEnum.java:128)
at org.apache.lucene.index.MultiTerms.iterator(MultiTerms.java:110)
at 
org.apache.lucene.search.TermQuery$TermWeight.getTermsEnum(TermQuery.java:102)
at 
org.apache.lucene.search.TermQuery$TermWeight.scorer(TermQuery.java:82)
at 
org.apache.lucene.search.BooleanQuery$BooleanWeight.scorer(BooleanQuery.java:323)
at 
org.apache.lucene.search.AssertingIndexSearcher$1.scorer(AssertingIndexSearcher.java:80)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:596)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:302)
at 
org.apache.lucene.search.TestTimeLimitingCollector.search(TestTimeLimitingCollector.java:124)
at 
org.apache.lucene.search.TestTimeLimitingCollector.doTestSearch(TestTimeLimitingCollector.java:139)
at 
org.apache.lucene.search.TestTimeLimitingCollector.access$200(TestTimeLimitingCollector.java:42)
at 
org.apache.lucene.search.TestTimeLimitingCollector$1.run(TestTimeLimitingCollector.java:292)




Build Log:
[...truncated 1167 lines...]
[junit4:junit4] Suite: org.apache.lucene.search.TestTimeLimitingCollector
[junit4:junit4]   2> 16-02-2013 06:26:24 AM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
[junit4:junit4]   2> ADVERTENCIA: Uncaught exception in thread: 
Thread[Thread-101,5,TGRP-TestTimeLimitingCollector]
[junit4:junit4]   2> java.lang.OutOfMemoryError: Java heap space
[junit4:junit4]   2>at 
__randomizedtesting.SeedInfo.seed([11CD979C9CE3DF6]:0)
[junit4:junit4]   2>at 
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:269)
[junit4:junit4]   2>at 
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:51)
[junit4:junit4]   2>at 
org.apache.lucene.store.DataInput.readVInt(DataInput.java:108)
[junit4:junit4]   2>at 
org.apache.lucene.store.BufferedIndexInput.readVInt(BufferedIndexInput.java:219)
[junit4:junit4]   2>at 
org.apache.lucene.store.MockIndexInputWrapper.readVInt(MockIndexInputWrapper.java:161)
[junit4:junit4]   2>at 
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.loadBlock(BlockTreeTermsReader.java:2357)
[junit4:junit4]   2>at 
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.next(BlockTreeTermsReader.java:2080)
[junit4:junit4]   2>at 
org.apache.lucene.index.MultiTermsEnum.reset(MultiTermsEnum.java:128)
[junit4:junit4]   2>at 
org.apache.lucene.index.MultiTerms.iterator(MultiTerms.java:110)
[junit4:junit4]   2>at 
org.apache.lucene.search.TermQuery$TermWeight.getTermsEnum(TermQuery.java:102)
[junit4:junit4]   2>at 
org.apache.lucene.search.TermQuery$TermWeight.scorer(TermQuery.java:82)
[junit4:junit4]   2>at 
org.apache.lucene.search.BooleanQuery$BooleanWeight.scorer(BooleanQuery.java:323)
[junit4:junit4]   2>at 
org.apache.lucene.search.AssertingIndexSearcher$1.scorer(AssertingIndexSearcher.java:80)
[junit4:junit4]   2>at 
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:596)
[junit4:junit4]   2>at 
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:302)
[junit4:junit4]   2>at 
org.apache.lucene.search.TestTimeLimitingCollector.search(TestTimeLimitingCollector.java:124)
[junit4:junit4]   2>at 
org.apache.lucene.search.TestTimeLimitingCollector.doTestSearch(TestTimeLimitingCollector.java:139)
[junit4:junit4]   2>at 
org.apache.lucene.search.TestTimeLimitingCollector.access$200(TestTi

[jira] [Commented] (SOLR-4408) Server hanging on startup

[Raintung Li (JIRA)]

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

Raintung Li commented on SOLR-4408:
---

The major problem searchExecutor is only one thread executor, if any listener 
method wait thread will block the registerSearcher() that cause can't notifyAll 
the wait object. Servlet can't initialize success. 
It is bug. 
BTW, If you want avoid this, you can set useColdSearcher=true in the 
solrconfig.xml.

> Server hanging on startup
> -
>
> Key: SOLR-4408
> URL: https://issues.apache.org/jira/browse/SOLR-4408
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1
> Environment: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode)
> Tomcat 7.0
> Eclipse Juno + WTP
>Reporter: Francois-Xavier Bonnet
>Assignee: Erick Erickson
> Fix For: 4.2, 5.0
>
>
> While starting, the server hangs indefinitely. Everything works fine when I 
> first start the server with no index created yet but if I fill the index then 
> stop and start the server, it hangs. Could it be a lock that is never 
> released?
> Here is what I get in a full thread dump:
> 2013-02-06 16:28:52
> Full thread dump OpenJDK 64-Bit Server VM (23.2-b09 mixed mode):
> "searcherExecutor-4-thread-1" prio=10 tid=0x7fbdfc16a800 nid=0x42c6 in 
> Object.wait() [0x7fbe0ab1]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0xc34c1c48> (a java.lang.Object)
>   at java.lang.Object.wait(Object.java:503)
>   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492)
>   - locked <0xc34c1c48> (a java.lang.Object)
>   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312)
>   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247)
>   at 
> org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:94)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:213)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:112)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
>   at 
> org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:64)
>   at org.apache.solr.core.SolrCore$5.call(SolrCore.java:1594)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>   at java.lang.Thread.run(Thread.java:722)
> "coreLoadExecutor-3-thread-1" prio=10 tid=0x7fbe04194000 nid=0x42c5 in 
> Object.wait() [0x7fbe0ac11000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0xc34c1c48> (a java.lang.Object)
>   at java.lang.Object.wait(Object.java:503)
>   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492)
>   - locked <0xc34c1c48> (a java.lang.Object)
>   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312)
>   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247)
>   at 
> org.apache.solr.handler.ReplicationHandler.getIndexVersion(ReplicationHandler.java:495)
>   at 
> org.apache.solr.handler.ReplicationHandler.getStatistics(ReplicationHandler.java:518)
>   at 
> org.apache.solr.core.JmxMonitoredMap$SolrDynamicMBean.getMBeanInfo(JmxMonitoredMap.java:232)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512)
>   at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:140)
>   at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:51)
>   at 
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:636)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:809)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:607

[jira] [Resolved] (SOLR-4459) The Replication 'index move' optimization doesn't kick in when using NRTCachingDirectory or the rate limiting option.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved SOLR-4459.
---

Resolution: Fixed

> The Replication 'index move' optimization doesn't kick in when using 
> NRTCachingDirectory or the rate limiting option.
> -
>
> Key: SOLR-4459
> URL: https://issues.apache.org/jira/browse/SOLR-4459
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4459.patches
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-3372) Upgrade Zookeeper to 3.4.x

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved SOLR-3372.
---

Resolution: Duplicate

Done in another issue.

> Upgrade Zookeeper to 3.4.x
> --
>
> Key: SOLR-3372
> URL: https://issues.apache.org/jira/browse/SOLR-3372
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Chris Male
>Priority: Minor
>
> I noticed while dealing with some log4j classpath problems in SOLR-3358, that 
> we have to include log4j-over-slf4j due to ZOOKEEPER-850, which has been 
> resolved in 3.4.0, so we should upgrade if we can.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4073) Overseer will miss operations in some cases for OverseerCollectionProcessor

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4073:
--

Fix Version/s: 5.0
   4.2
 Assignee: Mark Miller

> Overseer will miss  operations in some cases for OverseerCollectionProcessor
> 
>
> Key: SOLR-4073
> URL: https://issues.apache.org/jira/browse/SOLR-4073
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
> Environment: Solr cloud
>Reporter: Raintung Li
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: patch-4073
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> One overseer disconnect with Zookeeper, but overseer thread still handle the 
> request(A) in the DistributedQueue. Example: overseer thread reconnect 
> Zookeeper try to remove the Top's request. "workQueue.remove();".   
> Now the other server will take over the overseer privilege because old 
> overseer disconnect. Start overseer thread and handle the queue request(A) 
> again, and remove the request(A) from queue, then try to get the top's 
> request(B, doesn't get). In the this time old overseer reconnect with 
> ZooKeeper, and remove the top's request from queue. Now the top request is B, 
> it is moved by old overseer server.  New overseer server never do B 
> request,because this request deleted by old overseer server, at the last this 
> request(B) miss operations.
> At best, distributeQueue.peek can get the request's ID that will be removed 
> for workqueue.remove(ID), not remove the top's request.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-3964) Solr does not return error, even though create collection unsuccessfully

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved SOLR-3964.
---

Resolution: Duplicate

> Solr does not return error, even though create collection unsuccessfully 
> -
>
> Key: SOLR-3964
> URL: https://issues.apache.org/jira/browse/SOLR-3964
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: milesli
>  Labels: lack, message, response
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> Solr does not return error,
>  even though create/delete collection unsuccessfully; 
>  even though the request URL is incorrect;
> （example： 
> http://127.0.0.1:8983/solr/admin/collections?action=CREATE&name=tenancy_milesnumShards=3&numReplicas=2&collection.configName=myconf）
>  even though pass the collection name  already exists;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4459) The Replication 'index move' optimization doesn't kick in when using NRTCachingDirectory or the rate limiting option.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4459:
--

[branch_4x commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revision&revision=1446834

SOLR-4459: The Replication 'index move' rather than copy optimization doesn't 
kick in when using NRTCachingDirectory or the rate limiting feature.


> The Replication 'index move' optimization doesn't kick in when using 
> NRTCachingDirectory or the rate limiting option.
> -
>
> Key: SOLR-4459
> URL: https://issues.apache.org/jira/browse/SOLR-4459
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4459.patches
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4459) The Replication 'index move' optimization doesn't kick in when using NRTCachingDirectory or the rate limiting option.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4459:
--

[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revision&revision=1446833

SOLR-4459: The Replication 'index move' rather than copy optimization doesn't 
kick in when using NRTCachingDirectory or the rate limiting feature.


> The Replication 'index move' optimization doesn't kick in when using 
> NRTCachingDirectory or the rate limiting option.
> -
>
> Key: SOLR-4459
> URL: https://issues.apache.org/jira/browse/SOLR-4459
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4459.patches
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4780) MonotonicAppendingLongBuffer

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579628#comment-13579628
 ] 

Adrien Grand commented on LUCENE-4780:
--

bq. So this works even if its "mostly monotonic" but not always?

Even if not at all. The test case even tests it with completely random longs.

bq. In this case we would just get some negative deviations right?

Right.

> MonotonicAppendingLongBuffer
> 
>
> Key: LUCENE-4780
> URL: https://issues.apache.org/jira/browse/LUCENE-4780
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.2
>
> Attachments: LUCENE-4780.patch
>
>
> IndexWriter uses AppendingLongBuffer in several places, and in a few of them 
> the mapping is monotonically increasing so we could save additional space by 
> only encoding the delta from a linear projection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4780) MonotonicAppendingLongBuffer

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579620#comment-13579620
 ] 

Robert Muir commented on LUCENE-4780:
-

So this works even if its "mostly monotonic" but not always?

In LUCENE-4765, i refactored SortedBytes merging to use OrdinalMap, so if this 
works we can
also reduce RAM used during merging, which would be awesome. But using it in 
merge means that when there are 
"deleted terms" its ordinal mappings are not always strictly monotonic, but 
probably mostly so.

In this case we would just get some negative deviations right?


> MonotonicAppendingLongBuffer
> 
>
> Key: LUCENE-4780
> URL: https://issues.apache.org/jira/browse/LUCENE-4780
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.2
>
> Attachments: LUCENE-4780.patch
>
>
> IndexWriter uses AppendingLongBuffer in several places, and in a few of them 
> the mapping is monotonically increasing so we could save additional space by 
> only encoding the delta from a linear projection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Dave Cook (JIRA)]

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

Dave Cook commented on SOLR-4464:
-

Hi Shawn:

Yes, that's correct.  It's causing the counter up top to zero out...

Cheers,
Dave




> DIH - Processed documents counter resets to zero after first database request
> -
>
> Key: SOLR-4464
> URL: https://issues.apache.org/jira/browse/SOLR-4464
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1
> Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
> mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - 
> Java Heap set to 250Gb - resources are not an issue.
>Reporter: Dave Cook
>Priority: Minor
>  Labels: patch
>
> [11:20]  Solr 4.1 - Processed documents resets to 0 after 
> processing my first entity - all database schemas are identical
> [11:21]  However, all the documents get fetched and I can query 
> the results no problem.  
> Here's a link to a screenshot - http://findocs/gridworkz.com/solr 
> Everything works perfect except the screen doesn't increment the "Processed" 
> counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-2646) Integrate Solr benchmarking support into the Benchmark module

[Mark Bennett (JIRA)]

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

Mark Bennett commented on SOLR-2646:


Two other notes:
* Hard coded file path in the alg file
  
solr-lucene-410-bench/lucene/benchmark/conf/solr/internal/streaming-vs-httpcommon.alg
* I only pulled in the first 100 docs
  (by using the PDF instructions you can make the records line oriented, and 
use head -101 to get the first hundred records plus the header line)


> Integrate Solr benchmarking support into the Benchmark module
> -
>
> Key: SOLR-2646
> URL: https://issues.apache.org/jira/browse/SOLR-2646
> Project: Solr
>  Issue Type: New Feature
>Reporter: Mark Miller
> Attachments: chart.jpg, Dev-SolrBenchmarkModule.pdf, SOLR-2646.patch, 
> SOLR-2646.patch, SOLR-2646.patch, SOLR-2646.patch, SOLR-2646.patch, 
> SolrIndexingPerfHistory.pdf
>
>
> As part of my buzzwords Solr pef talk, I did some work to allow some Solr 
> benchmarking with the benchmark module.
> I'll attach a patch with the current work I've done soon - there is still a 
> fair amount to clean up and fix - a couple hacks or three - but it's already 
> fairly useful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4780) MonotonicAppendingLongBuffer

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-4780:


 Summary: MonotonicAppendingLongBuffer
 Key: LUCENE-4780
 URL: https://issues.apache.org/jira/browse/LUCENE-4780
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.2


IndexWriter uses AppendingLongBuffer in several places, and in a few of them 
the mapping is monotonically increasing so we could save additional space by 
only encoding the delta from a linear projection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-2646) Integrate Solr benchmarking support into the Benchmark module

[Mark Bennett (JIRA)]

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

Mark Bennett commented on SOLR-2646:


Arguments I used / specific test I got running.  If you're running other tests, 
your mileage may vary ;-)

Class: org.apache.lucene.benchmark.byTask.Benchmark
Argument: 
/Users/username/solr-lucene-410-bench/lucene/benchmark/conf/solr/internal/streaming-vs-httpcommon.alg
JVM: -Xmx512M


> Integrate Solr benchmarking support into the Benchmark module
> -
>
> Key: SOLR-2646
> URL: https://issues.apache.org/jira/browse/SOLR-2646
> Project: Solr
>  Issue Type: New Feature
>Reporter: Mark Miller
> Attachments: chart.jpg, Dev-SolrBenchmarkModule.pdf, SOLR-2646.patch, 
> SOLR-2646.patch, SOLR-2646.patch, SOLR-2646.patch, SOLR-2646.patch, 
> SolrIndexingPerfHistory.pdf
>
>
> As part of my buzzwords Solr pef talk, I did some work to allow some Solr 
> benchmarking with the benchmark module.
> I'll attach a patch with the current work I've done soon - there is still a 
> fair amount to clean up and fix - a couple hacks or three - but it's already 
> fairly useful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4780) MonotonicAppendingLongBuffer

[Adrien Grand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand updated LUCENE-4780:
-

Attachment: LUCENE-4780.patch

Patch. I tried to replace AppendingLongBuffer with MonotonicAppendingLongBuffer 
wherever it makes sense.

> MonotonicAppendingLongBuffer
> 
>
> Key: LUCENE-4780
> URL: https://issues.apache.org/jira/browse/LUCENE-4780
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.2
>
> Attachments: LUCENE-4780.patch
>
>
> IndexWriter uses AppendingLongBuffer in several places, and in a few of them 
> the mapping is monotonically increasing so we could save additional space by 
> only encoding the delta from a linear projection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4779) Simplify TestSort

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579519#comment-13579519
 ] 

Commit Tag Bot commented on LUCENE-4779:


[branch_4x commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1446782

LUCENE-4779: backport


> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
> Fix For: 4.2, 5.0
>
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4779) Simplify TestSort

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-4779.
-

   Resolution: Fixed
Fix Version/s: 5.0
   4.2

> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
> Fix For: 4.2, 5.0
>
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3583) Percentiles for facets, pivot facets, and distributed pivot facets

[Andrew Muldowney (JIRA)]

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

Andrew Muldowney commented on SOLR-3583:


I'm working on making a new version of this patch to work properly with the new 
version of SOLR-2894 that does distributed pivot facet refinements correctly.

> Percentiles for facets, pivot facets, and distributed pivot facets
> --
>
> Key: SOLR-3583
> URL: https://issues.apache.org/jira/browse/SOLR-3583
> Project: Solr
>  Issue Type: Improvement
>Reporter: Chris Russell
>Priority: Minor
>  Labels: newbie, patch
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3583.patch, SOLR-3583.patch, SOLR-3583.patch
>
>
> Built on top of SOLR-2894, this patch adds percentiles and averages to 
> facets, pivot facets, and distributed pivot facets by making use of range 
> facet internals.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-2894) Implement distributed pivot faceting

[Andrew Muldowney (JIRA)]

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

Andrew Muldowney edited comment on SOLR-2894 at 2/15/13 9:21 PM:
-

As Chris said above me I've been working on distributed pivot faceting. The 
model had to be reworked to support this change. The new workflow is each 
shards result goes into a shardRequest map, those maps are combined and 
converted into a list what is what is is looked at. The combined results are 
compared to each shard's and refinement requests are made. Once all the 
refinement requests are made another round of refinement is queued up, this 
time going one level deeper than the previous refinement requests. Because of 
the nature of the system distributedprocess(rb) needed to be called from the 
refinepivotfacets to actually take the enqueued refinement requests and make 
them into fully fledged refinement queries. This caused some issue where other 
refinment types would get recalled as their refinement identifier was never 
cleared, Field facets are slightly modified to have a boolean for 
"needsRefinements" and one for "wasRefined" to help distinguish.

  was (Author: andrew.muldowney):
As Chris said above me I've been working on distributed pivot faceting. The 
model had to be reworked to support this change. The new workflow is each 
shards result goes into a shardRequest map, those maps are combined and 
converted into a list what is what is is looked at. The combined results are 
compared to each shard's and refinement requests are made. Once all the 
refinement requests are made another round of refinement is queued up, this 
time going one level deeper than the previous refinement requests. Because of 
the nature of the system distributedprocess(rb) needed to be called from the 
refinepivotfacets to actually take the enqueued refinement requests and make 
them into fully fledged refinement queries. This caused some issue where other 
refinment types would get recalled at their refinement identifier was never 
cleared, Field facets are slightly modified to have a boolean for 
"needsRefinements" and one for "wasRefined" to help distinguish.
  
> Implement distributed pivot faceting
> 
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erik Hatcher
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894-reworked.patch
>
>
> Following up on SOLR-792, pivot faceting currently only supports 
> undistributed mode.  Distributed pivot faceting needs to be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-2894) Implement distributed pivot faceting

[Andrew Muldowney (JIRA)]

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

Andrew Muldowney edited comment on SOLR-2894 at 2/15/13 9:20 PM:
-

As Chris said above me I've been working on distributed pivot faceting. The 
model had to be reworked to support this change. The new workflow is each 
shards result goes into a shardRequest map, those maps are combined and 
converted into a list what is what is is looked at. The combined results are 
compared to each shard's and refinement requests are made. Once all the 
refinement requests are made another round of refinement is queued up, this 
time going one level deeper than the previous refinement requests. Because of 
the nature of the system distributedprocess(rb) needed to be called from the 
refinepivotfacets to actually take the enqueued refinement requests and make 
them into fully fledged refinement queries. This caused some issue where other 
refinment types would get recalled at their refinement identifier was never 
cleared, Field facets are slightly modified to have a boolean for 
"needsRefinements" and one for "wasRefined" to help distinguish.

  was (Author: andrew.muldowney):
Distributed pivot faceting, along with testing
  
> Implement distributed pivot faceting
> 
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erik Hatcher
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894-reworked.patch
>
>
> Following up on SOLR-792, pivot faceting currently only supports 
> undistributed mode.  Distributed pivot faceting needs to be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4779) Simplify TestSort

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579507#comment-13579507
 ] 

Commit Tag Bot commented on LUCENE-4779:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1446776

LUCENE-4779: add remaining tests


> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4779) Simplify TestSort

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579506#comment-13579506
 ] 

Commit Tag Bot commented on LUCENE-4779:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1446777

LUCENE-4779: replace old TestSort


> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting

[Andrew Muldowney (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Muldowney updated SOLR-2894:
---

Attachment: SOLR-2894.patch

Distributed pivot faceting, along with testing

> Implement distributed pivot faceting
> 
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erik Hatcher
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894-reworked.patch
>
>
> Following up on SOLR-792, pivot faceting currently only supports 
> undistributed mode.  Distributed pivot faceting needs to be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4779) Simplify TestSort

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579502#comment-13579502
 ] 

Commit Tag Bot commented on LUCENE-4779:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1446762

LUCENE-4779: add missing values tests


> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4466) DIH "Started" status says "less than a minute ago" when it's been much longer

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-4466:


I am not running into this on my own system, but I have seen it in connection 
with an import on another issue - SOLR-4464.

One difference between that user's setup and mine is that they have multiple 
entities - one for every US state and DC.  I only have one.


> DIH "Started" status says "less than a minute ago" when it's been much longer
> -
>
> Key: SOLR-4466
> URL: https://issues.apache.org/jira/browse/SOLR-4466
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> Sometimes (exact circumstances not known) the "Started" output on the DIH 
> status in the 4.1 UI will always say "less than a minute ago" even though the 
> actual value is quite some time ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4466) DIH "Started" status says "less than a minute ago" when it's been much longer

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-4466:
--

 Summary: DIH "Started" status says "less than a minute ago" when 
it's been much longer
 Key: SOLR-4466
 URL: https://issues.apache.org/jira/browse/SOLR-4466
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Shawn Heisey
 Fix For: 4.2, 5.0


Sometimes (exact circumstances not known) the "Started" output on the DIH 
status in the 4.1 UI will always say "less than a minute ago" even though the 
actual value is quite some time ago.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4465) Configurable Collectors

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-4465:


 Summary: Configurable Collectors
 Key: SOLR-4465
 URL: https://issues.apache.org/jira/browse/SOLR-4465
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.1
Reporter: Joel Bernstein
 Fix For: 4.2, 5.0


This issue is to add configurable custom collectors to Solr. This expands the 
design and work done in issue SOLR-1680 to include:

1) CollectorFactory configuration in solconfig.xml
2) Http parameters to allow clients to dynamically select a CollectorFactory 
and construct a custom Collector.
3) Make aspects of QueryComponent pluggable so that the output from distributed 
search can conform with custom collectors at the shard level.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-4464:


I'm with the user in #solr.  The "Total Documents Processed" field in the raw 
DIH output appears to go missing when it switches to the second request.  It's 
not there at all.


> DIH - Processed documents counter resets to zero after first database request
> -
>
> Key: SOLR-4464
> URL: https://issues.apache.org/jira/browse/SOLR-4464
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1
> Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
> mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - 
> Java Heap set to 250Gb - resources are not an issue.
>Reporter: Dave Cook
>Priority: Minor
>  Labels: patch
>
> [11:20]  Solr 4.1 - Processed documents resets to 0 after 
> processing my first entity - all database schemas are identical
> [11:21]  However, all the documents get fetched and I can query 
> the results no problem.  
> Here's a link to a screenshot - http://findocs/gridworkz.com/solr 
> Everything works perfect except the screen doesn't increment the "Processed" 
> counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Dave Cook (JIRA)]

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

Dave Cook commented on SOLR-4464:
-

Hi Greg:

I just reset back to zero on the second request:
http://76.72.160.178:8080/solr/#/zev/dataimport//dataimport

Cheers,
Dave




> DIH - Processed documents counter resets to zero after first database request
> -
>
> Key: SOLR-4464
> URL: https://issues.apache.org/jira/browse/SOLR-4464
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1
> Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
> mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - 
> Java Heap set to 250Gb - resources are not an issue.
>Reporter: Dave Cook
>Priority: Minor
>  Labels: patch
>
> [11:20]  Solr 4.1 - Processed documents resets to 0 after 
> processing my first entity - all database schemas are identical
> [11:21]  However, all the documents get fetched and I can query 
> the results no problem.  
> Here's a link to a screenshot - http://findocs/gridworkz.com/solr 
> Everything works perfect except the screen doesn't increment the "Processed" 
> counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4451) Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4451:
---

No such luck for me - I'll be trying to figure out why later.

> Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient
> -
>
> Key: SOLR-4451
> URL: https://issues.apache.org/jira/browse/SOLR-4451
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4451.patch
>
>
> HttpComponent is up to version 4.2, and included in 4.2 is a new subclass of 
> DefaultHttpClient named SystemDefaultHttpClient, which automatically 
> configures itself using the "standard" java system properties...
> http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/SystemDefaultHttpClient.html
> ...i think we should upgrade and start using this new class in place of 
> DefaultHttpClient, so that SolrJ clients (and implicitly SolrCloud) can 
> automaticly leverage system properties users may expect to work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4451) Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-4451:
---

i did the following:

svn up
ant eclipse
refresh project

and tests seemed to work fine here

> Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient
> -
>
> Key: SOLR-4451
> URL: https://issues.apache.org/jira/browse/SOLR-4451
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4451.patch
>
>
> HttpComponent is up to version 4.2, and included in 4.2 is a new subclass of 
> DefaultHttpClient named SystemDefaultHttpClient, which automatically 
> configures itself using the "standard" java system properties...
> http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/SystemDefaultHttpClient.html
> ...i think we should upgrade and start using this new class in place of 
> DefaultHttpClient, so that SolrJ clients (and implicitly SolrCloud) can 
> automaticly leverage system properties users may expect to work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4459) The Replication 'index move' optimization doesn't kick in when using NRTCachingDirectory or the rate limiting option.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4459:
--

Attachment: SOLR-4459.patches

We need something like this patch for the short term.

> The Replication 'index move' optimization doesn't kick in when using 
> NRTCachingDirectory or the rate limiting option.
> -
>
> Key: SOLR-4459
> URL: https://issues.apache.org/jira/browse/SOLR-4459
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4459.patches
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4451) Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-4451:


mark: Is there a classpath conflict between the httpclient version used by solr 
and some other httpclient version used in eclipse? because "
org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault()Lorg/apache/http/conn/scheme/SchemeRegistry"
 seems to exist in ./solrj/lib/httpclient-4.2.3.jar (which didn't change as 
part of SOLR-4462)

> Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient
> -
>
> Key: SOLR-4451
> URL: https://issues.apache.org/jira/browse/SOLR-4451
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4451.patch
>
>
> HttpComponent is up to version 4.2, and included in 4.2 is a new subclass of 
> DefaultHttpClient named SystemDefaultHttpClient, which automatically 
> configures itself using the "standard" java system properties...
> http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/SystemDefaultHttpClient.html
> ...i think we should upgrade and start using this new class in place of 
> DefaultHttpClient, so that SolrJ clients (and implicitly SolrCloud) can 
> automaticly leverage system properties users may expect to work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4451) Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-4451:


mark: nothing should be intrinsically dependent on a system property, it just 
uses them if they are set to provide defaults.

bq. 410 T11 oasc.SolrException.log SEVERE null:java.lang.NoSuchMethodError: 
org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault()Lorg/apache/http/conn/scheme/SchemeRegistry;

Do you see this before or after sarowe's changes in SOLR-4462 (or both?)


> Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient
> -
>
> Key: SOLR-4451
> URL: https://issues.apache.org/jira/browse/SOLR-4451
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4451.patch
>
>
> HttpComponent is up to version 4.2, and included in 4.2 is a new subclass of 
> DefaultHttpClient named SystemDefaultHttpClient, which automatically 
> configures itself using the "standard" java system properties...
> http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/SystemDefaultHttpClient.html
> ...i think we should upgrade and start using this new class in place of 
> DefaultHttpClient, so that SolrJ clients (and implicitly SolrCloud) can 
> automaticly leverage system properties users may expect to work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4451) Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4451:
---

Some tests run from eclipse now seem to fail after this. Is there a sys prop I 
need to pass now or something? I seem to get:

{noformat}410 T11 oasc.SolrException.log SEVERE 
null:java.lang.NoSuchMethodError: 
org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault()Lorg/apache/http/conn/scheme/SchemeRegistry;
at 
org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:118)
at 
org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:445)
at 
org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:179)
at 
org.apache.solr.client.solrj.impl.HttpClientConfigurer.configure(HttpClientConfigurer.java:33)
at 
org.apache.solr.client.solrj.impl.HttpClientUtil.configureClient(HttpClientUtil.java:115)
at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:105)
at 
org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:134)
at 
org.apache.solr.core.CoreContainer.initShardHandler(CoreContainer.java:704){noformat}

> Upgrade to httpclient 4.2.x and take advantage of SystemDefaultHttpClient
> -
>
> Key: SOLR-4451
> URL: https://issues.apache.org/jira/browse/SOLR-4451
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4451.patch
>
>
> HttpComponent is up to version 4.2, and included in 4.2 is a new subclass of 
> DefaultHttpClient named SystemDefaultHttpClient, which automatically 
> configures itself using the "standard" java system properties...
> http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/SystemDefaultHttpClient.html
> ...i think we should upgrade and start using this new class in place of 
> DefaultHttpClient, so that SolrJ clients (and implicitly SolrCloud) can 
> automaticly leverage system properties users may expect to work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4779) Simplify TestSort

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579452#comment-13579452
 ] 

Commit Tag Bot commented on LUCENE-4779:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1446741

LUCENE-4779: add custom parser tests


> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4778) Add a getter for the delegate in RateLimitedDirectoryWrapper.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved LUCENE-4778.
-

Resolution: Fixed

> Add a getter for the delegate in RateLimitedDirectoryWrapper.
> -
>
> Key: LUCENE-4778
> URL: https://issues.apache.org/jira/browse/LUCENE-4778
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Dave Cook (JIRA)]

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

Dave Cook commented on SOLR-4464:
-

Hi Greg:

I reset to 32Gb heap - as you can see Processed: looks fine on the first
Request, it'll take about 45min to hit the second request.

http://76.72.160.178:8080/solr/#/zev/dataimport//dataimport

Cheers,
Dave




> DIH - Processed documents counter resets to zero after first database request
> -
>
> Key: SOLR-4464
> URL: https://issues.apache.org/jira/browse/SOLR-4464
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1
> Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
> mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - 
> Java Heap set to 250Gb - resources are not an issue.
>Reporter: Dave Cook
>Priority: Minor
>  Labels: patch
>
> [11:20]  Solr 4.1 - Processed documents resets to 0 after 
> processing my first entity - all database schemas are identical
> [11:21]  However, all the documents get fetched and I can query 
> the results no problem.  
> Here's a link to a screenshot - http://findocs/gridworkz.com/solr 
> Everything works perfect except the screen doesn't increment the "Processed" 
> counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4778) Add a getter for the delegate in RateLimitedDirectoryWrapper.

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579437#comment-13579437
 ] 

Commit Tag Bot commented on LUCENE-4778:


[branch_4x commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revision&revision=1446730

LUCENE-4778: Add a getter for the delegate in RateLimitedDirectoryWrapper.


> Add a getter for the delegate in RateLimitedDirectoryWrapper.
> -
>
> Key: LUCENE-4778
> URL: https://issues.apache.org/jira/browse/LUCENE-4778
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4778) Add a getter for the delegate in RateLimitedDirectoryWrapper.

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579431#comment-13579431
 ] 

Commit Tag Bot commented on LUCENE-4778:


[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revision&revision=1446729

LUCENE-4778: Add a getter for the delegate in RateLimitedDirectoryWrapper.


> Add a getter for the delegate in RateLimitedDirectoryWrapper.
> -
>
> Key: LUCENE-4778
> URL: https://issues.apache.org/jira/browse/LUCENE-4778
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Greg Bowyer (JIRA)]

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

Greg Bowyer commented on SOLR-4464:
---

. I should read bug reports more carefully, everything else is working fine 
so maybe the heap size is not the issue (I would still lower it however)

> DIH - Processed documents counter resets to zero after first database request
> -
>
> Key: SOLR-4464
> URL: https://issues.apache.org/jira/browse/SOLR-4464
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1
> Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
> mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - 
> Java Heap set to 250Gb - resources are not an issue.
>Reporter: Dave Cook
>Priority: Minor
>  Labels: patch
>
> [11:20]  Solr 4.1 - Processed documents resets to 0 after 
> processing my first entity - all database schemas are identical
> [11:21]  However, all the documents get fetched and I can query 
> the results no problem.  
> Here's a link to a screenshot - http://findocs/gridworkz.com/solr 
> Everything works perfect except the screen doesn't increment the "Processed" 
> counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Greg Bowyer (JIRA)]

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

Greg Bowyer commented on SOLR-4464:
---

There is a good chance that a 250GB heap is the root cause of your problems, 
can you lower it to 16 or 32gb as a start and then see if this problem persists 
?

> DIH - Processed documents counter resets to zero after first database request
> -
>
> Key: SOLR-4464
> URL: https://issues.apache.org/jira/browse/SOLR-4464
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1
> Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
> mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - 
> Java Heap set to 250Gb - resources are not an issue.
>Reporter: Dave Cook
>Priority: Minor
>  Labels: patch
>
> [11:20]  Solr 4.1 - Processed documents resets to 0 after 
> processing my first entity - all database schemas are identical
> [11:21]  However, all the documents get fetched and I can query 
> the results no problem.  
> Here's a link to a screenshot - http://findocs/gridworkz.com/solr 
> Everything works perfect except the screen doesn't increment the "Processed" 
> counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4779) Simplify TestSort

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579416#comment-13579416
 ] 

Commit Tag Bot commented on LUCENE-4779:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1446727

LUCENE-4779: exercise all sorting collectors in this test


> Simplify TestSort
> -
>
> Key: LUCENE-4779
> URL: https://issues.apache.org/jira/browse/LUCENE-4779
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
>
> there must be a better way!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #770: POMs out of sync

[Robert Muir]

Thanks Steve!

I am happy to see the checker working

On Fri, Feb 15, 2013 at 2:00 PM, Steve Rowe  wrote:
> Fixed under SOLR-4462.
>
> On Feb 15, 2013, at 10:22 AM, Steve Rowe  wrote:
>
>> I read this email exchange as describing intentionally versioning httpclient 
>> separately from httpcore: .
>>
>> I can see that the previous three releases of httpclient (4.2.2, 4.2.1 and 
>> 4.2) depend on the exact same httpcore version, rather than lagging. 
>> [1][2][3]
>>
>> Going back, though, I can see more deviations from version sync: httpclient 
>> 4.1.3 depends on httpcore 4.1.4 (!), and httpclient 4.1.1 depends on 
>> httpcore 4.1. [4][5]
>>
>> So, again, I think the Lucene/Solr Ant build needs to change here to mirror 
>> the httpcomponents project's separate httpclient and httpcore versioning.
>>
>> I'll open a JIRA issue.
>>
>> Steve
>>
>> [1] 
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.2/pom.xml
>> [2] 
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.1/pom.xml
>> [3] 
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2/pom.xml
>> [4] 
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml
>> [5] 
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml
>>
>> On Feb 15, 2013, at 9:26 AM, Steve Rowe  wrote:
>>
>>> I'm looking into it.
>>>
>>> Httpclient uses Maven as its build system, so when the httpclient POM 
>>> declares a dependency, it's authoritative (since that's how it's built).
>>>
>>> The 4.2.3 release of httpclient depends on the 4.2.2 release of httpcore.  
>>> Looks to me like in this case the Solr Ant build should change to use the 
>>> 4.2.2 release of httpcore, rather than the Maven build changing.
>>>
>>> I see that the current trunk version of httpclient (4.3-alpha2-SNAPSHOT) 
>>> depends on the previous version of httpcore (4.3-alpha1): 
>>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/pom.xml - 
>>> look for the  under properties.  So this version lag 
>>> looks like it may be process driven, rather than a mistake.
>>>
>>> Steve
>>>
>>> On Feb 15, 2013, at 9:11 AM, Robert Muir  wrote:
>>>
 the poms are really out of sync. ant build depends on httpcore 4.2.3
 but maven on 4.2.2

 On Thu, Feb 14, 2013 at 11:34 PM, Apache Jenkins Server
  wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/770/
>
> No tests ran.
>
> Build Log:
> [...truncated 11059 lines...]
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #770: POMs out of sync

[Steve Rowe]

Fixed under SOLR-4462.

On Feb 15, 2013, at 10:22 AM, Steve Rowe  wrote:

> I read this email exchange as describing intentionally versioning httpclient 
> separately from httpcore: .
> 
> I can see that the previous three releases of httpclient (4.2.2, 4.2.1 and 
> 4.2) depend on the exact same httpcore version, rather than lagging. [1][2][3]
> 
> Going back, though, I can see more deviations from version sync: httpclient 
> 4.1.3 depends on httpcore 4.1.4 (!), and httpclient 4.1.1 depends on httpcore 
> 4.1. [4][5]
> 
> So, again, I think the Lucene/Solr Ant build needs to change here to mirror 
> the httpcomponents project's separate httpclient and httpcore versioning.
> 
> I'll open a JIRA issue.
> 
> Steve
> 
> [1] 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.2/pom.xml
> [2] 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.1/pom.xml
> [3] http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2/pom.xml
> [4] 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml
> [5] 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml
> 
> On Feb 15, 2013, at 9:26 AM, Steve Rowe  wrote:
> 
>> I'm looking into it.  
>> 
>> Httpclient uses Maven as its build system, so when the httpclient POM 
>> declares a dependency, it's authoritative (since that's how it's built).  
>> 
>> The 4.2.3 release of httpclient depends on the 4.2.2 release of httpcore.  
>> Looks to me like in this case the Solr Ant build should change to use the 
>> 4.2.2 release of httpcore, rather than the Maven build changing.
>> 
>> I see that the current trunk version of httpclient (4.3-alpha2-SNAPSHOT) 
>> depends on the previous version of httpcore (4.3-alpha1): 
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/pom.xml - 
>> look for the  under properties.  So this version lag looks 
>> like it may be process driven, rather than a mistake.
>> 
>> Steve
>> 
>> On Feb 15, 2013, at 9:11 AM, Robert Muir  wrote:
>> 
>>> the poms are really out of sync. ant build depends on httpcore 4.2.3
>>> but maven on 4.2.2
>>> 
>>> On Thu, Feb 14, 2013 at 11:34 PM, Apache Jenkins Server
>>>  wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/770/
 
 No tests ran.
 
 Build Log:
 [...truncated 11059 lines...]


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

[jira] [Resolved] (SOLR-4463) SolrCoreState ref counting is off for SolrCore reloads.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved SOLR-4463.
---

Resolution: Fixed

> SolrCoreState ref counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracked on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4464) DIH - Processed documents counter resets to zero after first database request

[Dave Cook (JIRA)]

Dave Cook created SOLR-4464:
---

 Summary: DIH - Processed documents counter resets to zero after 
first database request
 Key: SOLR-4464
 URL: https://issues.apache.org/jira/browse/SOLR-4464
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 4.1
 Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / 
mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - Java 
Heap set to 250Gb - resources are not an issue.
Reporter: Dave Cook
Priority: Minor


[11:20]  Solr 4.1 - Processed documents resets to 0 after 
processing my first entity - all database schemas are identical
[11:21]  However, all the documents get fetched and I can query 
the results no problem.  

Here's a link to a screenshot - http://findocs/gridworkz.com/solr 

Everything works perfect except the screen doesn't increment the "Processed" 
counter on subsequent database Requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4463) SolrCoreState ref counting is off for SolrCore reloads.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4463:
--

Priority: Critical  (was: Major)

> SolrCoreState ref counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracked on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4463) SolrCoreState ref counting is off for SolrCore reloads.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4463:
--

[branch_4x commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revision&revision=1446719

SOLR-4463: Fix SolrCoreState reference counting. 


> SolrCoreState ref counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracked on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4462:
-

Affects Version/s: (was: 4.0)
   (was: 4.1)
   4.2

> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.2
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 4.2
>
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}) (these are POMs for httpcomponents-client, which is the 
> parent module for httpclient, and declares its submodules' dependencies' 
> versions):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpcomponents-client POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe resolved SOLR-4462.
--

   Resolution: Fixed
Fix Version/s: 4.2
 Assignee: Steve Rowe

Committed to trunk and branch_4x.

> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 4.2
>
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}) (these are POMs for httpcomponents-client, which is the 
> parent module for httpclient, and declares its submodules' dependencies' 
> versions):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpcomponents-client POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4463) SolrCoreState ref counting is off for SolrCore reloads.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4463:
--

[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revision&revision=1446716

SOLR-4463: Fix SolrCoreState reference counting. 


> SolrCoreState ref counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracked on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4462:
-

Description: 
The httpcomponents project, which hosts both the httpclient and the httpcore 
modules, uses Maven as its build system, so when the httpclient POM declares a 
dependency, it's authoritative (since that's how httpclient is built and 
tested).

httpclient's httpcore dependency version doesn't always match the httpclient 
version.  Recent examples (look for {{}} under 
{{}}) (these are POMs for httpcomponents-client, which is the 
parent module for httpclient, and declares its submodules' dependencies' 
versions):

[https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
[http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
[http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]

I'm fairly certain that these versions-out-of-sync incidents are not mistakes - 
I read this email exchange as describing intentionally versioning httpclient 
separately from httpcore: [http://markmail.org/thread/ippp4gbxwwnt6aws].

SolrJ should separately version its httpclient and httpcore dependencies, and 
should draw the httpcore version from the httpcomponents-client POM.

  was:
The httpcomponents project, which hosts both the httpclient and the httpcore 
modules, uses Maven as its build system, so when the httpclient POM declares a 
dependency, it's authoritative (since that's how httpclient is built and 
tested).  httpclient depends on httpcore, so the SolrJ httpcore version should 
be drawn from the httpclient POM.

httpclient's httpcore dependency version doesn't always match the httpclient 
version.  Recent examples (look for {{}} under 
{{}}):

[https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
[http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
[http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]

I'm fairly certain that these versions-out-of-sync incidents are not mistakes - 
I read this email exchange as describing intentionally versioning httpclient 
separately from httpcore: [http://markmail.org/thread/ippp4gbxwwnt6aws].

SolrJ should separately version its httpclient and httpcore dependencies, and 
should draw the httpcore version from the httpclient POM.


> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}) (these are POMs for httpcomponents-client, which is the 
> parent module for httpclient, and declares its submodules' dependencies' 
> versions):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpcomponents-client POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3855) DocValues support

[Adrien Grand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand updated SOLR-3855:
---

Attachment: SOLR-3855.patch

New patch, all tests passed.

 - I made DV integration in the stats component a little cleaner,
 - numeric faceting now works even if facet.mincount=0 but it requires the 
field to be indexed.

I think it's ready?

> DocValues support
> -
>
> Key: SOLR-3855
> URL: https://issues.apache.org/jira/browse/SOLR-3855
> Project: Solr
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3855.patch, SOLR-3855.patch, SOLR-3855.patch, 
> SOLR-3855.patch, SOLR-3855.patch, SOLR-3855.patch, SOLR-3855.patch, 
> SOLR-3855.patch
>
>
> It would be nice if Solr supported DocValues:
>  - for ID fields (fewer disk seeks when running distributed search),
>  - for sorting/faceting/function queries (faster warmup time than fieldcache),
>  - better on-disk and in-memory efficiency (you can use packed impls).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4462:
--

[branch_4x commit] Steven Rowe
http://svn.apache.org/viewvc?view=revision&revision=1446714

SOLR-4462: downgraded Solrj httpcore dependency from 4.2.3 to 4.2.2, and added 
comments to solrj/ivy.xml describing versioning for httpcomponents httpmime and 
httpcore, based on httpclient version (merged trunk r1446713)


> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).  httpclient depends on httpcore, so the SolrJ httpcore version 
> should be drawn from the httpclient POM.
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpclient POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-4462:


bq. Comments added to solrj/ivy.xml discussing how to choose versions for 
httpcomponents httpmime and httpcore, based on the httpclient version.

+1 ... i actually noticed the discrepency in versions in that ivy.xml file when 
i commited r1445945 in SOLR-4451, but thought that was an existing bug 
(particularly since the pom.xml.template had a single consistent version number 
for httpcomponents.version (i didn't realize it was because of a transitive 
dependency quirks)

Running tests now with sarowe's patch to sanity check

> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).  httpclient depends on httpcore, so the SolrJ httpcore version 
> should be drawn from the httpclient POM.
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpclient POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4462:
--

[trunk commit] Steven Rowe
http://svn.apache.org/viewvc?view=revision&revision=1446713

SOLR-4462: downgraded Solrj httpcore dependency from 4.2.3 to 4.2.2, and added 
comments to solrj/ivy.xml describing versioning for httpcomponents httpmime and 
httpcore, based on httpclient version


> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).  httpclient depends on httpcore, so the SolrJ httpcore version 
> should be drawn from the httpclient POM.
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpclient POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-4462 at 2/15/13 5:56 PM:
---

Patch downgrading SolrJ httpcore dependency from 4.2.3 to 4.2.2.

Comments added to solrj/ivy.xml discussing how to choose versions for 
httpcomponents httpmime and httpcore, based on the httpclient version.

{{ant precommit}} and {{ant validate-maven-dependencies}} both pass. 

All Solr core, solrj, and Solr contrib tests pass, except 
ChaosMonkeySafeLeaderTest.testDistribSearch, which doesn't reliably reproduce 
(sometimes succeeds with a previously failing seed).  It mostly fails for me 
though (4/5 trials) - it seems to be much slower (~4X) when it fails.  I see 
Hoss already made an issue for this: SOLR-4454.

Committing shortly.


  was (Author: steve_rowe):
Patch downgrading SoljJ httpcore dependency from 4.2.3 to 4.2.2.

Comments added to solrj/ivy.xml discussing how to choose versions for 
httpcomponents httpmime and httpcore, based on the httpclient version.

{{ant precommit}} and {{ant validate-maven-dependencies}} both pass. 

All Solr core, solrj, and Solr contrib tests pass, except 
ChaosMonkeySafeLeaderTest.testDistribSearch, which doesn't reliably reproduce 
(sometimes succeeds with a previously failing seed).  It mostly fails for me 
though (4/5 trials) - it seems to be much slower (~4X) when it fails.  I see 
Hoss already made an issue for this: SOLR-4454.

Committing shortly.

  
> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).  httpclient depends on httpcore, so the SolrJ httpcore version 
> should be drawn from the httpclient POM.
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpclient POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4462:
-

Attachment: SOLR-4462.patch

Patch downgrading SoljJ httpcore dependency from 4.2.3 to 4.2.2.

Comments added to solrj/ivy.xml discussing how to choose versions for 
httpcomponents httpmime and httpcore, based on the httpclient version.

{{ant precommit}} and {{ant validate-maven-dependencies}} both pass. 

All Solr core, solrj, and Solr contrib tests pass, except 
ChaosMonkeySafeLeaderTest.testDistribSearch, which doesn't reliably reproduce 
(sometimes succeeds with a previously failing seed).  It mostly fails for me 
though (4/5 trials) - it seems to be much slower (~4X) when it fails.  I see 
Hoss already made an issue for this: SOLR-4454.

Committing shortly.


> SolrJ's httpclient and httpcore dependency versions should not be 
> synchronized - instead, the httpcore version to use should be drawn from the 
> httpclient POM
> -
>
> Key: SOLR-4462
> URL: https://issues.apache.org/jira/browse/SOLR-4462
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-4462.patch
>
>
> The httpcomponents project, which hosts both the httpclient and the httpcore 
> modules, uses Maven as its build system, so when the httpclient POM declares 
> a dependency, it's authoritative (since that's how httpclient is built and 
> tested).  httpclient depends on httpcore, so the SolrJ httpcore version 
> should be drawn from the httpclient POM.
> httpclient's httpcore dependency version doesn't always match the httpclient 
> version.  Recent examples (look for {{}} under 
> {{}}):
> [https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
> [http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]
> I'm fairly certain that these versions-out-of-sync incidents are not mistakes 
> - I read this email exchange as describing intentionally versioning 
> httpclient separately from httpcore: 
> [http://markmail.org/thread/ippp4gbxwwnt6aws].
> SolrJ should separately version its httpclient and httpcore dependencies, and 
> should draw the httpcore version from the httpclient POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4316) Admin UI - SolrCloud - extend core options to collections

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-4316:


If you decide that the current request-to-shard behavior is preferable to 
changing things, then I think that the query UI needs a highly visible notice 
that requests to that shard will actually go to the entire collection unless 
they make distrib=false, and there needs to be a checkbox for that parameter.

Either way, I think it's a good idea to make collections available as entities 
within the UI.


> Admin UI - SolrCloud - extend core options to collections
> -
>
> Key: SOLR-4316
> URL: https://issues.apache.org/jira/browse/SOLR-4316
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> There are a number of sections available when you are looking at a core in 
> the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, 
> Plugins / Stats, and Dataimport are the ones that I can see.
> A list of collections should be available, with as many of those options that 
> can apply to a collection,  If options specific to collections/SolrCloud can 
> be implemented, those should be there too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4316) Admin UI - SolrCloud - extend core options to collections

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4316:
---

It's how most distributed systems work. You hit one node, it queries your 
cluster by default - not just that one node.

> Admin UI - SolrCloud - extend core options to collections
> -
>
> Key: SOLR-4316
> URL: https://issues.apache.org/jira/browse/SOLR-4316
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> There are a number of sections available when you are looking at a core in 
> the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, 
> Plugins / Stats, and Dataimport are the ones that I can see.
> A list of collections should be available, with as many of those options that 
> can apply to a collection,  If options specific to collections/SolrCloud can 
> be implemented, those should be there too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4778) Add a getter for the delegate in RateLimitedDirectoryWrapper.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated LUCENE-4778:


Fix Version/s: 5.0

> Add a getter for the delegate in RateLimitedDirectoryWrapper.
> -
>
> Key: LUCENE-4778
> URL: https://issues.apache.org/jira/browse/LUCENE-4778
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4778) Add a getter for the delegate in RateLimitedDirectoryWrapper.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579326#comment-13579326
 ] 

Mark Miller commented on LUCENE-4778:
-

I'm just going to put the same thing NRTCachingDirectory has, getDelegate.

> Add a getter for the delegate in RateLimitedDirectoryWrapper.
> -
>
> Key: LUCENE-4778
> URL: https://issues.apache.org/jira/browse/LUCENE-4778
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4316) Admin UI - SolrCloud - extend core options to collections

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-4316:


bq. That's not right. You query the whole collection unless you pass the param 
distrib=false.

Very interesting!  That's not what I would have expected ... which IMHO 
violates the principle of least surprise.  If the core has the same name as the 
collection, then it's not a violation of that principle, and from what I 
understand, a 4.0.0 install *does* name the cores the same as the collection.  
I have not actually used 4.0.0 myself.

If cores are going to continue with the 4.1 method of having distinct names 
from the collection, then I think a request to a core should not go cloud-wide 
unless you specifically request that with an option.

Users who have never touched Solr before using SolrCloud of course have no 
expectations about how things work, and probably will appreciate this behavior. 
 It would be a similar situation for experienced users that have never tried 
the shards parameter.

Users like me that have distributed experience with older versions would be 
very surprised by this behavior, and will be looking for a "collections" 
section in the admin UI -- which is exactly what happened when I first started 
working with SolrCloud.


> Admin UI - SolrCloud - extend core options to collections
> -
>
> Key: SOLR-4316
> URL: https://issues.apache.org/jira/browse/SOLR-4316
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> There are a number of sections available when you are looking at a core in 
> the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, 
> Plugins / Stats, and Dataimport are the ones that I can see.
> A list of collections should be available, with as many of those options that 
> can apply to a collection,  If options specific to collections/SolrCloud can 
> be implemented, those should be there too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4463) SolrCoreState ref counting is off for SolrCore reloads.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4463:
--

Summary: SolrCoreState ref counting is off for SolrCore reloads.  (was: 
SolrCoreState reg counting is off for SolrCore reloads.)

Patch attached, with new test.

> SolrCoreState ref counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracked on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4463) SolrCoreState reg counting is off for SolrCore reloads.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4463:
--

Description: Seems to work sometimes, perhaps because of races, but when we 
moved this ref counting to the SolrCore to work around some other issues, the 
ref counting across reloads was messed up since the ref count is tracked on the 
SolrCore.  (was: Seems to work sometimes, perhaps because of races, but when we 
moved this ref counting to the SolrCore to work around some other issues, the 
ref counting across reloads was messed up since the ref count is tracker on the 
SolrCore.)

> SolrCoreState reg counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracked on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4463) SolrCoreState reg counting is off for SolrCore reloads.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4463:
--

Attachment: SOLR-4463.patch

> SolrCoreState reg counting is off for SolrCore reloads.
> ---
>
> Key: SOLR-4463
> URL: https://issues.apache.org/jira/browse/SOLR-4463
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4463.patch
>
>
> Seems to work sometimes, perhaps because of races, but when we moved this ref 
> counting to the SolrCore to work around some other issues, the ref counting 
> across reloads was messed up since the ref count is tracker on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4463) SolrCoreState reg counting is off for SolrCore reloads.

[Mark Miller (JIRA)]

Mark Miller created SOLR-4463:
-

 Summary: SolrCoreState reg counting is off for SolrCore reloads.
 Key: SOLR-4463
 URL: https://issues.apache.org/jira/browse/SOLR-4463
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.2, 5.0


Seems to work sometimes, perhaps because of races, but when we moved this ref 
counting to the SolrCore to work around some other issues, the ref counting 
across reloads was messed up since the ref count is tracker on the SolrCore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #247: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/247/

No tests ran.

Build Log:
[...truncated 10976 lines...]



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

[jira] [Created] (SOLR-4462) SolrJ's httpclient and httpcore dependency versions should not be synchronized - instead, the httpcore version to use should be drawn from the httpclient POM

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-4462:


 Summary: SolrJ's httpclient and httpcore dependency versions 
should not be synchronized - instead, the httpcore version to use should be 
drawn from the httpclient POM
 Key: SOLR-4462
 URL: https://issues.apache.org/jira/browse/SOLR-4462
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.1, 4.0
Reporter: Steve Rowe
Priority: Minor


The httpcomponents project, which hosts both the httpclient and the httpcore 
modules, uses Maven as its build system, so when the httpclient POM declares a 
dependency, it's authoritative (since that's how httpclient is built and 
tested).  httpclient depends on httpcore, so the SolrJ httpcore version should 
be drawn from the httpclient POM.

httpclient's httpcore dependency version doesn't always match the httpclient 
version.  Recent examples (look for {{}} under 
{{}}):

[https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.3/pom.xml]
[http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml]
[http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml]

I'm fairly certain that these versions-out-of-sync incidents are not mistakes - 
I read this email exchange as describing intentionally versioning httpclient 
separately from httpcore: [http://markmail.org/thread/ippp4gbxwwnt6aws].

SolrJ should separately version its httpclient and httpcore dependencies, and 
should draw the httpcore version from the httpclient POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #770: POMs out of sync

[Robert Muir]

On Fri, Feb 15, 2013 at 10:22 AM, Steve Rowe  wrote:
> I read this email exchange as describing intentionally versioning httpclient 
> separately from httpcore: .
>
> I can see that the previous three releases of httpclient (4.2.2, 4.2.1 and 
> 4.2) depend on the exact same httpcore version, rather than lagging. [1][2][3]
>
> Going back, though, I can see more deviations from version sync: httpclient 
> 4.1.3 depends on httpcore 4.1.4 (!), and httpclient 4.1.1 depends on httpcore 
> 4.1. [4][5]
>
> So, again, I think the Lucene/Solr Ant build needs to change here to mirror 
> the httpcomponents project's separate httpclient and httpcore versioning.
>

+1: whatever is their "release", we should match it (and not use a frankenstein)

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #770: POMs out of sync

[Steve Rowe]

I read this email exchange as describing intentionally versioning httpclient 
separately from httpcore: .

I can see that the previous three releases of httpclient (4.2.2, 4.2.1 and 4.2) 
depend on the exact same httpcore version, rather than lagging. [1][2][3]

Going back, though, I can see more deviations from version sync: httpclient 
4.1.3 depends on httpcore 4.1.4 (!), and httpclient 4.1.1 depends on httpcore 
4.1. [4][5]

So, again, I think the Lucene/Solr Ant build needs to change here to mirror the 
httpcomponents project's separate httpclient and httpcore versioning.

I'll open a JIRA issue.

Steve

[1] http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.2/pom.xml
[2] http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2.1/pom.xml
[3] http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.2/pom.xml
[4] http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.3/pom.xml
[5] http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1.1/pom.xml

On Feb 15, 2013, at 9:26 AM, Steve Rowe  wrote:

> I'm looking into it.  
> 
> Httpclient uses Maven as its build system, so when the httpclient POM 
> declares a dependency, it's authoritative (since that's how it's built).  
> 
> The 4.2.3 release of httpclient depends on the 4.2.2 release of httpcore.  
> Looks to me like in this case the Solr Ant build should change to use the 
> 4.2.2 release of httpcore, rather than the Maven build changing.
> 
> I see that the current trunk version of httpclient (4.3-alpha2-SNAPSHOT) 
> depends on the previous version of httpcore (4.3-alpha1): 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/pom.xml - 
> look for the  under properties.  So this version lag looks 
> like it may be process driven, rather than a mistake.
> 
> Steve
> 
> On Feb 15, 2013, at 9:11 AM, Robert Muir  wrote:
> 
>> the poms are really out of sync. ant build depends on httpcore 4.2.3
>> but maven on 4.2.2
>> 
>> On Thu, Feb 14, 2013 at 11:34 PM, Apache Jenkins Server
>>  wrote:
>>> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/770/
>>> 
>>> No tests ran.
>>> 
>>> Build Log:
>>> [...truncated 11059 lines...]
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 


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

[jira] [Commented] (SOLR-4165) Queries blocked when stopping a node

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-4165:
-

Correctt. Start up was up to 30 seconds and on shutdown not more than a few 
seconds. Shutdown still stops the world for about two seconds, not a lot more 
but you'll clearly notice it when a stream of HTTP requests suddenly freezes.

> Queries blocked when stopping a node
> 
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.
> UPDATE:
> Since SOLR-3655 queries are no longer blocked when starting a node, only for 
> a few seconds when a stopping node using Solr 5.0.0.2013.02.15.13.26.04

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #770: POMs out of sync

[Steve Rowe]

I'm looking into it.  

Httpclient uses Maven as its build system, so when the httpclient POM declares 
a dependency, it's authoritative (since that's how it's built).  

The 4.2.3 release of httpclient depends on the 4.2.2 release of httpcore.  
Looks to me like in this case the Solr Ant build should change to use the 4.2.2 
release of httpcore, rather than the Maven build changing.

I see that the current trunk version of httpclient (4.3-alpha2-SNAPSHOT) 
depends on the previous version of httpcore (4.3-alpha1): 
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/pom.xml - look 
for the  under properties.  So this version lag looks like it 
may be process driven, rather than a mistake.

Steve

On Feb 15, 2013, at 9:11 AM, Robert Muir  wrote:

> the poms are really out of sync. ant build depends on httpcore 4.2.3
> but maven on 4.2.2
> 
> On Thu, Feb 14, 2013 at 11:34 PM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/770/
>> 
>> No tests ran.
>> 
>> Build Log:
>> [...truncated 11059 lines...]
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Comment Edited] (SOLR-4165) Queries blocked when stopping a node

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-4165 at 2/15/13 2:25 PM:


These can't be blocked for long right? We are publishing down before shutting 
down - my guess is that doing what we do on startup - waiting to see the 
published state show up in our clusterstate, will deal with this, but must be a 
pretty short time difference even now. I suppose I could have said the same 
thing about startup though.

  was (Author: markrmil...@gmail.com):
These can't be blocked for wrong right? We are publishing down before 
shutting down - my guess is that doing what we do on startup - waiting to see 
the published state show up in our clusterstate, will deal with this, but must 
be a pretty short time difference even now. I suppose I could have said the 
same thing about startup though.
  
> Queries blocked when stopping a node
> 
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.
> UPDATE:
> Since SOLR-3655 queries are no longer blocked when starting a node, only for 
> a few seconds when a stopping node using Solr 5.0.0.2013.02.15.13.26.04

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4165) Queries blocked when stopping a node

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4165:
---

These can't be blocked for wrong right? We are publishing down before shutting 
down - my guess is that doing what we do on startup - waiting to see the 
published state show up in our clusterstate, will deal with this, but must be a 
pretty short time difference even now. I suppose I could have said the same 
thing about startup though.

> Queries blocked when stopping a node
> 
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.
> UPDATE:
> Since SOLR-3655 queries are no longer blocked when starting a node, only for 
> a few seconds when a stopping node using Solr 5.0.0.2013.02.15.13.26.04

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4461) gui issue

[ewe (JIRA)]

ewe created SOLR-4461:
-

 Summary: gui issue
 Key: SOLR-4461
 URL: https://issues.apache.org/jira/browse/SOLR-4461
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Debian Squeeze
Reporter: ewe
Priority: Minor


In the web gui, under "core Admin", you can create a new core. When i press " 
+add core" and i want to create the default "new_core" I will get next message:


   Error CREATEing SolrCore 'new_core': Unable to create core: new_core


When i reload the screen an error pops up:

   SolrCore Initialization Failures new_core: 
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
Could not load config for solrconfig.xml


and the logging provides me with the following:


org.apache.solr.common.SolrException: Could not load config for solrconfig.xml
at 
org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:973)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1033)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleCreateAction(CoreAdminHandler.java:521)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:143)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at 
org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:365)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Can't find resource 'solrconfig.xml' in 
classpath or 'solr/new_core/conf/', cwd=/var/lib/tomcat6
at 
org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:316)
at 
org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:281)
at org.apache.solr.core.Config.(Config.java:103)
at org.apache.solr.core.Config.(Config.java:73)
at org.apache.solr.core.SolrConfig.(SolrConfig.java:117)
at 
org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:971)
... 18 more




Any ideas?



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #770: POMs out of sync

[Robert Muir]

the poms are really out of sync. ant build depends on httpcore 4.2.3
but maven on 4.2.2

On Thu, Feb 14, 2013 at 11:34 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/770/
>
> No tests ran.
>
> Build Log:
> [...truncated 11059 lines...]
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

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

[jira] [Updated] (SOLR-4165) Queries blocked when stopping a node

[Markus Jelsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Jelsma updated SOLR-4165:


Description: 
Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries briefly 
when a node is stopped gracefully and again blocks queries for at least a few 
seconds when the node is started again.

We're using siege to send roughly 10 queries per second to a pair a load 
balancers. Those load balancers ping (admin/ping) each node every few hundres 
milliseconds. The ping queries continue to operate normally while the requests 
to our main request handler is blocked. A manual request directly to a live 
Solr node is also blocked for the same duration.

There are no errors logged. But it is clear that the the entire cluster blocks 
queries as soon as the starting node is reading its config from Zookeeper, 
likely even slightly earlier.

The blocking time when stopping a node varies between 1 or 5 seconds. The 
blocking time when starting a node varies between 10 up to 30 seconds. The 
blocked queries come rushing in again after a queue of ping requests are 
served. The ping request sets the main request handler via the qt parameter.



UPDATE:
Since SOLR-3655 queries are no longer blocked when starting a node, only for a 
few seconds when a stopping node using Solr 5.0.0.2013.02.15.13.26.04


  was:
Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries briefly 
when a node is stopped gracefully and again blocks queries for at least a few 
seconds when the node is started again.

We're using siege to send roughly 10 queries per second to a pair a load 
balancers. Those load balancers ping (admin/ping) each node every few hundres 
milliseconds. The ping queries continue to operate normally while the requests 
to our main request handler is blocked. A manual request directly to a live 
Solr node is also blocked for the same duration.

There are no errors logged. But it is clear that the the entire cluster blocks 
queries as soon as the starting node is reading its config from Zookeeper, 
likely even slightly earlier.

The blocking time when stopping a node varies between 1 or 5 seconds. The 
blocking time when starting a node varies between 10 up to 30 seconds. The 
blocked queries come rushing in again after a queue of ping requests are 
served. The ping request sets the main request handler via the qt parameter.



Summary: Queries blocked when stopping a node  (was: Queries blocked 
when stopping and starting a node)

> Queries blocked when stopping a node
> 
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.
> UPDATE:
> Since SOLR-3655 queries are no longer blocked when starting a node, only for 
> a few seconds when a stopping node using Solr 5.0.0.2013.02.15.13.26.04

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Reopened] (SOLR-4165) Queries blocked when stopping and starting a node

[Markus Jelsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Jelsma reopened SOLR-4165:
-


> Queries blocked when stopping and starting a node
> -
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4165) Queries blocked when stopping and starting a node

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4165:
---

i guess reopen and rename this is the best move

> Queries blocked when stopping and starting a node
> -
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 180 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/180/

2 tests failed.
REGRESSION:  org.apache.lucene.search.TestSearcherManager.testSearcherManager

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([F2018D8395CAAB09]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.search.TestSearcherManager

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([F2018D8395CAAB09]:0)




Build Log:
[...truncated 1212 lines...]
[junit4:junit4] Suite: org.apache.lucene.search.TestSearcherManager
[junit4:junit4]   2> 15/02/2013 02:32:08 ? 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
[junit4:junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.search.TestSearcherManager
[junit4:junit4]   2>  jstack at approximately timeout time 
[junit4:junit4]   2> "Thread-656" ID=792 BLOCKED on 
org.apache.lucene.index.SerialMergeScheduler@2bbec682 owned by "Thread-655" 
ID=791
[junit4:junit4]   2>at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:37)
[junit4:junit4]   2>- blocked on 
org.apache.lucene.index.SerialMergeScheduler@2bbec682
[junit4:junit4]   2>at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1845)
[junit4:junit4]   2>at 
org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:388)
[junit4:junit4]   2>at 
org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:270)
[junit4:junit4]   2>at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:245)
[junit4:junit4]   2>at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:235)
[junit4:junit4]   2>at 
org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:169)
[junit4:junit4]   2>at 
org.apache.lucene.search.SearcherManager.refreshIfNeeded(SearcherManager.java:118)
[junit4:junit4]   2>at 
org.apache.lucene.search.SearcherManager.refreshIfNeeded(SearcherManager.java:58)
[junit4:junit4]   2>at 
org.apache.lucene.search.ReferenceManager.doMaybeRefresh(ReferenceManager.java:155)
[junit4:junit4]   2>at 
org.apache.lucene.search.ReferenceManager.maybeRefresh(ReferenceManager.java:204)
[junit4:junit4]   2>at 
org.apache.lucene.search.TestSearcherManager.getCurrentSearcher(TestSearcherManager.java:144)
[junit4:junit4]   2>at 
org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase$2.run(ThreadedIndexingAndSearchingTestCase.java:332)
[junit4:junit4]   2>Locked synchronizers:
[junit4:junit4]   2>- 
java.util.concurrent.locks.ReentrantLock$NonfairSync@34c42ad1
[junit4:junit4]   2> 
[junit4:junit4]   2> "Thread-655" ID=791 RUNNABLE
[junit4:junit4]   2>at java.lang.StrictMath.ceil(Native Method)
[junit4:junit4]   2>at java.lang.Math.ceil(Math.java:405)
[junit4:junit4]   2>at 
org.apache.lucene.util.packed.PackedInts$Format$1.byteCount(PackedInts.java:95)
[junit4:junit4]   2>at 
org.apache.lucene.util.packed.Packed64.(Packed64.java:90)
[junit4:junit4]   2>at 
org.apache.lucene.util.packed.PackedInts.getReaderNoHeader(PackedInts.java:845)
[junit4:junit4]   2>at 
org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get(CompressingTermVectorsReader.java:271)
[junit4:junit4]   2>at 
org.apache.lucene.index.SegmentReader.getTermVectors(SegmentReader.java:175)
[junit4:junit4]   2>at 
org.apache.lucene.index.IndexReader.getTermVector(IndexReader.java:295)
[junit4:junit4]   2>at 
org.apache.lucene.index.ParallelAtomicReader.getTermVectors(ParallelAtomicReader.java:236)
[junit4:junit4]   2>at 
org.apache.lucene.index.BaseCompositeReader.getTermVectors(BaseCompositeReader.java:97)
[junit4:junit4]   2>at 
org.apache.lucene.index.SlowCompositeReaderWrapper.getTermVectors(SlowCompositeReaderWrapper.java:147)
[junit4:junit4]   2>at 
org.apache.lucene.index.FilterAtomicReader.getTermVectors(FilterAtomicReader.java:344)
[junit4:junit4]   2>at 
org.apache.lucene.index.FieldFilterAtomicReader.getTermVectors(FieldFilterAtomicReader.java:61)
[junit4:junit4]   2>at 
org.apache.lucene.index.IndexReader.getTermVector(IndexReader.java:295)
[junit4:junit4]   2>at 
org.apache.lucene.index.ParallelAtomicReader.getTermVectors(ParallelAtomicReader.java:236)
[junit4:junit4]   2>at 
org.apache.lucene.index.FilterAtomicReader.getTermVectors(FilterAtomicReader.java:344)
[junit4:junit4]   2>at 
org.apache.lucene.index.FieldFilterAtomicReader.getTermVectors(FieldFilterAtomicReader.java:61)
[junit4:junit4]   2>at 
org.apache.lucene.index.IndexReader.getTermVector(IndexReader.java:295)
[junit4:junit4]   2>at 
org.apache.lucene.index.ParallelAtomicRe

[jira] [Commented] (SOLR-4165) Queries blocked when stopping and starting a node

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-4165:
-

Mark, i'm not sure this issue is entirely resolved. If i'm doing a stress test 
against a cluster and restart a node, the entire cluster still gets blocked. 
SOLR-3655 did improve things a lot, now the cluster only gets blocked when a 
node stops. When the node starts up again the stress test continues without 
being interrupted.

> Queries blocked when stopping and starting a node
> -
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.2, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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