date:20121128

[jira] [Commented] (LUCENE-4569) Allow customization of column stride field and norms via indexing chain

2012-11-28 Thread Chris Male (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505294#comment-13505294
 ] 

Chris Male commented on LUCENE-4569:


John,

I don't really know much about the API you're wanting to change, but to help me 
understand are you able to explain more what you're trying to do in your custom 
indexing format / code? 

I think one of the major motivation for Codecs is to allow this sort of 
customization through their API (there is already Codecs for holding this in 
memory).

 Allow customization of column stride field and norms via indexing chain
 ---

 Key: LUCENE-4569
 URL: https://issues.apache.org/jira/browse/LUCENE-4569
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Affects Versions: 4.0
Reporter: John Wang
 Attachments: patch.diff


 We are building an in-memory indexing format and managing our own segments. 
 We are doing this by implementing a custom IndexingChain. We would like to 
 support column-stride-fields and norms without having to wire in a codec 
 (since we are managing our postings differently)
 Suggested change is consistent with the api support for passing in a custom 
 InvertedDocConsumer.

--
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-4114) Collection API: Allow multiple shards from one collection on the same Solr server

2012-11-28 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505295#comment-13505295
 ] 

Per Steffensen commented on SOLR-4114:
--

bq. As far as terminology, when I say replicationFactor of 3, I mean 3 copies 
of the data. I also count the leader as a replica of a shard (which is 
logical). It follows from the clusterstate.json, which lists all replicas for 
a shard and one of them just has a flag indicating it's the leader. This also 
makes it easier to talk about a shard having 0 replicas (meaning there is not 
even a leader).

Ok, its just than the replicationFactor you specify in your request is the 
other thing. You get replicationFactor + 1 shards per slice, if we define 
replicationFactor as the one you give in your request.

 Collection API: Allow multiple shards from one collection on the same Solr 
 server
 -

 Key: SOLR-4114
 URL: https://issues.apache.org/jira/browse/SOLR-4114
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
 Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Per Steffensen
  Labels: collection-api, multicore, shard, shard-allocation
 Attachments: SOLR-4114.patch


 We should support running multiple shards from one collection on the same 
 Solr server - the run a collection with 8 shards on a 4 Solr server cluster 
 (each Solr server running 2 shards).
 Performance tests at our side has shown that this is a good idea, and it is 
 also a good idea for easy elasticity later on - it is much easier to move an 
 entire existing shards from one Solr server to another one that just joined 
 the cluter than it is to split an exsiting shard among the Solr that used to 
 run it and the new Solr.
 See dev mailing list discussion Multiple shards for one collection on the 
 same Solr server

--
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-4114) Collection API: Allow multiple shards from one collection on the same Solr server

2012-11-28 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505296#comment-13505296
 ] 

Per Steffensen commented on SOLR-4114:
--

bq. Solr 3.X to Solr 4.X back compat is not considered the same as Solr 4.0 to 
Solr 4.1 back compat.

Of course, I agree! But anyway...

 Collection API: Allow multiple shards from one collection on the same Solr 
 server
 -

 Key: SOLR-4114
 URL: https://issues.apache.org/jira/browse/SOLR-4114
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
 Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Per Steffensen
  Labels: collection-api, multicore, shard, shard-allocation
 Attachments: SOLR-4114.patch


 We should support running multiple shards from one collection on the same 
 Solr server - the run a collection with 8 shards on a 4 Solr server cluster 
 (each Solr server running 2 shards).
 Performance tests at our side has shown that this is a good idea, and it is 
 also a good idea for easy elasticity later on - it is much easier to move an 
 entire existing shards from one Solr server to another one that just joined 
 the cluter than it is to split an exsiting shard among the Solr that used to 
 run it and the new Solr.
 See dev mailing list discussion Multiple shards for one collection on the 
 same Solr server

--
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-2141) NullPointerException when using escapeSql function

2012-11-28 Thread Dominik Siebel (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505337#comment-13505337
 ] 

Dominik Siebel commented on SOLR-2141:
--

Hi, James, sorry I already forgot about that. Thanks for the good work!

 NullPointerException when using escapeSql function
 --

 Key: SOLR-2141
 URL: https://issues.apache.org/jira/browse/SOLR-2141
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.4.1, 4.0
 Environment: openjdk 1.6.0 b12
Reporter: Edward Rudd
Assignee: James Dyer
 Fix For: 4.1, 5.0

 Attachments: dih-config.xml, dih-file.xml, SOLR-2141.b341f5b.patch, 
 SOLR-2141.patch, SOLR-2141.patch, SOLR-2141.patch, SOLR-2141.patch, 
 SOLR-2141.patch, SOLR-2141.patch, SOLR-2141-sample.patch, SOLR-2141-test.patch


 I have two entities defined, nested in each other..
 entity name=article query=select category, subcategory from articles
entity name=other query=select other from othertable where 
 category='${dataimporter.functions.escapeSql(article.category)}'
   AND 
 subcategory='${dataimporter.functions.escapeSql(article.subcategory)}'  
/entity
 /entity
 Now, when I run that it bombs on any article where subcategory = '' (it's a 
 NOT NULL column so empty string is there)  If i do where subcategory!='' in 
 the article query it works fine (aside from not pulling in all of the 
 articles).
 org.apache.solr.handler.dataimport.DataImportHandlerException: 
 java.lang.NullPointerException
 at 
 org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:424)
 at 
 org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:383)
 at 
 org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:242)
 at 
 org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:180)
 at 
 org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:331)
 at 
 org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:389)
 at 
 org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:370)
 Caused by: java.lang.NullPointerException
 at 
 org.apache.solr.handler.dataimport.EvaluatorBag$1.evaluate(EvaluatorBag.java:75)
 at 
 org.apache.solr.handler.dataimport.EvaluatorBag$5.get(EvaluatorBag.java:216)
 at 
 org.apache.solr.handler.dataimport.EvaluatorBag$5.get(EvaluatorBag.java:204)
 at 
 org.apache.solr.handler.dataimport.VariableResolverImpl.resolve(VariableResolverImpl.java:107)
 at 
 org.apache.solr.handler.dataimport.TemplateString.fillTokens(TemplateString.java:81)
 at 
 org.apache.solr.handler.dataimport.TemplateString.replaceTokens(TemplateString.java:75)
 at 
 org.apache.solr.handler.dataimport.VariableResolverImpl.replaceTokens(VariableResolverImpl.java:87)
 at 
 org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:71)
 at 
 org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:237)
 at 
 org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:357)
 ... 6 more

--
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-4115) WordBreakSpellChecker throws ArrayIndexOutOfBoundsException for random query string

2012-11-28 Thread Andreas Hubold (JIRA)

Andreas Hubold created SOLR-4115:


 Summary: WordBreakSpellChecker throws 
ArrayIndexOutOfBoundsException for random query string
 Key: SOLR-4115
 URL: https://issues.apache.org/jira/browse/SOLR-4115
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Affects Versions: 4.0
 Environment: java version 1.6.0_37
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)
Reporter: Andreas Hubold


The following SolrJ test code causes an ArrayIndexOutOfBoundsException in the 
WordBreakSpellChecker. I tested this with the Solr 4.0.0 example webapp started 
with {{java -jar start.jar}}.

{code:java}
  @Test
  public void testWordbreakSpellchecker() throws Exception {
SolrQuery q = new SolrQuery(\uD864\uDC79);
q.setRequestHandler(/browse);
q.setParam(spellcheck.dictionary, wordbreak);
HttpSolrServer server = new HttpSolrServer(http://localhost:8983/solr;);
server.query(q, SolrRequest.METHOD.POST);
  }
{code}

{noformat}
INFO: [collection1] webapp=/solr path=/browse 
params={spellcheck.dictionary=wordbreakqt=/browsewt=javabinq=?version=2} 
hits=0 status=500 QTime=11 
Nov 28, 2012 11:23:01 AM org.apache.solr.common.SolrException log
SEVERE: null:java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.lucene.util.UnicodeUtil.UTF8toUTF16(UnicodeUtil.java:599)
at org.apache.lucene.util.BytesRef.utf8ToString(BytesRef.java:165)
at org.apache.lucene.index.Term.text(Term.java:72)
at 
org.apache.lucene.search.spell.WordBreakSpellChecker.generateSuggestWord(WordBreakSpellChecker.java:350)
at 
org.apache.lucene.search.spell.WordBreakSpellChecker.generateBreakUpSuggestions(WordBreakSpellChecker.java:283)
at 
org.apache.lucene.search.spell.WordBreakSpellChecker.suggestWordBreaks(WordBreakSpellChecker.java:122)
at 
org.apache.solr.spelling.WordBreakSolrSpellChecker.getSuggestions(WordBreakSolrSpellChecker.java:229)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:172)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:455)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:900)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:954)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:857)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:662)
{noformat}

The query string

[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server

2012-11-28 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505368#comment-13505368
]

Per Steffensen commented on SOLR-4114:
--

bq. As far as terminology, when I say replicationFactor of 3, I mean 3 copies
of the data. I also count the leader as a replica of a shard (which is
logical). It follows from the clusterstate.json, which lists all replicas for
a shard and one of them just has a flag indicating it's the leader. This also
makes it easier to talk about a shard having 0 replicas (meaning there is not
even a leader).

I understand that you can view all shards under a slice as a replica, but in
my mind replica is also a role that a shard plays at runtime - all shards
except one under a slice plays the replica role at runtime, the remaining
shard play the leader role. To not create to much confusion I suggest you use
the term shards for all the instances under a slice, and that you use the term
replica only for a role that a shard plays at runtime.
But that of course would require changes e.g. to Slice-class where e.g.
getReplicas, getReplicasCopy and getReplicasMap needs to me renamed to
getShardsXXX. It probably shouldnt be done now, but as a part of a cross-code
cleaning up in term-usage.

Suggested terms:
* collection: A big logical bucket to fill data into
* slice: A logical part of a collection. A part of the data going into a
collection goes into a particular slice. Slices for a particular collection are
non-overlapping
* shard: A physical instance of a slice. Running without replica there is one
shard per slice. Running with replication-factor X there are X+1 shards per
slice.
* replica and leader: Roles played by shards at runtime. As soon as the system
is not running there are no replica/leader - there are just shards
* node-base-url: The prefix/base (up to and including the webapp-context) of
the URL for a specific Solr server
* node-name: A logical name for the Solr server - the same as node-base-url
except /'s are replaced by _'s and the protocol part (http(s)://) is removed

Collection API: Allow multiple shards from one collection on the same Solr
server
-

Key: SOLR-4114
URL: https://issues.apache.org/jira/browse/SOLR-4114
Project: Solr
Issue Type: New Feature
Components: multicore, SolrCloud
Affects Versions: 4.0
Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Per Steffensen
Labels: collection-api, multicore, shard, shard-allocation
Attachments: SOLR-4114.patch

We should support running multiple shards from one collection on the same
Solr server - the run a collection with 8 shards on a 4 Solr server cluster
(each Solr server running 2 shards).
Performance tests at our side has shown that this is a good idea, and it is
also a good idea for easy elasticity later on - it is much easier to move an
entire existing shards from one Solr server to another one that just joined
the cluter than it is to split an exsiting shard among the Solr that used to
run it and the new Solr.
See dev mailing list discussion Multiple shards for one collection on the
same Solr server

--
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-3377) eDismax: A fielded query wrapped by parens is not recognized

2012-11-28 Thread Leonhard Maylein (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505370#comment-13505370
 ] 

Leonhard Maylein commented on SOLR-3377:


I do not agree that this issue is solved.

I've tried the following combination with SOLR 4.0.0

q: +sw(a b) +ti:(c d)
qf: freitext exttext^0.5
pf: freitext^6 exttext^3

The result is:

str name=rawquerystring+sw:(a b) +ti:(c d)/str

str name=querystring+sw:(a b) +ti:(c d)/str

str name=parsedquery(+(+(sw:a sw:b) +(ti:c ti:d)) 
DisjunctionMaxQuery((freitext:b d^6.0)) DisjunctionMaxQuery((exttext:b 
d^3.0)))/no_coord/str

There should be no splitting on the qf/pf fields and therefore no 
DisjunctionMaxQueries.

The query '+(sw:a sw:b) +(ti:c ti:d)' works as expected.

 eDismax: A fielded query wrapped by parens is not recognized
 

 Key: SOLR-3377
 URL: https://issues.apache.org/jira/browse/SOLR-3377
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 3.6
Reporter: Jan Høydahl
Assignee: Yonik Seeley
Priority: Critical
 Fix For: 4.0-BETA

 Attachments: SOLR-3377.patch, SOLR-3377.patch, SOLR-3377.patch, 
 SOLR-3377.patch


 As reported by bernd on the user list, a query like this
 {{q=(name:test)}}
 will yield 0 hits in 3.6 while it worked in 3.5. It works without the parens.

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

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

[jira] [Comment Edited] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server

2012-11-28 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505368#comment-13505368
]

Per Steffensen edited comment on SOLR-4114 at 11/28/12 11:20 AM:
-

I understand that you can view all shards under a slice as a replica, but in
my mind replica is also a role that a shard plays at runtime - all shards
except one under a slice play the replica role at runtime, the remaining
shard plays the leader role at runtime. To not create to much confusion, I
suggest you use the term shards for all the instances under a slice, and that
you use the terms replica and leader only for a role that a shard plays at
runtime.
But that of course would require changes e.g. to Slice-class where e.g.
getReplicas, getReplicasCopy and getReplicasMap needs to me renamed to
getShardsXXX. It probably shouldnt be done now, but as a part of a cross-code
cleaning up in term-usage. Today there is a heavy mixup of term-usage in the
code - replica and shard are sometimes used for a node, replica and shard are
used for the same thing, etc.

was (Author: steff1193):
bq. As far as terminology, when I say replicationFactor of 3, I mean 3
copies of the data. I also count the leader as a replica of a shard (which is
logical). It follows from the clusterstate.json, which lists all replicas for
a shard and one of them just has a flag indicating it's the leader. This also
makes it easier to talk about a shard having 0 replicas (meaning there is not
even a leader).

Collection API: Allow multiple shards from one collection on the same Solr
server
-

[jira] [Commented] (SOLR-2368) Improve extended dismax (edismax) parser

2012-11-28 Thread Leonhard Maylein (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505374#comment-13505374
 ] 

Leonhard Maylein commented on SOLR-2368:


Please consider to also incorporate SOLR-3377 which is marked as fixed but it 
is not completely solved (see my comment on SOLR-3377).

 Improve extended dismax (edismax) parser
 

 Key: SOLR-2368
 URL: https://issues.apache.org/jira/browse/SOLR-2368
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Reporter: Yonik Seeley
  Labels: QueryParser

 This is a mother issue to track further improvements for eDismax parser.
 The goal is to be able to deprecate and remove the old dismax once edismax 
 satisfies all usecases of dismax.

--
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-4032) Files larger than an internal buffer size fail to replicate

2012-11-28 Thread Markus Jelsma (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505378#comment-13505378
 ] 

Markus Jelsma commented on SOLR-4032:
-

Great work, it seems this issue is resolved indeed as i cannot reproduce this 
exact problem. But another EOF exception pops up, i'll open a new issue.

 Files larger than an internal buffer size fail to replicate
 ---

 Key: SOLR-4032
 URL: https://issues.apache.org/jira/browse/SOLR-4032
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0-SNAPSHOT 1366361:1404534M - markus - 2012-11-01 
 12:37:38
 Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
Reporter: Markus Jelsma
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-4032.patch


 Please see: 
 http://lucene.472066.n3.nabble.com/trunk-is-unable-to-replicate-between-nodes-Unable-to-download-completely-td4017049.html
  and 
 http://lucene.472066.n3.nabble.com/Possible-memory-leak-in-recovery-td4017833.html

--
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-4116) Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException

2012-11-28 Thread Markus Jelsma (JIRA)

Markus Jelsma created SOLR-4116:
---

 Summary: Log Replay [recoveryExecutor-8-thread-1] - : 
java.io.EOFException
 Key: SOLR-4116
 URL: https://issues.apache.org/jira/browse/SOLR-4116
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0.0.2012.11.28.10.42.06
Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
Reporter: Markus Jelsma
 Fix For: 5.0


With SOLR-4032 fixed we see other issues when randomly taking down nodes 
(nicely via tomcat restart) while indexing a few million web pages from Hadoop. 
We do make sure that at least one node is up for a shard but due to recovery 
issues it may not be live.

{code}
2012-11-28 11:32:33,086 WARN [solr.update.UpdateLog] - 
[recoveryExecutor-8-thread-1] - : Starting log replay 
tlog{file=/opt/solr/cores/openindex_e/data/tlog/tlog.028 
refcount=2} active=false starting pos=0
2012-11-28 11:32:41,873 ERROR [solr.update.UpdateLog] - 
[recoveryExecutor-8-thread-1] - : java.io.EOFException
at 
org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:151)
at 
org.apache.solr.common.util.JavaBinCodec.readStr(JavaBinCodec.java:479)
at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:176)
at 
org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:374)
at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
at 
org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:451)
at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:182)
at 
org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:618)
at 
org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1198)
at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1143)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}



--
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-4117) IO error while trying to get the size of the Directory

2012-11-28 Thread Markus Jelsma (JIRA)

Markus Jelsma created SOLR-4117:
---

 Summary: IO error while trying to get the size of the Directory
 Key: SOLR-4117
 URL: https://issues.apache.org/jira/browse/SOLR-4117
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0.0.2012.11.28.10.42.06
Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
Reporter: Markus Jelsma
 Fix For: 5.0


With SOLR-4032 fixed we see other issues when randomly taking down nodes 
(nicely via tomcat restart) while indexing a few million web pages from Hadoop. 
We do make sure that at least one node is up for a shard but due to recovery 
issues it may not be live.

One node seems to work but generates IO errors in the log and ZookeeperExeption 
in the GUI. In the GUI we only see:
{code}

SolrCore Initialization Failures

openindex_f: 
org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException:
 

Please check your logs for more information
{code}

and in the log we only see the following exception:

{code}
2012-11-28 11:47:26,652 ERROR [solr.handler.ReplicationHandler] - 
[http-8080-exec-28] - : IO error while trying to get the size of the 
Directory:org.apache.lucene.store.NoSuchDirectoryException: directory 
'/opt/solr/cores/shard_f/data/index' does not exist
at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:217)
at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:240)
at 
org.apache.lucene.store.NRTCachingDirectory.listAll(NRTCachingDirectory.java:132)
at 
org.apache.solr.core.DirectoryFactory.sizeOfDirectory(DirectoryFactory.java:146)
at 
org.apache.solr.handler.ReplicationHandler.getIndexSize(ReplicationHandler.java:472)
at 
org.apache.solr.handler.ReplicationHandler.getReplicationDetails(ReplicationHandler.java:568)
at 
org.apache.solr.handler.ReplicationHandler.handleRequestBody(ReplicationHandler.java:213)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
at 
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:240)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1830)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:476)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:744)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}

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

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

[jira] [Comment Edited] (SOLR-4032) Files larger than an internal buffer size fail to replicate

2012-11-28 Thread Markus Jelsma (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505378#comment-13505378
 ] 

Markus Jelsma edited comment on SOLR-4032 at 11/28/12 11:51 AM:


Great work, it seems this issue is resolved indeed as i cannot reproduce this 
exact problem. But another EOF exception pops up, i'll open a new issue.
edit: another issue popped up as well, added SOLR-4116 and SOLR-4117

  was (Author: markus17):
Great work, it seems this issue is resolved indeed as i cannot reproduce 
this exact problem. But another EOF exception pops up, i'll open a new issue.
  
 Files larger than an internal buffer size fail to replicate
 ---

 Key: SOLR-4032
 URL: https://issues.apache.org/jira/browse/SOLR-4032
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0-SNAPSHOT 1366361:1404534M - markus - 2012-11-01 
 12:37:38
 Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
Reporter: Markus Jelsma
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-4032.patch


 Please see: 
 http://lucene.472066.n3.nabble.com/trunk-is-unable-to-replicate-between-nodes-Unable-to-download-completely-td4017049.html
  and 
 http://lucene.472066.n3.nabble.com/Possible-memory-leak-in-recovery-td4017833.html

--
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-4117) IO error while trying to get the size of the Directory

2012-11-28 Thread Markus Jelsma (JIRA)


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

Markus Jelsma updated SOLR-4117:


Priority: Minor  (was: Major)

This issue is the same as reported in SOLR-4032. It does not resolve itself, as 
it did before in SOLR-4032, when reloading a core or restarting the servlet 
container. The Zookeeper exception in the GUI is gone after restart so it's 
likely not related.

 IO error while trying to get the size of the Directory
 --

 Key: SOLR-4117
 URL: https://issues.apache.org/jira/browse/SOLR-4117
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0.0.2012.11.28.10.42.06
 Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
Reporter: Markus Jelsma
Priority: Minor
 Fix For: 5.0


 With SOLR-4032 fixed we see other issues when randomly taking down nodes 
 (nicely via tomcat restart) while indexing a few million web pages from 
 Hadoop. We do make sure that at least one node is up for a shard but due to 
 recovery issues it may not be live.
 One node seems to work but generates IO errors in the log and 
 ZookeeperExeption in the GUI. In the GUI we only see:
 {code}
 SolrCore Initialization Failures
 openindex_f: 
 org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException:
  
 Please check your logs for more information
 {code}
 and in the log we only see the following exception:
 {code}
 2012-11-28 11:47:26,652 ERROR [solr.handler.ReplicationHandler] - 
 [http-8080-exec-28] - : IO error while trying to get the size of the 
 Directory:org.apache.lucene.store.NoSuchDirectoryException: directory 
 '/opt/solr/cores/shard_f/data/index' does not exist
 at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:217)
 at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:240)
 at 
 org.apache.lucene.store.NRTCachingDirectory.listAll(NRTCachingDirectory.java:132)
 at 
 org.apache.solr.core.DirectoryFactory.sizeOfDirectory(DirectoryFactory.java:146)
 at 
 org.apache.solr.handler.ReplicationHandler.getIndexSize(ReplicationHandler.java:472)
 at 
 org.apache.solr.handler.ReplicationHandler.getReplicationDetails(ReplicationHandler.java:568)
 at 
 org.apache.solr.handler.ReplicationHandler.handleRequestBody(ReplicationHandler.java:213)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
 at 
 org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:240)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1830)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:476)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
 at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
 at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:744)
 at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 {code}

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

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

[jira] [Comment Edited] (SOLR-4117) IO error while trying to get the size of the Directory

2012-11-28 Thread Markus Jelsma (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505391#comment-13505391
 ] 

Markus Jelsma edited comment on SOLR-4117 at 11/28/12 12:17 PM:


This issue is the same as reported in SOLR-4032. It does not resolve itself, as 
it did before in SOLR-4032, when reloading a core or restarting the servlet 
container. The Zookeeper exception in the GUI is gone after restart so it's 
likely not related.

edit: the index.properties file in both cores point to the correct 
index.LARGE_NUMBER directory but NRTDir tries ./data/index regardless.

  was (Author: markus17):
This issue is the same as reported in SOLR-4032. It does not resolve 
itself, as it did before in SOLR-4032, when reloading a core or restarting the 
servlet container. The Zookeeper exception in the GUI is gone after restart so 
it's likely not related.
  
 IO error while trying to get the size of the Directory
 --

 Key: SOLR-4117
 URL: https://issues.apache.org/jira/browse/SOLR-4117
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0.0.2012.11.28.10.42.06
 Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
Reporter: Markus Jelsma
Priority: Minor
 Fix For: 5.0


 With SOLR-4032 fixed we see other issues when randomly taking down nodes 
 (nicely via tomcat restart) while indexing a few million web pages from 
 Hadoop. We do make sure that at least one node is up for a shard but due to 
 recovery issues it may not be live.
 One node seems to work but generates IO errors in the log and 
 ZookeeperExeption in the GUI. In the GUI we only see:
 {code}
 SolrCore Initialization Failures
 openindex_f: 
 org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException:
  
 Please check your logs for more information
 {code}
 and in the log we only see the following exception:
 {code}
 2012-11-28 11:47:26,652 ERROR [solr.handler.ReplicationHandler] - 
 [http-8080-exec-28] - : IO error while trying to get the size of the 
 Directory:org.apache.lucene.store.NoSuchDirectoryException: directory 
 '/opt/solr/cores/shard_f/data/index' does not exist
 at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:217)
 at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:240)
 at 
 org.apache.lucene.store.NRTCachingDirectory.listAll(NRTCachingDirectory.java:132)
 at 
 org.apache.solr.core.DirectoryFactory.sizeOfDirectory(DirectoryFactory.java:146)
 at 
 org.apache.solr.handler.ReplicationHandler.getIndexSize(ReplicationHandler.java:472)
 at 
 org.apache.solr.handler.ReplicationHandler.getReplicationDetails(ReplicationHandler.java:568)
 at 
 org.apache.solr.handler.ReplicationHandler.handleRequestBody(ReplicationHandler.java:213)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
 at 
 org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:240)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1830)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:476)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
 at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
 at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:744)
 at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 {code}

--
This message is automatically

[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server

2012-11-28 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505397#comment-13505397
 ] 

Per Steffensen commented on SOLR-4114:
--

Patch including the maxShardsPerNode feature comming up. And (much) better 
testing of the create operation of the Collections API.

 Collection API: Allow multiple shards from one collection on the same Solr 
 server
 -

 Key: SOLR-4114
 URL: https://issues.apache.org/jira/browse/SOLR-4114
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
 Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Per Steffensen
  Labels: collection-api, multicore, shard, shard-allocation
 Attachments: SOLR-4114.patch


 We should support running multiple shards from one collection on the same 
 Solr server - the run a collection with 8 shards on a 4 Solr server cluster 
 (each Solr server running 2 shards).
 Performance tests at our side has shown that this is a good idea, and it is 
 also a good idea for easy elasticity later on - it is much easier to move an 
 entire existing shards from one Solr server to another one that just joined 
 the cluter than it is to split an exsiting shard among the Solr that used to 
 run it and the new Solr.
 See dev mailing list discussion Multiple shards for one collection on the 
 same Solr server

--
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-4028) When using ZK chroot, it would be nice if Solr would create the initial path when it doesn't exist.

2012-11-28 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SOLR-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505415#comment-13505415
 ] 

Tomás Fernández Löbbe commented on SOLR-4028:
-

I think I see the issue here, the problem would be if someone mistype the 
initial path, instead of throwing exceptions and stopping, we would be creating 
a new path and probably hiding an error. 
However, we do create paths for overseer and upload configs automatically, I 
think creating the initial path is more consistent with the current behavior 
than stopping startup. Other options I thought are:
•   Only create the initial path when bootstrap_conf is true (or 
bootstrap_confdir). This could still have the same issue described above.
•   Add a new parameter to force creation, something like 
–DzkHost.create=true. This could add unnecessary parameters and configuration 
complexity.


 When using ZK chroot, it would be nice if Solr would create the initial path 
 when it doesn't exist.
 ---

 Key: SOLR-4028
 URL: https://issues.apache.org/jira/browse/SOLR-4028
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-4028.patch


 I think this would make it easier to test and develop with SolrCloud, in 
 order to start with a fresh ZK directory now the approach is to delete ZK 
 data, with this improvement one could just add a chroot to the zkHost like:
 java -DzkHost=localhost:2181/testXYZ -jar start.jar
 Right now this is possible but you have to manually create the initial path. 

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

1 2 >

1 - 100 of 171 matches

Mail list logo