[jira] [Comment Edited] (LUCENE-3865) MemoryIndex does not allow user to add multiple values for a single field name

[Ashwin Jayaprakash (JIRA)]

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

Ashwin Jayaprakash edited comment on LUCENE-3865 at 10/30/12 6:48 AM:
--

An option to delete fields would also be useful.

Does this mean that RAMDirectory is still alright to use for small data sets?

  was (Author: ashwin.jayaprakash):
An option to delete fields would also be useful.
  
> MemoryIndex does not allow user to add multiple values for a single field name
> --
>
> Key: LUCENE-3865
> URL: https://issues.apache.org/jira/browse/LUCENE-3865
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 3.5
> Environment: All
>Reporter: Dave Seltzer
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When using MemoryIndex.addField the following operation throws an 
> IllegalArgumentException:
> index.addField("foobar", "value1", LuceneAnalyzer); 
> index.addField("foobar", "value2", LuceneAnalyzer); 
> This throws:
> java.lang.IllegalArgumentException: field must not be added more than once
> According to Uwe Schindler on the java-user mailing list this violates the 
> IndexWriter/IndexReader contract.

--
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-3865) MemoryIndex does not allow user to add multiple values for a single field name

[Ashwin Jayaprakash (JIRA)]

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

Ashwin Jayaprakash commented on LUCENE-3865:


An option to delete fields would also be useful.

> MemoryIndex does not allow user to add multiple values for a single field name
> --
>
> Key: LUCENE-3865
> URL: https://issues.apache.org/jira/browse/LUCENE-3865
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 3.5
> Environment: All
>Reporter: Dave Seltzer
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When using MemoryIndex.addField the following operation throws an 
> IllegalArgumentException:
> index.addField("foobar", "value1", LuceneAnalyzer); 
> index.addField("foobar", "value2", LuceneAnalyzer); 
> This throws:
> java.lang.IllegalArgumentException: field must not be added more than once
> According to Uwe Schindler on the java-user mailing list this violates the 
> IndexWriter/IndexReader contract.

--
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 build is back to normal : fast-io-beasting #6321

[Charlie Cron]

See 


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

[jira] [Updated] (SOLR-4014) Add plugin module in the solr core for request handler(path)

[Raintung Li (JIRA)]

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

Raintung Li updated SOLR-4014:
--

Description: 
Solr can't add flexible some plugins in the handler that means have to rewrite 
the self handle if you want to append new functional. Ex. Validation module 

The plugin module can be setting in the solrconfig.xml, the default plugin can 
be request parameter that it is same as SolrPluginUtils.setDefaults behavior.

If customer want to add some new/common function, don't need write the self 
handler, only add a new plugin and configure it in the xml file.

Config XML format:
 

 

  was:
Solr can't add flexible some plugins in the handler that means have to rewrite 
the self handle if you want to append new functional. Ex. Validation module 

The plugin module can be setting in the solrconfig.xml, the default plugin can 
be request parameter that it is same as SolrPluginUtils.setDefaults behavior.

If customer want to add some new/common function, don't need write the self 
handler, only add a new plugin and configure it in the xml file.

Config XML format:
 

 


> Add plugin module in the solr core for request handler(path)
> 
>
> Key: SOLR-4014
> URL: https://issues.apache.org/jira/browse/SOLR-4014
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
> Environment: Solr core 
>Reporter: Raintung Li
>  Labels: handler, plugin, request
> Attachments: patch-SOLR-4014
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Solr can't add flexible some plugins in the handler that means have to 
> rewrite the self handle if you want to append new functional. Ex. Validation 
> module 
> The plugin module can be setting in the solrconfig.xml, the default plugin 
> can be request parameter that it is same as SolrPluginUtils.setDefaults 
> behavior.
> If customer want to add some new/common function, don't need write the self 
> handler, only add a new plugin and configure it in the xml file.
> Config XML format:
>  
>   
>  

--
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-4014) Add plugin module in the solr core for request handler(path)

[Raintung Li (JIRA)]

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

Raintung Li updated SOLR-4014:
--

Attachment: patch-SOLR-4014

The plugin module source code simple

> Add plugin module in the solr core for request handler(path)
> 
>
> Key: SOLR-4014
> URL: https://issues.apache.org/jira/browse/SOLR-4014
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
> Environment: Solr core 
>Reporter: Raintung Li
>  Labels: handler, plugin, request
> Attachments: patch-SOLR-4014
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Solr can't add flexible some plugins in the handler that means have to 
> rewrite the self handle if you want to append new functional. Ex. Validation 
> module 
> The plugin module can be setting in the solrconfig.xml, the default plugin 
> can be request parameter that it is same as SolrPluginUtils.setDefaults 
> behavior.
> If customer want to add some new/common function, don't need write the self 
> handler, only add a new plugin and configure it in the xml file.
> Config XML format:
>  
>   
>  

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

Build failed in Jenkins: fast-io-beasting #6320

[Charlie Cron]

See 

--
[...truncated 13938 lines...]
[junit4:junit4]   2> 436624 T44 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13ab04eb3e50003, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 436624 T10 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:56456 which had sessionid 0x13ab04eb3e50005
[junit4:junit4]   2> 436625 T68 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13ab04eb3e50005, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 436625 T10 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:55890 which had sessionid 0x13ab04eb3e50002
[junit4:junit4]   2> 436626 T30 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13ab04eb3e50002, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 436626 T10 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:56452 which had sessionid 0x13ab04eb3e50004
[junit4:junit4]   2> 436626 T56 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13ab04eb3e50004, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 436627 T10 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:56722 which had sessionid 0x13ab04eb3e50006
[junit4:junit4]   2> 436627 T81 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13ab04eb3e50006, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 436627 T12 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 436628 T10 oazs.FinalRequestProcessor.shutdown shutdown of 
request processor complete
[junit4:junit4]   2> 436629 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
55886
[junit4:junit4]   2> 436629 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=805562662
[junit4:junit4]   2> 436630 T10 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@11396ef7
[junit4:junit4]   2> 436638 T13 oazs.SessionTrackerImpl.run SessionTrackerImpl 
exited loop!
[junit4:junit4]   2> 436644 T10 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 436644 T10 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 436644 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 436645 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 436645 T10 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 436647 T32 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88576994759213058-127.0.0.1:55886_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 436724 T45 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@48423606 
name:ZooKeeperConnection Watcher:127.0.0.1:57176/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 436725 T45 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 436725 T69 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@561526e3 
name:ZooKeeperConnection Watcher:127.0.0.1:57176/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 436726 T69 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 436726 T31 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 436727 T57 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@5b25d568 
name:ZooKeeperConnection Watcher:127.0.0.1:57176/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 436727 T10 oaz.ZooKeeper.close Session: 0x13ab04eb3e50002 
closed
[junit4:junit4]   2> 436728 T82 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@2a8d1749 
name:ZooKeeperConnection Watcher:127.0.0.1:57176/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 436728 T82 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 436727 T57 oascc.Connection

[jira] [Created] (SOLR-4014) Add plugin module in the solr core for request handler(path)

[Raintung Li (JIRA)]

Raintung Li created SOLR-4014:
-

 Summary: Add plugin module in the solr core for request 
handler(path)
 Key: SOLR-4014
 URL: https://issues.apache.org/jira/browse/SOLR-4014
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA
 Environment: Solr core 
Reporter: Raintung Li


Solr can't add flexible some plugins in the handler that means have to rewrite 
the self handle if you want to append new functional. Ex. Validation module 

The plugin module can be setting in the solrconfig.xml, the default plugin can 
be request parameter that it is same as SolrPluginUtils.setDefaults behavior.

If customer want to add some new/common function, don't need write the self 
handler, only add a new plugin and configure it in the xml file.

Config XML format:
 

 

--
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-trunk-Linux (64bit/jdk1.7.0_07) - Build # 2088 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2088/
Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 19621 lines...]
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 0.59s.), 1 error(s).

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:223: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 27 minutes 54 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC
Email was triggered for: Failure
Sending email for trigger: Failure



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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_07) - Build # 1364 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/1364/
Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.TestSolrCoreProperties

Error Message:
2 threads leaked from SUITE scope at org.apache.solr.TestSolrCoreProperties:
 1) Thread[id=24, name=metrics-meter-tick-thread-1, state=WAITING, 
group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
at java.lang.Thread.run(Thread.java:722)2) Thread[id=25, 
name=metrics-meter-tick-thread-2, state=TIMED_WAITING, 
group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
at java.lang.Thread.run(Thread.java:722)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.TestSolrCoreProperties: 
   1) Thread[id=24, name=metrics-meter-tick-thread-1, state=WAITING, 
group=TGRP-TestSolrCoreProperties]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
   2) Thread[id=25, name=metrics-meter-tick-thread-2, state=TIMED_WAITING, 
group=TGRP-TestSolrCoreProperties]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
at __randomizedtesting.SeedInfo.seed([AA6DC17C64435491]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.TestSolrCoreProperties

Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=24, 
name=metrics-meter-tick-thread-1, state=WAITING, 
group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecuto

Jenkins build is back to normal : fast-io-beasting #6316

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6315

[Charlie Cron]

See 

--
[...truncated 21619 lines...]
[junit4:junit4]   2> 91750 T360 oasc.LeaderElector$1.process WARNING  
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /collections
[junit4:junit4]   2>at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:118)
[junit4:junit4]   2>at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
[junit4:junit4]   2>at 
org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:815)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.SolrZkClient$3.execute(SolrZkClient.java:176)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.SolrZkClient$3.execute(SolrZkClient.java:173)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:63)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:173)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:384)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:353)
[junit4:junit4]   2>at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:340)
[junit4:junit4]   2>at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:95)
[junit4:junit4]   2>at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:155)
[junit4:junit4]   2>at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:99)
[junit4:junit4]   2>at 
org.apache.solr.cloud.LeaderElector.access$000(LeaderElector.java:55)
[junit4:junit4]   2>at 
org.apache.solr.cloud.LeaderElector$1.process(LeaderElector.java:128)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:526)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
[junit4:junit4]   2> 
[junit4:junit4]   2> 91751 T360 oascc.ZkStateReader$3.process WARNING ZooKeeper 
watch triggered, but Solr cannot talk to ZK
[junit4:junit4]   2> 91751 T360 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 9 T436 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x13ab024256c0003 
type:create cxid:0xa zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = NodeExists for /solr/overseer
[junit4:junit4]   2> 92223 T436 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x13ab024256c0003 
type:create cxid:0xb zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer/queue Error:KeeperErrorCode = NoNode for 
/solr/overseer/queue
[junit4:junit4]   2> 92228 T447 oascc.ZkStateReader.updateClusterState Updating 
cloud state from ZooKeeper... 
[junit4:junit4]   2> 92228 T447 oasc.Overseer$ClusterStateUpdater.updateState 
Update state numShards=1 message={
[junit4:junit4]   2>  "operation":"state",
[junit4:junit4]   2>  "numShards":"1",
[junit4:junit4]   2>  "state":"recovering",
[junit4:junit4]   2>  "core":"core1",
[junit4:junit4]   2>  "collection":"collection1",
[junit4:junit4]   2>  "node_name":"node1",
[junit4:junit4]   2>  "base_url":"http://node1/solr/"}
[junit4:junit4]   2> 92228 T447 
oasc.Overseer$ClusterStateUpdater.createCollection Create collection 
collection1 with numShards 1
[junit4:junit4]   2> 92229 T436 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x13ab024256c0004 
type:create cxid:0x23 zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer/queue-work Error:KeeperErrorCode = NoNode for 
/solr/overseer/queue-work
[junit4:junit4]   2> 92235 T438 oascc.ZkStateReader$2.process A cluster state 
change has occurred - updating... (1)
[junit4:junit4]   2> 92235 T444 oascc.ZkStateReader$2.process A cluster state 
change has occurred - updating... (1)
[junit4:junit4]   2> 92727 T96 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/leader_elect/shard1/election
[junit4:junit4]   2> 92735 T436 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x13ab024256c0003 
type:delete cxid:0x1c zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/collections/collection1/leaders Error:KeeperErrorCode = NoNode for 
/solr/collections/collection1/leaders
[junit4:junit4]   2> 92737 T96 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/leaders/shard1
[junit4:junit4]   2> 92742 T436 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x13ab024256c0003 
type:create cxid:0x24 zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = Node

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_07) - Build # 2087 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2087/
Java: 32bit/jdk1.7.0_07 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 19625 lines...]
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 0.65s.), 1 error(s).

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:223: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 26 minutes 33 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 32bit/jdk1.7.0_07 -server -XX:+UseConcMarkSweepGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_07) - Build # 1363 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/1363/
Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 19582 lines...]
check-licenses:
 [echo] License check under: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr
 [licenses] MISSING sha1 checksum file for: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\lib\metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 0.93s.), 1 error(s).

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:67: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:223: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 46 minutes 34 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_07) - Build # 2086 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2086/
Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 19567 lines...]
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 0.63s.), 1 error(s).

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:223: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 25 minutes 47 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

Jenkins build is back to normal : fast-io-beasting #6306

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6305

[Charlie Cron]

See 

--
[...truncated 13274 lines...]
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1101)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221103 T142 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:58638
[junit4:junit4]   2> 7221102 T131 oaz.ClientCnxn$SendThread.startConnect 
WARNING Unexpected exception java.lang.InterruptedException: sleep interrupted
[junit4:junit4]   2>at java.lang.Thread.sleep(Native Method)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1045)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1101)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221102 T148 oaz.ClientCnxn$SendThread.startConnect 
WARNING Unexpected exception java.lang.InterruptedException: sleep interrupted
[junit4:junit4]   2>at java.lang.Thread.sleep(Native Method)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1045)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1101)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221104 T131 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:58638
[junit4:junit4]   2> 7221102 T139 oaz.ClientCnxn$SendThread.startConnect 
WARNING Unexpected exception java.lang.InterruptedException: sleep interrupted
[junit4:junit4]   2>at java.lang.Thread.sleep(Native Method)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1045)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1101)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221104 T148 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:58638
[junit4:junit4]   2> 7221105 T139 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:58638
[junit4:junit4]   2> 7221103 T136 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:58638
[junit4:junit4]   2> 7221102 T121 oaz.ZooKeeper.close Session: 
0x13aaf5cd3cf0004 closed
[junit4:junit4]   2> 7221106 T148 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaf5cd3cf0007 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221106 T121 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=904550161
[junit4:junit4]   2> 7221106 T131 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaf5cd3cf0002 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221106 T142 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaf5cd3cf0005 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 7221107 T121 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@4174b989
[junit4:junit4]   2> 7221106 T136 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaf5cd3cf0003 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 722 T121 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,del

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b58) - Build # 2085 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2085/
Java: 32bit/jdk1.8.0-ea-b58 -client -XX:+UseParallelGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestBinaryField

Error Message:
2 threads leaked from SUITE scope at org.apache.solr.schema.TestBinaryField:
 1) Thread[id=21, name=metrics-meter-tick-thread-1, state=TIMED_WAITING, 
group=TGRP-TestBinaryField] at sun.misc.Unsafe.park(Native Method)  
   at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1091)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:808)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1045)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
at java.lang.Thread.run(Thread.java:722)2) Thread[id=22, 
name=metrics-meter-tick-thread-2, state=WAITING, group=TGRP-TestBinaryField]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1086)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:808)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1045)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
at java.lang.Thread.run(Thread.java:722)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.schema.TestBinaryField: 
   1) Thread[id=21, name=metrics-meter-tick-thread-1, state=TIMED_WAITING, 
group=TGRP-TestBinaryField]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1091)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:808)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1045)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
   2) Thread[id=22, name=metrics-meter-tick-thread-2, state=WAITING, 
group=TGRP-TestBinaryField]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1086)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:808)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1045)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
at __randomizedtesting.SeedInfo.seed([22CE607FB4B0C94E]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestBinaryField

Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=22, 
name=metrics-meter-tick-thread-2, state=TIMED_WAITING, 
group=TGRP-TestBinaryField] at sun.misc.Unsafe.park(Native Method)  
   at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1091)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:808)
 

Jenkins build is back to normal : fast-io-beasting #6301

[Charlie Cron]

See 


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

Jenkins build is back to normal : slow-io-beasting #5099

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6300

[Charlie Cron]

See 

--
[...truncated 20202 lines...]
[junit4:junit4]   2> 91259 T432 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T420 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T430 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T436 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T414 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T426 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T418 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91259 T434 oascc.ZkStateReader$3.process Updating live 
nodes... (13)
[junit4:junit4]   2> 91261 T414 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 91261 T291 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:41146 which had sessionid 0x13aaf32d278003a
[junit4:junit4]   2> 91261 T161 oaz.ZooKeeper.close Session: 0x13aaf32d278003a 
closed
[junit4:junit4]   2> 91261 T294 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x13aaf32d278003e 
type:create cxid:0x5d zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = NodeExists for /solr/overseer
[junit4:junit4]   2> 91264 T294 oazs.PrepRequestProcessor.pRequest Processed 
session termination for sessionid: 0x13aaf32d278003b
[junit4:junit4]   2> 91264 T426 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91264 T436 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T440 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T420 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T428 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T432 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T438 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T418 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T430 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T434 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T416 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91265 T424 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91267 T416 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 91267 T422 oascc.ZkStateReader$3.process Updating live 
nodes... (12)
[junit4:junit4]   2> 91267 T291 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:41147 which had sessionid 0x13aaf32d278003b
[junit4:junit4]   2> 91267 T161 oaz.ZooKeeper.close Session: 0x13aaf32d278003b 
closed
[junit4:junit4]   2> 91269 T426 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T440 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T436 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T422 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T434 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T420 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T438 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T294 oazs.PrepRequestProcessor.pRequest Processed 
session termination for sessionid: 0x13aaf32d278003c
[junit4:junit4]   2> 91269 T430 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T428 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T424 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T432 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91269 T418 oascc.ZkStateReader$3.process Updating live 
nodes... (11)
[junit4:junit4]   2> 91270 T418 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 91270 T291 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:41148 which had sessionid 0x13aaf32d278003c
[junit4:junit4]   2> 91270 T161 oaz.ZooKeeper.close Session: 0x13aaf32d278003c 
closed
[junit4:junit4]   2> 91271 T438 oascc.ZkStateReader$3.process Updating live 
nodes... (10)
[junit4:junit4]   2> 91271 T434 oascc.ZkStateReader$3.process Updating live 
nodes... (10)
[junit4:junit4]   2> 91271 T430 oascc.ZkStateReader$3.process Updating live 
nodes... (10)
[junit4:junit4]   2> 91271 T294 oazs.PrepRe

[jira] [Commented] (SOLR-3980) Incorporate lazily-loaded cores into core listings for clients

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3980:
--

Duh, because it's late and I didn't think of it? But I think you're right, that 
would make more sense.

> Incorporate lazily-loaded cores into core listings for clients
> --
>
> Key: SOLR-3980
> URL: https://issues.apache.org/jira/browse/SOLR-3980
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore, web gui
>Affects Versions: 4.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.1
>
>
> Part of SOLR-1293 (supporting lots of cores) will require we do something to 
> allow clients (particularly the admin GUI) to get a full list of all possible 
> cores, whether they've been loaded or not.

--
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-trunk #659: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/659/

All tests passed

Build Log:
[...truncated 4065 lines...]
  [mvn] [INFO] Compiling 486 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/maven-build/solr/core/src/java/target/classes
  [mvn] [INFO] -
  [mvn] [ERROR] COMPILATION ERROR : 
  [mvn] [INFO] -

[...truncated 249 lines...]



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

Build failed in Jenkins: slow-io-beasting #5098

[Charlie Cron]

See 

--
[...truncated 13829 lines...]
[junit4:junit4]   2> 26848 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 26849 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 26849 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 26876 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 26914 T10 oass.SolrIndexSearcher. Opening 
Searcher@38fb59 main
[junit4:junit4]   2> 26915 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 26916 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 26917 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 26918 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 26918 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 26918 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 26919 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 26919 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 26919 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 26919 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 26920 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 26920 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 26920 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 26936 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 26937 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 26937 T119 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@38fb59 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 26937 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 26939 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@1a8739b
[junit4:junit4]   2> 26957 T116 C9 oasc.SolrDeletionPolicy.onInit 
SolrDeletionPolicy.onInit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@ccc621),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 26960 T116 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 26967 T116 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 15
[junit4:junit4]   2> 26971 T118 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 26987 T118 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@ccc621),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@ccc621),segFN=segments_2,generation=2,filenames=[_0.fnm,
 _0.frq, _0.tim, _0_nrm.cfe, segments_2, _0.fdx, _0_nrm.cfs, _0.si, _0.tip, 
_0.fdt]
[junit4:junit4]   2> 26988 T118 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 2700

Build failed in Jenkins: slow-io-beasting #5097

[Charlie Cron]

See 

--
[...truncated 13756 lines...]
[junit4:junit4]   2> 26950 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 26950 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 26950 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 26986 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 27011 T10 oass.SolrIndexSearcher. Opening 
Searcher@1a6eeab main
[junit4:junit4]   2> 27012 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 27012 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 27012 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 27013 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 27013 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 27013 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 27014 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 27014 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 27014 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 27014 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 27015 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 27015 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 27015 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 27036 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 27036 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 27036 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 27037 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> 27038 T113 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@1a6eeab 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@646bfb
[junit4:junit4]   2> 27066 T107 C9 oasc.SolrDeletionPolicy.onInit 
SolrDeletionPolicy.onInit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1f2a9da),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 27068 T107 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 27073 T107 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 19
[junit4:junit4]   2> 27075 T109 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 27093 T109 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1f2a9da),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1f2a9da),segFN=segments_2,generation=2,filenames=[_0.fnm,
 _0_SimpleText_0.pst, _0_nrm.cfe, segments_2, _0.fdx, _0_nrm.cfs, _0.si, _0.fdt]
[junit4:junit4]   2> 27094 T109 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 2713

[jira] [Created] (SOLR-4013) Creating a core should prevent more than one thread from creating a core of the same name at once.

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-4013:


 Summary: Creating a core should prevent more than one thread from 
creating a core of the same name at once.
 Key: SOLR-4013
 URL: https://issues.apache.org/jira/browse/SOLR-4013
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.1, 5.0


This hasn't been an issue so far since cores are created at startup. But in the 
lots of cores case (see SOLR-1293) the probability that more than one thread 
will attempt to create a core of the same name is vastly greater. We need to 
block other threads from creating a core if the core is already being created 
in a different thread.

Once the core is created, the blocked thread should pick up the newly-created 
core rather than create it again.

--
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-3980) Incorporate lazily-loaded cores into core listings for clients

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-3980:
--

Why should STATUS force a core load - in the world of lazily loaded cores? I 
would think that STATUS should be changed to indicate that a core might not be 
loaded.

> Incorporate lazily-loaded cores into core listings for clients
> --
>
> Key: SOLR-3980
> URL: https://issues.apache.org/jira/browse/SOLR-3980
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore, web gui
>Affects Versions: 4.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.1
>
>
> Part of SOLR-1293 (supporting lots of cores) will require we do something to 
> allow clients (particularly the admin GUI) to get a full list of all possible 
> cores, whether they've been loaded or not.

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

Build failed in Jenkins: slow-io-beasting #5096

[Charlie Cron]

See 

--
[...truncated 13859 lines...]
[junit4:junit4]   2> 29669 T18 oasc.CoreContainer$Initializer.initialize 
looking for solr.xml: 

[junit4:junit4]   2> 29669 T18 oasc.CoreContainer. New CoreContainer 
5282041
[junit4:junit4]   2> 29670 T18 oasc.CoreContainer$Initializer.initialize no 
solr.xml file found - using default
[junit4:junit4]   2> 29670 T18 oasc.CoreContainer.load Loading CoreContainer 
using Solr Home: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\'
[junit4:junit4]   2> 29671 T18 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\'
[junit4:junit4]   2> 29694 T18 oasc.CoreContainer.load Registering Log Listener
[junit4:junit4]   2> 29800 T18 oasc.CoreContainer.create Creating SolrCore 
'collection1' using instanceDir: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\collection1
[junit4:junit4]   2> 29803 T18 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\collection1\'
[junit4:junit4]   2> 29852 T18 oasc.SolrConfig. Using Lucene 
MatchVersion: LUCENE_41
[junit4:junit4]   2> 29936 T18 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
[junit4:junit4]   2> 29937 T18 oass.IndexSchema.readSchema Reading Solr Schema
[junit4:junit4]   2> 29941 T18 oass.IndexSchema.readSchema Schema name=test
[junit4:junit4]   2> 29979 T18 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 29980 T18 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\collection1\data\
[junit4:junit4]   2> 29981 T18 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 29983 T18 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\collection1\data\index/
[junit4:junit4]   2> 29985 T18 oasc.SolrCore.initIndex WARNING [collection1] 
Solr index directory 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351556083410\solr\collection12\collection1\data\index'
 doesn't exist. Creating new index...
[junit4:junit4]   2> 29985 T18 oasc.CachingDirectoryFactory.get return new 
directory for 

 forceNew:false
[junit4:junit4]   2> 29992 T18 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@e265f5),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 29992 T18 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 29993 T18 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 29994 T18 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 29994 T18 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 29994 T18 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 29994 T18 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 29995 T18 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 30005 T18 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 30017 T18 oass.SolrIndexSearcher. Opening 
Searcher@46a658 main
[junit4:junit4]   2> 30018 T18 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 30018 T18 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 30018 T18 oasu.CommitTracker. 

[jira] [Commented] (SOLR-3980) Incorporate lazily-loaded cores into core listings for clients

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3980:
--

In looking at this a bit more, the only way that currently exists to get a list 
of cores is to do a core admin STATUS command. Unfortunately, that loads all 
the cores and in the case where there are a large number of them, this will be 
unacceptable.

I propose a new core admin command LIST that will return a simple listing of 
the cores, just the name. The Admin UI will need to use this to display the 
actual list, then make a STATUS request when the user is drilling down

I suppose another solution would be an extra parameter for STATUS, 
namesOnly=true or some such, but I don't really like that, although I'd be 
willing to be persuaded otherwise.

> Incorporate lazily-loaded cores into core listings for clients
> --
>
> Key: SOLR-3980
> URL: https://issues.apache.org/jira/browse/SOLR-3980
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore, web gui
>Affects Versions: 4.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.1
>
>
> Part of SOLR-1293 (supporting lots of cores) will require we do something to 
> allow clients (particularly the admin GUI) to get a full list of all possible 
> cores, whether they've been loaded or not.

--
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] [Assigned] (SOLR-1905) Multicore admin/cores?action=CREATE

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-1905:


Assignee: Erick Erickson

> Multicore admin/cores?action=CREATE 
> 
>
> Key: SOLR-1905
> URL: https://issues.apache.org/jira/browse/SOLR-1905
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 1.4
> Environment: Solaris x86, jdk 1.6, tomcat 2.0.16
>Reporter: Robbin Turner
>Assignee: Erick Erickson
>
> Using the information off the CoreAdmin Wiki,  I initially set up Solr with 
> one core with solr.xml looking like the following:
> 
> 
>  instanceDir="/opt/solrcores"
> dataDir="/data1/core1"
> config="solrconfig.xml"
> 
> properties="conf/solrcore-core1.properties"
> schema="schema-core1.xml" />
> 
> 
> The application starts up fine and I can get to the 
> http:///solrcores.  I see the link for Admin core1 and 
> everything is running fine.  I then enter the URL:
> http:///solrcores/admin/cores?action=CREATE&name=core2&instanceDir=/opt/solrcores&config=solrconfig-core2.xml&schema=schema-core2.xml&dataDir=/data1/core2&properties=conf/solrcore-core2.properties
> to create my next core, core2.  The new core is registered and does show in 
> the base URL, http:///solrcores, which now list links for 
> Admin core1 and Admin core2.
> When I looked in the solr.xml, I see the following:
> 
> 
>  instanceDir="/opt/solrcores" schema="schema-core1.xml" 
> properties="conf/solrcore-core1.properties" dataDir="/data1/core1" />
>  instanceDir="/opt/solrcores" schema="schema-core2.xml" dataDir="/data1/core2" 
>  />
> 
> 
> Shouldn't all the parameters be added to the solr.xml core2 that were passed 
> in from the URL?  And why did the config="solrconfig.xml" get removed from 
> the core1 definition?

--
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-trunk-Linux (32bit/jdk1.7.0_07) - Build # 2082 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2082/
Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 19620 lines...]
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 0.64s.), 1 error(s).

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:223: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 28 minutes 8 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC
Email was triggered for: Failure
Sending email for trigger: Failure



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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_07) - Build # 1360 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/1360/
Java: 32bit/jdk1.7.0_07 -server -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 19586 lines...]
check-licenses:
 [echo] License check under: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr
 [licenses] MISSING sha1 checksum file for: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\lib\metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 1.30s.), 1 error(s).

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:67: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:223: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 47 minutes 18 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 32bit/jdk1.7.0_07 -server -XX:+UseSerialGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

Jenkins build is back to normal : slow-io-beasting #5092

[Charlie Cron]

See 


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

Re: svn commit: r1403555 - in /lucene/dev/trunk/solr: ./ core/ core/src/java/org/apache/solr/handler/ core/src/test/org/apache/solr/core/ test-framework/src/java/org/apache/solr/

[Robert Muir]

the new ivy jar will want .sha1's and licenses files. (builds will fail)

you can generate the .sha1s with ant jar-checksums. but the
license/notice you have to put in licenses/ manually.

On Mon, Oct 29, 2012 at 6:13 PM,   wrote:
> Author: romseygeek
> Date: Mon Oct 29 22:13:03 2012
> New Revision: 1403555
>
> URL: http://svn.apache.org/viewvc?rev=1403555&view=rev
> Log:
> SOLR-1972: Add extra query stats to RequestHandler
>
> Modified:
> lucene/dev/trunk/solr/CHANGES.txt
> lucene/dev/trunk/solr/core/ivy.xml
> 
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java
> 
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/core/RequestHandlersTest.java
> 
> lucene/dev/trunk/solr/test-framework/src/java/org/apache/solr/SolrIgnoredThreadsFilter.java
>
> Modified: lucene/dev/trunk/solr/CHANGES.txt
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?rev=1403555&r1=1403554&r2=1403555&view=diff
> ==
> --- lucene/dev/trunk/solr/CHANGES.txt (original)
> +++ lucene/dev/trunk/solr/CHANGES.txt Mon Oct 29 22:13:03 2012
> @@ -55,6 +55,10 @@ New Features
>  * SOLR-3911: Make Directory and DirectoryFactory first class so that the 
> majority
>of Solr's features work with any custom implementations. (Mark Miller)
>
> +* SOLR-1972: Add extra statistics to RequestHandlers - 5 & 15-minute reqs/sec
> +  rolling averages; median, 75th, 95th, 99th, 99.9th percentile request times
> +  (Alan Woodward)
> +
>  Optimizations
>  --
>
>
> Modified: lucene/dev/trunk/solr/core/ivy.xml
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/ivy.xml?rev=1403555&r1=1403554&r2=1403555&view=diff
> ==
> --- lucene/dev/trunk/solr/core/ivy.xml (original)
> +++ lucene/dev/trunk/solr/core/ivy.xml Mon Oct 29 22:13:03 2012
> @@ -28,6 +28,7 @@
> transitive="false"/>
> transitive="false"/>
> transitive="false"/>
> +   transitive="false"/>
>
>  
>  
>
> Modified: 
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java?rev=1403555&r1=1403554&r2=1403555&view=diff
> ==
> --- 
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java
>  (original)
> +++ 
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java
>  Mon Oct 29 22:13:03 2012
> @@ -17,6 +17,11 @@
>
>  package org.apache.solr.handler;
>
> +import com.yammer.metrics.Metrics;
> +import com.yammer.metrics.core.Counter;
> +import com.yammer.metrics.core.Timer;
> +import com.yammer.metrics.core.TimerContext;
> +import com.yammer.metrics.stats.Snapshot;
>  import org.apache.lucene.queryparser.classic.ParseException;
>  import org.apache.solr.common.SolrException;
>  import org.apache.solr.common.params.SolrParams;
> @@ -30,26 +35,34 @@ import org.apache.solr.response.SolrQuer
>  import org.apache.solr.util.SolrPluginUtils;
>
>  import java.net.URL;
> +import java.util.concurrent.atomic.AtomicLong;
>
>  /**
>   *
>   */
>  public abstract class RequestHandlerBase implements SolrRequestHandler, 
> SolrInfoMBean {
>
> -  // statistics
> -  // TODO: should we bother synchronizing these, or is an off-by-one error
> -  // acceptable every million requests or so?
> -  volatile long numRequests;
> -  volatile long numErrors;
> -  volatile long numTimeouts;
>protected NamedList initArgs = null;
>protected SolrParams defaults;
>protected SolrParams appends;
>protected SolrParams invariants;
> -  volatile long totalTime = 0;
> -  long handlerStart = System.currentTimeMillis();
>protected boolean httpCaching = true;
>
> +  // Statistics
> +  private static final AtomicLong handlerNumber = new AtomicLong();
> +  private final Counter numRequests;
> +  private final Counter numErrors;
> +  private final Counter numTimeouts;
> +  private final Timer requestTimes;
> +  long handlerStart = System.currentTimeMillis();
> +
> +  public RequestHandlerBase() {
> +String scope = new String("metrics-scope-" + 
> handlerNumber.getAndIncrement());
> +numRequests = Metrics.newCounter(RequestHandlerBase.class, 
> "numRequests", scope);
> +numErrors = Metrics.newCounter(RequestHandlerBase.class, "numErrors", 
> scope);
> +numTimeouts = Metrics.newCounter(RequestHandlerBase.class, 
> "numTimeouts", scope);
> +requestTimes = Metrics.newTimer(RequestHandlerBase.class, 
> "requestTimes", scope);
> +  }
>
>/**
> * Initializes the {@link org.apache.solr.request.SolrRequestHandler} by 
> creating three {@link org.apache.solr.common.params.SolrParams} named.
> @@ -93,7 +106,7 @@ public abstract class RequestHandlerB

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_35) - Build # 2081 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2081/
Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 18935 lines...]
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/metrics-core-2.1.2.jar
 [licenses] Scanned 90 JAR file(s) for licenses (in 0.65s.), 1 error(s).

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:223: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 31 minutes 11 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

Build failed in Jenkins: slow-io-beasting #5091

[Charlie Cron]

See 

--
[...truncated 13433 lines...]
[junit4:junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
[junit4:junit4] Completed on J7 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.BadComponentTest
[junit4:junit4] Completed on J7 in 0.00s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.TestUpdate
[junit4:junit4] Completed on J7 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2
[junit4:junit4] Completed on J7 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.DefaultValueUpdateProcessorTest
[junit4:junit4] Completed on J7 in 0.03s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestLFUCache
[junit4:junit4] Completed on J7 in 0.03s, 5 tests, 5 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestQuerySenderListener
[junit4:junit4] Completed on J7 in 0.01s, 3 tests, 3 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.SolrIndexConfigTest
[junit4:junit4] Completed on J7 in 0.02s, 2 tests, 2 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
[junit4:junit4] Completed on J1 in 2.75s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery
[junit4:junit4] Completed on J7 in 0.01s, 3 tests, 3 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.NumericFieldsTest
[junit4:junit4] Completed on J7 in 0.00s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.TestNumberUtils
[junit4:junit4] Completed on J7 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.MultiTermTest
[junit4:junit4] Completed on J7 in 0.01s, 3 tests, 3 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.cloud.TestMultiCoreConfBootstrap
[junit4:junit4] Completed on J6 in 5.99s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestJmxMonitoredMap
[junit4:junit4] Completed on J7 in 0.01s, 2 tests, 2 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.EchoParamsTest
[junit4:junit4] Completed on J7 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.SpellPossibilityIteratorTest
[junit4:junit4] Completed on J7 in 0.01s, 3 tests, 3 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestStressLucene
[junit4:junit4] Completed on J6 in 0.60s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.IndexReaderFactoryTest
[junit4:junit4] Completed on J1 in 1.74s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestBM25SimilarityFactory
[junit4:junit4] Completed on J7 in 0.02s, 2 tests, 2 skipped
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest
[junit4:junit4] Completed on J3 in 4.48s, 26 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestPerFieldSimilarity
[junit4:junit4] Completed on J7 in 0.01s, 7 tests, 7 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestCodecSupport
[junit4:junit4] Completed on J7 in 0.01s, 3 tests, 3 skipped
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestDefaultSimilarityFactory
[junit4:junit4] Completed on J7 in 0.01s, 2 tests, 2 skipped
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestLMJelinekMercerSimilarityFactory
[junit4:junit4] Completed on J3 in 0.50s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.TimeZoneUtilsTest
[junit4:junit4] Completed on J7 in 0.01s, 5 tests, 5 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestFastLRUCache
[junit4:junit4] Completed on J3 in 0.06s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.DateMathParserTest
[junit4:junit4] Completed on J7 in 0.01s, 8 tests, 8 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest
[junit4:junit4] Completed on J6 in 1.42s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.TestPhraseSuggestions
[junit4:junit4] Completed on J1 in 1.35s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.FileUtilsTest
[junit4:junit4] Completed on J7 in 0.05s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestSolrXMLSerializer
[junit4:junit4] Completed on J1 in 0.11s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.DateFieldTest
[junit4:junit4] Completed on J7 in 0.04s, 8 tests, 8 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.TestSuggestSpellingConverter
[junit4:junit4] Completed o

Jenkins build is back to normal : fast-io-beasting #6284

[Charlie Cron]

See 


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

[jira] [Updated] (LUCENE-4509) Make CompressingStoredFieldsFormat the new default StoredFieldsFormat impl

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-4509:
-

Assignee: Adrien Grand

> Make CompressingStoredFieldsFormat the new default StoredFieldsFormat impl
> --
>
> Key: LUCENE-4509
> URL: https://issues.apache.org/jira/browse/LUCENE-4509
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: core/store
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
>
> What would you think of making CompressingStoredFieldsFormat the new default 
> StoredFieldsFormat?
> Stored fields compression has many benefits :
>  - it makes the I/O cache work for us,
>  - file-based index replication/backup becomes cheaper.
> Things to know:
>  - even with incompressible data, there is less than 0.5% overhead with LZ4,
>  - LZ4 compression requires ~ 16kB of memory and LZ4 HC compression requires 
> ~ 256kB,
>  - LZ4 uncompression has almost no memory overhead,
>  - on my low-end laptop, the LZ4 impl in Lucene uncompresses at ~ 300mB/s.
> I think we could use the same default parameters as in CompressingCodec :
>  - LZ4 compression,
>  - in-memory stored fields index that is very memory-efficient (less than 12 
> bytes per block of compressed docs) and uses binary search to locate 
> documents in the fields data file,
>  - 16 kB blocks (small enough so that there is no major slow down when the 
> whole index would fit into the I/O cache anyway, and large enough to provide 
> interesting compression ratios ; for example Robert got a 0.35 compression 
> ratio with the geonames.org database).
> Any concerns?

--
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-1972) Need additional query stats in admin interface - median, 95th and 99th percentile

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-1972:
-

Committed to trunk, r1403555.  I'll let it sit here for a bit before 
back-porting.

> Need additional query stats in admin interface - median, 95th and 99th 
> percentile
> -
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
>Reporter: Shawn Heisey
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.1
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, 
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, 
> SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch, 
> SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, 
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972-url_pattern.patch
>
>
> I would like to see more detailed query statistics from the admin GUI.  This 
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785 
> I'd like to see more data on the time per request - median, 95th percentile, 
> 99th percentile, and any other statistical function that makes sense to 
> include.  In my environment, the first bunch of queries after startup tend to 
> take several seconds each.  I find that the average value tends to be useless 
> until it has several thousand queries under its belt and the caches are 
> thoroughly warmed.  The statistical functions I have mentioned would quickly 
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query.  I don't know 
> if this is something Solr does already.  It would be nice to have a 
> configurable count of how many of the most recent data points are kept, to 
> control the amount of memory the feature uses.  The default value could be 
> something like 1024 or 4096.

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

Build failed in Jenkins: fast-io-beasting #6283

[Charlie Cron]

See 

--
[...truncated 13943 lines...]
[junit4:junit4]   2> 435847 T10 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@d44752d
[junit4:junit4]   2> 435859 T10 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 435859 T10 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 435860 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 435860 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 435861 T10 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 435865 T32 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88575088228958210-127.0.0.1:45414_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 435942 T82 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@68deeebd 
name:ZooKeeperConnection Watcher:127.0.0.1:42008/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435942 T82 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435942 T69 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@5a335053 
name:ZooKeeperConnection Watcher:127.0.0.1:42008/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435943 T69 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435944 T31 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 435943 T10 oaz.ZooKeeper.close Session: 0x13aae92cdd60002 
closed
[junit4:junit4]   2> 435944 T45 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@420253af 
name:ZooKeeperConnection Watcher:127.0.0.1:42008/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435945 T45 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435945 T57 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@2a06bbe7 
name:ZooKeeperConnection Watcher:127.0.0.1:42008/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435945 T57 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435966 T10 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 436012 T13 oazs.SessionTrackerImpl.run SessionTrackerImpl 
exited loop!
[junit4:junit4]   2> 436018 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
58989
[junit4:junit4]   2> 436018 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=93608538
[junit4:junit4]   2> 437350 T68 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:42008
[junit4:junit4]   2> 437351 T68 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aae92cdd60005 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 437364 T56 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:42008
[junit4:junit4]   2> 437365 T56 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aae92cdd60004 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 437813 T44 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:42008
[junit4:junit4]   2> 437839 T81 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:42008
[junit4:junit4]   2> 437839 T81 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aae92cdd60006 for server null, unexpect

Jenkins build is back to normal : fast-io-beasting #6279

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6278

[Charlie Cron]

See 

--
[...truncated 13589 lines...]
[junit4:junit4]   2> 250469 T389 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aae6417810006, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 250469 T318 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:51280 which had sessionid 0x13aae6417810003
[junit4:junit4]   2> 250470 T351 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aae6417810003, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 250470 T318 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:51275 which had sessionid 0x13aae6417810002
[junit4:junit4]   2> 250470 T337 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aae6417810002, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 250470 T318 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:51302 which had sessionid 0x13aae6417810005
[junit4:junit4]   2> 250470 T320 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 250470 T375 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aae6417810005, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 250471 T318 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 250471 T318 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
44163
[junit4:junit4]   2> 250471 T318 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=490205887
[junit4:junit4]   2> 250471 T318 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@7789bd81
[junit4:junit4]   2> 250474 T318 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 250474 T318 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 250475 T318 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 250475 T318 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 250476 T318 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 250478 T339 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88574887601438722-127.0.0.1:44163_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 250570 T364 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@54911265 
name:ZooKeeperConnection Watcher:127.0.0.1:50886/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 250570 T390 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@7498213f 
name:ZooKeeperConnection Watcher:127.0.0.1:50886/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 250570 T364 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 250570 T390 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 250570 T338 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@104a73cb 
name:ZooKeeperConnection Watcher:127.0.0.1:50886/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 250570 T352 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1c52dd05 
name:ZooKeeperConnection Watcher:127.0.0.1:50886/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 250570 T318 oaz.ZooKeeper.close Session: 0x13aae6417810002 
closed
[junit4:junit4]   2> 250570 T338 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 250571 T376 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@6ed36d63 
name:ZooKeeperConnection Watcher:127.0.0.1:50886/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 250571 T338 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 250571 T352 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 250571 T376 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 250594 T318 oe

[jira] [Updated] (SOLR-4009) As not caught SolrException, leading OverseerCollectionProcessor abort.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-4009:
--

Attachment: SOLR-4009.patch

> As not caught SolrException, leading OverseerCollectionProcessor abort.
> ---
>
> Key: SOLR-4009
> URL: https://issues.apache.org/jira/browse/SOLR-4009
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
> Environment: As not caught SolrException, leading 
> OverseerCollectionProcessor abort.
> When delete a collection that does not exist ，  it  thrown SolrException, but 
> did not capture,
> then OverseerCollectionProcessor  thread abort.
>Reporter: milesli
>Assignee: Mark Miller
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4009.patch
>
>


--
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-4009) As not caught SolrException, leading OverseerCollectionProcessor abort.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4009:
---

Thanks milesli!

> As not caught SolrException, leading OverseerCollectionProcessor abort.
> ---
>
> Key: SOLR-4009
> URL: https://issues.apache.org/jira/browse/SOLR-4009
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
> Environment: As not caught SolrException, leading 
> OverseerCollectionProcessor abort.
> When delete a collection that does not exist ，  it  thrown SolrException, but 
> did not capture,
> then OverseerCollectionProcessor  thread abort.
>Reporter: milesli
>Assignee: Mark Miller
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4009.patch
>
>


--
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 build is back to normal : slow-io-beasting #5084

[Charlie Cron]

See 


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

Re: [jira] [Commented] (SOLR-3816) Need a more granular nrt system that is close to a realtime system.

[Radim Kolar]

Dne 29.10.2012 17:31, Erick Erickson napsal(a):

Radim:

Do you mean branch 4x (as opposed to 4.0) or trunk (5.x)?

5.x, it can be merged to 4x if it proves to be useful

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

[jira] [Commented] (LUCENE-4512) Additional memory savings in CompressingStoredFieldsIndex.MEMORY_CHUNK

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4512:
-

I do think we should use n=(some power of 2 or whatever) chunks, because e.g. 
just testing with that geonames dataset i saw the
deltas grow quite large at points... this caused it to use 24 bits per value 
(still better than 29), but with a tiny bit of 
effort I think it could be significantly less.


> Additional memory savings in CompressingStoredFieldsIndex.MEMORY_CHUNK
> --
>
> Key: LUCENE-4512
> URL: https://issues.apache.org/jira/browse/LUCENE-4512
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
>
> Robert had a great idea to save memory with 
> {{CompressingStoredFieldsIndex.MEMORY_CHUNK}}: instead of storing the 
> absolute start pointers we could compute the mean number of bytes per chunk 
> of documents and only store the delta between the actual value and the 
> expected value (avgChunkBytes * chunkNumber).
> By applying this idea to every n(=1024?) chunks, we would even:
>  - make sure to never hit the worst case (delta ~= maxStartPointer)
>  - reduce memory usage at indexing time.

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

Build failed in Jenkins: slow-io-beasting #5083

[Charlie Cron]

See 

--
[...truncated 13858 lines...]
[junit4:junit4]   2> 25423 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 25424 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 25424 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 25424 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 25425 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 25425 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 25425 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 25425 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 25426 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 25426 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 25426 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 25426 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 25438 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 25439 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 25439 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 25439 T115 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@e265f5 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 25439 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@14c0275
[junit4:junit4]   2> 25452 T111 C9 oasc.SolrDeletionPolicy.onInit 
SolrDeletionPolicy.onInit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@166ce5f),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 25455 T111 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 25465 T111 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 18
[junit4:junit4]   2> 25471 T113 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 25487 T113 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@166ce5f),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@166ce5f),segFN=segments_2,generation=2,filenames=[_0.fnm,
 _0_Lucene41_0.doc, _0_nrm.cfe, segments_2, _0.fdx, _0_nrm.cfs, _0.si, 
_0_Lucene41_0.tim, _0.fdt, _0_Lucene41_0.tip]
[junit4:junit4]   2> 25487 T113 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 25500 T113 C9 oass.SolrIndexSearcher. Opening 
Searcher@3e0339 main
[junit4:junit4]   2> 25501 T113 C9 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 25501 T113 C9 oasu.DirectUpdateHandler2.commit 
end_commit_flush
[junit4:junit4]   2> 25501 T115 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@3e0339 
main{StandardDirectoryReader(segments_2:3 _0(4.1):C10)}
[junit4:junit4]   2> 25502 T113 C9 UPDATE [collection1] webapp=/solr 
path=/update 
params={waitSearcher=true&wt=javabin&commit=true&softCommit=false&version=2

Jenkins build is back to normal : fast-io-beasting #6271

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6270

[Charlie Cron]

See 

--
[...truncated 21483 lines...]
[junit4:junit4]   2>at 
org.apache.solr.cloud.LeaderElector.access$000(LeaderElector.java:55)
[junit4:junit4]   2>at 
org.apache.solr.cloud.LeaderElector$1.process(LeaderElector.java:128)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:526)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
[junit4:junit4]   2> 
[junit4:junit4]   2> 96289 T392 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 98347 T33 oas.SolrTestCaseJ4.deleteCore ###deleteCore
[junit4:junit4]   2> NOTE: test params are: codec=Lucene41: {}, 
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, locale=it, 
timezone=US/Pacific
[junit4:junit4]   2> NOTE: Linux 3.2.0-24-generic amd64/Sun Microsystems Inc. 
1.6.0_27 (64-bit)/cpus=8,threads=10,free=206855456,total=305004544
[junit4:junit4]   2> NOTE: All tests run in this JVM: 
[DocumentAnalysisRequestHandlerTest, TestCollationField, 
TestSolrDeletionPolicy2, ZkNodePropsTest, TestIBSimilarityFactory, 
StatelessScriptUpdateProcessorFactoryTest, TestCSVLoader, HighlighterTest, 
OverseerTest]
[junit4:junit4] Completed on J1 in 98.40s, 8 tests, 1 failure <<< FAILURES!
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTSTTest
[junit4:junit4] Completed on J7 in 1.62s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
[junit4:junit4] Completed on J5 in 1.94s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.internal.csv.CSVStrategyTest
[junit4:junit4] Completed on J1 in 0.01s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTest
[junit4:junit4] Completed on J4 in 1.58s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.UpdateParamsTest
[junit4:junit4] Completed on J1 in 1.16s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest
[junit4:junit4] Completed on J6 in 1.14s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestSearchPerf
[junit4:junit4] Completed on J7 in 0.33s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.analysis.TestLuceneMatchVersion
[junit4:junit4] Completed on J6 in 0.20s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.StandardRequestHandlerTest
[junit4:junit4] Completed on J1 in 0.90s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
[junit4:junit4] Completed on J5 in 1.49s, 18 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
[junit4:junit4] Completed on J4 in 1.35s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest
[junit4:junit4] Completed on J7 in 1.15s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.servlet.DirectSolrConnectionTest
[junit4:junit4] Completed on J1 in 0.72s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.TestSuggestSpellingConverter
[junit4:junit4] Completed on J1 in 0.11s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestPropInject
[junit4:junit4] Completed on J6 in 1.52s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
[junit4:junit4] Completed on J7 in 0.64s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest
[junit4:junit4] Completed on J5 in 0.98s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestXIncludeConfig
[junit4:junit4] Completed on J7 in 0.18s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.TestUpdate
[junit4:junit4] Completed on J4 in 1.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
[junit4:junit4] Completed on J6 in 0.56s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.DefaultValueUpdateProcessorTest
[junit4:junit4] Completed on J1 in 0.86s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestDocSet
[junit4:junit4] Completed on J5 in 0.56s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.SolrCmdDistributorTest
[junit4:junit4] Completed on J3 in 5.24s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestLFUCache
[junit4:junit4] Completed on J7 in 0.61s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.SolrIndexConfigTest
[junit4:junit4] Completed on J4 in 0.49s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.MultiTermTest
[junit4:junit4] Completed on J5 in 0.24s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.NumericFieldsTest
[junit4:junit4] Completed on J6 

[jira] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-1972:
-

Hi Lance, in this case, that's represented by the 95th percentile - lower 
numbers mean faster query times.

I'll commit this later this evening if no-one objects.

> Need additional query stats in admin interface - median, 95th and 99th 
> percentile
> -
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
>Reporter: Shawn Heisey
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.1
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, 
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, 
> SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch, 
> SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, 
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972-url_pattern.patch
>
>
> I would like to see more detailed query statistics from the admin GUI.  This 
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785 
> I'd like to see more data on the time per request - median, 95th percentile, 
> 99th percentile, and any other statistical function that makes sense to 
> include.  In my environment, the first bunch of queries after startup tend to 
> take several seconds each.  I find that the average value tends to be useless 
> until it has several thousand queries under its belt and the caches are 
> thoroughly warmed.  The statistical functions I have mentioned would quickly 
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query.  I don't know 
> if this is something Solr does already.  It would be nice to have a 
> configurable count of how many of the most recent data points are kept, to 
> control the amount of memory the feature uses.  The default value could be 
> something like 1024 or 4096.

--
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-1972) Need additional query stats in admin interface - median, 95th and 99th percentile

[Lance Norskog (JIRA)]

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

Lance Norskog commented on SOLR-1972:
-

The 5th percentile is really useful. There is always a maximum query time of 
30s just because of a garbage collection failure, and people look at that 
number and freak out. For query times, the 5th percentile shows what is 
repeatedly "too slow". 

> Need additional query stats in admin interface - median, 95th and 99th 
> percentile
> -
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
>Reporter: Shawn Heisey
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.1
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, 
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, 
> SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch, 
> SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, 
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972-url_pattern.patch
>
>
> I would like to see more detailed query statistics from the admin GUI.  This 
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785 
> I'd like to see more data on the time per request - median, 95th percentile, 
> 99th percentile, and any other statistical function that makes sense to 
> include.  In my environment, the first bunch of queries after startup tend to 
> take several seconds each.  I find that the average value tends to be useless 
> until it has several thousand queries under its belt and the caches are 
> thoroughly warmed.  The statistical functions I have mentioned would quickly 
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query.  I don't know 
> if this is something Solr does already.  It would be nice to have a 
> configurable count of how many of the most recent data points are kept, to 
> control the amount of memory the feature uses.  The default value could be 
> something like 1024 or 4096.

--
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 build is back to normal : fast-io-beasting #6265

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6264

[Charlie Cron]

See 

--
[...truncated 24425 lines...]
[junit4:junit4]   2> 111476 T20 oasc.SolrCore.close [collection2]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@6bedc67e
[junit4:junit4]   2> 111480 T20 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=2,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=1,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 111480 T20 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 111480 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 111481 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 111482 T20 oasc.SolrCore.closeSearcher [collection2] 
Closing main searcher on request.
[junit4:junit4]   2> 111483 T20 oasc.SolrCore.close [collection3]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@10daab16
[junit4:junit4]   2> 111488 T20 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=2,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=1,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 111489 T20 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 111489 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 111489 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 111491 T20 oasc.SolrCore.closeSearcher [collection3] 
Closing main searcher on request.
[junit4:junit4]   2> 111492 T20 oasc.SolrCore.close [awholynewcollection_0]  
CLOSING SolrCore org.apache.solr.core.SolrCore@26bdff5e
[junit4:junit4]   2> 111493 T20 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 111493 T20 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 111494 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 111494 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 111495 T20 oasc.SolrCore.closeSearcher 
[awholynewcollection_0] Closing main searcher on request.
[junit4:junit4]   2> 111496 T20 oasc.SolrCore.close [awholynewcollection_1]  
CLOSING SolrCore org.apache.solr.core.SolrCore@22d03aac
[junit4:junit4]   2> 111497 T20 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 111497 T20 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 111497 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 111498 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 111498 T20 oasc.SolrCore.closeSearcher 
[awholynewcollection_1] Closing main searcher on request.
[junit4:junit4]   2> 111499 T20 oasc.SolrCore.close [unloadcollection3]  
CLOSING SolrCore org.apache.solr.core.SolrCore@1bc0e7b8
[junit4:junit4]   2> 111507 T20 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=80,adds=80,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=80,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 111507 T20 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 111507 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 111508 T20 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 111510 T20 oasc.SolrCore.closeSearcher [unloadcollection3] 
Closing main searcher on request.
[junit4:junit4]   2> 112071 T107 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:35618
[junit4:junit4]   2> 112071 T107 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aade2ed090009 for server nu

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[Phani Vempaty (JIRA)]

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

Phani Vempaty commented on LUCENE-2899:
---

Would there be a patch for 4.0 as it is released.

> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java, opennlp_trunk.patch
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp

--
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 build is back to normal : slow-io-beasting #5077

[Charlie Cron]

See 


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

[jira] [Commented] (LUCENE-4513) Deleted nested docs are scored into parent doc.

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4513:


+1, nice catch!

> Deleted nested docs are scored into parent doc.
> ---
>
> Key: LUCENE-4513
> URL: https://issues.apache.org/jira/browse/LUCENE-4513
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-4513.patch
>
>
> If a nested doc is deleted is still scored into the parent doc, which I think 
> isn't right. 

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

Build failed in Jenkins: slow-io-beasting #5076

[Charlie Cron]

See 

--
[...truncated 13813 lines...]
[junit4:junit4]   2> 32069 T10 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
[junit4:junit4]   2> 32070 T10 oass.IndexSchema.readSchema Reading Solr Schema
[junit4:junit4]   2> 32076 T10 oass.IndexSchema.readSchema Schema name=test
[junit4:junit4]   2> 32112 T10 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 32115 T10 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351534249774\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351534249774\solr\collection12\collection1\data\
[junit4:junit4]   2> 32116 T10 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 32124 T10 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351534249774\solr\collection12\collection1\data\index/
[junit4:junit4]   2> 32126 T10 oasc.SolrCore.initIndex WARNING [collection1] 
Solr index directory 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351534249774\solr\collection12\collection1\data\index'
 doesn't exist. Creating new index...
[junit4:junit4]   2> 32127 T10 oasc.CachingDirectoryFactory.get return new 
directory for 

 forceNew:false
[junit4:junit4]   2> 32139 T10 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.NIOFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1cfad77),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 32139 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 32140 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 32140 T10 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 32141 T10 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 32141 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 32141 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 32142 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 32151 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 32177 T10 oass.SolrIndexSearcher. Opening 
Searcher@1ed2061 main
[junit4:junit4]   2> 32177 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 32178 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 32178 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 32178 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 32179 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 32179 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 32179 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 32180 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 32181 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 32181 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 32182 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 32182 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 32182 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 32195 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 32196 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 32196 T10 oass.SolrDispatchFilter.init 
user.dir=

[jira] [Updated] (LUCENE-4513) Deleted nested docs are scored into parent doc.

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen updated LUCENE-4513:
--

Attachment: LUCENE-4513.patch

Attached fix + test case. I'll commit soon.

> Deleted nested docs are scored into parent doc.
> ---
>
> Key: LUCENE-4513
> URL: https://issues.apache.org/jira/browse/LUCENE-4513
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-4513.patch
>
>
> If a nested doc is deleted is still scored into the parent doc, which I think 
> isn't right. 

--
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-4513) Deleted nested docs are scored into parent doc.

[Martijn van Groningen (JIRA)]

Martijn van Groningen created LUCENE-4513:
-

 Summary: Deleted nested docs are scored into parent doc.
 Key: LUCENE-4513
 URL: https://issues.apache.org/jira/browse/LUCENE-4513
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Martijn van Groningen
Priority: Minor


If a nested doc is deleted is still scored into the parent doc, which I think 
isn't right. 

--
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-4009) As not caught SolrException, leading OverseerCollectionProcessor abort.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-4009:
--

Fix Version/s: 5.0
   4.1

> As not caught SolrException, leading OverseerCollectionProcessor abort.
> ---
>
> Key: SOLR-4009
> URL: https://issues.apache.org/jira/browse/SOLR-4009
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
> Environment: As not caught SolrException, leading 
> OverseerCollectionProcessor abort.
> When delete a collection that does not exist ，  it  thrown SolrException, but 
> did not capture,
> then OverseerCollectionProcessor  thread abort.
>Reporter: milesli
>Assignee: Mark Miller
> Fix For: 4.1, 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] [Assigned] (SOLR-4009) As not caught SolrException, leading OverseerCollectionProcessor abort.

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-4009:
-

Assignee: Mark Miller

> As not caught SolrException, leading OverseerCollectionProcessor abort.
> ---
>
> Key: SOLR-4009
> URL: https://issues.apache.org/jira/browse/SOLR-4009
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
> Environment: As not caught SolrException, leading 
> OverseerCollectionProcessor abort.
> When delete a collection that does not exist ，  it  thrown SolrException, but 
> did not capture,
> then OverseerCollectionProcessor  thread abort.
>Reporter: milesli
>Assignee: Mark Miller
> Fix For: 4.1, 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

Re: Ant command for installing Lucene and Solr Maven dependencies locally?

[Tommaso Teofili]

try "ant run-maven-build -DskipTests=true", hope this helps,
Tommaso

2012/10/29 Jason Rutherglen 

> Any way to make it skip tests?
>
> On Mon, Oct 29, 2012 at 12:55 PM, Tommaso Teofili
>  wrote:
> > 'ant run-maven-build' should do the trick.
> > Tommaso
> >
> > 2012/10/29 Jason Rutherglen 
> >>
> >> I have used 'ant generate-maven-artifacts' to generate the Maven
> >> artifacts.  Is there a target to install them locally?
> >>
> >> -
> >> 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] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2878:


It's sort of disturbing that if you iterate over intervals for a PhraseQuery we 
pull two DocsAndPositionsEnums per term in the phrase ...

But then ... this would "typically" be used to find the locations to hilite, 
right?  Ie not for the "main" query?  Because if you wanted to do this for the 
main query you should really use one of the oal.search.intervals.* queries 
instead, and those pull only a single D&PEnum per Term I think?

> Allow Scorer to expose positions and payloads aka. nuke spans 
> --
>
> Key: LUCENE-2878
> URL: https://issues.apache.org/jira/browse/LUCENE-2878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: Positions Branch
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
> mentor
> Fix For: Positions Branch
>
> Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878_trunk.patch, 
> LUCENE-2878_trunk.patch, LUCENE-2878-vs-trunk.patch, PosHighlighter.patch, 
> PosHighlighter.patch
>
>
> Currently we have two somewhat separate types of queries, the one which can 
> make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
> doesn't really do scoring comparable to what other queries do and at the end 
> of the day they are duplicating lot of code all over lucene. Span*Queries are 
> also limited to other Span*Query instances such that you can not use a 
> TermQuery or a BooleanQuery with SpanNear or anthing like that. 
> Beside of the Span*Query limitation other queries lacking a quiet interesting 
> feature since they can not score based on term proximity since scores doesn't 
> expose any positional information. All those problems bugged me for a while 
> now so I stared working on that using the bulkpostings API. I would have done 
> that first cut on trunk but TermScorer is working on BlockReader that do not 
> expose positions while the one in this branch does. I started adding a new 
> Positions class which users can pull from a scorer, to prevent unnecessary 
> positions enums I added ScorerContext#needsPositions and eventually 
> Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
> currently only TermQuery / TermScorer implements this API and other simply 
> return null instead. 
> To show that the API really works and our BulkPostings work fine too with 
> positions I cut over TermSpanQuery to use a TermScorer under the hood and 
> nuked TermSpans entirely. A nice sideeffect of this was that the Position 
> BulkReading implementation got some exercise which now :) work all with 
> positions while Payloads for bulkreading are kind of experimental in the 
> patch and those only work with Standard codec. 
> So all spans now work on top of TermScorer ( I truly hate spans since today ) 
> including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
> to implement the other codecs yet since I want to get feedback on the API and 
> on this first cut before I go one with it. I will upload the corresponding 
> patch in a minute. 
> I also had to cut over SpanQuery.getSpans(IR) to 
> SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
> first but after that pain today I need a break first :).
> The patch passes all core tests 
> (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
> look into the MemoryIndex BulkPostings API yet)

--
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-3997) QueryElevationComponent using native File object to access file

[James Ji (JIRA)]

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

James Ji updated SOLR-3997:
---

Description: 
We are currently working on having Solr files read from HDFS. We have a class 
which extends Directory class to handle all file access. However, we found that 
QueryElevationComponent is not using Directory class but using the native File 
object. 

QueryElevationComponent.inform(){

File fC = new File(core.getResourceLoader().getConfigDir(), f);
File fD = new File(core.getDataDir(), f);
if (fC.exists() == fD.exists()) {
 throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
 "QueryElevationComponent missing config file: '" + f + "\n"
 + "either: " + fC.getAbsolutePath() + " or " + 
 fD.getAbsolutePath() + " must exist, but not both.");
  }
 if (fC.exists()) {
exists = true;
log.info("Loading QueryElevation from: "+fC.getAbsolutePath());
Config cfg = new Config(core.getResourceLoader(), f);
elevationCache.put(null, loadElevationMap(cfg));
 }

}

  was:
We are currently working on having Solr files read from HDFS. We extended some 
of the classes so as to avoid modifying the original Solr code and make it 
compatible with the future release. So here comes the question, I found in 
QueryElevationComponent, there is a piece of code checking whether elevate.xml 
exists at local file system. I am wondering if there is a way to by pass this?
QueryElevationComponent.inform(){

File fC = new File(core.getResourceLoader().getConfigDir(), f);
File fD = new File(core.getDataDir(), f);
if (fC.exists() == fD.exists()) {
 throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
 "QueryElevationComponent missing config file: '" + f + "\n"
 + "either: " + fC.getAbsolutePath() + " or " + 
 fD.getAbsolutePath() + " must exist, but not both.");
  }
 if (fC.exists()) {
exists = true;
log.info("Loading QueryElevation from: "+fC.getAbsolutePath());
Config cfg = new Config(core.getResourceLoader(), f);
elevationCache.put(null, loadElevationMap(cfg));
 }

}

 Issue Type: Bug  (was: Wish)
Summary: QueryElevationComponent using native File object to access 
file  (was: Have solr config and index files on HDFS.)

> QueryElevationComponent using native File object to access file
> ---
>
> Key: SOLR-3997
> URL: https://issues.apache.org/jira/browse/SOLR-3997
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 4.0
>Reporter: James Ji
>
> We are currently working on having Solr files read from HDFS. We have a class 
> which extends Directory class to handle all file access. However, we found 
> that QueryElevationComponent is not using Directory class but using the 
> native File object. 
> QueryElevationComponent.inform(){
> 
> File fC = new File(core.getResourceLoader().getConfigDir(), f);
> File fD = new File(core.getDataDir(), f);
> if (fC.exists() == fD.exists()) {
>  throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
>  "QueryElevationComponent missing config file: '" + f + "\n"
>  + "either: " + fC.getAbsolutePath() + " or " +   
>fD.getAbsolutePath() + " must exist, but not both.");
>   }
>  if (fC.exists()) {
> exists = true;
> log.info("Loading QueryElevation from: "+fC.getAbsolutePath());
> Config cfg = new Config(core.getResourceLoader(), f);
> elevationCache.put(null, loadElevationMap(cfg));
>  }
> 
> }

--
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 build is back to normal : fast-io-beasting #6256

[Charlie Cron]

See 


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

[jira] [Updated] (LUCENE-4511) TermsFilter might return wrong results if a field is not indexed or not present in the index

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-4511:


Attachment: LUCENE-4511.patch

new patch - moving the terms.iterator call into the block that checks if the 
field changed. I also remove copying the bytes which doesn't make sense here 
really. 

I don't think we should keep the fields around because then comparison always 
needs the previous and that makes the loop more complex. 

I also added a comment regarding the automaton idea.

this is ready to go IMO. 

> TermsFilter might return wrong results if a field is not indexed or not 
> present in the index
> 
>
> Key: LUCENE-4511
> URL: https://issues.apache.org/jira/browse/LUCENE-4511
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 4.0, 4.1, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4511.patch, LUCENE-4511.patch, LUCENE-4511.patch
>
>
> TermsFilter returns if a term returns null from AIR#terms(term) while it 
> should just continue. I will upload a test & fix shortly

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

Build failed in Jenkins: fast-io-beasting #6255

[Charlie Cron]

See 

--
[...truncated 14007 lines...]
[junit4:junit4]   2> 255325 T88 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:37444
[junit4:junit4]   2> 255325 T88 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8f0a0e0006 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 255833 T74 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:37444
[junit4:junit4]   2> 255834 T74 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8f0a0e0005 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 255834 T50 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:37444
[junit4:junit4]   2> 255850 T62 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:37444
[junit4:junit4]   2> 255851 T62 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8f0a0e0004 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 255935 T51 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 255935 T16 oaz.ZooKeeper.close Session: 0x13aad8f0a0e0003 
closed
[junit4:junit4]   2> 255958 T16 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 256010 T16 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
47940
[junit4:junit4]   2> 256011 T16 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1890657725
[junit4:junit4]   2> 256011 T16 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@3191394e
[junit4:junit4]   2> 256015 T16 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 256016 T16 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 256017 T16 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 256017 T16 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 256019 T16 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 256960 T88 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:37444
[junit4:junit4]   2> 256961 T88 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8f0a0e0006 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 256975 T62 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:37444
[junit4:junit4]   2> 257076 T63 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 257076 T16 oaz.ZooKeeper.close Session: 0x13aad8f0a0e0004 
closed
[junit4:junit4]   2> 257098 T16 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 257150 T16 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
59666
[junit4:junit4]   2> 257151 T16 oasc.CoreContainer.shutdown Shutting down 
CoreContainer ins

Build failed in Jenkins: fast-io-beasting #6254

[Charlie Cron]

See 

--
[...truncated 13954 lines...]
[junit4:junit4]   2> 435837 T10 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 435837 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 435838 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 435839 T10 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 435842 T32 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88573922203205634-127.0.0.1:48976_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 435914 T45 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@24c759f5 
name:ZooKeeperConnection Watcher:127.0.0.1:50501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435915 T45 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435915 T82 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@19a33662 
name:ZooKeeperConnection Watcher:127.0.0.1:50501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435915 T82 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435916 T57 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@6534ae32 
name:ZooKeeperConnection Watcher:127.0.0.1:50501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435916 T57 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435917 T31 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@47e9d9b1 
name:ZooKeeperConnection Watcher:127.0.0.1:50501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435917 T10 oaz.ZooKeeper.close Session: 0x13aad8351490002 
closed
[junit4:junit4]   2> 435918 T31 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435918 T69 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@4b61cd25 
name:ZooKeeperConnection Watcher:127.0.0.1:50501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 435918 T69 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 435919 T31 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 435940 T10 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 435994 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
44273
[junit4:junit4]   2> 435995 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1927866617
[junit4:junit4]   2> 436228 T13 oazs.SessionTrackerImpl.run SessionTrackerImpl 
exited loop!
[junit4:junit4]   2> 437215 T81 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:50501
[junit4:junit4]   2> 437216 T81 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8351490006 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 437594 T68 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:50501
[junit4:junit4]   2> 437595 T68 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8351490005 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 437896 T44 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:50501
[junit4:junit4]   2> 437912 T56 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:50501
[junit4:junit4]   2> 437913 T56 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad8351490004 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connec

[jira] [Commented] (LUCENE-4511) TermsFilter might return wrong results if a field is not indexed or not present in the index

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4511:


Wow, this looks good!  We could also make an outer array w/ one entry (holding 
field name & array of terms I guess) per field, instead of the array of 
booleans marking the transition.

Hmm, but, you are calling terms.iterator once per term in each field?  Can we 
call that only once per field instead?

At some point/density it may be worth union-ing the terms into an A and using 
Terms.intersect ... we've talked about doing that before ... but we should do 
that separately.

> TermsFilter might return wrong results if a field is not indexed or not 
> present in the index
> 
>
> Key: LUCENE-4511
> URL: https://issues.apache.org/jira/browse/LUCENE-4511
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 4.0, 4.1, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4511.patch, LUCENE-4511.patch
>
>
> TermsFilter returns if a term returns null from AIR#terms(term) while it 
> should just continue. I will upload a test & fix shortly

--
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 build is back to normal : slow-io-beasting #5073

[Charlie Cron]

See 


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

Build failed in Jenkins: slow-io-beasting #5072

[Charlie Cron]

See 

--
[...truncated 13864 lines...]
[junit4:junit4]   2> 26565 T18 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1ff8de3),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 26566 T18 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 26568 T18 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 26568 T18 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 26569 T18 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 26569 T18 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 26569 T18 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 26569 T18 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 26581 T18 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 26608 T18 oass.SolrIndexSearcher. Opening 
Searcher@c1df71 main
[junit4:junit4]   2> 26609 T18 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 26609 T18 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 26609 T18 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 26610 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 26610 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 26610 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 26610 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 26611 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 26611 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 26611 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 26612 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 26612 T18 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 26612 T18 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 26625 T18 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 26625 T18 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 26626 T18 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 26626 T125 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@c1df71 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 26626 T18 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@3e8ad1
[junit4:junit4]   2> 26642 T121 C9 oasc.SolrDeletionPolicy.onInit 
SolrDeletionPolicy.onInit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.MMapDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1ff8de3),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 26643 T121 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 26646 T121 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 10
[junit4:junit4]   2> 26652 T123 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 26661 T123 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=MockDirWra

[jira] [Updated] (LUCENE-3846) Fuzzy suggester

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-3846:
---

Attachment: LUCENE-3846.patch

New patch, w/ CHANGES entry, fixing a couple issues Robert spotted (thanks!).

> Fuzzy suggester
> ---
>
> Key: LUCENE-3846
> URL: https://issues.apache.org/jira/browse/LUCENE-3846
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1
>
> Attachments: LUCENE-3846_fuzzy_analyzing.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch, LUCENE-3846.patch
>
>
> Would be nice to have a suggester that can handle some fuzziness (like spell 
> correction) so that it's able to suggest completions that are "near" what you 
> typed.
> As a first go at this, I implemented 1T (ie up to 1 edit, including a 
> transposition), except the first letter must be correct.
> But there is a penalty, ie, the "corrected" suggestion needs to have a much 
> higher freq than the "exact match" suggestion before it can compete.
> Still tons of nocommits, and somehow we should merge this / make it work with 
> analyzing suggester too (LUCENE-3842).

--
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: Ant command for installing Lucene and Solr Maven dependencies locally?

[Jason Rutherglen]

Any way to make it skip tests?

On Mon, Oct 29, 2012 at 12:55 PM, Tommaso Teofili
 wrote:
> 'ant run-maven-build' should do the trick.
> Tommaso
>
> 2012/10/29 Jason Rutherglen 
>>
>> I have used 'ant generate-maven-artifacts' to generate the Maven
>> artifacts.  Is there a target to install them locally?
>>
>> -
>> 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: Ant command for installing Lucene and Solr Maven dependencies locally?

[Tommaso Teofili]

'ant run-maven-build' should do the trick.
Tommaso

2012/10/29 Jason Rutherglen 

> I have used 'ant generate-maven-artifacts' to generate the Maven
> artifacts.  Is there a target to install them locally?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [jira] [Commented] (SOLR-3816) Need a more granular nrt system that is close to a realtime system.

[Erick Erickson]

Radim:

Do you mean branch 4x (as opposed to 4.0) or trunk (5.x)?

On Mon, Oct 29, 2012 at 10:10 AM, Radim Kolar (JIRA)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/SOLR-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486034#comment-13486034
>  ]
>
> Radim Kolar commented on SOLR-3816:
> ---
>
> patch should be against solr trunk. Solr 4.0 branch is for bugfixes only.
>
>> Need a more granular nrt system that is close to a realtime system.
>> ---
>>
>> Key: SOLR-3816
>> URL: https://issues.apache.org/jira/browse/SOLR-3816
>> Project: Solr
>>  Issue Type: Improvement
>>  Components: clients - java, replication (java), search, 
>> SearchComponents - other, SolrCloud, update
>>Affects Versions: 4.0
>>Reporter: Nagendra Nagarajayya
>>  Labels: nrt, realtime, replication, search, solrcloud, update
>> Attachments: SOLR-3816_4.0_branch.patch, solr-3816-realtime_nrt.patch
>>
>>
>> Need a more granular NRT system that is close to a realtime system. A 
>> realtime system should be able to reflect changes to the index as and when 
>> docs are added/updated to the index. soft-commit offers NRT and is more 
>> realtime friendly than hard commit but is limited by the dependency on the 
>> SolrIndexSearcher being closed and reopened and offers a coarse granular 
>> NRT. Closing and reopening of the SolrIndexSearcher may impact performance 
>> also.
>
> --
> 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
>

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

[jira] [Commented] (SOLR-4005) If CoreContainer fails to register a created core, it should close it.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4005:
---

Simple change:

{noformat}lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (original)
+++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreContainer.java 
Mon Oct 29 16:10:39 2012
@@ -482,6 +482,7 @@ public class CoreContainer 

for (int i=0; i If CoreContainer fails to register a created core, it should close it.
> --
>
> Key: SOLR-4005
> URL: https://issues.apache.org/jira/browse/SOLR-4005
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 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] [Resolved] (SOLR-4005) If CoreContainer fails to register a created core, it should close it.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-4005.
---

Resolution: Fixed

> If CoreContainer fails to register a created core, it should close it.
> --
>
> Key: SOLR-4005
> URL: https://issues.apache.org/jira/browse/SOLR-4005
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 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-3846) Fuzzy suggester

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-3846:
-

I think we might want to beast the tests on this before merging!

> Fuzzy suggester
> ---
>
> Key: LUCENE-3846
> URL: https://issues.apache.org/jira/browse/LUCENE-3846
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1
>
> Attachments: LUCENE-3846_fuzzy_analyzing.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch
>
>
> Would be nice to have a suggester that can handle some fuzziness (like spell 
> correction) so that it's able to suggest completions that are "near" what you 
> typed.
> As a first go at this, I implemented 1T (ie up to 1 edit, including a 
> transposition), except the first letter must be correct.
> But there is a penalty, ie, the "corrected" suggestion needs to have a much 
> higher freq than the "exact match" suggestion before it can compete.
> Still tons of nocommits, and somehow we should merge this / make it work with 
> analyzing suggester too (LUCENE-3842).

--
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-4511) TermsFilter might return wrong results if a field is not indexed or not present in the index

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-4511:


Attachment: LUCENE-4511.patch

here is a new patch basically rewriting the TermsFilter. I switch to a Term 
array rather than a treemap and made the filter immutable. I really don't like 
if you can cache this filter somehow and its mutable. I also moved the most of 
the work (figuring out when to reset the terms enum and when a field changes to 
the ctor rather than doing it for each segment.  I also added some more tests

> TermsFilter might return wrong results if a field is not indexed or not 
> present in the index
> 
>
> Key: LUCENE-4511
> URL: https://issues.apache.org/jira/browse/LUCENE-4511
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 4.0, 4.1, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4511.patch, LUCENE-4511.patch
>
>
> TermsFilter returns if a term returns null from AIR#terms(term) while it 
> should just continue. I will upload a test & fix shortly

--
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-3846) Fuzzy suggester

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-3846:
-

cool man it looks good. we need a changes entry but from my side this looks 
good. we can tackle the todos on trunk

> Fuzzy suggester
> ---
>
> Key: LUCENE-3846
> URL: https://issues.apache.org/jira/browse/LUCENE-3846
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1
>
> Attachments: LUCENE-3846_fuzzy_analyzing.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch
>
>
> Would be nice to have a suggester that can handle some fuzziness (like spell 
> correction) so that it's able to suggest completions that are "near" what you 
> typed.
> As a first go at this, I implemented 1T (ie up to 1 edit, including a 
> transposition), except the first letter must be correct.
> But there is a penalty, ie, the "corrected" suggestion needs to have a much 
> higher freq than the "exact match" suggestion before it can compete.
> Still tons of nocommits, and somehow we should merge this / make it work with 
> analyzing suggester too (LUCENE-3842).

--
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 build is back to normal : fast-io-beasting #6245

[Charlie Cron]

See 


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

Build failed in Jenkins: fast-io-beasting #6244

[Charlie Cron]

See 

--
[...truncated 24285 lines...]
[junit4:junit4]   2> 117316 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 117316 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 117321 T12 oasc.SolrCore.closeSearcher 
[awholynewcollection_0] Closing main searcher on request.
[junit4:junit4]   2> 117321 T12 oasc.SolrCore.close [awholynewcollection_2]  
CLOSING SolrCore org.apache.solr.core.SolrCore@8fe6a6a
[junit4:junit4]   2> 117328 T12 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 117329 T12 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 117329 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 117329 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 117331 T12 oasc.SolrCore.closeSearcher 
[awholynewcollection_2] Closing main searcher on request.
[junit4:junit4]   2> 117331 T12 oasc.SolrCore.close [unloadcollection3]  
CLOSING SolrCore org.apache.solr.core.SolrCore@3137c799
[junit4:junit4]   2> 117353 T12 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=80,adds=80,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=80,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 117356 T12 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 117357 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 117357 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 117368 T12 oasc.SolrCore.closeSearcher [unloadcollection3] 
Closing main searcher on request.
[junit4:junit4]   2> 117603 T97 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:50196
[junit4:junit4]   2> 117604 T97 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aad2a33640009 for server null, unexpected error, closing socket connection 
and attempting reconnect java.net.ConnectException: Connection refused
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 118797 T70 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:50196
[junit4:junit4]   2> 118898 T71 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 118898 T12 oaz.ZooKeeper.close Session: 0x13aad2a33640005 
closed
[junit4:junit4]   2> 118921 T12 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 118973 T12 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
44820
[junit4:junit4]   2> 118974 T12 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=203141979
[junit4:junit4]   2> 118974 T12 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@37d3ac6e
[junit4:junit4]   2> 118994 T12 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=118,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=86,cumulative_deletesById=0,cumulative_deletesByQuery=1,cumulative_errors=0}
[junit4:junit4]   2> 118994 T12 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 118995 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 118995 T12 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 119001 T12 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 119002 T12 oasc.SolrCore.close [collection2]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@290e6c5e
[junit4:junit4]   2> 119013 T12 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=2,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=2,cumulative_deletesById=0,cumulative

[jira] [Updated] (LUCENE-3846) Fuzzy suggester

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-3846:
---

Attachment: LUCENE-3846.patch

I think this is ready!  I'm attaching the reviewable patch w/ diffs on the 
branch vs trunk ...

> Fuzzy suggester
> ---
>
> Key: LUCENE-3846
> URL: https://issues.apache.org/jira/browse/LUCENE-3846
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1
>
> Attachments: LUCENE-3846_fuzzy_analyzing.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, LUCENE-3846.patch, 
> LUCENE-3846.patch
>
>
> Would be nice to have a suggester that can handle some fuzziness (like spell 
> correction) so that it's able to suggest completions that are "near" what you 
> typed.
> As a first go at this, I implemented 1T (ie up to 1 edit, including a 
> transposition), except the first letter must be correct.
> But there is a penalty, ie, the "corrected" suggestion needs to have a much 
> higher freq than the "exact match" suggestion before it can compete.
> Still tons of nocommits, and somehow we should merge this / make it work with 
> analyzing suggester too (LUCENE-3842).

--
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-4012) LeaderIntegrationTest sometimes hangs

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4012:
---

It's waiting to see other replicas come up - which is odd, because it should be 
the first time the nodes are coming up in setup - seems like perhaps pollution 
between the two tests...I'm adding a timestamp to the zk dir so it's sure to be 
different for each test in this class.

> LeaderIntegrationTest sometimes hangs
> -
>
> Key: SOLR-4012
> URL: https://issues.apache.org/jira/browse/SOLR-4012
> Project: Solr
>  Issue Type: Test
>  Components: Tests
> Environment: windows
>Reporter: Robert Muir
>
> I was unable to get a stacktrace before. This time I succeeded.

--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-2878:
-

I don't like the general style of things like Collector.postingsFeatures()

>From the naming, you cant tell this is a "getter". In general I think methods 
>like this should be getPostingsFeatures() ?



> Allow Scorer to expose positions and payloads aka. nuke spans 
> --
>
> Key: LUCENE-2878
> URL: https://issues.apache.org/jira/browse/LUCENE-2878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: Positions Branch
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
> mentor
> Fix For: Positions Branch
>
> Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878_trunk.patch, 
> LUCENE-2878_trunk.patch, LUCENE-2878-vs-trunk.patch, PosHighlighter.patch, 
> PosHighlighter.patch
>
>
> Currently we have two somewhat separate types of queries, the one which can 
> make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
> doesn't really do scoring comparable to what other queries do and at the end 
> of the day they are duplicating lot of code all over lucene. Span*Queries are 
> also limited to other Span*Query instances such that you can not use a 
> TermQuery or a BooleanQuery with SpanNear or anthing like that. 
> Beside of the Span*Query limitation other queries lacking a quiet interesting 
> feature since they can not score based on term proximity since scores doesn't 
> expose any positional information. All those problems bugged me for a while 
> now so I stared working on that using the bulkpostings API. I would have done 
> that first cut on trunk but TermScorer is working on BlockReader that do not 
> expose positions while the one in this branch does. I started adding a new 
> Positions class which users can pull from a scorer, to prevent unnecessary 
> positions enums I added ScorerContext#needsPositions and eventually 
> Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
> currently only TermQuery / TermScorer implements this API and other simply 
> return null instead. 
> To show that the API really works and our BulkPostings work fine too with 
> positions I cut over TermSpanQuery to use a TermScorer under the hood and 
> nuked TermSpans entirely. A nice sideeffect of this was that the Position 
> BulkReading implementation got some exercise which now :) work all with 
> positions while Payloads for bulkreading are kind of experimental in the 
> patch and those only work with Standard codec. 
> So all spans now work on top of TermScorer ( I truly hate spans since today ) 
> including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
> to implement the other codecs yet since I want to get feedback on the API and 
> on this first cut before I go one with it. I will upload the corresponding 
> patch in a minute. 
> I also had to cut over SpanQuery.getSpans(IR) to 
> SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
> first but after that pain today I need a break first :).
> The patch passes all core tests 
> (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
> look into the MemoryIndex BulkPostings API yet)

--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-2878:
-

There seems to be a lot of unrelated formatting changes in important classes 
like TermWeight.java etc

Can we factor these out and do any formatting changes separately?

> Allow Scorer to expose positions and payloads aka. nuke spans 
> --
>
> Key: LUCENE-2878
> URL: https://issues.apache.org/jira/browse/LUCENE-2878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: Positions Branch
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
> mentor
> Fix For: Positions Branch
>
> Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878_trunk.patch, 
> LUCENE-2878_trunk.patch, LUCENE-2878-vs-trunk.patch, PosHighlighter.patch, 
> PosHighlighter.patch
>
>
> Currently we have two somewhat separate types of queries, the one which can 
> make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
> doesn't really do scoring comparable to what other queries do and at the end 
> of the day they are duplicating lot of code all over lucene. Span*Queries are 
> also limited to other Span*Query instances such that you can not use a 
> TermQuery or a BooleanQuery with SpanNear or anthing like that. 
> Beside of the Span*Query limitation other queries lacking a quiet interesting 
> feature since they can not score based on term proximity since scores doesn't 
> expose any positional information. All those problems bugged me for a while 
> now so I stared working on that using the bulkpostings API. I would have done 
> that first cut on trunk but TermScorer is working on BlockReader that do not 
> expose positions while the one in this branch does. I started adding a new 
> Positions class which users can pull from a scorer, to prevent unnecessary 
> positions enums I added ScorerContext#needsPositions and eventually 
> Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
> currently only TermQuery / TermScorer implements this API and other simply 
> return null instead. 
> To show that the API really works and our BulkPostings work fine too with 
> positions I cut over TermSpanQuery to use a TermScorer under the hood and 
> nuked TermSpans entirely. A nice sideeffect of this was that the Position 
> BulkReading implementation got some exercise which now :) work all with 
> positions while Payloads for bulkreading are kind of experimental in the 
> patch and those only work with Standard codec. 
> So all spans now work on top of TermScorer ( I truly hate spans since today ) 
> including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
> to implement the other codecs yet since I want to get feedback on the API and 
> on this first cut before I go one with it. I will upload the corresponding 
> patch in a minute. 
> I also had to cut over SpanQuery.getSpans(IR) to 
> SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
> first but after that pain today I need a break first :).
> The patch passes all core tests 
> (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
> look into the MemoryIndex BulkPostings API yet)

--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-2878:
-

{quote}
Instead of PostingFeatures.isProximityFeature, can we just use
X.compareTo(PostingsFeatures.POSITIONS) >= 0? (We do this for
IndexOptions).
{quote}

I think this is a confusing part of the current patch. For example:

{noformat}
// Check if we can return a BooleanScorer
-  if (!scoreDocsInOrder && topScorer && required.size() == 0) {
+  if (!scoreDocsInOrder && flags == PostingFeatures.DOCS_AND_FREQS && 
topScorer && required.size() == 0) {
{noformat}

I don't think we should be doing these == comparisons. What if someone sends 
DOCS_ONLY? (which really ConstantScoreQuery i think should pass down to its 
subs and so on, so they can skip freq blocks, but thats another thing to 
tackle).


> Allow Scorer to expose positions and payloads aka. nuke spans 
> --
>
> Key: LUCENE-2878
> URL: https://issues.apache.org/jira/browse/LUCENE-2878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: Positions Branch
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
> mentor
> Fix For: Positions Branch
>
> Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
> LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878_trunk.patch, 
> LUCENE-2878_trunk.patch, LUCENE-2878-vs-trunk.patch, PosHighlighter.patch, 
> PosHighlighter.patch
>
>
> Currently we have two somewhat separate types of queries, the one which can 
> make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
> doesn't really do scoring comparable to what other queries do and at the end 
> of the day they are duplicating lot of code all over lucene. Span*Queries are 
> also limited to other Span*Query instances such that you can not use a 
> TermQuery or a BooleanQuery with SpanNear or anthing like that. 
> Beside of the Span*Query limitation other queries lacking a quiet interesting 
> feature since they can not score based on term proximity since scores doesn't 
> expose any positional information. All those problems bugged me for a while 
> now so I stared working on that using the bulkpostings API. I would have done 
> that first cut on trunk but TermScorer is working on BlockReader that do not 
> expose positions while the one in this branch does. I started adding a new 
> Positions class which users can pull from a scorer, to prevent unnecessary 
> positions enums I added ScorerContext#needsPositions and eventually 
> Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
> currently only TermQuery / TermScorer implements this API and other simply 
> return null instead. 
> To show that the API really works and our BulkPostings work fine too with 
> positions I cut over TermSpanQuery to use a TermScorer under the hood and 
> nuked TermSpans entirely. A nice sideeffect of this was that the Position 
> BulkReading implementation got some exercise which now :) work all with 
> positions while Payloads for bulkreading are kind of experimental in the 
> patch and those only work with Standard codec. 
> So all spans now work on top of TermScorer ( I truly hate spans since today ) 
> including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
> to implement the other codecs yet since I want to get feedback on the API and 
> on this first cut before I go one with it. I will upload the corresponding 
> patch in a minute. 
> I also had to cut over SpanQuery.getSpans(IR) to 
> SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
> first but after that pain today I need a break first :).
> The patch passes all core tests 
> (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
> look into the MemoryIndex BulkPostings API yet)

--
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-3858) Doc-to-shard assignment based on "range" property on shards

[Dmitry Kan (JIRA)]

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

Dmitry Kan commented on SOLR-3858:
--

Is there an idea of how the range property should be defined? Something like 
this in solrconfig:


   FieldName 
   20121001 
   20121031


?

Does this property (if defined) turn the sharding scheme into logical sharding?


> Doc-to-shard assignment based on "range" property on shards
> ---
>
> Key: SOLR-3858
> URL: https://issues.apache.org/jira/browse/SOLR-3858
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Yonik Seeley
>
> Anything that maps a document id to a shard should consult the ranges defined 
> on the shards (currently indexing and real-time get).

--
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-4512) Additional memory savings in CompressingStoredFieldsIndex.MEMORY_CHUNK

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-4512:
-

Description: 
Robert had a great idea to save memory with 
{{CompressingStoredFieldsIndex.MEMORY_CHUNK}}: instead of storing the absolute 
start pointers we could compute the mean number of bytes per chunk of documents 
and only store the delta between the actual value and the expected value 
(avgChunkBytes * chunkNumber).

By applying this idea to every n(=1024?) chunks, we would even:
 - make sure to never hit the worst case (delta ~= maxStartPointer)
 - reduce memory usage at indexing time.

  was:
Robert had a great idea to save memory with 
{{CompressingStoredFieldsIndex.MEMORY_CHUNK}}: instead of storing the absolute 
start pointers we could compute the mean number of bytes per chunk of documents 
and only store the delta between the actual value and the expected value 
(avgChunkBytes * chunkNumber).

Given that the list of start pointers is stricly increasing, the error is at 
most maxStartPointer / 2 (and is very likely to be much lower) so we are 
guaranteed to save memory. (The same principle could be applied to docBases.)

By applying this idea to every n(=1024?) chunks, we would even:
 - make sure to never hit the worst case (same memory usage as if we stored the 
absolute offsets)
 - reduce memory usage at indexing time.


> Additional memory savings in CompressingStoredFieldsIndex.MEMORY_CHUNK
> --
>
> Key: LUCENE-4512
> URL: https://issues.apache.org/jira/browse/LUCENE-4512
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
>
> Robert had a great idea to save memory with 
> {{CompressingStoredFieldsIndex.MEMORY_CHUNK}}: instead of storing the 
> absolute start pointers we could compute the mean number of bytes per chunk 
> of documents and only store the delta between the actual value and the 
> expected value (avgChunkBytes * chunkNumber).
> By applying this idea to every n(=1024?) chunks, we would even:
>  - make sure to never hit the worst case (delta ~= maxStartPointer)
>  - reduce memory usage at indexing time.

--
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-4512) Additional memory savings in CompressingStoredFieldsIndex.MEMORY_CHUNK

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-4512:


 Summary: Additional memory savings in 
CompressingStoredFieldsIndex.MEMORY_CHUNK
 Key: LUCENE-4512
 URL: https://issues.apache.org/jira/browse/LUCENE-4512
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.1


Robert had a great idea to save memory with 
{{CompressingStoredFieldsIndex.MEMORY_CHUNK}}: instead of storing the absolute 
start pointers we could compute the mean number of bytes per chunk of documents 
and only store the delta between the actual value and the expected value 
(avgChunkBytes * chunkNumber).

Given that the list of start pointers is stricly increasing, the error is at 
most maxStartPointer / 2 (and is very likely to be much lower) so we are 
guaranteed to save memory. (The same principle could be applied to docBases.)

By applying this idea to every n(=1024?) chunks, we would even:
 - make sure to never hit the worst case (same memory usage as if we stored the 
absolute offsets)
 - reduce memory usage at indexing time.

--
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] [Assigned] (SOLR-1306) Support pluggable persistence/loading of solr.xml details

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-1306:


Assignee: Erick Erickson

> Support pluggable persistence/loading of solr.xml details
> -
>
> Key: SOLR-1306
> URL: https://issues.apache.org/jira/browse/SOLR-1306
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Noble Paul
>Assignee: Erick Erickson
> Fix For: 4.1
>
>
> Persisting and loading details from one xml is fine if the no:of cores are 
> small and the no:of cores are few/fixed . If there are 10's of thousands of 
> cores in a single box adding a new core (with persistent=true) becomes very 
> expensive because every core creation has to write this huge xml. 
> Moreover , there is a good chance that the file gets corrupted and all the 
> cores become unusable . In that case I would prefer it to be stored in a 
> centralized DB which is backed up/replicated and all the information is 
> available in a centralized location. 
> We may need to refactor CoreContainer to have a pluggable implementation 
> which can load/persist the details . The default implementation should 
> write/read from/to solr.xml . And the class should be pluggable as follows in 
> solr.xml
> {code:xml}
> 
>   
> 
> {code}
> There will be a new interface (or abstract class ) called SolrDataProvider 
> which this class must implement

--
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-4011) SolrCore - correct behavior while having error loading specific cores

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-4011.
--

Resolution: Not A Problem

Gian:

No Problem, I'll close this and we can re-open it if there's something that 
should be done Solr-wise

> SolrCore - correct behavior while having error loading specific cores
> -
>
> Key: SOLR-4011
> URL: https://issues.apache.org/jira/browse/SOLR-4011
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
> Environment: RHEL 6.1/6.3
> Solr 3.6.1
>Reporter: Gianluca Varisco
>Assignee: Erick Erickson
>Priority: Minor
>
> I've a multicore setup.  Solr.xml contains the following:
> 
>   
> 
>  dataDir="/shop/solr/staging/a/data/" configName="solrconfig.xml" 
> schemaName="schema.xml" />
>  dataDir="/shop/solr/staging/b/data/" configName="solrconfig.xml" 
> schemaName="schema.xml" />
>  dataDir="/shop/solr/staging/c/data/" configName="solrconfig.xml" 
> schemaName="schema.xml" />
> 
> 
> When solr starts, it tries to LOAD all the cores. If one fails (no 
> solrconfig.xml or instanceDir found), the whole multicore configuration is 
> broken and Solr won't answer as well for the other two cores. 
> Is there a workaround for it? Reasons while it can happen is, for example, if 
> cores' creation in the XML are managed indipendently (e.g via Puppet) but 
> applications are not deployed in that instanceDir yet (therefore: no 
> solrconfig.xml/schema.xml). Is there a specific parameter to use?
>  

--
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-4011) SolrCore - correct behavior while having error loading specific cores

[Gianluca Varisco (JIRA)]

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

Gianluca Varisco commented on SOLR-4011:


Erick, great - thanks for your feedback! 

Will raise this kind of question in user's ML next time, got the point! :-)

Gian

> SolrCore - correct behavior while having error loading specific cores
> -
>
> Key: SOLR-4011
> URL: https://issues.apache.org/jira/browse/SOLR-4011
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
> Environment: RHEL 6.1/6.3
> Solr 3.6.1
>Reporter: Gianluca Varisco
>Assignee: Erick Erickson
>Priority: Minor
>
> I've a multicore setup.  Solr.xml contains the following:
> 
>   
> 
>  dataDir="/shop/solr/staging/a/data/" configName="solrconfig.xml" 
> schemaName="schema.xml" />
>  dataDir="/shop/solr/staging/b/data/" configName="solrconfig.xml" 
> schemaName="schema.xml" />
>  dataDir="/shop/solr/staging/c/data/" configName="solrconfig.xml" 
> schemaName="schema.xml" />
> 
> 
> When solr starts, it tries to LOAD all the cores. If one fails (no 
> solrconfig.xml or instanceDir found), the whole multicore configuration is 
> broken and Solr won't answer as well for the other two cores. 
> Is there a workaround for it? Reasons while it can happen is, for example, if 
> cores' creation in the XML are managed indipendently (e.g via Puppet) but 
> applications are not deployed in that instanceDir yet (therefore: no 
> solrconfig.xml/schema.xml). Is there a specific parameter to use?
>  

--
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 build is back to normal : slow-io-beasting #5063

[Charlie Cron]

See 


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

[jira] [Commented] (SOLR-3816) Need a more granular nrt system that is close to a realtime system.

[Radim Kolar (JIRA)]

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

Radim Kolar commented on SOLR-3816:
---

patch should be against solr trunk. Solr 4.0 branch is for bugfixes only.

> Need a more granular nrt system that is close to a realtime system.
> ---
>
> Key: SOLR-3816
> URL: https://issues.apache.org/jira/browse/SOLR-3816
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java, replication (java), search, 
> SearchComponents - other, SolrCloud, update
>Affects Versions: 4.0
>Reporter: Nagendra Nagarajayya
>  Labels: nrt, realtime, replication, search, solrcloud, update
> Attachments: SOLR-3816_4.0_branch.patch, solr-3816-realtime_nrt.patch
>
>
> Need a more granular NRT system that is close to a realtime system. A 
> realtime system should be able to reflect changes to the index as and when 
> docs are added/updated to the index. soft-commit offers NRT and is more 
> realtime friendly than hard commit but is limited by the dependency on the 
> SolrIndexSearcher being closed and reopened and offers a coarse granular NRT. 
> Closing and reopening of the SolrIndexSearcher may impact performance also.

--
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-4511) TermsFilter might return wrong results if a field is not indexed or not present in the index

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4511:


Nice catch!

Hmm should we set lastField = field (and termsEnum = null) before continue (so 
we don't keep calling fields.terms() on the non-existent field), and then 
change that bogus if to check if termsEnum != null?



> TermsFilter might return wrong results if a field is not indexed or not 
> present in the index
> 
>
> Key: LUCENE-4511
> URL: https://issues.apache.org/jira/browse/LUCENE-4511
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 4.0, 4.1, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4511.patch
>
>
> TermsFilter returns if a term returns null from AIR#terms(term) while it 
> should just continue. I will upload a test & fix shortly

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

Build failed in Jenkins: slow-io-beasting #5062

[Charlie Cron]

See 

--
[...truncated 14649 lines...]
[junit4:junit4]   2>at sun.nio.ch.SocketChannelImpl.checkConnect(Native 
Method)
[junit4:junit4]   2>at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
[junit4:junit4]   2>at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)
[junit4:junit4]   2> 
[junit4:junit4]   2> 279200 T73 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 279200 T14 oaz.ZooKeeper.close Session: 0x13aacc8aa050005 
closed
[junit4:junit4]   2> 279210 T14 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 279261 T14 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
64346
[junit4:junit4]   2> 279261 T14 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=816382
[junit4:junit4]   2> 279261 T14 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@132b67c
[junit4:junit4]   2> 279274 T14 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 279274 T14 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 279275 T14 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 279275 T14 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 279276 T14 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 280945 T84 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server 127.0.0.1/127.0.0.1:63884
[junit4:junit4]   2> 282037 T85 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 282037 T14 oaz.ZooKeeper.close Session: 0x13aacc8aa050006 
closed
[junit4:junit4]   2> 282047 T14 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 282408 T14 oas.SolrTestCaseJ4.tearDown ###Ending 
testDistribSearch
[junit4:junit4]   1>"core":"collection1",
[junit4:junit4]   1>"node_name":"127.0.0.1:63912_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:63912/solr"}
[junit4:junit4]   1>/solr/collections/control_collection (3)
[junit4:junit4]   1>DATA:
[junit4:junit4]   1>{"configName":"conf1"}
[junit4:junit4]   1> /solr/collections/control_collection/shards (0)
[junit4:junit4]   1> /solr/collections/control_collection/leader_elect (1)
[junit4:junit4]   1>  
/solr/collections/control_collection/leader_elect/control_shard (1)
[junit4:junit4]   1>   
/solr/collections/control_collection/leader_elect/control_shard/election (1)
[junit4:junit4]   1>
/solr/collections/control_collection/leader_elect/control_shard/election/88573120533037058-127.0.0.1:63891_solr_collection1-n_00
 (0)
[junit4:junit4]   1> /solr/collections/control_collection/leaders (1)
[junit4:junit4]   1>  
/solr/collections/control_collection/leaders/control_shard (0)
[junit4:junit4]   1>  DATA:
[junit4:junit4]   1>  {
[junit4:junit4]   1>"core":"collection1",
[junit4:junit4]   1>"node_name":"127.0.0.1:63891_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:63891/solr"}
[junit4:junit4]   1>   /solr/clusterstate.json (0)
[junit4:junit4]   1>   DATA:
[junit4:junit4]   1>   {
[junit4:junit4]   1> "collection1":{
[junit4:junit4]   1>   "shard1":{
[junit4:junit4]   1> "range":"8000-",
[junit4:junit4]   1> "replicas":{
[junit4:junit4]   1>   "127.0.0.1:63906_solr_collection1":{
[junit4:junit4]   1> "shard":"shard1",
[junit4:junit4]   1> "roles":null,
[junit4:junit4]   1> "state":"active",
[junit4:junit4]   1> "core":"collection1",
[junit4:junit4]   1> "collection":"collection1",
[junit4:junit4]   1> "node_name":"127.0.0.1:63906_solr",
[junit4:junit4]   1> "base_url":"http://127.0.0.1:63906/solr";,
[junit4:junit4]   1> "leader":"true"},
[junit4:junit4]   1>   "127.0.0.1:63927_solr_collection1":{
[junit4:junit4]   1> "shard":null,
[junit4:junit4]   1> "roles":null,
[junit4:junit4]   1> "state":"down",
[junit4:junit4]   1> "core":"collection1",
[junit4:junit4]   1> "collection":"collection1",
[junit4:junit4]   1> "node_name":"127.0.0.1:63927_solr",
[junit4:junit4]   1> 
"base_url":"http://127.0.0.1:63927/solr"

[jira] [Commented] (SOLR-4012) LeaderIntegrationTest sometimes hangs

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-4012:
---

Yup, sorry, thought it's the hung runner issue.

> LeaderIntegrationTest sometimes hangs
> -
>
> Key: SOLR-4012
> URL: https://issues.apache.org/jira/browse/SOLR-4012
> Project: Solr
>  Issue Type: Test
>  Components: Tests
> Environment: windows
>Reporter: Robert Muir
>
> I was unable to get a stacktrace before. This time I succeeded.

--
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-4012) LeaderIntegrationTest sometimes hangs

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-4012:
---

This is just a "normal" test hang I think.


> LeaderIntegrationTest sometimes hangs
> -
>
> Key: SOLR-4012
> URL: https://issues.apache.org/jira/browse/SOLR-4012
> Project: Solr
>  Issue Type: Test
>  Components: Tests
> Environment: windows
>Reporter: Robert Muir
>
> I was unable to get a stacktrace before. This time I succeeded.

--
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] [Assigned] (LUCENE-4511) TermsFilter might return wrong results if a field is not indexed or not present in the index

[Simon Willnauer (JIRA)]

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

Simon Willnauer reassigned LUCENE-4511:
---

Assignee: Simon Willnauer

> TermsFilter might return wrong results if a field is not indexed or not 
> present in the index
> 
>
> Key: LUCENE-4511
> URL: https://issues.apache.org/jira/browse/LUCENE-4511
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 4.0, 4.1, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4511.patch
>
>
> TermsFilter returns if a term returns null from AIR#terms(term) while it 
> should just continue. I will upload a test & fix shortly

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