date:20121028

[jira] [Resolved] (SOLR-433) MultiCore and SpellChecker replication

2012-10-28 Thread Otis Gospodnetic (JIRA)


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

Otis Gospodnetic resolved SOLR-433.
---

Resolution: Won't Fix

I think this is no longer needed, since spellchecker no longer needs a separate 
index.  Resolving as Won't Fix.

> MultiCore and SpellChecker replication
> --
>
> Key: SOLR-433
> URL: https://issues.apache.org/jira/browse/SOLR-433
> Project: Solr
>  Issue Type: Improvement
>  Components: replication (scripts), spellchecker
>Affects Versions: 1.3
>Reporter: Otis Gospodnetic
> Fix For: 4.1
>
> Attachments: RunExecutableListener.patch, solr-433.patch, 
> SOLR-433.patch, SOLR-433.patch, SOLR-433.patch, SOLR-433.patch, 
> SOLR-433-r698590.patch, SOLR-433_unified.patch, spellindexfix.patch
>
>
> With MultiCore functionality coming along, it looks like we'll need to be 
> able to:
>   A) snapshot each core's index directory, and
>   B) replicate any and all cores' complete data directories, not just their 
> index directories.
> Pulled from the "spellchecker and multi-core index replication" thread - 
> http://markmail.org/message/pj2rjzegifd6zm7m
> Otis:
> I think that makes sense - distribute everything for a given core, not just 
> its index.  And the spellchecker could then also have its data dir (and only 
> index/ underneath really) and be replicated in the same fashion.
> Right?
> Ryan:
> Yes, that was my thought.  If an arbitrary directory could be distributed, 
> then you could have
>   /path/to/dist/index/...
>   /path/to/dist/spelling-index/...
>   /path/to/dist/foo
> and that would all get put into a snapshot.  This would also let you put 
> multiple cores within a single distribution:
>   /path/to/dist/core0/index/...
>   /path/to/dist/core0/spelling-index/...
>   /path/to/dist/core0/foo
>   /path/to/dist/core1/index/...
>   /path/to/dist/core1/spelling-index/...
>   /path/to/dist/core1/foo

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

2012-10-28 Thread 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 #5042

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13766 lines...]
[junit4:junit4]   2> 29130 T10 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@15c30f6),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 29130 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 29130 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 29130 T10 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 29130 T10 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 29130 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 29130 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 29130 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 29177 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 29239 T10 oass.SolrIndexSearcher. Opening 
Searcher@1dc6a9d main
[junit4:junit4]   2> 29255 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 29255 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 29255 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 29255 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 29255 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 29255 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 29255 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 29255 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 29255 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 29271 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 29271 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 29271 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 29271 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 29286 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 29302 T117 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@1dc6a9d 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 29302 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 29302 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 29302 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@539a92
[junit4:junit4]   2> 29333 T115 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@15c30f6),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 29333 T115 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 29333 T115 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 16
[junit4:junit4]   2> 29349 T116 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 29364 T116 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=MockDirW

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

2012-10-28 Thread 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 #5041

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 15743 lines...]
[junit4:junit4]   1>/solr/overseer/queue (0)
[junit4:junit4]   1>DATA:
[junit4:junit4]   1>
[junit4:junit4]   1>/solr/overseer/queue-work (0)
[junit4:junit4]   1>DATA:
[junit4:junit4]   1>
[junit4:junit4]   1>/solr/overseer/collection-queue-work (0)
[junit4:junit4]   1>DATA:
[junit4:junit4]   1>
[junit4:junit4]   1>   /solr/overseer_elect (2)
[junit4:junit4]   1>/solr/overseer_elect/election (7)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135363-127.0.0.1:61508_solr-n_01
 (0)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135364-127.0.0.1:61515_solr-n_02
 (0)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135367-127.0.0.1:61683_solr-n_05
 (0)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135368-127.0.0.1:61690_solr-n_06
 (0)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135366-127.0.0.1:61672_solr-n_04
 (0)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135362-127.0.0.1:61496_solr-n_00
 (0)
[junit4:junit4]   1> 
/solr/overseer_elect/election/88571295253135365-127.0.0.1:61665_solr-n_03
 (0)
[junit4:junit4]   1>/solr/overseer_elect/leader (0)
[junit4:junit4]   1>DATA:
[junit4:junit4]   1>
{"id":"88571295253135362-127.0.0.1:61496_solr-n_00"}
[junit4:junit4]   1>   /solr/collections (2)
[junit4:junit4]   1>/solr/collections/collection1 (3)
[junit4:junit4]   1>DATA:
[junit4:junit4]   1>{"configName":"conf1"}
[junit4:junit4]   1> /solr/collections/collection1/shards (0)
[junit4:junit4]   1> /solr/collections/collection1/leader_elect (2)
[junit4:junit4]   1>  /solr/collections/collection1/leader_elect/shard1 (1)
[junit4:junit4]   1>   
/solr/collections/collection1/leader_elect/shard1/election (3)
[junit4:junit4]   1>
/solr/collections/collection1/leader_elect/shard1/election/88571295253135365-127.0.0.1:61665_solr_collection1-n_01
 (0)
[junit4:junit4]   1>
/solr/collections/collection1/leader_elect/shard1/election/88571295253135363-127.0.0.1:61508_solr_collection1-n_00
 (0)
[junit4:junit4]   1>
/solr/collections/collection1/leader_elect/shard1/election/88571295253135367-127.0.0.1:61683_solr_collection1-n_02
 (0)
[junit4:junit4]   1>  /solr/collections/collection1/leader_elect/shard2 (1)
[junit4:junit4]   1>   
/solr/collections/collection1/leader_elect/shard2/election (2)
[junit4:junit4]   1>
/solr/collections/collection1/leader_elect/shard2/election/88571295253135366-127.0.0.1:61672_solr_collection1-n_00
 (0)
[junit4:junit4]   1>
/solr/collections/collection1/leader_elect/shard2/election/88571295253135368-127.0.0.1:61690_solr_collection1-n_01
 (0)
[junit4:junit4]   1> /solr/collections/collection1/leaders (2)
[junit4:junit4]   1>  /solr/collections/collection1/leaders/shard1 (0)
[junit4:junit4]   1>  DATA:
[junit4:junit4]   1>  {
[junit4:junit4]   1>"core":"collection1",
[junit4:junit4]   1>"node_name":"127.0.0.1:61508_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:61508/solr"}
[junit4:junit4]   1>  /solr/collections/collection1/leaders/shard2 (0)
[junit4:junit4]   1>  DATA:
[junit4:junit4]   1>  {
[junit4:junit4]   1>"core":"collection1",
[junit4:junit4]   1>"node_name":"127.0.0.1:61672_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:61672/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/88571295253135362-127.0.0.1:61496_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:61496_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:61496/solr"}
[junit4:junit4]   1>   /solr/clusterstate.json (0)
[junit4:junit4]   1>   DATA:
[junit4:junit4]   1>   {
[junit4:junit4]   1> "collection1":{
[j

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 14033 lines...]
[junit4:junit4]   2> 256452 T508 oaz.ZooKeeper.close Session: 0x13aab1f3da90004 
closed
[junit4:junit4]   2> 256475 T508 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 256527 T508 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
39737
[junit4:junit4]   2> 256527 T508 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1066494635
[junit4:junit4]   2> 258006 T577 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:40889
[junit4:junit4]   2> 258007 T577 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aab1f3da90006 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> 258176 T565 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:40889
[junit4:junit4]   2> 258276 T566 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 258276 T508 oaz.ZooKeeper.close Session: 0x13aab1f3da90005 
closed
[junit4:junit4]   2> 258299 T508 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 258351 T508 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
47491
[junit4:junit4]   2> 258352 T508 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=2024912301
[junit4:junit4]   2> 258352 T508 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@4edc90c4
[junit4:junit4]   2> 258359 T508 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=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 258359 T508 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 258359 T508 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 258359 T508 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 258360 T508 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 259658 T577 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:40889
[junit4:junit4]   2> 259759 T578 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 259759 T508 oaz.ZooKeeper.close Session: 0x13aab1f3da90006 
closed
[junit4:junit4]   2> 259782 T508 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 259849 T508 oas.SolrTestCaseJ4.tearDown ###Ending 
testDistribSearch
[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/88571293353967618-127.0.0.1:45544_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:45544_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:45544/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:37928_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:37928_solr",
[junit4:junit4]   1>

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 16585 lines...]
[junit4:junit4] Suite: org.apache.solr.SolrInfoMBeanTest
[junit4:junit4] Completed on J1 in 2.51s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.XsltUpdateRequestHandlerTest
[junit4:junit4] Completed on J3 in 2.34s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.IndexSchemaRuntimeFieldTest
[junit4:junit4] Completed on J7 in 1.75s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.analysis.TestReversedWildcardFilterFactory
[junit4:junit4] Completed on J2 in 1.76s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.DirectUpdateHandlerOptimizeTest
[junit4:junit4] Completed on J6 in 2.18s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
[junit4:junit4] Completed on J5 in 2.68s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.ReturnFieldsTest
[junit4:junit4] Completed on J1 in 1.92s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.RequestHandlersTest
[junit4:junit4] Completed on J3 in 1.92s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.RequiredFieldsTest
[junit4:junit4] Completed on J2 in 1.54s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.CopyFieldTest
[junit4:junit4] Completed on J5 in 1.73s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest
[junit4:junit4] Completed on J7 in 1.85s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.TestOmitPositions
[junit4:junit4] Completed on J6 in 1.90s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestArbitraryIndexDir
[junit4:junit4] Completed on J1 in 2.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestQueryUtils
[junit4:junit4] Completed on J3 in 2.52s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.request.TestWriterPerf
[junit4:junit4] Completed on J1 in 1.94s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
[junit4:junit4] Completed on J7 in 2.47s, 18 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.TestDistributedSearch
[junit4:junit4] Completed on J4 in 58.32s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTest
[junit4:junit4] Completed on J2 in 4.16s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.TestIndexingPerformance
[junit4:junit4] Completed on J3 in 2.82s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest
[junit4:junit4] Completed on J6 in 3.74s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest
[junit4:junit4] Completed on J1 in 1.95s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest
[junit4:junit4] Completed on J7 in 1.96s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.TestBinaryField
[junit4:junit4] Completed on J6 in 0.94s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.BadIndexSchemaTest
[junit4:junit4] Completed on J5 in 5.47s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.BadComponentTest
[junit4:junit4] Completed on J3 in 1.50s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
[junit4:junit4] Completed on J4 in 2.00s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestDocSet
[junit4:junit4] Completed on J6 in 0.41s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.SOLR749Test
[junit4:junit4] Completed on J1 in 1.38s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.TestNumberUtils
[junit4:junit4] Completed on J1 in 0.14s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestPropInjectDefaults
[junit4:junit4] Completed on J7 in 1.53s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.OutputWriterTest
[junit4:junit4] Completed on J6 in 0.69s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.SpellPossibilityIteratorTest
[junit4:junit4] Completed on J6 in 0.17s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestJmxMonitoredMap
[junit4:junit4] Completed on J1 in 0.30s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.NumericFieldsTest
[junit4:junit4] Completed on J4 in 1.26s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery
[junit4:junit4] Completed on J5 in 1.76s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.IndexReaderFactoryTest
[junit4:junit4] Completed on J3 in 1.72s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.s

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

2012-10-28 Thread 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 #6204

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 11672 lines...]
[junit4:junit4] Completed on J5 in 0.70s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest
[junit4:junit4] Completed on J3 in 0.70s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.DirectUpdateHandlerOptimizeTest
[junit4:junit4] Completed on J4 in 0.86s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterWFSTTest
[junit4:junit4] Completed on J1 in 1.17s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.RequiredFieldsTest
[junit4:junit4] Completed on J6 in 0.65s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.ReturnFieldsTest
[junit4:junit4] Completed on J7 in 0.77s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.CopyFieldTest
[junit4:junit4] Completed on J3 in 0.70s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.TestOmitPositions
[junit4:junit4] Completed on J5 in 0.80s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest
[junit4:junit4] Completed on J1 in 0.80s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest
[junit4:junit4] Completed on J6 in 0.72s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.analysis.TestLuceneMatchVersion
[junit4:junit4] Completed on J5 in 0.39s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTSTTest
[junit4:junit4] Completed on J4 in 1.40s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
[junit4:junit4] Completed on J4 in 0.60s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
[junit4:junit4] Completed on J3 in 1.41s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestPropInject
[junit4:junit4] Completed on J1 in 1.06s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest
[junit4:junit4] Completed on J5 in 0.90s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.request.TestWriterPerf
[junit4:junit4] Completed on J6 in 1.17s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.TestBinaryField
[junit4:junit4] Completed on J3 in 0.44s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.BadIndexSchemaTest
[junit4:junit4] Completed on J7 in 2.20s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestXIncludeConfig
[junit4:junit4] Completed on J3 in 0.19s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2
[junit4:junit4] Completed on J1 in 0.64s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.SOLR749Test
[junit4:junit4] Completed on J5 in 0.52s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
[junit4:junit4] Completed on J6 in 0.53s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest
[junit4:junit4] Completed on J4 in 0.83s, 26 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestDocSet
[junit4:junit4] Completed on J7 in 0.63s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.TestCollationField
[junit4:junit4] Completed on J1 in 0.46s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.NumericFieldsTest
[junit4:junit4] Completed on J5 in 0.43s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.OutputWriterTest
[junit4:junit4] Completed on J6 in 0.42s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.TestNumberUtils
[junit4:junit4] Completed on J4 in 0.27s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestQuerySenderListener
[junit4:junit4] Completed on J3 in 0.60s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.EchoParamsTest
[junit4:junit4] Completed on J6 in 0.18s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.TestPhraseSuggestions
[junit4:junit4] Completed on J4 in 0.16s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.MultiTermTest
[junit4:junit4] Completed on J7 in 0.29s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestLMDirichletSimilarityFactory
[junit4:junit4] Completed on J3 in 0.14s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.TestSolrCoreProperties
[junit4:junit4] Completed on J1 in 0.26s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestConfig
[junit4:junit4] Completed on J5 in 0.36s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.TestPluginEnable
[junit4:junit4] Completed on J6 in 0.11s, 1 test
[ju

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

2012-10-28 Thread Charlie Cron

See 


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

Re: Build failed in Jenkins: slow-io-beasting #5036

2012-10-28 Thread Robert Muir

I killed this, again the same hung  slave, refusing to be
terminated or jstack'd. So I had to kill its parent instead.

On Mon, Oct 29, 2012 at 12:40 AM, Charlie Cron
 wrote:
> See 
>
> --
> [...truncated 8410 lines...]
> -clover.setup:
>
> clover:
>
> common.compile-core:
>
> compile-core:
>
> common.compile-test:
>
> install-junit4-taskdef:
>
> validate:
>
> common.test:
> [mkdir] Created dir: 
> 
> [junit4:junit4]  says g'day! Master seed: 8427391B4502DA84
> [junit4:junit4] Your default console's encoding may not display certain 
> unicode glyphs: windows-1252
> [junit4:junit4] Executing 65 suites with 8 JVMs.
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.index.params.PerDimensionIndexingParamsTest
> [junit4:junit4] Completed on J6 in 1.86s, 2 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.index.attributes.CategoryAttributesIterableTest
> [junit4:junit4] Completed on J4 in 1.70s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.index.CategoryContainerTest
> [junit4:junit4] Completed on J4 in 0.16s, 10 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.search.params.FacetRequestTest
> [junit4:junit4] Completed on J7 in 3.28s, 6 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.IntHashSetTest
> [junit4:junit4] Completed on J7 in 0.30s, 10 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.index.streaming.CategoryTokenizerTest
> [junit4:junit4] Completed on J4 in 1.51s, 2 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.UnsafeByteArrayInputStreamTest
> [junit4:junit4] Completed on J7 in 0.17s, 5 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.enhancements.association.AssociationPropertyTest
> [junit4:junit4] Completed on J4 in 0.14s, 3 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.example.TestAdaptiveExample
> [junit4:junit4] Completed on J6 in 1.89s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.ObjectToFloatMapTest
> [junit4:junit4] Completed on J4 in 0.22s, 6 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.enhancements.TwoEnhancementsTest
> [junit4:junit4] Completed on J6 in 0.84s, 2 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.IntToObjectMapTest
> [junit4:junit4] Completed on J6 in 0.08s, 6 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.index.params.DefaultFacetIndexingParamsTest
> [junit4:junit4] Completed on J6 in 0.03s, 3 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.Vint8Test
> [junit4:junit4] Completed on J6 in 0.05s, 5 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.search.TestFacetsCollector
> [junit4:junit4] Completed on J0 in 5.93s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.search.CategoryListIteratorTest
> [junit4:junit4] Completed on J7 in 2.34s, 2 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.TestCompactLabelToOrdinal
> [junit4:junit4] Completed on J6 in 1.44s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.FloatToObjectMapTest
> [junit4:junit4] Completed on J6 in 0.11s, 6 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyWriter
> [junit4:junit4] Completed on J5 in 7.95s, 9 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.IntArrayTest
> [junit4:junit4] Completed on J5 in 0.08s, 4 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.IntToDoubleMapTest
> [junit4:junit4] Completed on J5 in 0.11s, 6 tests
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.TestCharBlockArray
> [junit4:junit4] Completed on J7 in 3.37s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: 
> org.apache.lucene.facet.index.FacetsPayloadProcessorProviderTest
> [junit4:junit4] Completed on J5 in 1.54s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.search.DrillDownTest
> [junit4:junit4] Completed on J7 in 0.51s, 4 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.search.TestTotalFacetCounts
> [junit4:junit4] Completed on J5 in 0.58s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.facet.util.TestScoredDocIDsUtils
> [junit4:junit4] Completed on J7 in 1.06s, 3 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.util.collections.IntToIntMapTest
> [junit4:junit4] Completed on J7 in 0.06s, 6 tests
> [junit4:junit4]
> [junit4:junit4] Su

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 8410 lines...]
-clover.setup:

clover:

common.compile-core:

compile-core:

common.compile-test:

install-junit4-taskdef:

validate:

common.test:
[mkdir] Created dir: 

[junit4:junit4]  says g'day! Master seed: 8427391B4502DA84
[junit4:junit4] Your default console's encoding may not display certain unicode 
glyphs: windows-1252
[junit4:junit4] Executing 65 suites with 8 JVMs.
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.index.params.PerDimensionIndexingParamsTest
[junit4:junit4] Completed on J6 in 1.86s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.index.attributes.CategoryAttributesIterableTest
[junit4:junit4] Completed on J4 in 1.70s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.index.CategoryContainerTest
[junit4:junit4] Completed on J4 in 0.16s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.search.params.FacetRequestTest
[junit4:junit4] Completed on J7 in 3.28s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.IntHashSetTest
[junit4:junit4] Completed on J7 in 0.30s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.index.streaming.CategoryTokenizerTest
[junit4:junit4] Completed on J4 in 1.51s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.UnsafeByteArrayInputStreamTest
[junit4:junit4] Completed on J7 in 0.17s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.enhancements.association.AssociationPropertyTest
[junit4:junit4] Completed on J4 in 0.14s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.example.TestAdaptiveExample
[junit4:junit4] Completed on J6 in 1.89s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.ObjectToFloatMapTest
[junit4:junit4] Completed on J4 in 0.22s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.enhancements.TwoEnhancementsTest
[junit4:junit4] Completed on J6 in 0.84s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.IntToObjectMapTest
[junit4:junit4] Completed on J6 in 0.08s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.index.params.DefaultFacetIndexingParamsTest
[junit4:junit4] Completed on J6 in 0.03s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.Vint8Test
[junit4:junit4] Completed on J6 in 0.05s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.search.TestFacetsCollector
[junit4:junit4] Completed on J0 in 5.93s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.search.CategoryListIteratorTest
[junit4:junit4] Completed on J7 in 2.34s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.taxonomy.writercache.cl2o.TestCompactLabelToOrdinal
[junit4:junit4] Completed on J6 in 1.44s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.FloatToObjectMapTest
[junit4:junit4] Completed on J6 in 0.11s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyWriter
[junit4:junit4] Completed on J5 in 7.95s, 9 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.IntArrayTest
[junit4:junit4] Completed on J5 in 0.08s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.IntToDoubleMapTest
[junit4:junit4] Completed on J5 in 0.11s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.taxonomy.writercache.cl2o.TestCharBlockArray
[junit4:junit4] Completed on J7 in 3.37s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.index.FacetsPayloadProcessorProviderTest
[junit4:junit4] Completed on J5 in 1.54s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.search.DrillDownTest
[junit4:junit4] Completed on J7 in 0.51s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.search.TestTotalFacetCounts
[junit4:junit4] Completed on J5 in 0.58s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.util.TestScoredDocIDsUtils
[junit4:junit4] Completed on J7 in 1.06s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.collections.IntToIntMapTest
[junit4:junit4] Completed on J7 in 0.06s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.search.TestTopKResultsHandlerRandom
[junit4:junit4] Completed on J3 in 11.14s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4:junit4] Completed on J5 in 1.07s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.facet.search.TestTotalFacetCountsCache
[

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

2012-10-28 Thread Charlie Cron

See 


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

[jira] [Created] (SOLR-4007) Morfologik dictionaries not available in Solr field type

2012-10-28 Thread Lance Norskog (JIRA)

Lance Norskog created SOLR-4007:
---

 Summary: Morfologik dictionaries not available in Solr field type
 Key: SOLR-4007
 URL: https://issues.apache.org/jira/browse/SOLR-4007
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 4.1
Reporter: Lance Norskog
Priority: Minor


The Polish Morfologik type does not find its dictionaries when used in Solr. To 
demonstrate:

1) Add this to example/solr/collection1/conf/schema.xml:
{noformat}


  


  

{noformat}

2) Add this to example/solr/collection1/conf/solrconfig.xml:

{noformat}
  
  
  
{noformat}

3) Test 'text_pl' in the analysis page. You will get an exception.
{noformat}
Oct 28, 2012 8:27:19 PM org.apache.solr.core.SolrCore execute
INFO: [collection1] webapp=/solr path=/analysis/field 
params={analysis.showmatch=true&analysis.query=&wt=json&analysis.fieldvalue=blah+blah&analysis.fieldtype=text_pl}
 status=500 QTime=26 
Oct 28, 2012 8:27:19 PM org.apache.solr.common.SolrException log
SEVERE: null:java.lang.RuntimeException: Default dictionary resource for 
language 'plnot found.
at morfologik.stemming.Dictionary.getForLanguage(Dictionary.java:163)
at morfologik.stemming.PolishStemmer.(PolishStemmer.java:64)
at 
org.apache.lucene.analysis.morfologik.MorfologikFilter.(MorfologikFilter.java:70)
at 
org.apache.lucene.analysis.morfologik.MorfologikFilterFactory.create(MorfologikFilterFactory.java:63)
at 
org.apache.solr.handler.AnalysisRequestHandlerBase.analyzeValue(AnalysisRequestHandlerBase.java:125)
at 
org.apache.solr.handler.FieldAnalysisRequestHandler.analyzeValues(FieldAnalysisRequestHandler.java:220)
at 
org.apache.solr.handler.FieldAnalysisRequestHandler.handleAnalysisRequest(FieldAnalysisRequestHandler.java:181)
at 
org.apache.solr.handler.FieldAnalysisRequestHandler.doAnalysis(FieldAnalysisRequestHandler.java:100)
at 

[...]

Caused by: java.io.IOException: Could not locate resource: 
morfologik/dictionaries/pl.dict
at morfologik.util.ResourceUtils.openInputStream(ResourceUtils.java:56)
at morfologik.stemming.Dictionary.getForLanguage(Dictionary.java:156)
... 38 more

{noformat}

{{morfologik-polish-1.5.3.jar}} has {{morfologik/dictionaries/pl.dict}}.

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13475 lines...]
[junit4:junit4]   2> 7222463 T114 oascc.SolrZkClient.makePath makePath: 
/overseer_elect/election
[junit4:junit4]   2> 7222471 T150 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x1353d710002 
type:delete cxid:0x15 zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer_elect/leader Error:KeeperErrorCode = NoNode for 
/solr/overseer_elect/leader
[junit4:junit4]   2> 7222474 T114 oascc.SolrZkClient.makePath makePath: 
/overseer_elect/leader
[junit4:junit4]   2> 7222479 T114 oasc.Overseer.start Overseer 
(id=88570769364287490-127.0.0.1:7000_solr-n_00) starting
[junit4:junit4]   2> 7222480 T150 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x1353d710002 
type:create cxid:0x1a zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = NodeExists for /solr/overseer
[junit4:junit4]   2> 7222483 T150 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x1353d710002 
type:create cxid:0x1b zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = NodeExists for /solr/overseer
[junit4:junit4]   2> 7222485 T150 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x1353d710002 
type:create cxid:0x1c zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = NodeExists for /solr/overseer
[junit4:junit4]   2> 7222487 T150 oazs.PrepRequestProcessor.pRequest Got 
user-level KeeperException when processing sessionid:0x1353d710002 
type:create cxid:0x1d zxid:0xfffe txntype:unknown reqpath:n/a Error 
Path:/solr/overseer Error:KeeperErrorCode = NodeExists for /solr/overseer
[junit4:junit4]   2> 7222489 T158 oasc.OverseerCollectionProcessor.run Process 
current queue of collection creations
[junit4:junit4]   2> 7222490 T114 oascc.SolrZkClient.makePath makePath: 
/clusterstate.json
[junit4:junit4]   2> 7222494 T114 
oascc.ZkStateReader.createClusterStateWatchersAndUpdate Updating cluster state 
from ZooKeeper... 
[junit4:junit4]   2> 7222496 T157 oasc.Overseer$ClusterStateUpdater.run 
Starting to work on the main queue
[junit4:junit4]   2> 7222499 T114 oasc.CoreContainer.create Creating SolrCore 
'collection1' using instanceDir: 

[junit4:junit4]   2> 7222500 T114 oasc.ZkController.createCollectionZkNode 
Check for collection zkNode:collection1
[junit4:junit4]   2> 7222500 T114 oasc.ZkController.createCollectionZkNode 
Collection zkNode exists
[junit4:junit4]   2> 7222501 T114 oasc.ZkController.readConfigName Load 
collection config from:/collections/collection1
[junit4:junit4]   2> 7222502 T114 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'
[junit4:junit4]   2> 7222502 T114 oasc.SolrResourceLoader.replaceClassLoader 
Adding 
'
 to classloader
[junit4:junit4]   2> 7222502 T114 oasc.SolrResourceLoader.replaceClassLoader 
Adding 
'
 to classloader
[junit4:junit4]   2> 7222526 T114 oasc.SolrConfig. Using Lucene 
MatchVersion: LUCENE_41
[junit4:junit4]   2> 7222550 T114 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
[junit4:junit4]   2> 7222551 T114 oass.IndexSchema.readSchema Reading Solr 
Schema
[junit4:junit4]   2> 7222556 T114 oass.IndexSchema.readSchema Schema name=test
[junit4:junit4]   2> 7222764 T114 oass.OpenExchangeRatesOrgProvider.init 
Initialized with rates=open-exchange-rates.json, refreshInterval=1440.
[junit4:junit4]   2> 7222768 T114 oass.IndexSchema.readSchema default search 
field in schema is text
[junit4:junit4]   2> 7222769 T114 oass.IndexSchema.readSchema unique key field: 
id
[junit4:junit4]   2> 7222771 T114 oasc.CoreContainer.create SEVERE Unable to 
create core: collection1 java.lang.RuntimeException: java.io.IOException: Error 
opening /configs/conf1/stopwords.txt
[junit4:junit4]   2>at 
org.apache.solr.schema.IndexSchema.(IndexSchema.java:116)
[junit4:junit4]   2>at 
org.apache.solr.core.CoreContainer.getSchemaFromZk(CoreContainer.java:1434)
[junit4:junit4]   2>at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:825)
[junit4:junit4]   2>at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:529)
[junit4:junit4]   2>at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:351)
[j

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

2012-10-28 Thread 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 #5032

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13130 lines...]
[junit4:junit4]   2> 20719 T506 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 20719 T506 oasc.RequestHandlers.initHandlersFromConfig 
created /get: solr.RealTimeGetHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created dismax: solr.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created mock: org.apache.solr.core.MockQuerySenderListenerReqHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created /admin/: org.apache.solr.handler.admin.AdminHandlers
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created /terms: org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created spellCheckCompRH: org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created spellCheckCompRH_Direct: org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created spellCheckWithWordbreak: org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created spellCheckWithWordbreak_Direct: 
org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created spellCheckCompRH1: org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created tvrh: org.apache.solr.handler.component.SearchHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created /mlt: solr.MoreLikeThisHandler
[junit4:junit4]   2> 20735 T506 oasc.RequestHandlers.initHandlersFromConfig 
created /debug/dump: solr.DumpRequestHandler
[junit4:junit4]   2> 20937 T506 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 20984 T506 oasc.SolrCore.initDeprecatedSupport WARNING 
solrconfig.xml uses deprecated , Please update your config 
to use the ShowFileRequestHandler.
[junit4:junit4]   2> 21047 T506 oasc.SolrCore.initDeprecatedSupport WARNING 
adding ShowFileRequestHandler with hidden files: [SCHEMA.XML, OLD_SYNONYMS.TXT, 
STOPWORDS.TXT, PROTWORDS.TXT, OPEN-EXCHANGE-RATES.JSON, SYNONYMS.TXT, 
CURRENCY.XML, MAPPING-ISOLATIN1ACCENT.TXT]
[junit4:junit4]   2> 21047 T506 oass.SolrIndexSearcher. Opening 
Searcher@11365ad main
[junit4:junit4]   2> 21047 T506 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 21047 T506 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 21047 T506 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 21047 T506 oashc.SpellCheckComponent.inform Initializing 
spell checkers
[junit4:junit4]   2> 21047 T506 oass.DirectSolrSpellChecker.init init: 
{name=direct,classname=DirectSolrSpellChecker,field=lowerfilt,minQueryLength=3}
[junit4:junit4]   2> 21062 T506 oasc.ZkController.publish numShards not found 
on descriptor - reading it from system property
[junit4:junit4]   2> 21078 T532 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@11365ad 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 21405 T518 oascc.ZkStateReader.updateClusterState Updating 
cloud state from ZooKeeper... 
[junit4:junit4]   2> 21405 T518 oasc.Overseer$ClusterStateUpdater.updateState 
Update state numShards=null message={
[junit4:junit4]   2>  "operation":"state",
[junit4:junit4]   2>  "numShards":null,
[junit4:junit4]   2>  "shard":null,
[junit4:junit4]   2>  "roles":null,
[junit4:junit4]   2>  "state":"down",
[junit4:junit4]   2>  "core":"collection1",
[junit4:junit4]   2>  "collection":"collection1",
[junit4:junit4]   2>  "node_name":"BIGBOY:8983_solr",
[junit4:junit4]   2>  "base_url":"http://BIGBOY:8983/solr"}
[junit4:junit4]   2> 21437 T517 oascc.ZkStateReader$2.process A cluster state 
change has occurred - updating... (2)
[junit4:junit4]   2> 82713 T506 oasc.SolrException.log SEVERE 
null:org.apache.solr.common.SolrException: Could not get shard_id for core: 
collection

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

2012-10-28 Thread 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 #5029

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13806 lines...]
[junit4:junit4]   2> 28247 T10 oasc.CoreContainer.create Creating SolrCore 
'collection1' using instanceDir: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351476582149\solr\collection12\collection1
[junit4:junit4]   2> 28247 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351476582149\solr\collection12\collection1\'
[junit4:junit4]   2> 28356 T10 oasc.SolrConfig. Using Lucene 
MatchVersion: LUCENE_41
[junit4:junit4]   2> 28466 T10 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
[junit4:junit4]   2> 28466 T10 oass.IndexSchema.readSchema Reading Solr Schema
[junit4:junit4]   2> 28466 T10 oass.IndexSchema.readSchema Schema name=test
[junit4:junit4]   2> 28497 T10 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 28497 T10 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351476582149\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351476582149\solr\collection12\collection1\data\
[junit4:junit4]   2> 28512 T10 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 28512 T10 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351476582149\solr\collection12\collection1\data\index/
[junit4:junit4]   2> 28512 T10 oasc.SolrCore.initIndex WARNING [collection1] 
Solr index directory 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351476582149\solr\collection12\collection1\data\index'
 doesn't exist. Creating new index...
[junit4:junit4]   2> 28512 T10 oasc.CachingDirectoryFactory.get return new 
directory for 

 forceNew:false
[junit4:junit4]   2> 28528 T10 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@153e0c0),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 28528 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 28528 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 28528 T10 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 28528 T10 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 28528 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 28528 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 28528 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 28544 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 28559 T10 oass.SolrIndexSearcher. Opening 
Searcher@1ae0e7d main
[junit4:junit4]   2> 28559 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 28559 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 28559 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 28559 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fai

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13895 lines...]
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.NIOFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@627b5c),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> 34106 T102 C8 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 34106 T102 C8 oass.SolrIndexSearcher. Opening 
Searcher@1d5d765 main
[junit4:junit4]   2> 34106 T102 C8 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 34106 T102 C8 oasu.DirectUpdateHandler2.commit 
end_commit_flush
[junit4:junit4]   2> 34106 T107 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@1d5d765 
main{StandardDirectoryReader(segments_2:3 _0(4.1):C10)}
[junit4:junit4]   2> 34106 T102 C8 UPDATE [collection1] webapp=/solr 
path=/update 
params={waitSearcher=true&wt=javabin&commit=true&softCommit=false&version=2} 
{commit=} 0 15
[junit4:junit4]   2> 34122 T10 oejs.Server.doStart jetty-8.1.2.v20120308
[junit4:junit4]   2> 34138 T10 oejs.AbstractConnector.doStart Started 
SelectChannelConnector@0.0.0.0:63662
[junit4:junit4]   2> 34153 T10 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
[junit4:junit4]   2> 34153 T10 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12
[junit4:junit4]   2> 34153 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for deduced Solr Home: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\'
[junit4:junit4]   2> 34200 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init()
[junit4:junit4]   2> 34200 T10 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
[junit4:junit4]   2> 34200 T10 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12
[junit4:junit4]   2> 34200 T10 oasc.CoreContainer$Initializer.initialize 
looking for solr.xml: 

[junit4:junit4]   2> 34200 T10 oasc.CoreContainer. New CoreContainer 
29525271
[junit4:junit4]   2> 34200 T10 oasc.CoreContainer$Initializer.initialize no 
solr.xml file found - using default
[junit4:junit4]   2> 34200 T10 oasc.CoreContainer.load Loading CoreContainer 
using Solr Home: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\'
[junit4:junit4]   2> 34200 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\'
[junit4:junit4]   2> 34262 T10 oasc.CoreContainer.load Registering Log Listener
[junit4:junit4]   2> 34294 T10 oasc.CoreContainer.create Creating SolrCore 
'collection1' using instanceDir: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\collection1
[junit4:junit4]   2> 34294 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\collection1\'
[junit4:junit4]   2> 34356 T10 oasc.SolrConfig. Using Lucene 
MatchVersion: LUCENE_41
[junit4:junit4]   2> 34434 T10 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
[junit4:junit4]   2> 34434 T10 oass.IndexSchema.readSchema Reading Solr Schema
[junit4:junit4]   2> 34450 T10 oass.IndexSchema.readSchema Schema name=test
[junit4:junit4]   2> 34465 T10 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 34465 T10 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351475623684\solr\collection12\collection1\data\
[junit4:junit4]   2> 34481 T10 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 34481 T10 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrIns

Re: Source Control

2012-10-28 Thread David Smiley (@MITRE.org)

+1 I'm definitely in favor of moving to git.  I've gotten past the learning
curve hurdle and I appreciate its benefits.

The real challenge, I think, is figuring out how we can get real
collaboration like what is possible on GitHub, without actually truly being
on GitHub.  Maybe Atlassian's new Stash? 
http://www.atlassian.com/software/stash/  It'd be free for the ASF.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Source-Control-tp4016207p4016542.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

2012-10-28 Thread Charlie Cron

See 


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

Re: Build failed in Jenkins: fast-io-beasting #6191

2012-10-28 Thread Mark Miller


So the issue here appears to be:

[junit4:junit4]   2> 72153 T359 oasc.SolrException.log SEVERE 
null:org.apache.solr.common.SolrException: Could not get shard_id for core: 
collection1
[junit4:junit4]   2> at 
org.apache.solr.cloud.ZkController.doGetShardIdProcess(ZkController.java:996)
[junit4:junit4]   2> at 
org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1054)
[junit4:junit4]   2> at 
org.apache.solr.core.CoreContainer.register(CoreContainer.java:657)
[junit4:junit4]   2> at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:530)
[junit4:junit4]   2> at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:351)

Sami, any chance you are around to look into this?

- Mark



On 10/28/2012 09:05 PM, Charlie Cron wrote:

See 

--
[...truncated 13491 lines...]
[junit4:junit4]   2> 89052 T359 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 89053 T359 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 89055 T432 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 89055 T432 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaa09ba0c0006 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> 89347 T404 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 89368 T418 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 89368 T418 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaa09ba0c0005 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> 89448 T405 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 89448 T359 oaz.ZooKeeper.close Session: 0x13aaa09ba0c0004 
closed
[junit4:junit4]   2> 89471 T359 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 89522 T359 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
38259
[junit4:junit4]   2> 89522 T359 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=711560962
[junit4:junit4]   2> 89523 T359 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@7402a821
[junit4:junit4]   2> 89528 T359 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> 89529 T359 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 89529 T359 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 89530 T359 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 89531 T359 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 90655 T418 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 90756 T419 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 90756 T359 oaz.ZooKeeper.close Session: 0x13aaa09ba0c0005 
closed
[junit4:junit4]   2> 90779 T359 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 90831 T359 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
50727
[junit4:junit4]   2> 90831 T359 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=2007775322
[junit4:junit4]   2> 90853 T432 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 90953 T433 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:j

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13491 lines...]
[junit4:junit4]   2> 89052 T359 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 89053 T359 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 89055 T432 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 89055 T432 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaa09ba0c0006 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> 89347 T404 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 89368 T418 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 89368 T418 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aaa09ba0c0005 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> 89448 T405 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 89448 T359 oaz.ZooKeeper.close Session: 0x13aaa09ba0c0004 
closed
[junit4:junit4]   2> 89471 T359 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 89522 T359 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
38259
[junit4:junit4]   2> 89522 T359 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=711560962
[junit4:junit4]   2> 89523 T359 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@7402a821
[junit4:junit4]   2> 89528 T359 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> 89529 T359 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 89529 T359 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 89530 T359 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 89531 T359 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 90655 T418 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 90756 T419 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 90756 T359 oaz.ZooKeeper.close Session: 0x13aaa09ba0c0005 
closed
[junit4:junit4]   2> 90779 T359 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 90831 T359 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
50727
[junit4:junit4]   2> 90831 T359 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=2007775322
[junit4:junit4]   2> 90853 T432 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:34975
[junit4:junit4]   2> 90953 T433 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 90953 T359 oaz.ZooKeeper.close Session: 0x13aaa09ba0c0006 
closed
[junit4:junit4]   2> 90976 T359 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 91043 T359 oas.SolrTestCaseJ4.tearDown ###Ending 
testDistribSearch
[junit4:junit4]   1>
/solr/collections/control_collection/leader_elect/control_shard/election/88570101439922178-127.0.0.1:49583_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:49583_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:49583/solr"}

[jira] [Commented] (SOLR-4006) Many tests on Apache Jenkins are failing with lingering threads.

2012-10-28 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-4006:
---

The good news is, I can duplicate this on my FreeBSD VM. The bad news is, I 
don't have a fix yet.

I suspect the fails started happening because of the switch to using the nio 
jetty connector. I don't think it's acceptable that I have to avoid using that 
(plus it makes one test randomly take 3 minutes rather than 3 seconds if I 
don't use it), but I'm not sure how to get around this yet.

If the hurricane does not eat me up, I'll continue trying to overcome this.

> Many tests on Apache Jenkins are failing with lingering threads.
> 
>
> Key: SOLR-4006
> URL: https://issues.apache.org/jira/browse/SOLR-4006
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>
> I think I've tracked this down to being related to the black hole.
> It seems to be a recovery call to a server that is down or something - it's 
> hanging in the connect method even though we are using a connect timeout.
> {noformat}
> Thread[RecoveryThread,5,TGRP-SyncSliceTest]
> java.net.PlainSocketImpl.socketConnect(Native Method)
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
> java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> java.net.Socket.connect(Socket.java:546)
> {noformat}

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

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

[jira] [Created] (SOLR-4006) Many tests on Apache Jenkins are failing with lingering threads.

2012-10-28 Thread Mark Miller (JIRA)

Mark Miller created SOLR-4006:
-

 Summary: Many tests on Apache Jenkins are failing with lingering 
threads.
 Key: SOLR-4006
 URL: https://issues.apache.org/jira/browse/SOLR-4006
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller


I think I've tracked this down to being related to the black hole.

It seems to be a recovery call to a server that is down or something - it's 
hanging in the connect method even though we are using a connect timeout.

{noformat}

Thread[RecoveryThread,5,TGRP-SyncSliceTest]
java.net.PlainSocketImpl.socketConnect(Native Method)
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
java.net.Socket.connect(Socket.java:546)
{noformat}

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

2012-10-28 Thread Charlie Cron

See 


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

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

2012-10-28 Thread Mark Miller (JIRA)

Mark Miller created SOLR-4005:
-

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

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13977 lines...]
[junit4:junit4]   2> 686941 T216 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa9d8483b0002, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 686941 T197 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:49533 which had sessionid 0x13aa9d8483b0004
[junit4:junit4]   2> 686941 T197 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:49604 which had sessionid 0x13aa9d8483b0006
[junit4:junit4]   2> 686941 T268 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa9d8483b0006, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 686941 T197 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:49582 which had sessionid 0x13aa9d8483b0005
[junit4:junit4]   2> 686941 T199 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 686941 T197 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 686941 T197 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
49404
[junit4:junit4]   2> 686941 T197 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=21402892
[junit4:junit4]   2> 686941 T197 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@1adc6a5
[junit4:junit4]   2> 686941 T197 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> 686941 T197 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 686941 T197 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 686941 T197 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 686941 T197 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 686941 T218 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88569889077002242-127.0.0.1:49404_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 687050 T197 oaz.ZooKeeper.close Session: 0x13aa9d8483b0002 
closed
[junit4:junit4]   2> 687050 T269 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@10713e3 name:ZooKeeperConnection 
Watcher:127.0.0.1:49386/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 687050 T217 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@f048dc name:ZooKeeperConnection 
Watcher:127.0.0.1:49386/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 687050 T231 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1bf3d77 name:ZooKeeperConnection 
Watcher:127.0.0.1:49386/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 687050 T255 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@159bc95 name:ZooKeeperConnection 
Watcher:127.0.0.1:49386/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 687050 T243 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@a37a18 name:ZooKeeperConnection 
Watcher:127.0.0.1:49386/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 687050 T231 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 687050 T269 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 687050 T243 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 687050 T217 oascc.ConnectionManager.process 
Client->ZooKeeper status change trigger but we are already closed
[junit4:junit4]   2> 687050 T255 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 687050 T217 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 687051 T197 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 687102 T197 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
49470
[junit4:junit4]   2> 687102 T197 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=31291218
[junit4:junit4]   2> 687102 T197 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@52a72a
[junit4:jun

Re: Build failed in Jenkins: slow-io-beasting #5020

2012-10-28 Thread Mark Miller

This is happening right at the start of the test - so all the nodes are 
not showing up as ready as part of the setup - before the test even starts.


I've added some test code to print the zk tree and all the current 
thread stack traces when this times out.


- Mark

On 10/28/2012 07:17 PM, Charlie Cron wrote:

See 

--
[...truncated 14006 lines...]
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58646 which had sessionid 0x13aa99d68d2
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58708 which had sessionid 0x13aa99d68d4
[junit4:junit4]   2> 690757 T303 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d2, likely server has closed 
socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T331 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d4, likely server has closed 
socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:59242 which had sessionid 0x13aa99d68d6
[junit4:junit4]   2> 690757 T355 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d6, likely server has closed 
socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58739 which had sessionid 0x13aa99d68d5
[junit4:junit4]   2> 690757 T343 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d5, likely server has closed 
socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58674 which had sessionid 0x13aa99d68d3
[junit4:junit4]   2> 690757 T284 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 690757 T317 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d3, likely server has closed 
socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 690757 T282 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
58639
[junit4:junit4]   2> 690757 T282 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=25232942
[junit4:junit4]   2> 690757 T282 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@7e4f51
[junit4:junit4]   2> 690757 T282 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> 690757 T282 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 690757 T282 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 690757 T282 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 690757 T282 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 690757 T305 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88569636220567554-127.0.0.1:58639_solr-n_00) am no 
longer a leader.
[junit4:junit4]   2> 690866 T318 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@4985d9 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected type:None 
path:null path:null type:None
[junit4:junit4]   2> 690866 T344 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@13c22b0 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected type:None 
path:null path:null type:None
[junit4:junit4]   2> 690866 T356 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1b66ab4 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected type:None 
path:null path:null type:None
[junit4:junit4]   2> 690866 T318 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T344 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T356 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T332 oascc.ConnectionManager.process Watcher 
org.apache.sol

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

2012-10-28 Thread Charlie Cron

See 


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

Re: Source Control

2012-10-28 Thread Sanne Grinovero

If Lucene was moved to use GIT, I would love that.

Not going into details now, but having used GIT for two years on other
open source projects I'm pretty sure that it makes collaboration
significantly easier. We use GitHub, but the star is GIT: GitHub makes
it easier for non-power users and is great to have but after you get
used to the command line git it's outrageously useful and I don't
actually use the github webinterface any more (but it's nice that
occasional contributors can).

Being very flexible indeed often the problem might be to find an
agreement on some consistent work flow, but that's never been a
blocker in our case as each user is free to use what he prefers on his
personal repository.

Highly recommended!

Sanne

On 28 October 2012 16:58, Dawid Weiss  wrote:
> Different toys for different boys. Everyone will have his or her
> favorite workflow, it'll be impossible to find a consensus here. As
> for me, I've tasted cvs, svn, git and other version control systems
> and I must say git is the one I like the most, although there were a
> good few cursing moments along the way.
>
> As for legal -- the maven team had to go through the same process, I
> don't think the checkbox (or its absence) was a problem.
>
> Dawid
>
> P.S. If anybody knows the equivalent of "git add -A ." (that also
> stages removed files) in svn I'd really like to know ;)
>
> On Sun, Oct 28, 2012 at 5:49 PM, Adrien Grand  wrote:
>> Hi Uwe,
>>
>> On Sun, Oct 28, 2012 at 5:25 PM, Uwe Schindler  wrote:
>>> I don't want to use GIT; HG was horrible, too!
>>
>> Why don't you like them?
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 14006 lines...]
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58646 which had sessionid 0x13aa99d68d2
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58708 which had sessionid 0x13aa99d68d4
[junit4:junit4]   2> 690757 T303 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d2, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T331 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d4, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:59242 which had sessionid 0x13aa99d68d6
[junit4:junit4]   2> 690757 T355 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d6, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58739 which had sessionid 0x13aa99d68d5
[junit4:junit4]   2> 690757 T343 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d5, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:58674 which had sessionid 0x13aa99d68d3
[junit4:junit4]   2> 690757 T284 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 690757 T317 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa99d68d3, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 690757 T282 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 690757 T282 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
58639
[junit4:junit4]   2> 690757 T282 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=25232942
[junit4:junit4]   2> 690757 T282 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@7e4f51
[junit4:junit4]   2> 690757 T282 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> 690757 T282 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 690757 T282 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 690757 T282 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 690757 T282 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 690757 T305 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88569636220567554-127.0.0.1:58639_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 690866 T318 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@4985d9 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 690866 T344 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@13c22b0 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 690866 T356 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1b66ab4 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 690866 T318 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T344 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T356 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T332 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@b57ca1 name:ZooKeeperConnection 
Watcher:127.0.0.1:58626/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 690866 T332 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 690866 T304 oascc.Connec

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

2012-10-28 Thread 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 #6178

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 12597 lines...]
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
[junit4:junit4]   2>at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:564)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:285)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   3) Thread[id=772, name=qtp1628632972-772 Acceptor1 
SelectChannelConnector@0.0.0.0:46194, state=RUNNABLE, 
group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
org.eclipse.jetty.server.nio.SelectChannelConnector.getConnection(SelectChannelConnector.java:155)
[junit4:junit4]   2>at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:929)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   4) Thread[id=770, name=qtp1628632972-770 Selector1, 
state=RUNNABLE, group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
[junit4:junit4]   2>at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:564)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:285)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   5) Thread[id=769, name=HashSessionScavenger-11, 
state=TIMED_WAITING, group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at java.lang.Object.wait(Native Method)
[junit4:junit4]   2>at 
java.util.TimerThread.mainLoop(Timer.java:509)
[junit4:junit4]   2>at java.util.TimerThread.run(Timer.java:462)
[junit4:junit4]   2>   6) Thread[id=778, 
name=TEST-BasicDistributedZk2Test.testDistribSearch-seed#[FD84871E6F70F998]-SendThread(localhost.localdomain:60440),
 state=TIMED_WAITING, group=TGRP-BasicDistributedZk2Test]
[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>   7) Thread[id=771, name=qtp1628632972-771 Acceptor0 
SelectChannelConnector@0.0.0.0:46194, state=RUNNABLE, 
group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
org.eclipse.jetty.server.nio.SelectChannelConnector.getConnection(SelectChannelConnector.java:155)
[junit4:junit4]   2>at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:929)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2> NOTE: test params are: codec=Lucene3x, 
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=zh_SG, 
timezone=Asia/Tel_Aviv
[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=81316232,total=343146496
[junit4:junit4]   2> NOTE: All tests run in this JVM: [N

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

2012-10-28 Thread 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 #5018

2012-10-28 Thread Charlie Cron

See 

Changes:

[romseygeek] SOLR-4004: Improve Javadoc for SolrPing

--
[...truncated 14045 lines...]
[junit4:junit4]   2> 28744 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 28744 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 28744 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 28760 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 28760 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 28760 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 28760 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> 28760 T115 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@c84361 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@8034b6
[junit4:junit4]   2> 28776 T109 C9 oasc.SolrDeletionPolicy.onInit 
SolrDeletionPolicy.onInit: commits:num=1
[junit4:junit4]   2>
commit{dir=BaseDirectoryWrapper(org.apache.lucene.store.SimpleFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1b5d2b2),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 28776 T109 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 28776 T109 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 0
[junit4:junit4]   2> 28791 T110 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 28791 T110 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=BaseDirectoryWrapper(org.apache.lucene.store.SimpleFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1b5d2b2),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2>
commit{dir=BaseDirectoryWrapper(org.apache.lucene.store.SimpleFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1b5d2b2),segFN=segments_2,generation=2,filenames=[_0_1.len,
 _0_0.len, segments_2, _0.inf, _0.si, _0.pst, _0.fld]
[junit4:junit4]   2> 28791 T110 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 28807 T110 C9 oass.SolrIndexSearcher. Opening 
Searcher@b91602 main
[junit4:junit4]   2> 28807 T110 C9 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.BaseDirectoryWrapper
[junit4:junit4]   2> 28807 T110 C9 oasu.DirectUpdateHandler2.commit 
end_commit_flush
[junit4:junit4]   2> 28807 T115 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@b91602 
main{StandardDirectoryReader(segments_2:3 _0(4.1):C10)}
[junit4:junit4]   2> 28807 T110 C9 UPDATE [collection1] webapp=/solr 
path=/update 
params={waitSearcher=true&wt=javabin&commit=true&softCommit=false&version=2} 
{commit=} 0 16
[junit4:junit4]   2> 28822 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=31713234
[junit4:junit4]   2> 28822 T10 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@3e574
[junit4:junit4]   2> 28822 T10 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=10,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 28822 T10 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 28822 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 28822 T10 oasu.DefaultSolrCoreState.closeIn

[jira] [Closed] (SOLR-3983) Test failure in SoftAutoCommitTest

2012-10-28 Thread Alan Woodward (JIRA)


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

Alan Woodward closed SOLR-3983.
---

Resolution: Not A Problem

Doesn't reproduce if my IDE isn't running.

> Test failure in SoftAutoCommitTest
> --
>
> Key: SOLR-3983
> URL: https://issues.apache.org/jira/browse/SOLR-3983
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 5.0
>Reporter: Alan Woodward
>Priority: Minor
>
> [junit4:junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SoftAutoCommitTest 
> -Dtests.method=testSoftAndHardCommitMaxTimeDelete 
> -Dtests.seed=170BD2F6138202CF -Dtests.slow=true -Dtests.locale=it 
> -Dtests.timezone=America/Cancun -Dtests.file.encoding=ISO-8859-1
> [junit4:junit4] FAILURE 11.1s | 
> SoftAutoCommitTest.testSoftAndHardCommitMaxTimeDelete <<<
> [junit4:junit4]> Throwable #1: java.lang.AssertionError: searcher529 
> wasn't soon enough after soft529: 1351065837489 !< 1351065837316 + 100 (fudge)
> [junit4:junit4]>  at 
> __randomizedtesting.SeedInfo.seed([170BD2F6138202CF:D0476A6B082ACF7F]:0)
> [junit4:junit4]>  at org.junit.Assert.fail(Assert.java:93)
> [junit4:junit4]>  at org.junit.Assert.assertTrue(Assert.java:43)
> [junit4:junit4]>  at 
> org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeDelete(SoftAutoCommitTest.java:256)
> 100% repeatable for me.

--
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-4004) Improve Javadoc for SolrPing

2012-10-28 Thread Alan Woodward (JIRA)


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

Alan Woodward resolved SOLR-4004.
-

   Resolution: Fixed
Fix Version/s: 5.0
   4.1

Committed, trunk: 1403109, branch4x: 1403110

Thanks Benson!

> Improve Javadoc for SolrPing
> 
>
> Key: SOLR-4004
> URL: https://issues.apache.org/jira/browse/SOLR-4004
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
>Reporter: Benson Margulies
>Assignee: Alan Woodward
> Fix For: 4.1, 5.0
>
>
> There's no text in the javadoc of SolrPing. Since it depends on a particular 
> admin request handler, it would be helpful if it explained the situation. 
> Patch to be attached.
> Since this is such a small patch, I'm dropping it here:
> {noformat}
> diff --git 
> a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java 
> b/solr/solrj/src/java/org/apache/
> index a1c6be2..4adbc41 100644
> --- a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
> +++ b/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
> @@ -28,7 +28,9 @@ import org.apache.solr.common.params.ModifiableSolrParams;
>  import org.apache.solr.common.util.ContentStream;
>  
>  /**
> - * 
> + * Verify that there is a working Solr core at the URL of a {@link 
> SolrServer}.
> + * To use this class, the solrconfig.xml for the relevant core must include 
> the
> + * request handler for /admin/ping.
>   *
>   * @since solr 1.3
>   */
> {noformat}

--
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-4004) Improve Javadoc for SolrPing

2012-10-28 Thread Alan Woodward (JIRA)


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

Alan Woodward reassigned SOLR-4004:
---

Assignee: Alan Woodward

> Improve Javadoc for SolrPing
> 
>
> Key: SOLR-4004
> URL: https://issues.apache.org/jira/browse/SOLR-4004
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
>Reporter: Benson Margulies
>Assignee: Alan Woodward
>
> There's no text in the javadoc of SolrPing. Since it depends on a particular 
> admin request handler, it would be helpful if it explained the situation. 
> Patch to be attached.
> Since this is such a small patch, I'm dropping it here:
> {noformat}
> diff --git 
> a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java 
> b/solr/solrj/src/java/org/apache/
> index a1c6be2..4adbc41 100644
> --- a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
> +++ b/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
> @@ -28,7 +28,9 @@ import org.apache.solr.common.params.ModifiableSolrParams;
>  import org.apache.solr.common.util.ContentStream;
>  
>  /**
> - * 
> + * Verify that there is a working Solr core at the URL of a {@link 
> SolrServer}.
> + * To use this class, the solrconfig.xml for the relevant core must include 
> the
> + * request handler for /admin/ping.
>   *
>   * @since solr 1.3
>   */
> {noformat}

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

2012-10-28 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-2878:


{quote}
bq. I'm confused on how one uses IntervalIterator along with the Scorer it 
"belongs" to. Say I want to visit all Intervals for a given TermQuery ... do I 
first get the TermScorer and then call .intervals, up front? And then call 
TermScorer.nextDoc(), but then how to iterate over all intervals for that one 
document? EG, is the caller supposed to call IntervalIterator.scorerAdvanced 
for each next'd doc?

so my major goal here was to make this totally detached, optional and lazy ie 
no additional code in scorer except of IntervalIterator creation on demand. 
once you have a scorer you can call intervals() and get an iterator. This 
instance can and should be reused while docs are collected / scored / matched 
on a given reader. For each doc I need to iterate over intervals I call 
scorerAdvanced and update the internal structures this prevents any additional 
work if it is not really needed ie. on a complex query/scorer tree. Once the 
iterator is setup (scorerAdvanced is called) you can just call next() on it in 
a loop --> while ((interval = iter.next) != null) and get all the intervals. 
makes sense?
{quote}

OK so it sounds like I pull one IntervalIterator up front (and use it
for the whole time), and it's my job to call .scorerAdvanced(docID)
every time I either .nextDoc or .advance the original Scorer?  Ie this
"resets" my IntervalIterator onto the current doc's intervals.

bq. I think the scorer#interval method javadoc make this clear, no? if not I 
should make it clear!

I was still confused :)  I'll take a stab at improving it ... also we
should add @experimental...

{quote}
bq. I'm also confused why TermIntervalIterator.collect only collects one 
interval (I think?). Shouldn't it collect all intervals for the current doc?

the collect method is special. It's an interface that allows to collect the 
"current" interval or all "current" intervals that contributed to a higher 
level interval. For each next call you should call collect if you need all the 
subtrees intervals or the leaves. one usecase where we do this right now is 
highlighing. you can highlight based on phrases ie. if you collect on a BQ or 
you can do individual terms ie. collect leaves. makes sense?
{quote}

Ahhh  so it visits all intervals in the query tree leading up to
the current match interval (of the top query) that you've iterated to?
OK.  Maybe we can find a better name ... can't think of one now :)


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

[jira] [Updated] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans

2012-10-28 Thread Michael McCandless (JIRA)


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

Michael McCandless updated LUCENE-2878:
---

Attachment: LUCENE-2878.patch

This is what I had in mind to remove PostingFeatures.isProximityFeature (it's 
only used in one place...).

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

2012-10-28 Thread Alan Woodward (JIRA)


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

Alan Woodward updated SOLR-1972:


Attachment: SOLR-1972_metrics.patch

In this patch, the scope name is generated from a static AtomicLong (which is 
basically what Shawn suggested a few days ago before I tried to be clever :-).

All tests pass

> 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

what's up, doc?

2012-10-28 Thread Benson Margulies

Folks,

I'm going to go out on an egotistical limb and ask you all if you
would consider making me a committer based on my slow but steady drip
of javadoc patches.

If you don't, I'll still keep tossing in patches.

My experience is that every time I do a round of applying myself to
Solr, I trip over some places where I wish that there was more doc,
particularly more javadoc, and by and large I can provide it.

--benson

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

[jira] [Updated] (SOLR-4004) Improve Javadoc for SolrPing

2012-10-28 Thread Benson Margulies (JIRA)


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

Benson Margulies updated SOLR-4004:
---

Description: 
There's no text in the javadoc of SolrPing. Since it depends on a particular 
admin request handler, it would be helpful if it explained the situation. Patch 
to be attached.

Since this is such a small patch, I'm dropping it here:

{noformat}
diff --git 
a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java 
b/solr/solrj/src/java/org/apache/
index a1c6be2..4adbc41 100644
--- a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
+++ b/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
@@ -28,7 +28,9 @@ import org.apache.solr.common.params.ModifiableSolrParams;
 import org.apache.solr.common.util.ContentStream;
 
 /**
- * 
+ * Verify that there is a working Solr core at the URL of a {@link SolrServer}.
+ * To use this class, the solrconfig.xml for the relevant core must include the
+ * request handler for /admin/ping.
  *
  * @since solr 1.3
  */
{noformat}



  was:
There's no text in the javadoc of SolrPing. Since it depends on a particular 
admin request handler, it would be helpful if it explained the situation. Patch 
to be attached.



> Improve Javadoc for SolrPing
> 
>
> Key: SOLR-4004
> URL: https://issues.apache.org/jira/browse/SOLR-4004
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
>Reporter: Benson Margulies
>
> There's no text in the javadoc of SolrPing. Since it depends on a particular 
> admin request handler, it would be helpful if it explained the situation. 
> Patch to be attached.
> Since this is such a small patch, I'm dropping it here:
> {noformat}
> diff --git 
> a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java 
> b/solr/solrj/src/java/org/apache/
> index a1c6be2..4adbc41 100644
> --- a/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
> +++ b/solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java
> @@ -28,7 +28,9 @@ import org.apache.solr.common.params.ModifiableSolrParams;
>  import org.apache.solr.common.util.ContentStream;
>  
>  /**
> - * 
> + * Verify that there is a working Solr core at the URL of a {@link 
> SolrServer}.
> + * To use this class, the solrconfig.xml for the relevant core must include 
> the
> + * request handler for /admin/ping.
>   *
>   * @since solr 1.3
>   */
> {noformat}

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

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

[jira] [Created] (SOLR-4004) Improve Javadoc for SolrPing

2012-10-28 Thread Benson Margulies (JIRA)

Benson Margulies created SOLR-4004:
--

 Summary: Improve Javadoc for SolrPing
 Key: SOLR-4004
 URL: https://issues.apache.org/jira/browse/SOLR-4004
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
Reporter: Benson Margulies


There's no text in the javadoc of SolrPing. Since it depends on a particular 
admin request handler, it would be helpful if it explained the situation. Patch 
to be attached.


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

Are the Solr BCD field types still supported?

2012-10-28 Thread Jack Krupansky

I was going through the Solr field types and ran across the “BCD” field types. 
They are not mentioned in the Solr Schema wiki and have no Javadoc. Are they 
really supported anymore? Should they be deprecated? They are NOT marked as 
“legacy” field types.

If they are to be supported, will anybody add doc for them?? As hossman 
comments on SOLR-2935: “(FYI: As someone who has never even remotely understood 
the point of the BCD*Field classes, I left those docs blank)”

See:
https://issues.apache.org/jira/browse/SOLR-2935

I could guess why there are there, but with the newer trie fields, they seem an 
unnecessary holdover.

I have a slightly similar question about support for the “ByteField” and 
“ShortField” field type. I mean, if it wasn’t important enough to include trie 
field types for them, are they really needed/supported anymore? They also are 
NOT marked as “legacy” field types. They are not on the schema wiki or in the 
example schema either.

-- Jack Krupansky

Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.

2012-10-28 Thread Mark Bennett

+1  !!!

Also a BIG +1 for leaving the old logic around.

I've been discussing this with a client, on behalf of their clients.
They're fine with the slower speed, and they need the option of lower
percentage matches, which they combine with other business logic, to insure
acceptable matches.

***My fear is that the deprecated stuff then later goes away completely in
subsequent releases.  This would actually prevent them from upgrading
further (without patches, etc)***

Is it now the case that if the parser sees a floating point number 0.0 to
1.0 it uses the older/slower code, whereas just ~ or ~(integer) uses the
new code?

They also prefer the percent match syntax, though I realize that's a
different issue.

--
Mark Bennett / New Idea Engineering, Inc. / mbenn...@ideaeng.com
Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513

On Thu, Sep 13, 2012 at 7:31 PM, Yonik Seeley  wrote:

> On Thu, Sep 13, 2012 at 6:41 PM, Jack Krupansky 
> wrote:
> > I would argue that
> > SlowFuzzyQuery should be un-deprecated and moved from sandbox back into
> > Lucene proper since it does have value in SOME cases. Actually, I would
> > argue that it should be recombined with "fast" FuzzyQuery (joined at the
> hip
> > as it were) and simply document that if you use a max edit distance > 2
> then
> > it will be "slow".
>
> +1
> Sounds reasonable to me.
>
> -Yonik
> http://lucidworks.com
>
> -
> 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 #6155

2012-10-28 Thread 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 #6154

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 24164 lines...]
[junit4:junit4]   2> 112510 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 112512 T18 oasc.SolrCore.closeSearcher [collection3] 
Closing main searcher on request.
[junit4:junit4]   2> 112512 T18 oasc.SolrCore.close [awholynewcollection_0]  
CLOSING SolrCore org.apache.solr.core.SolrCore@73c4390a
[junit4:junit4]   2> 112513 T18 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> 112514 T18 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 112514 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 112514 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 112515 T18 oasc.SolrCore.closeSearcher 
[awholynewcollection_0] Closing main searcher on request.
[junit4:junit4]   2> 112516 T18 oasc.SolrCore.close [awholynewcollection_1]  
CLOSING SolrCore org.apache.solr.core.SolrCore@57e75713
[junit4:junit4]   2> 112527 T18 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> 112528 T18 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 112528 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 112529 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 112530 T18 oasc.SolrCore.closeSearcher 
[awholynewcollection_1] Closing main searcher on request.
[junit4:junit4]   2> 112530 T18 oasc.SolrCore.close [awholynewcollection_3]  
CLOSING SolrCore org.apache.solr.core.SolrCore@2414b575
[junit4:junit4]   2> 112534 T18 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> 112534 T18 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 112535 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 112535 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 112536 T18 oasc.SolrCore.closeSearcher 
[awholynewcollection_3] Closing main searcher on request.
[junit4:junit4]   2> 112536 T18 oasc.SolrCore.close [unloadcollection3]  
CLOSING SolrCore org.apache.solr.core.SolrCore@83e591f
[junit4:junit4]   2> 112542 T18 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> 112543 T18 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 112543 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 112543 T18 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 112546 T18 oasc.SolrCore.closeSearcher [unloadcollection3] 
Closing main searcher on request.
[junit4:junit4]   2> 113562 T76 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:43304
[junit4:junit4]   2> 113609 T90 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:43304
[junit4:junit4]   2> 113610 T90 oaz.ClientCnxn$SendThread.run WARNING Session 
0x13aa8c0f0310006 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> 113663 T77 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:j

[jira] [Commented] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans

2012-10-28 Thread Simon Willnauer (JIRA)


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

Simon Willnauer commented on LUCENE-2878:
-

thanks mike for taking a look at this. It still has it's edges so every review 
is very valuable.

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

sure, I was actually thinking about this for a while though. After a day of 
playing with different ways of doing it I really asked myself why we have 2 
different docs enums and why not just one and one set of features / flags this 
would make a lot of things easier. Different discussion / progress over 
perfection..

{quote}Should we move PostingFeatures to its own source instead of hiding it
in Weight.java?{quote}

alone the same lines, sure lets move it out.


{quote}Can we put back single imports (not wildcard, eg "import
org.apache.lucene.index.*")?{quote}

yeah I saw that when I created the diff I will go over it and bring it back.

{quote}PostingFeatures is very similar to FieldInfo.IndexOptions (except the
latter does not cover payloads) ... would be nice if we could somehow
combine them ...{quote}

I agree it would be nice to unify all of this. Lets open another issue - we 
have a good set of usecases now.

{quote} I'm confused on how one uses IntervalIterator along with the Scorer it
"belongs" to. Say I want to visit all Intervals for a given TermQuery
... do I first get the TermScorer and then call .intervals, up front?
And then call TermScorer.nextDoc(), but then how to iterate over all
intervals for that one document? EG, is the caller supposed to call
IntervalIterator.scorerAdvanced for each next'd doc?{quote}

so my major goal here was to make this totally detached, optional and lazy ie 
no additional code in scorer except of IntervalIterator creation on demand. 
once you have a scorer you can call intervals() and get an iterator. This 
instance can and should be reused while docs are collected / scored / matched 
on a given reader. For each doc I need to iterate over intervals I call 
scorerAdvanced and update the internal structures this prevents any additional 
work if it is not really needed ie. on a complex query/scorer tree. Once the 
iterator is setup (scorerAdvanced is called) you can just call next() on it in 
a loop --> while ((interval = iter.next) != null) and get all the intervals. 
makes sense?

{quote}Or ... am I supposed to call .intervals() after each .nextDoc() (but
that looks rather costly/wasteful since it's a newly alloc'd
TermIntervalIterator each time).{quote}

no that is not what you should do. I think the scorer#interval method javadoc 
make this clear, no? if not I should make it clear!

{quote} I'm also confused why TermIntervalIterator.collect only collects one
interval (I think?). Shouldn't it collect all intervals for the
current doc?{quote}

the collect method is special. It's an interface that allows to collect the 
"current" interval or all "current" intervals that contributed to a higher 
level interval. For each next call you should call collect if you need all the 
subtrees intervals or the leaves. one usecase where we do this right now is 
highlighing. you can highlight based on phrases ie. if you collect on a BQ or 
you can do individual terms ie. collect leaves. makes sense?

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

[jira] [Commented] (SOLR-1028) Automatic core loading unloading for multicore

2012-10-28 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-1028:
---

Kind of an aside to this specific issue, but in relation to all of these 
massive number of SolrCore issues: I'm not sure what I think about all this 
multi-core work if it's not going to jive with SolrCloud. Trying to develop 
Solr as two different systems is too costly in the long term IMO. My feeling 
has been that we would push away from the std mode and always run in SolrCloud 
mode eventually - it's just a matter of waiting until it's ready. And so 
introducing a lot of new work and code that is not compatible with SolrCloud 
makes me think.

A lot of the ugly warts that are left now are around because we are straddling 
two different ways of doing things. The path that makes it all much nicer 
involves narrowing down to one way of doing things I think. 

Not quite the right place for the discussion here, but probably one that we 
should have.

> Automatic core loading unloading for multicore
> --
>
> Key: SOLR-1028
> URL: https://issues.apache.org/jira/browse/SOLR-1028
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Noble Paul
>Assignee: Erick Erickson
> Fix For: 4.1
>
> Attachments: SOLR-1028.patch
>
>
> usecase: I have many small cores (say one per user) on a single Solr box . 
> All the cores are not be always needed . But when I need it I should be able 
> to directly issue a search request and the core must be STARTED automatically 
> and the request must be served.
> This also requires that I must have an upper limit on the no:of cores that 
> should be loaded at any given point in time. If the limit is crossed the 
> CoreContainer must unload a core (preferably the least recently used core)  
> There must be a choice of specifying some cores as fixed. These cores must 
> never be unloaded 

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

2012-10-28 Thread 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-1028) Automatic core loading unloading for multicore

2012-10-28 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-1028:
--

Here are the comments I _meant_ to include.

1> implementa loadOnStartup (default true) as a  attribute. Causes the 
core to be loaded when Solr starts, just like it does now.
2> implements swappable (default false) as a  attribute. Allows Solr 
to automatically unload the core if it runs out of room in a (new) LRU core 
list.
3> implements a swappableCacheSize attribute for  (default unlimited) 
for how large the list of "swappable" cores can grow to before they're closed 
and swapped out.
4> Wraps a bunch of exceptions in CoreContainer into a SolrException (as per 
comments in that code).
5> persists these two new  attributes. 
6> persists the swappableCacheSize attribute of  if set.

All the tests run, so it'll be interesting to see what the build machine 
thinks. In all its forms.

The cost of this functionality in the usual case (i.e. for current users) is, I 
believe, only a single check in CoreContainer.getCore when the core name isn't 
already found in the usual" list.


> Automatic core loading unloading for multicore
> --
>
> Key: SOLR-1028
> URL: https://issues.apache.org/jira/browse/SOLR-1028
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Noble Paul
>Assignee: Erick Erickson
> Fix For: 4.1
>
> Attachments: SOLR-1028.patch
>
>
> usecase: I have many small cores (say one per user) on a single Solr box . 
> All the cores are not be always needed . But when I need it I should be able 
> to directly issue a search request and the core must be STARTED automatically 
> and the request must be served.
> This also requires that I must have an upper limit on the no:of cores that 
> should be loaded at any given point in time. If the limit is crossed the 
> CoreContainer must unload a core (preferably the least recently used core)  
> There must be a choice of specifying some cores as fixed. These cores must 
> never be unloaded 

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13925 lines...]
[junit4:junit4]   2> 27554 T10 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 27554 T10 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351446615875\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351446615875\solr\collection12\collection1\data\
[junit4:junit4]   2> 27554 T10 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 27554 T10 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351446615875\solr\collection12\collection1\data\index/
[junit4:junit4]   2> 27554 T10 oasc.SolrCore.initIndex WARNING [collection1] 
Solr index directory 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351446615875\solr\collection12\collection1\data\index'
 doesn't exist. Creating new index...
[junit4:junit4]   2> 27554 T10 oasc.CachingDirectoryFactory.get return new 
directory for 

 forceNew:false
[junit4:junit4]   2> 27585 T10 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=1
[junit4:junit4]   2>
commit{dir=BaseDirectoryWrapper(org.apache.lucene.store.SimpleFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@30b601),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 27585 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 27585 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 27585 T10 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 27585 T10 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 27585 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 27585 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 27585 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 27601 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 27617 T10 oass.SolrIndexSearcher. Opening 
Searcher@1f55cae main
[junit4:junit4]   2> 27617 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.BaseDirectoryWrapper
[junit4:junit4]   2> 27617 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 27617 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 27617 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 27617 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 27632 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 27632 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 27632 T115 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@1f55cae 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 27632 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13818 lines...]
[junit4:junit4]   2> 32509 T10 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
[junit4:junit4]   2> 32509 T10 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12
[junit4:junit4]   2> 32509 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for deduced Solr Home: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\'
[junit4:junit4]   2> 32556 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init()
[junit4:junit4]   2> 32556 T10 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
[junit4:junit4]   2> 32556 T10 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12
[junit4:junit4]   2> 32556 T10 oasc.CoreContainer$Initializer.initialize 
looking for solr.xml: 

[junit4:junit4]   2> 32556 T10 oasc.CoreContainer. New CoreContainer 
4188490
[junit4:junit4]   2> 32556 T10 oasc.CoreContainer$Initializer.initialize no 
solr.xml file found - using default
[junit4:junit4]   2> 32556 T10 oasc.CoreContainer.load Loading CoreContainer 
using Solr Home: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\'
[junit4:junit4]   2> 32556 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\'
[junit4:junit4]   2> 32587 T10 oasc.CoreContainer.load Registering Log Listener
[junit4:junit4]   2> 32619 T10 oasc.CoreContainer.create Creating SolrCore 
'collection1' using instanceDir: 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\collection1
[junit4:junit4]   2> 32619 T10 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\collection1\'
[junit4:junit4]   2> 32681 T10 oasc.SolrConfig. Using Lucene 
MatchVersion: LUCENE_41
[junit4:junit4]   2> 32775 T10 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
[junit4:junit4]   2> 32775 T10 oass.IndexSchema.readSchema Reading Solr Schema
[junit4:junit4]   2> 32775 T10 oass.IndexSchema.readSchema Schema name=test
[junit4:junit4]   2> 32821 T10 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 32821 T10 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\collection1\data\
[junit4:junit4]   2> 32821 T10 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 32821 T10 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\collection1\data\index/
[junit4:junit4]   2> 32821 T10 oasc.SolrCore.initIndex WARNING [collection1] 
Solr index directory 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351445679807\solr\collection12\collection1\data\index'
 doesn't exist. Creating new index...
[junit4:junit4]   2> 32821 T10 oasc.CachingDirectoryFactory.get return new 
directory for 

 forceNew:false
[junit4:junit4]   2> 32837 T10 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@601f3f; 
maxCacheMB=0.78125 
maxMergeSizeMB=0.0380859375)),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 32837 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 32837 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 32837 T10 oasc.RequestHandlers.initHandlersFr

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

2012-10-28 Thread 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 #6143

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13408 lines...]
[junit4:junit4]   2> 674313 T548 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 674313 T548 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 674315 T548 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 674614 T593 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:47300
[junit4:junit4]   2> 674715 T594 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 674715 T548 oaz.ZooKeeper.close Session: 0x13aa85725a60004 
closed
[junit4:junit4]   2> 674726 T548 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 674777 T548 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
35853
[junit4:junit4]   2> 674777 T548 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1750813966
[junit4:junit4]   2> 675507 T605 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:47300
[junit4:junit4]   2> 675608 T606 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 675608 T548 oaz.ZooKeeper.close Session: 0x13aa85725a60005 
closed
[junit4:junit4]   2> 675630 T548 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 675682 T548 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
44954
[junit4:junit4]   2> 675682 T548 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1996393755
[junit4:junit4]   2> 675682 T548 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@682f78a8
[junit4:junit4]   2> 675692 T548 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=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 675692 T548 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 675693 T548 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 675693 T548 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 675694 T548 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 676290 T617 oaz.ClientCnxn$SendThread.startConnect Opening 
socket connection to server localhost.localdomain/127.0.0.1:47300
[junit4:junit4]   2> 676391 T618 oaz.ClientCnxn$EventThread.run EventThread 
shut down
[junit4:junit4]   2> 676391 T548 oaz.ZooKeeper.close Session: 0x13aa85725a60006 
closed
[junit4:junit4]   2> 676412 T548 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 676487 T548 oas.SolrTestCaseJ4.tearDown ###Ending 
testDistribSearch
[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/88568234934403074-127.0.0.1:53134_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:53134_solr",
[junit4:junit4]   1>"base_url":"http://127.0.0.1:53134/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:42048_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:42048_solr",
[junit4:junit4]   1> "base_url":"http://127.0.0.1:42048/solr";,
[junit4:junit4]   1>

[jira] [Updated] (SOLR-1028) Automatic core loading unloading for multicore

2012-10-28 Thread Erick Erickson (JIRA)


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

Erick Erickson updated SOLR-1028:
-

Attachment: SOLR-1028.patch

Patch attached. This will subsume SOLR-880, keeping them separate was more 
trouble than it was worth.

I'd like to commit this to trunk real soon now and let it bake a while before 
merging into 4.x. At least let it bake until after 4.0.1 or 4.1 (whatever) is 
cut.

> Automatic core loading unloading for multicore
> --
>
> Key: SOLR-1028
> URL: https://issues.apache.org/jira/browse/SOLR-1028
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Noble Paul
>Assignee: Erick Erickson
> Fix For: 4.1
>
> Attachments: SOLR-1028.patch
>
>
> usecase: I have many small cores (say one per user) on a single Solr box . 
> All the cores are not be always needed . But when I need it I should be able 
> to directly issue a search request and the core must be STARTED automatically 
> and the request must be served.
> This also requires that I must have an upper limit on the no:of cores that 
> should be loaded at any given point in time. If the limit is crossed the 
> CoreContainer must unload a core (preferably the least recently used core)  
> There must be a choice of specifying some cores as fixed. These cores must 
> never be unloaded 

--
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: Source Control

2012-10-28 Thread Dawid Weiss

Different toys for different boys. Everyone will have his or her
favorite workflow, it'll be impossible to find a consensus here. As
for me, I've tasted cvs, svn, git and other version control systems
and I must say git is the one I like the most, although there were a
good few cursing moments along the way.

As for legal -- the maven team had to go through the same process, I
don't think the checkbox (or its absence) was a problem.

Dawid

P.S. If anybody knows the equivalent of "git add -A ." (that also
stages removed files) in svn I'd really like to know ;)

On Sun, Oct 28, 2012 at 5:49 PM, Adrien Grand  wrote:
> Hi Uwe,
>
> On Sun, Oct 28, 2012 at 5:25 PM, Uwe Schindler  wrote:
>> I don't want to use GIT; HG was horrible, too!
>
> Why don't you like them?
>
> --
> Adrien
>
> -
> 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: Source Control

2012-10-28 Thread Adrien Grand

Hi Uwe,

On Sun, Oct 28, 2012 at 5:25 PM, Uwe Schindler  wrote:
> I don't want to use GIT; HG was horrible, too!

Why don't you like them?

-- 
Adrien

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

2012-10-28 Thread Charlie Cron

See 


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

RE: Source Control

2012-10-28 Thread Uwe Schindler

I don't want to use GIT; HG was horrible, too!

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Mark Miller [mailto:markrmil...@gmail.com]
> Sent: Saturday, October 27, 2012 1:02 AM
> To: dev@lucene.apache.org
> Subject: Source Control
> 
> So, it's not everyone's favorite tool, but it sure seems to be the most 
> popular
> tool.
> 
> What are peoples thoughts about moving to git?
> 
> Distributed version control is where it's at :)
> 
> I know some prefer mercurial, but git and github clearly are taking over the
> world.
> 
> Also, the cmd line for git is a little eccentric - I use a GUI client called 
> SmartGit.
> Some very clever German's make it.
> 
> A few Apache projects are already using git.
> 
> I'd like to hear what people feel about this idea.
> 
> - Mark
> -
> 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: Source Control

2012-10-28 Thread Jack Krupansky

Can we put a notice on the github page that essentially says “ownership of any 
code committed to this repo is implicitly transferred to ASF”?

-- Jack Krupansky

From: Mark Miller 
Sent: Sunday, October 28, 2012 12:01 PM
To: dev@lucene.apache.org 
Subject: Re: Source Control

This has come up in discussion at the ASF. I think a couple people thought the 
check box was critical. I think some higher level people said that is bs. The 
important part still comes down to the committer committing code that has been 
properly contributed. You don't need a checkbox for that, and it's no guarantee 
for that.

So I don't know the various workflows that have been worked out (a handful of 
projects are already using git at apache), but I don't think the check box 
thing is a huge issue over the long term.

Some projects are still attaching patches to JIRA for git though. Would have to 
investigate to see how far any of these projects have evolved beyond that. 
Since we don't have something like github to act as a pull request coordinator 
(that I know of), perhaps things are not much better yet. But based on 
discussion I've seen, I think things could get better.

At the least, I know we get emails about pull requests from github already - 
and it's probably easy to pull from their to an Apache git repo. You could 
probably avoid a patch pretty easily. Just have to discover what the current 
rules are with the 'pilot' projects.

- Mark

On Oct 28, 2012, at 8:04 AM, Shai Erera  wrote:

  What I wish we could do is to truly collaborate on these branches. For 
instance, when we create a feature branch today (following an issue), then 
people are free to commit changes to the branch, without worrying about 
breaking the main branch or nightly builds. When it's time, the changes will be 
merged to the main branch. But what we lack today is true collaboration -- 
allow all those involved to commit changes to the branch, thereby creating a 
healthier collaboration atmosphere. When the main people involved are 
committers, this is not so felt, but if the main people involved are 
non-committers, it's not so fun (to them mostly).

  Yet, I don't think that it can work otherwise, from the legal side. When 
people post patches in JIRA, there's a little checkbox that they need to tick, 
granting the ASF rights for this code. There's no checkbox to tick when changes 
are committed (well, since committers sign an agreement with the ASF about code 
rights, there's like a virtual tiny checkbox that they tick at commit time).

  So, and without me being a lawyer or anything (!), how would that work if we 
move to GIT? If we don't allow other people to commit to "feature branches", 
because there might be code licensing issues, what will be the advantage of 
moving to GIT?

  I'm asking because IMO if we cannot do that (let non-committers commit to 
feature branches), there's no strong reason to move away from SVN. We all know 
it, feel comfortable with it, and what's most important -- it does the job that 
we need.

  Shai

  But throughout the development of a feature, it'd be great if we can let all 
those involved to commit freely to the branch, without going through patches. 
Is that possible with our current SVN setup (or can we modify it)? Is that 

  On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner  
wrote:

Am 28.10.12 10:57, schrieb Robert Muir: 

  On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
wrote:

I also had/have quite some trouble to get used to the git commandline,
although or maybe because I used SVN commandline for many years, but I 
am
very glad now to be using git on other projects, because in particular 
the
process in being able to do feature based branches with git helps so 
much,
that I think it's definitely worth the price.

  There's no one on this planet that can convince me git is technically 
better.

I am not talking about "technically better" (or maybe I misunderstand this 
term), but
I am talking about "process". With git I can do the following:

- Basically for every change (even in case it might just be a typo inside 
documentation) I am creating a branch (which I can a "feature" branch)
- I can share these branches easily with other people even if they don't 
have commit/push access to the master branch and hence collaborate
- I can merge branches easily and in particular merge the master branch 
into my feature branches, and hence keep my feature branches in sync, which 
greatly simplies merging later on into the master branch
- I can commit stuff without having to be online, which is great when doing 
several steps on the code, e.g.
 - Commit one: Formatting changes
 - Commit two: Functional changes
- Because of the above I can use a RTC (ReviewThenCommit) process, because 
"others" can commit to feature branches, where I can review the code changes 
and after successful review commit/

Re: [JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3346 - Still Failing

2012-10-28 Thread Dawid Weiss

> I got another hang (heartbeat in ""), but i couldnt use
> jstack (access denied, even as root!) on the forked jvm. the other

We observed something like this a few times on FreeBSD. Might be a JVM
issue, hard to tell. I'm testing a hung shutdown hook and it passes on
all my testing environments (various JVMs, windows, linux). Might be
something entirely different too... but a live JVM should respond to
jstack/ kill signal.

D.

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 479927 lines...]
[junit4:junit4]   2> 1050031 T245 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:50577 which had sessionid 0x13aa81b3d080003
[junit4:junit4]   2> 1050031 T247 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 1050031 T278 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa81b3d080003, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 1050031 T245 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 1050031 T245 oasc.ChaosMonkey.monkeyLog monkey: stop 
shard! 50539
[junit4:junit4]   2> 1050031 T245 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=21770149
[junit4:junit4]   2> 1050031 T245 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@1b0a038
[junit4:junit4]   2> 1050031 T245 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=35881,adds=35881,deletesById=17662,deletesByQuery=0,errors=0,cumulative_adds=35881,cumulative_deletesById=17662,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 1050031 T245 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 1050031 T245 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 1050031 T245 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 1050140 T279 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@b285b6 name:ZooKeeperConnection 
Watcher:127.0.0.1:50523/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 1050140 T265 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@114069b name:ZooKeeperConnection 
Watcher:127.0.0.1:50523/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 1050140 T338 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@13c470b name:ZooKeeperConnection 
Watcher:127.0.0.1:50523/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 1050140 T279 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 1050140 T265 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 1050140 T338 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 1050494 T245 C13 P50539 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@8a8b07; 
maxCacheMB=48.0 
maxMergeSizeMB=4.0),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2>
commit{dir=NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@8a8b07; 
maxCacheMB=48.0 
maxMergeSizeMB=4.0),segFN=segments_2,generation=2,filenames=[_35t.fdx, 
_34t.fdt, _35t.fdt, _34t.fnm, _1c9_1.del, _2zo_Lucene40_0.prx, _2pe_1.del, 
_2kb.fnm, _1c9.fnm, _2zo.fnm, _34t_nrm.cfe, _34t_Lucene40_0.tim, 
_34t_Lucene40_0.tip, _35r.fdx, _35r.fdt, _1c9.si, _35u.si, _34t_nrm.cfs, 
_35r_Lucene40_0.prx, _35q.fnm, _35v_nrm.cfs, _35t.si, _35u_Lucene40_0.prx, 
_2kb.fdx, _35q.si, _2kb.fdt, _35q_Lucene40_0.prx, _35u_nrm.cfe, 
_1c9_Lucene40_0.frq, _34t_1.del, _2uk.si, _2uk_Lucene40_0.frq, _34t.fdx, 
_35t_Lucene40_0.tim, _35t.fnm, _35u_Lucene40_0.frq, _35t_Lucene40_0.tip, 
_35s_nrm.cfs, _35v_Lucene40_0.prx, _2zo_1.del, _2kb_Lucene40_0.frq, 
_35q_Lucene40_0.frq, _35v.fdx, _35s_nrm.cfe, _35v.fdt, _2zo_nrm.cfs, 
_34t_Lucene40_0.frq, _2uk_1.del, _2kb_nrm.cfe, _35q.fdx, _2zo_Lucene40_0.frq, 
_35t_Lucene40_0.prx, _35q.fdt, _2zo.fdx, _2zo_nrm.cfe, _2zo.fdt, _35r.fnm, 
_2pe.fdt, _2pe_Lucene40_0.frq, _2kb_nrm.cfs, _2pe.fdx, _35u_Lucene40_0.tip, 
_2kb.si, _2pe_Lucene40_0.tip, _2uk.fdx, _35u_Lucene40_0.tim, _35u.fnm, 
_2uk_Lucene40_0.tip, _2pe_Lucene40_0.tim, _1c9.fdt, _2kb_Lucene40_0.tip, 
_2uk.fdt, _1c9.fdx, _35v_Lucene40_0.tip, _35t_Lucene40_0.frq, 
_1c9_Lucene40_0.prx, _35v_Lucene40_0.tim, _35q_nrm.cfs, _35r_Lucene40_0.tip, 
_35s_Lucene40_0

Re: Build failed in Jenkins: fast-io-beasting #6138

2012-10-28 Thread Mark Miller

I tried raising the timeout a bit here since this seems to be intermittent.

On Oct 28, 2012, at 12:08 PM, Charlie Cron  wrote:

> See 
> 
> --
> [...truncated 13310 lines...]
> [junit4:junit4]   2> 87794 T10 oazs.FinalRequestProcessor.shutdown shutdown 
> of request processor complete
> [junit4:junit4]   2> 87794 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
> 46093
> [junit4:junit4]   2> 87795 T10 oasc.CoreContainer.shutdown Shutting down 
> CoreContainer instance=1371706360
> [junit4:junit4]   2> 87796 T10 oasc.SolrCore.close [collection1]  CLOSING 
> SolrCore org.apache.solr.core.SolrCore@1f635484
> [junit4:junit4]   2> 87796 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> 87797 T10 oasc.SolrCore.decrefSolrCoreState Closing 
> SolrCoreState
> [junit4:junit4]   2> 87797 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
> SolrCoreState ref count has reached 0 - closing IndexWriter
> [junit4:junit4]   2> 87798 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
> closing IndexWriter with IndexWriterCloser
> [junit4:junit4]   2> 87799 T10 oasc.SolrCore.closeSearcher [collection1] 
> Closing main searcher on request.
> [junit4:junit4]   2> 87801 T32 oasc.Overseer$ClusterStateUpdater.amILeader 
> According to ZK I (id=88567990930702338-127.0.0.1:46093_solr-n_00) am 
> no longer a leader.
> [junit4:junit4]   2> 87889 T83 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@7b8353cf 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87890 T83 oascc.ConnectionManager.process zkClient has 
> disconnected
> [junit4:junit4]   2> 87890 T109 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@758c3b7 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87890 T109 oascc.ConnectionManager.process zkClient has 
> disconnected
> [junit4:junit4]   2> 87892 T69 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@62a34b91 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87892 T10 oaz.ZooKeeper.close Session: 0x13aa81e55e50002 
> closed
> [junit4:junit4]   2> 87892 T31 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1edfbb43 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87892 T69 oascc.ConnectionManager.process zkClient has 
> disconnected
> [junit4:junit4]   2> 87893 T45 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@58dcdffc 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87893 T57 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@7331f919 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87894 T45 oascc.ConnectionManager.process zkClient has 
> disconnected
> [junit4:junit4]   2> 87893 T31 oascc.ConnectionManager.process 
> Client->ZooKeeper status change trigger but we are already closed
> [junit4:junit4]   2> 87894 T97 oascc.ConnectionManager.process Watcher 
> org.apache.solr.common.cloud.ConnectionManager@fe14de0 
> name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> [junit4:junit4]   2> 87894 T31 oaz.ClientCnxn$EventThread.run EventThread 
> shut down
> [junit4:junit4]   2> 87895 T97 oascc.ConnectionManager.process zkClient has 
> disconnected
> [junit4:junit4]   2> 87895 T57 oascc.ConnectionManager.process zkClient has 
> disconnected
> [junit4:junit4]   2> 87914 T10 oejsh.ContextHandler.doStop stopped 
> o.e.j.s.ServletContextHandler{/solr,null}
> [junit4:junit4]   2> 87967 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
> 48747
> [junit4:junit4]   2> 87968 T10 oasc.CoreContainer.shutdown Shutting down 
> CoreContainer instance=336575420
> [junit4:junit4]   2> 87968 T10 oasc.SolrCore.close [collection1]  CLOSING 
> SolrCore org.apache.solr.core.SolrCore@134683c0
> [junit4:junit4]   2> 87969 T10 oasu.DirectUpdateHandler2.clos

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

2012-10-28 Thread Charlie Cron

See 


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

[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 27 - Still Failing

2012-10-28 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/27/

No tests ran.

Build Log:
[...truncated 30432 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease
 [copy] Copying 396 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene
 [copy] Copying 4 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene/changes
  [get] Getting: http://people.apache.org/keys/group/lucene.asc
  [get] To: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene/KEYS
 [copy] Copying 189 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr
 [copy] Copying 1 file to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr
 [copy] Copying 4 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr/changes
 [exec] NOTE: output encoding is US-ASCII
 [exec] 
 [exec] Load release URL 
"file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/"...
 [exec] 
 [exec] Test Lucene...
 [exec]   test basics...
 [exec]   get KEYS
 [exec] 0.1 MB
 [exec]   check changes HTML...
 [exec]   download lucene-5.0.0-src.tgz...
 [exec] 26.2 MB
 [exec] verify md5/sha1 digests
 [exec]   download lucene-5.0.0.tgz...
 [exec] 47.2 MB
 [exec] verify md5/sha1 digests
 [exec]   download lucene-5.0.0.zip...
 [exec] 56.5 MB
 [exec] verify md5/sha1 digests
 [exec]   unpack lucene-5.0.0.tgz...
 [exec] verify JAR/WAR metadata...
 [exec] test demo with 1.6...
 [exec]   got 5273 hits for query "lucene"
 [exec] test demo with 1.7...
 [exec]   got 5273 hits for query "lucene"
 [exec] check Lucene's javadoc JAR
 [exec]   unpack lucene-5.0.0.zip...
 [exec] verify JAR/WAR metadata...
 [exec] test demo with 1.6...
 [exec]   got 5273 hits for query "lucene"
 [exec] test demo with 1.7...
 [exec]   got 5273 hits for query "lucene"
 [exec] check Lucene's javadoc JAR
 [exec]   unpack lucene-5.0.0-src.tgz...
 [exec] make sure no JARs/WARs in src dist...
 [exec] run "ant validate"
 [exec] run tests w/ Java 6...
 [exec] test demo with 1.6...
 [exec]   got 202 hits for query "lucene"
 [exec] generate javadocs w/ Java 6...
 [exec] run tests w/ Java 7...
 [exec] test demo with 1.7...
 [exec]   got 202 hits for query "lucene"
 [exec] generate javadocs w/ Java 7...
 [exec] 
 [exec] Crawl/parse...
 [exec] Traceback (most recent call last):
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1342, in 
 [exec] main()
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1288, in main
 [exec] smokeTest(baseURL, version, tmpDir, isSigned)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1324, in smokeTest
 [exec] unpackAndVerify('lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, version)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 563, in unpackAndVerify
 [exec] verifyUnpacked(project, artifact, unpackPath, version, tmpDir)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 673, in verifyUnpacked
 [exec] checkJavadocpathFull('%s/build/docs' % unpackPath)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 854, in checkJavadocpathFull
 [exec] if checkJavadocLinks.checkAll(path):
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/checkJavadocLinks.py",
 line 160, in checkAll
 [exec] allFiles[fullPath] = parse(fullPath, open('%s/%s' % (root, f), 
encoding='UTF-8').read())
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/checkJavadocLinks.py",
 line 110, in parse
 [exec] parser.feed(html)
 [exec]   File "/usr/local/lib/python3.2/html/parser.py", line 142, in feed
 [exec] self.goahead(0)
 [exec]   File "/usr/local/lib/python3.2/html/parser.py", line 188, in 
goahead
 [exec] k = self

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13310 lines...]
[junit4:junit4]   2> 87794 T10 oazs.FinalRequestProcessor.shutdown shutdown of 
request processor complete
[junit4:junit4]   2> 87794 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
46093
[junit4:junit4]   2> 87795 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1371706360
[junit4:junit4]   2> 87796 T10 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@1f635484
[junit4:junit4]   2> 87796 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> 87797 T10 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 87797 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 87798 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 87799 T10 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 87801 T32 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88567990930702338-127.0.0.1:46093_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 87889 T83 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@7b8353cf 
name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 87890 T83 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 87890 T109 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@758c3b7 name:ZooKeeperConnection 
Watcher:127.0.0.1:54501/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 87890 T109 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 87892 T69 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@62a34b91 
name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 87892 T10 oaz.ZooKeeper.close Session: 0x13aa81e55e50002 
closed
[junit4:junit4]   2> 87892 T31 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1edfbb43 
name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 87892 T69 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 87893 T45 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@58dcdffc 
name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 87893 T57 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@7331f919 
name:ZooKeeperConnection Watcher:127.0.0.1:54501/solr got event WatchedEvent 
state:Disconnected type:None path:null path:null type:None
[junit4:junit4]   2> 87894 T45 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 87893 T31 oascc.ConnectionManager.process 
Client->ZooKeeper status change trigger but we are already closed
[junit4:junit4]   2> 87894 T97 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@fe14de0 name:ZooKeeperConnection 
Watcher:127.0.0.1:54501/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 87894 T31 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 87895 T97 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 87895 T57 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 87914 T10 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 87967 T10 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
48747
[junit4:junit4]   2> 87968 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=336575420
[junit4:junit4]   2> 87968 T10 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@134683c0
[junit4:junit4]   2> 87969 T10 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>

Re: Source Control

2012-10-28 Thread Mark Miller

This has come up in discussion at the ASF. I think a couple people thought the 
check box was critical. I think some higher level people said that is bs. The 
important part still comes down to the committer committing code that has been 
properly contributed. You don't need a checkbox for that, and it's no guarantee 
for that.

So I don't know the various workflows that have been worked out (a handful of 
projects are already using git at apache), but I don't think the check box 
thing is a huge issue over the long term.

Some projects are still attaching patches to JIRA for git though. Would have to 
investigate to see how far any of these projects have evolved beyond that. 
Since we don't have something like github to act as a pull request coordinator 
(that I know of), perhaps things are not much better yet. But based on 
discussion I've seen, I think things could get better.

At the least, I know we get emails about pull requests from github already - 
and it's probably easy to pull from their to an Apache git repo. You could 
probably avoid a patch pretty easily. Just have to discover what the current 
rules are with the 'pilot' projects.

- Mark

On Oct 28, 2012, at 8:04 AM, Shai Erera  wrote:

> What I wish we could do is to truly collaborate on these branches. For 
> instance, when we create a feature branch today (following an issue), then 
> people are free to commit changes to the branch, without worrying about 
> breaking the main branch or nightly builds. When it's time, the changes will 
> be merged to the main branch. But what we lack today is true collaboration -- 
> allow all those involved to commit changes to the branch, thereby creating a 
> healthier collaboration atmosphere. When the main people involved are 
> committers, this is not so felt, but if the main people involved are 
> non-committers, it's not so fun (to them mostly).
> 
> Yet, I don't think that it can work otherwise, from the legal side. When 
> people post patches in JIRA, there's a little checkbox that they need to 
> tick, granting the ASF rights for this code. There's no checkbox to tick when 
> changes are committed (well, since committers sign an agreement with the ASF 
> about code rights, there's like a virtual tiny checkbox that they tick at 
> commit time).
> 
> So, and without me being a lawyer or anything (!), how would that work if we 
> move to GIT? If we don't allow other people to commit to "feature branches", 
> because there might be code licensing issues, what will be the advantage of 
> moving to GIT?
> 
> I'm asking because IMO if we cannot do that (let non-committers commit to 
> feature branches), there's no strong reason to move away from SVN. We all 
> know it, feel comfortable with it, and what's most important -- it does the 
> job that we need.
> 
> Shai
> 
> But throughout the development of a feature, it'd be great if we can let all 
> those involved to commit freely to the branch, without going through patches. 
> Is that possible with our current SVN setup (or can we modify it)? Is that 
> 
> On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner  
> wrote:
> Am 28.10.12 10:57, schrieb Robert Muir:
> 
> On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
>   wrote:
> 
> I also had/have quite some trouble to get used to the git commandline,
> although or maybe because I used SVN commandline for many years, but I am
> very glad now to be using git on other projects, because in particular the
> process in being able to do feature based branches with git helps so much,
> that I think it's definitely worth the price.
> 
> There's no one on this planet that can convince me git is technically better.
> 
> I am not talking about "technically better" (or maybe I misunderstand this 
> term), but
> I am talking about "process". With git I can do the following:
> 
> - Basically for every change (even in case it might just be a typo inside 
> documentation) I am creating a branch (which I can a "feature" branch)
> - I can share these branches easily with other people even if they don't have 
> commit/push access to the master branch and hence collaborate
> - I can merge branches easily and in particular merge the master branch into 
> my feature branches, and hence keep my feature branches in sync, which 
> greatly simplies merging later on into the master branch
> - I can commit stuff without having to be online, which is great when doing 
> several steps on the code, e.g.
>  - Commit one: Formatting changes
>  - Commit two: Functional changes
> - Because of the above I can use a RTC (ReviewThenCommit) process, because 
> "others" can commit to feature branches, where I can review the code changes 
> and after successful review commit/push to the master branch.
> 
> With SVN I couldn't do this that easily and because it wasn't easy, I didn't 
> do it. But git allowed me/us to change the process and for me personally that 
> is great.
> 
> I think the question is what process do you want and what tool

[jira] [Commented] (SOLR-1533) Partition data directories into multiple "bucket" directories

2012-10-28 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-1533:
--

I'm thinking of killing this JIRA, SOLR-1306 (which is up real soon now on my 
list) seems like it would handle this case. Having a pluggable 
CoreDescriptorProvider should allow the resident code to provide whatever 
instanceDir one wants. Since it's resident on the server, it can do whatever is 
needed to insure that the actual core directories are distributed as desired.

So I'll kill this (or, more accurately, say it's a duplicate of 1306) unless I 
there's a reason 1306 won't handle this.

> Partition data directories into multiple "bucket" directories
> -
>
> Key: SOLR-1533
> URL: https://issues.apache.org/jira/browse/SOLR-1533
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Shalin Shekhar Mangar
>Assignee: Erick Erickson
> Fix For: 4.1
>
>
> Provide a way to partition data directories into multiple "bucket" 
> directories. For example, instead of creating 10,000 data directories inside 
> one base data directory, Solr can assign a core to one of 4 base directories, 
> thereby distributing them.
> The underlying problem is that with large number of indexes, we see slower 
> and slower system performance as one goes on increasing the number of cores, 
> thereby increasing the number of directories in the single data directory.

--
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: Source Control

2012-10-28 Thread Mark Miller


On 10/28/2012 11:09 AM, Alan Woodward wrote:

We have an official git mirror for the project, though - 
git.apache.org/lucene-solr.  So if people want to use git to collaborate, they 
can clone that repository and create branches there.

I much prefer git to svn - I use staged adds, rebases and stashes all the time 
- but anyone can currently use that by setting up a git-svn bridge.  I'm not 
sure we gain anything except headaches by migrating the entire repo.

I don't agree with that! I've used the git mirror and it's a real hassle 
because then you have to jump back to svn to commit. God forbid there is 
a binary file to deal with, or moves or renames. I've done it and I 
always give it up after a while - it's too annoying. And I don't trust 
the git-svn bridge stuff - it's always got some limitations or gotchyas, 
and I just don't trust it for anything but the simplest stuff.


I've seen large svn repos moved to git, and the process seems pretty 
painless.


So I think the headache situation is the reverse :)

- Mark

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13878 lines...]
[junit4:junit4]   2> 26695 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 26695 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 26695 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 26710 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 26710 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 26710 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 26710 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> 26710 T113 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@37dde9 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@1d5d765
[junit4:junit4]   2> 26757 T112 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@552379),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 26757 T112 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 26757 T112 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 31
[junit4:junit4]   2> 26773 T109 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 26773 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@552379),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@552379),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> 26773 T109 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 26788 T109 C9 oass.SolrIndexSearcher. Opening 
Searcher@158c3b7 main
[junit4:junit4]   2> 26788 T109 C9 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 26804 T109 C9 oasu.DirectUpdateHandler2.commit 
end_commit_flush
[junit4:junit4]   2> 26804 T113 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@158c3b7 
main{StandardDirectoryReader(segments_2:3 _0(4.1):C10)}
[junit4:junit4]   2> 26804 T109 C9 UPDATE [collection1] webapp=/solr 
path=/update 
params={waitSearcher=true&wt=javabin&commit=true&softCommit=false&version=2} 
{commit=} 0 31
[junit4:junit4]   2> 26819 T10 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=23699909
[junit4:junit4]   2> 26819 T10 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@e29f36
[junit4:junit4]   2> 26819 T10 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=10,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
[junit4:junit4]   2> 26819 T10 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 26819 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 26819 T10 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]

[jira] [Assigned] (SOLR-1533) Partition data directories into multiple "bucket" directories

2012-10-28 Thread Erick Erickson (JIRA)


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

Erick Erickson reassigned SOLR-1533:


Assignee: Erick Erickson

> Partition data directories into multiple "bucket" directories
> -
>
> Key: SOLR-1533
> URL: https://issues.apache.org/jira/browse/SOLR-1533
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Shalin Shekhar Mangar
>Assignee: Erick Erickson
> Fix For: 4.1
>
>
> Provide a way to partition data directories into multiple "bucket" 
> directories. For example, instead of creating 10,000 data directories inside 
> one base data directory, Solr can assign a core to one of 4 base directories, 
> thereby distributing them.
> The underlying problem is that with large number of indexes, we see slower 
> and slower system performance as one goes on increasing the number of cores, 
> thereby increasing the number of directories in the single data directory.

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

2012-10-28 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on SOLR-1972:


After reading the documentation of {{Object.toString}} 
http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#toString() it 
seems to me that it can still break if the hashCode is overriden with an impl 
that is likely to return the same value for 2 different instances. I know this 
is very unlikely but on the other hand the bug would be very hard to track... 
so I think we should rather generate unique strings (unique a static atomic 
counter for example) to make sure timers and counters are never shared?

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

2012-10-28 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on SOLR-1972:
-

I suppose if we had two custom request handlers that both overrode it with the 
same String it could break.

How about using super.toString() instead of this.toString()?  That way it's 
always the parent Object method that's called.

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

Re: Source Control

2012-10-28 Thread Alan Woodward

We have an official git mirror for the project, though - 
git.apache.org/lucene-solr.  So if people want to use git to collaborate, they 
can clone that repository and create branches there.

I much prefer git to svn - I use staged adds, rebases and stashes all the time 
- but anyone can currently use that by setting up a git-svn bridge.  I'm not 
sure we gain anything except headaches by migrating the entire repo.

On 28 Oct 2012, at 12:38, Erick Erickson wrote:

> I don't have stropng feelings either way. If it would allow better 
> collaboration
> branch merging, etc., then sure.
> 
> I'm assuming we'd be able to do pre/post move diffs, right?.
> 
> What about reformatting at that point? It'd be one of the few times when
> we would, I think, have all the code in the repository at once. Not insisting
> on this, I've actually grown used to avoiding re-formatting too much. But it'd
> be one of the least painful moments to reformat. Not painless, mind, but
> 
> Erick
> 
> On Sun, Oct 28, 2012 at 8:04 AM, Shai Erera  wrote:
>> What I wish we could do is to truly collaborate on these branches. For
>> instance, when we create a feature branch today (following an issue), then
>> people are free to commit changes to the branch, without worrying about
>> breaking the main branch or nightly builds. When it's time, the changes will
>> be merged to the main branch. But what we lack today is true collaboration
>> -- allow all those involved to commit changes to the branch, thereby
>> creating a healthier collaboration atmosphere. When the main people involved
>> are committers, this is not so felt, but if the main people involved are
>> non-committers, it's not so fun (to them mostly).
>> 
>> Yet, I don't think that it can work otherwise, from the legal side. When
>> people post patches in JIRA, there's a little checkbox that they need to
>> tick, granting the ASF rights for this code. There's no checkbox to tick
>> when changes are committed (well, since committers sign an agreement with
>> the ASF about code rights, there's like a virtual tiny checkbox that they
>> tick at commit time).
>> 
>> So, and without me being a lawyer or anything (!), how would that work if we
>> move to GIT? If we don't allow other people to commit to "feature branches",
>> because there might be code licensing issues, what will be the advantage of
>> moving to GIT?
>> 
>> I'm asking because IMO if we cannot do that (let non-committers commit to
>> feature branches), there's no strong reason to move away from SVN. We all
>> know it, feel comfortable with it, and what's most important -- it does the
>> job that we need.
>> 
>> Shai
>> 
>> But throughout the development of a feature, it'd be great if we can let all
>> those involved to commit freely to the branch, without going through
>> patches. Is that possible with our current SVN setup (or can we modify it)?
>> Is that
>> 
>> On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner 
>> wrote:
>>> 
>>> Am 28.10.12 10:57, schrieb Robert Muir:
>>> 
 On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
   wrote:
 
> I also had/have quite some trouble to get used to the git commandline,
> although or maybe because I used SVN commandline for many years, but I
> am
> very glad now to be using git on other projects, because in particular
> the
> process in being able to do feature based branches with git helps so
> much,
> that I think it's definitely worth the price.
> 
 There's no one on this planet that can convince me git is technically
 better.
>>> 
>>> 
>>> I am not talking about "technically better" (or maybe I misunderstand this
>>> term), but
>>> I am talking about "process". With git I can do the following:
>>> 
>>> - Basically for every change (even in case it might just be a typo inside
>>> documentation) I am creating a branch (which I can a "feature" branch)
>>> - I can share these branches easily with other people even if they don't
>>> have commit/push access to the master branch and hence collaborate
>>> - I can merge branches easily and in particular merge the master branch
>>> into my feature branches, and hence keep my feature branches in sync, which
>>> greatly simplies merging later on into the master branch
>>> - I can commit stuff without having to be online, which is great when
>>> doing several steps on the code, e.g.
>>> - Commit one: Formatting changes
>>> - Commit two: Functional changes
>>> - Because of the above I can use a RTC (ReviewThenCommit) process, because
>>> "others" can commit to feature branches, where I can review the code changes
>>> and after successful review commit/push to the master branch.
>>> 
>>> With SVN I couldn't do this that easily and because it wasn't easy, I
>>> didn't do it. But git allowed me/us to change the process and for me
>>> personally that is great.
>>> 
>>> I think the question is what process do you want and what tool does make
>>> this process simple?
>>> 
>>> Maybe be

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

2012-10-28 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on SOLR-1972:


Can it break if people write custom request handlers that override toString?

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

2012-10-28 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-2878:


I'm confused on how one uses IntervalIterator along with the Scorer it
"belongs" to.  Say I want to visit all Intervals for a given TermQuery
... do I first get the TermScorer and then call .intervals, up front?
And then call TermScorer.nextDoc(), but then how to iterate over all
intervals for that one document?  EG, is the caller supposed to call
IntervalIterator.scorerAdvanced for each next'd doc?

Or ... am I supposed to call .intervals() after each .nextDoc() (but
that looks rather costly/wasteful since it's a newly alloc'd
TermIntervalIterator each time).

I'm also confused why TermIntervalIterator.collect only collects one
interval (I think?).  Shouldn't it collect all intervals for the
current doc?


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

2012-10-28 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on SOLR-1972:
-

The toString() is sort of a randomly-generated string, really.  It's the 
default Object toString, ie a class name and a memory address.

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

2012-10-28 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-2878:


I'm still trying to catch up here (net/net this looks awesome!), but
here's some minor stuff I noticed:

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

Should we move PostingFeatures to its own source instead of hiding it
in Weight.java?

Can we put back single imports (not wildcard, eg "import
org.apache.lucene.index.*")?

PostingFeatures is very similar to FieldInfo.IndexOptions (except the
latter does not cover payloads) ... would be nice if we could somehow
combine them ...


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

Typo in _version_ error message

2012-10-28 Thread Jack Krupansky

The _version_ error message is missing a space between _version_ and “field”:

Oct 28, 2012 10:24:34 AM org.apache.solr.update.UpdateLog init
SEVERE: Unable to use updateLog: _version_field must exist in schema, using 
indexed="true" stored="true" and multiValued="false" (_version_ does not exist)

This is in 4.0.0.

-- Jack Krupansky

[jira] [Resolved] (LUCENE-3319) Cut over remaining queries to provide PositionIterators

2012-10-28 Thread Simon Willnauer (JIRA)


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

Simon Willnauer resolved LUCENE-3319.
-

Resolution: Fixed

tracked in the toplevel issue and resolved except of MultiPhraseQuery

> Cut over remaining queries to provide PositionIterators
> ---
>
> Key: LUCENE-3319
> URL: https://issues.apache.org/jira/browse/LUCENE-3319
> Project: Lucene - Core
>  Issue Type: Sub-task
>  Components: core/search
>Affects Versions: Positions Branch
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: Positions Branch
>
>
> most queries already providing positions but some are still missing. This 
> issue / subtask will track progress along those lines.

--
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-880) SolrCore should have a a lazy startup option

2012-10-28 Thread Erick Erickson (JIRA)


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

Erick Erickson resolved SOLR-880.
-

Resolution: Duplicate

This functionality will be part of SOLR-1028, which will be checked in shortly.

> SolrCore should have a a lazy startup option
> 
>
> Key: SOLR-880
> URL: https://issues.apache.org/jira/browse/SOLR-880
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
>Reporter: Noble Paul
>Assignee: Erick Erickson
> Attachments: SOLR-880.patch, SOLR-880.patch
>
>
> * a core should have an option of loadOnStartup=true|false. default should be 
> true
> If there are too many cores (tens of thousands) where each of them may be 
> used occassionally, we should not load all of them at once. In the runtime I 
> should be able to STOP and START a core on demand. A listing command would 
> let me know which one is present and what is up and what is down. A stopped 
> core must not use any resource

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

2012-10-28 Thread 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 #4991

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13902 lines...]
[junit4:junit4]   2> 30038 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 30053 T10 oass.SolrIndexSearcher. Opening 
Searcher@605b1e main
[junit4:junit4]   2> 30053 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 30053 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 30053 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 30053 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 30053 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 30069 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 30069 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 30069 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 30069 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> 30069 T119 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@605b1e 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@db5b3f
[junit4:junit4]   2> 30116 T109 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@1dc6a9d),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 30131 T109 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 30163 T109 C9 UPDATE [collection1] webapp=/solr 
path=/update params={wt=javabin&version=2} {add=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]} 
0 78
[junit4:junit4]   2> 30178 T116 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 30225 T116 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@1dc6a9d),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@1dc6a9d),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> 30225 T116 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 2
[junit4:junit4]   2> 30241 T116 C9 oass.SolrIndexSearcher. Opening 
Searcher@e634bf main
[junit4:junit4]   2> 30241 T116 C9 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 30241 T116 C9 oasu.DirectUpdateHandler2.commit 
end_com

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13823 lines...]
[junit4:junit4]   2> 29933 T10 oass.IndexSchema.readSchema unique key field: id
[junit4:junit4]   2> 29933 T10 oasc.SolrCore. [collection1] Opening new 
SolrCore at 
.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351431804443\solr\collection12\collection1\,
 
dataDir=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351431804443\solr\collection12\collection1\data\
[junit4:junit4]   2> 29933 T10 oasc.SolrCore. JMX monitoring not detected 
for core: collection1
[junit4:junit4]   2> 29933 T10 oasc.SolrCore.getNewIndexDir New index directory 
detected: old=null 
new=.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351431804443\solr\collection12\collection1\data\index/
[junit4:junit4]   2> 29933 T10 oasc.SolrCore.initIndex WARNING [collection1] 
Solr index directory 
'.\org.apache.solr.client.solrj.TestLBHttpSolrServer$SolrInstance-1351431804443\solr\collection12\collection1\data\index'
 doesn't exist. Creating new index...
[junit4:junit4]   2> 29933 T10 oasc.CachingDirectoryFactory.get return new 
directory for 

 forceNew:false
[junit4:junit4]   2> 29948 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@1c0adca),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 29948 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 29948 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 29948 T10 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 29948 T10 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 29948 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 29948 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 29948 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 29980 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 30011 T10 oass.SolrIndexSearcher. Opening 
Searcher@10704e1 main
[junit4:junit4]   2> 30011 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 30026 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 30026 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 30026 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 30026 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 30042 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 30042 T113 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@10704e1 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> 30042 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 30042 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2>

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13817 lines...]
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.NIOFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@e8fdc9),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 27671 T10 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 27671 T10 oasc.RequestHandlers.initHandlersFromConfig 
created standard: solr.StandardRequestHandler
[junit4:junit4]   2> 27671 T10 oasc.RequestHandlers.initHandlersFromConfig 
created defaults: solr.StandardRequestHandler
[junit4:junit4]   2> 27671 T10 oasc.RequestHandlers.initHandlersFromConfig 
adding lazy requestHandler: solr.StandardRequestHandler
[junit4:junit4]   2> 27671 T10 oasc.RequestHandlers.initHandlersFromConfig 
created lazy: solr.StandardRequestHandler
[junit4:junit4]   2> 27671 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /update: solr.UpdateRequestHandler
[junit4:junit4]   2> 27671 T10 oasc.RequestHandlers.initHandlersFromConfig 
created /replication: solr.ReplicationHandler
[junit4:junit4]   2> 27686 T10 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
[junit4:junit4]   2> 27702 T10 oass.SolrIndexSearcher. Opening 
Searcher@17e4cec main
[junit4:junit4]   2> 27702 T10 oass.SolrIndexSearcher.getIndexDir WARNING 
WARNING: Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
[junit4:junit4]   2> 27702 T10 oasu.CommitTracker. Hard AutoCommit: 
disabled
[junit4:junit4]   2> 27702 T10 oasu.CommitTracker. Soft AutoCommit: 
disabled
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maximumPoolSize to: 2147483647
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting maxThreadIdleTime to: 5
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting sizeOfQueue to: -1
[junit4:junit4]   2> 27702 T10 oashc.HttpShardHandlerFactory.getParameter 
Setting fairnessPolicy to: false
[junit4:junit4]   2> 27702 T10 oascsi.HttpClientUtil.createClient Creating new 
http client, 
config:maxConnectionsPerHost=20&maxConnections=1&socketTimeout=0&connTimeout=0&retry=false
[junit4:junit4]   2> 27717 T10 oash.ReplicationHandler.inform Commits will be 
reserved for  1
[junit4:junit4]   2> 27717 T10 oasc.CoreContainer.register registering core: 
collection1
[junit4:junit4]   2> 27717 T10 oass.SolrDispatchFilter.init 
user.dir=
[junit4:junit4]   2> 27717 T10 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init() done
[junit4:junit4]   2> 27733 T115 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@17e4cec 
main{StandardDirectoryReader(segments_1:1)}
[junit4:junit4]   2> ASYNC  NEW_CORE C9 name=collection1 
org.apache.solr.core.SolrCore@742397
[junit4:junit4]   2> 27733 T111 C9 oasc.SolrDeletionPolicy.onInit 
SolrDeletionPolicy.onInit: commits:num=1
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.NIOFSDirectory@
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@e8fdc9),segFN=segments_1,generation=1,filenames=[segments_1]
[junit4:junit4]   2> 27733 T111 C9 oasc.SolrDeletionPolicy.updateCommits newest 
commit = 1
[junit4:junit4]   2> 27749 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 16
[junit4:junit4]   2> 27764 T114 C9 oasu.DirectUpdateHandler2.commit start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
[junit4:junit4]   2> 27764 T114 C9 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits:num=2
[junit4:junit4]   2>
commit{dir=MockDirWrapper(org.apache.lucene.store.NIOFSDirectory@

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

2012-10-28 Thread 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 #6121

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 13484 lines...]
[junit4:junit4]   2> 752 T81 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 753 T81 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 753 T81 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 754 T81 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 7222536 T135 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:42588
[junit4:junit4]   2> 7222537 T135 oaz.ClientCnxn$SendThread.run WARNING Session 
0x0 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> 7222740 T108 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> 7222740 T81 oaz.ZooKeeper.close Session: 0x13aa71790c20007 
closed
[junit4:junit4]   2> 7222741 T108 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server localhost.localdomain/127.0.0.1:42588
[junit4:junit4]   2> 7222741 T85 oazs.SyncRequestProcessor.run 
SyncRequestProcessor exited!
[junit4:junit4]   2> 7222742 T81 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 7222788 T81 oazs.FinalRequestProcessor.shutdown shutdown 
of request processor complete
[junit4:junit4]   2> 7222788 T81 oas.SolrTestCaseJ4.tearDown ###Ending 
testSimpleSliceLeaderElection
[junit4:junit4]   2> 7222796 T81 oas.SolrTestCaseJ4.setUp ###Starting 
testLeaderElectionAfterClientTimeout
[junit4:junit4]   2> Creating dataDir: 

[junit4:junit4]   2> 7222797 T81 oasc.ZkTestServer.run STARTING ZK TEST SERVER
[junit4:junit4]   2> 7222799 T137 oazs.ZooKeeperServer.setTickTime tickTime set 
to 1000
[junit4:junit4]   2> 7222799 T137 oazs.NIOServerCnxn$Factory. binding to 
port 0.0.0.0/0.0.0.0:0
[junit4:junit4]   2> 7222800 T137 oazsp.FileTxnSnapLog.save Snapshotting: 0
[junit4:junit4]   2> 7222898 T81 oasc.ZkTestServer.run start zk server on 
port:50537
[junit4:junit4]   2> 7222898 T81 oaz.ZooKeeper. Initiating client 
connection, connectString=127.0.0.1:50537 sessionTimeout=1 
watcher=org.apache.solr.common.cloud.ConnectionManager@6fa053d5
[junit4:junit4]   2> 7222899 T142 oaz.ClientCnxn$SendThread.startConnect 
Opening socket connection to server /127.0.0.1:50537
[junit4:junit4]   2> 7222901 T142 oaz.ClientCnxn$SendThread.primeConnection 
Socket connection established to localhost.localdomain/127.0.0.1:50537, 
initiating session
[junit4:junit4]   2> 7222901 T138 oazs.NIOServerCnxn$Factory.run Accepted 
socket connection from /127.0.0.1:43376
[junit4:junit4]   2> 7222901 T81 oascc.ConnectionManager.waitForConnected 
Waiting for client to connect to ZooKeeper
[junit4:junit4]   2> 7222901 T138 oazs.NIOServerCnxn.readConnectRequest Client 
attempting to establish new session at /127.0.0.1:43376
[junit4:junit4]   2> 7222902 T140 oazsp.FileTxnLog.append Creating new log 
file: log.1
[junit4:junit4]   2> 7222906 T140 oazs.NIOServerCnxn.finishSessionInit 
Established session 0x13aa785c674 with negotiated timeout 1 for client 
/127.0.0.1:43376
[junit4:junit4]   2> 7222906 T142 oaz.ClientCnxn$SendThread.readConnectResult 
Session establishment complete on server localhost.localdomain/127.0.0.1:50537, 
sessionid = 0x13aa785c674, negotiated timeout = 1
[junit4:junit4]   2> 7222907 T143 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@6fa053d5 
name:ZooKeeperConnection Watcher:127.0.0.1:50537 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
[junit4:junit4]   2> 7222907 T81 oascc.ConnectionManager.waitForConnected 
Client is connected to ZooKeeper
[junit4:junit4]   2> 7222908 T81 oascc.SolrZkClient.makePath makePath: /solr
[junit4:junit4]   2> 7222913 T141 oazs.PrepRequestProcessor.pRequest Processed 
session termination for sessionid: 0x13aa785c674
[ju

Re: Source Control

2012-10-28 Thread Erick Erickson

I don't have stropng feelings either way. If it would allow better collaboration
branch merging, etc., then sure.

I'm assuming we'd be able to do pre/post move diffs, right?.

What about reformatting at that point? It'd be one of the few times when
we would, I think, have all the code in the repository at once. Not insisting
on this, I've actually grown used to avoiding re-formatting too much. But it'd
be one of the least painful moments to reformat. Not painless, mind, but

Erick

On Sun, Oct 28, 2012 at 8:04 AM, Shai Erera  wrote:
> What I wish we could do is to truly collaborate on these branches. For
> instance, when we create a feature branch today (following an issue), then
> people are free to commit changes to the branch, without worrying about
> breaking the main branch or nightly builds. When it's time, the changes will
> be merged to the main branch. But what we lack today is true collaboration
> -- allow all those involved to commit changes to the branch, thereby
> creating a healthier collaboration atmosphere. When the main people involved
> are committers, this is not so felt, but if the main people involved are
> non-committers, it's not so fun (to them mostly).
>
> Yet, I don't think that it can work otherwise, from the legal side. When
> people post patches in JIRA, there's a little checkbox that they need to
> tick, granting the ASF rights for this code. There's no checkbox to tick
> when changes are committed (well, since committers sign an agreement with
> the ASF about code rights, there's like a virtual tiny checkbox that they
> tick at commit time).
>
> So, and without me being a lawyer or anything (!), how would that work if we
> move to GIT? If we don't allow other people to commit to "feature branches",
> because there might be code licensing issues, what will be the advantage of
> moving to GIT?
>
> I'm asking because IMO if we cannot do that (let non-committers commit to
> feature branches), there's no strong reason to move away from SVN. We all
> know it, feel comfortable with it, and what's most important -- it does the
> job that we need.
>
> Shai
>
> But throughout the development of a feature, it'd be great if we can let all
> those involved to commit freely to the branch, without going through
> patches. Is that possible with our current SVN setup (or can we modify it)?
> Is that
>
> On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner 
> wrote:
>>
>> Am 28.10.12 10:57, schrieb Robert Muir:
>>
>>> On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
>>>   wrote:
>>>
 I also had/have quite some trouble to get used to the git commandline,
 although or maybe because I used SVN commandline for many years, but I
 am
 very glad now to be using git on other projects, because in particular
 the
 process in being able to do feature based branches with git helps so
 much,
 that I think it's definitely worth the price.

>>> There's no one on this planet that can convince me git is technically
>>> better.
>>
>>
>> I am not talking about "technically better" (or maybe I misunderstand this
>> term), but
>> I am talking about "process". With git I can do the following:
>>
>> - Basically for every change (even in case it might just be a typo inside
>> documentation) I am creating a branch (which I can a "feature" branch)
>> - I can share these branches easily with other people even if they don't
>> have commit/push access to the master branch and hence collaborate
>> - I can merge branches easily and in particular merge the master branch
>> into my feature branches, and hence keep my feature branches in sync, which
>> greatly simplies merging later on into the master branch
>> - I can commit stuff without having to be online, which is great when
>> doing several steps on the code, e.g.
>>  - Commit one: Formatting changes
>>  - Commit two: Functional changes
>> - Because of the above I can use a RTC (ReviewThenCommit) process, because
>> "others" can commit to feature branches, where I can review the code changes
>> and after successful review commit/push to the master branch.
>>
>> With SVN I couldn't do this that easily and because it wasn't easy, I
>> didn't do it. But git allowed me/us to change the process and for me
>> personally that is great.
>>
>> I think the question is what process do you want and what tool does make
>> this process simple?
>>
>> Maybe before argueing SVN versus git you should specify how you want to
>> collaborate and also specify requirements (as for example you point ou below
>> about speed). Once you have a clear picture about this, then consider the
>> various tools which exist.
>>
>> HTH
>>
>> Michael
>>
>>> I've used git on projects before. Its not that i have trouble getting
>>> used to it, its command line is genuinely horrible.
>>>
>>> And svn is absurdly fast for me:
>>> rmuir@beast:~/workspace$ time svn co
>>> https://svn.apache.org/repos/asf/lucene/dev/trunk
>>> real0m23.454s
>>> user0m5.712s
>>> sys

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

2012-10-28 Thread 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 #4985

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 25804 lines...]
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.FieldAnalysisRequestHandlerTest
[junit4:junit4] Completed on J3 in 2.65s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.JsonLoaderTest
[junit4:junit4] Completed on J7 in 2.57s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
[junit4:junit4] Completed on J2 in 2.68s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest
[junit4:junit4] Completed on J0 in 2.43s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
[junit4:junit4] Completed on J6 in 2.51s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.DirectUpdateHandlerOptimizeTest
[junit4:junit4] Completed on J4 in 2.75s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest
[junit4:junit4] Completed on J3 in 2.43s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterWFSTTest
[junit4:junit4] Completed on J5 in 4.12s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.CopyFieldTest
[junit4:junit4] Completed on J7 in 1.87s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.NotRequiredUniqueKeyTest
[junit4:junit4] Completed on J7 in 0.89s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest
[junit4:junit4] Completed on J4 in 2.45s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.search.TestQueryUtils
[junit4:junit4] Completed on J2 in 3.21s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.UpdateParamsTest
[junit4:junit4] Completed on J3 in 2.56s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.component.BadComponentTest
[junit4:junit4] Completed on J3 in 1.69s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.handler.admin.ShowFileRequestHandlerTest
[junit4:junit4] Completed on J5 in 4.55s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
[junit4:junit4] Completed on J2 in 2.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTSTTest
[junit4:junit4] Completed on J0 in 5.16s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.internal.csv.CSVPrinterTest
[junit4:junit4] Completed on J3 in 1.22s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest
[junit4:junit4] Completed on J5 in 1.56s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.SOLR749Test
[junit4:junit4] Completed on J2 in 1.64s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest
[junit4:junit4] Completed on J4 in 3.97s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest
[junit4:junit4] Completed on J7 in 4.80s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.OutputWriterTest
[junit4:junit4] Completed on J4 in 0.61s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.TestNumberUtils
[junit4:junit4] Completed on J7 in 0.16s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestQuerySenderListener
[junit4:junit4] Completed on J3 in 1.67s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.EchoParamsTest
[junit4:junit4] Completed on J3 in 0.77s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.SolrIndexConfigTest
[junit4:junit4] Completed on J5 in 1.84s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.schema.MultiTermTest
[junit4:junit4] Completed on J4 in 1.09s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.update.processor.DefaultValueUpdateProcessorTest
[junit4:junit4] Completed on J0 in 4.18s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestConfig
[junit4:junit4] Completed on J7 in 1.78s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestDFRSimilarityFactory
[junit4:junit4] Completed on J5 in 0.63s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery
[junit4:junit4] Completed on J2 in 2.60s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.core.TestCodecSupport
[junit4:junit4] Completed on J0 in 0.42s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.solr.search.similarities.TestIBSimilarityFactory
[junit4:junit4] Completed on J4 in 0.58s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.TimeZoneUtilsTest
[junit4:junit4] Completed on J7 in 0.22s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.util.DateMathP

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

2012-10-28 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on SOLR-1972:


In that case could we use something else than the string representation as a 
scope? (like a randomly-generated string that is unique across 
RequestHandlerBase instances?)

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

Re: Source Control

2012-10-28 Thread Shai Erera

What I wish we could do is to truly collaborate on these branches. For
instance, when we create a feature branch today (following an issue), then
people are free to commit changes to the branch, without worrying about
breaking the main branch or nightly builds. When it's time, the changes
will be merged to the main branch. But what we lack today is true
collaboration -- allow all those involved to commit changes to the branch,
thereby creating a healthier collaboration atmosphere. When the main people
involved are committers, this is not so felt, but if the main people
involved are non-committers, it's not so fun (to them mostly).

Yet, I don't think that it can work otherwise, from the legal side. When
people post patches in JIRA, there's a little checkbox that they need to
tick, granting the ASF rights for this code. There's no checkbox to tick
when changes are committed (well, since committers sign an agreement with
the ASF about code rights, there's like a virtual tiny checkbox that they
tick at commit time).

So, and without me being a lawyer or anything (!), how would that work if
we move to GIT? If we don't allow other people to commit to "feature
branches", because there might be code licensing issues, what will be the
advantage of moving to GIT?

I'm asking because IMO if we cannot do that (let non-committers commit to
feature branches), there's no strong reason to move away from SVN. We all
know it, feel comfortable with it, and what's most important -- it does the
job that we need.

Shai

But throughout the development of a feature, it'd be great if we can let
all those involved to commit freely to the branch, without going through
patches. Is that possible with our current SVN setup (or can we modify it)?
Is that

On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner
wrote:

> Am 28.10.12 10:57, schrieb Robert Muir:
>
>  On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
>>   wrote:
>>
>>  I also had/have quite some trouble to get used to the git commandline,
>>> although or maybe because I used SVN commandline for many years, but I am
>>> very glad now to be using git on other projects, because in particular
>>> the
>>> process in being able to do feature based branches with git helps so
>>> much,
>>> that I think it's definitely worth the price.
>>>
>>>  There's no one on this planet that can convince me git is technically
>> better.
>>
>
> I am not talking about "technically better" (or maybe I misunderstand this
> term), but
> I am talking about "process". With git I can do the following:
>
> - Basically for every change (even in case it might just be a typo inside
> documentation) I am creating a branch (which I can a "feature" branch)
> - I can share these branches easily with other people even if they don't
> have commit/push access to the master branch and hence collaborate
> - I can merge branches easily and in particular merge the master branch
> into my feature branches, and hence keep my feature branches in sync, which
> greatly simplies merging later on into the master branch
> - I can commit stuff without having to be online, which is great when
> doing several steps on the code, e.g.
>  - Commit one: Formatting changes
>  - Commit two: Functional changes
> - Because of the above I can use a RTC (ReviewThenCommit) process, because
> "others" can commit to feature branches, where I can review the code
> changes and after successful review commit/push to the master branch.
>
> With SVN I couldn't do this that easily and because it wasn't easy, I
> didn't do it. But git allowed me/us to change the process and for me
> personally that is great.
>
> I think the question is what process do you want and what tool does make
> this process simple?
>
> Maybe before argueing SVN versus git you should specify how you want to
> collaborate and also specify requirements (as for example you point ou
> below about speed). Once you have a clear picture about this, then consider
> the various tools which exist.
>
> HTH
>
> Michael
>
>  I've used git on projects before. Its not that i have trouble getting
>> used to it, its command line is genuinely horrible.
>>
>> And svn is absurdly fast for me:
>> rmuir@beast:~/workspace$ time svn co
>> https://svn.apache.org/repos/**asf/lucene/dev/trunk
>> real0m23.454s
>> user0m5.712s
>> sys 0m3.232s
>>
>> The speed of my internet connection makes git obselete.
>>
>> But if other people really like it, i won't stand in the way.
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@lucene.apache.**org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@lucene.apache.**org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

2012-10-28 Thread 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 #4982

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 14009 lines...]
[junit4:junit4]   2> 694989 T17 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:57720 which had sessionid 0x13aa7129a150002
[junit4:junit4]   2> 694989 T37 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa7129a150002, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 694989 T17 oazs.NIOServerCnxn.closeSock Closed socket 
connection for client /127.0.0.1:57753 which had sessionid 0x13aa7129a150004
[junit4:junit4]   2> 694989 T19 oazs.NIOServerCnxn$Factory.run NIOServerCnxn 
factory exited run method
[junit4:junit4]   2> 694989 T67 oaz.ClientCnxn$SendThread.run Unable to read 
additional data from server sessionid 0x13aa7129a150004, likely server has 
closed socket, closing socket connection and attempting reconnect
[junit4:junit4]   2> 694989 T17 oazs.FinalRequestProcessor.shutdown shutdown of 
request processor complete
[junit4:junit4]   2> 694989 T17 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
57715
[junit4:junit4]   2> 694989 T17 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=8578291
[junit4:junit4]   2> 694989 T17 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@193c366
[junit4:junit4]   2> 695005 T17 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> 695005 T17 oasc.SolrCore.decrefSolrCoreState Closing 
SolrCoreState
[junit4:junit4]   2> 695005 T17 oasu.DefaultSolrCoreState.closeIndexWriter 
SolrCoreState ref count has reached 0 - closing IndexWriter
[junit4:junit4]   2> 695005 T17 oasu.DefaultSolrCoreState.closeIndexWriter 
closing IndexWriter with IndexWriterCloser
[junit4:junit4]   2> 695005 T17 oasc.SolrCore.closeSearcher [collection1] 
Closing main searcher on request.
[junit4:junit4]   2> 695005 T39 oasc.Overseer$ClusterStateUpdater.amILeader 
According to ZK I (id=88566841023463426-127.0.0.1:57715_solr-n_00) am 
no longer a leader.
[junit4:junit4]   2> 695099 T68 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@14b03ea name:ZooKeeperConnection 
Watcher:127.0.0.1:57708/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 695099 T54 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@15da7d name:ZooKeeperConnection 
Watcher:127.0.0.1:57708/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 695099 T96 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@24c22b name:ZooKeeperConnection 
Watcher:127.0.0.1:57708/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 695099 T82 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1ea6a1c name:ZooKeeperConnection 
Watcher:127.0.0.1:57708/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 695099 T96 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 695099 T54 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 695099 T82 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 695099 T68 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 695099 T38 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@cd6aa0 name:ZooKeeperConnection 
Watcher:127.0.0.1:57708/solr got event WatchedEvent state:Disconnected 
type:None path:null path:null type:None
[junit4:junit4]   2> 695099 T17 oaz.ZooKeeper.close Session: 0x13aa7129a150002 
closed
[junit4:junit4]   2> 695099 T38 oascc.ConnectionManager.process zkClient has 
disconnected
[junit4:junit4]   2> 695099 T38 oaz.ClientCnxn$EventThread.run EventThread shut 
down
[junit4:junit4]   2> 695100 T17 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
[junit4:junit4]   2> 695154 T17 oasc.ChaosMonkey.monkeyLog monkey: stop shard! 
57724
[junit4:junit4]   2> 695154 T17 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=7281109
[junit4:junit4]   2> 695154 T17 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@1408325
[junit4:junit4]   2> 695161 T17 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=

Re: Source Control

2012-10-28 Thread Michael Wechner


Am 28.10.12 10:57, schrieb Robert Muir:

On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
  wrote:


I also had/have quite some trouble to get used to the git commandline,
although or maybe because I used SVN commandline for many years, but I am
very glad now to be using git on other projects, because in particular the
process in being able to do feature based branches with git helps so much,
that I think it's definitely worth the price.


There's no one on this planet that can convince me git is technically better.


I am not talking about "technically better" (or maybe I misunderstand 
this term), but

I am talking about "process". With git I can do the following:

- Basically for every change (even in case it might just be a typo 
inside documentation) I am creating a branch (which I can a "feature" 
branch)
- I can share these branches easily with other people even if they don't 
have commit/push access to the master branch and hence collaborate
- I can merge branches easily and in particular merge the master branch 
into my feature branches, and hence keep my feature branches in sync, 
which greatly simplies merging later on into the master branch
- I can commit stuff without having to be online, which is great when 
doing several steps on the code, e.g.

 - Commit one: Formatting changes
 - Commit two: Functional changes
- Because of the above I can use a RTC (ReviewThenCommit) process, 
because "others" can commit to feature branches, where I can review the 
code changes and after successful review commit/push to the master branch.


With SVN I couldn't do this that easily and because it wasn't easy, I 
didn't do it. But git allowed me/us to change the process and for me 
personally that is great.


I think the question is what process do you want and what tool does make 
this process simple?


Maybe before argueing SVN versus git you should specify how you want to 
collaborate and also specify requirements (as for example you point ou 
below about speed). Once you have a clear picture about this, then 
consider the various tools which exist.


HTH

Michael

I've used git on projects before. Its not that i have trouble getting
used to it, its command line is genuinely horrible.

And svn is absurdly fast for me:
rmuir@beast:~/workspace$ time svn co
https://svn.apache.org/repos/asf/lucene/dev/trunk
real0m23.454s
user0m5.712s
sys 0m3.232s

The speed of my internet connection makes git obselete.

But if other people really like it, i won't stand in the way.

-
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

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

2012-10-28 Thread Charlie Cron

See 

--
[...truncated 12597 lines...]
[junit4:junit4]   2>at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
[junit4:junit4]   2>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   2) Thread[id=355, name=qtp1507851527-355 Selector1, 
state=RUNNABLE, group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
[junit4:junit4]   2>at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:564)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:285)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   3) Thread[id=354, name=qtp1507851527-354 Selector0, 
state=RUNNABLE, group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
[junit4:junit4]   2>at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
[junit4:junit4]   2>at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
[junit4:junit4]   2>at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:564)
[junit4:junit4]   2>at 
org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:285)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   4) Thread[id=353, name=HashSessionScavenger-11, 
state=TIMED_WAITING, group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at java.lang.Object.wait(Native Method)
[junit4:junit4]   2>at 
java.util.TimerThread.mainLoop(Timer.java:509)
[junit4:junit4]   2>at java.util.TimerThread.run(Timer.java:462)
[junit4:junit4]   2>   5) Thread[id=362, 
name=TEST-BasicDistributedZk2Test.testDistribSearch-seed#[1CC8DE1026D91344]-SendThread(localhost.localdomain:54157),
 state=TIMED_WAITING, group=TGRP-BasicDistributedZk2Test]
[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>   6) Thread[id=357, name=qtp1507851527-357 Acceptor1 
SelectChannelConnector@0.0.0.0:45525, state=RUNNABLE, 
group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:951)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2>   7) Thread[id=356, name=qtp1507851527-356 Acceptor0 
SelectChannelConnector@0.0.0.0:45525, state=BLOCKED, 
group=TGRP-BasicDistributedZk2Test]
[junit4:junit4]   2>at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:951)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
[junit4:junit4]   2>at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
[junit4:junit4]   2>at java.lang.Thread.run(Thread.java:662)
[junit4:junit4]   2> NOTE: test params are: codec=SimpleText, 
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_VE, 
timezone=Etc/GMT+9
[junit4:junit4]   2> NOTE: Linux 3.2.

1 2 >

1 - 100 of 114 matches

Mail list logo