[jira] [Updated] (SOLR-4374) Solr could not support numeric field name in return

[Qun Wang (JIRA)]

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

Qun Wang updated SOLR-4374:
---

Labels: field name numeric search  (was: )

> Solr could not support numeric field name in return
> ---
>
> Key: SOLR-4374
> URL: https://issues.apache.org/jira/browse/SOLR-4374
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.0
>Reporter: Qun Wang
>  Labels: field, name, numeric, search
> Fix For: 4.1.1
>
>
> When using numeric field name in schema.xml, like {code:xml} name="1001" type="string"...>{code}, it could not be fetched the specific 
> field name by parameter 'fl' from Solr.
> such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
> would be like: '"docs""[{"1001":1001,...},...]'
> In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
> name defination could not be pure numbers:
> {code:title=org.apache.solr.search.ReturnFields.java|borderStyle=solid}
> // like getId, but also accepts dashes for legacy fields
>   String getFieldName(QueryParsing.StrParser sp) {
> sp.eatws();
> int id_start = sp.pos;
> char ch;
> if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
> Character.isJavaIdentifierStart(ch)) {
>   sp.pos++;
>   while (sp.pos < sp.end) {
> ch = sp.val.charAt(sp.pos);
> if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
>   break;
> }
> sp.pos++;
>   }
>   return sp.val.substring(id_start, sp.pos);
> }
> return null;
>   }
> {code}
> Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
> for allowing numeric field name defination?

--
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-4374) Solr could not support numeric field name in return

[Qun Wang (JIRA)]

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

Qun Wang updated SOLR-4374:
---

Description: 
When using numeric field name in schema.xml, like {code:xml}{code}, it could not be fetched the specific field name by 
parameter 'fl' from Solr.
such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
would be like: '"docs""[{"1001":1001,...},...]'
In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
name defination could not be pure numbers:
{code:title=org.apache.solr.search.ReturnFields.java|borderStyle=solid}
// like getId, but also accepts dashes for legacy fields
  String getFieldName(QueryParsing.StrParser sp) {
sp.eatws();
int id_start = sp.pos;
char ch;
if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
Character.isJavaIdentifierStart(ch)) {
  sp.pos++;
  while (sp.pos < sp.end) {
ch = sp.val.charAt(sp.pos);
if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
  break;
}
sp.pos++;
  }
  return sp.val.substring(id_start, sp.pos);
}

return null;
  }
{code}
Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
for allowing numeric field name defination?

  was:
When using numeric field name in schema.xml, like , it could not be fetched the specific field name by parameter 
'fl' from Solr.
such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
would be like: '"docs""[{"1001":1001,...},...]'
In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
name defination could not be pure numbers:
{code:title=org.apache.solr.search.ReturnFields.java|borderStyle=solid}
// like getId, but also accepts dashes for legacy fields
  String getFieldName(QueryParsing.StrParser sp) {
sp.eatws();
int id_start = sp.pos;
char ch;
if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
Character.isJavaIdentifierStart(ch)) {
  sp.pos++;
  while (sp.pos < sp.end) {
ch = sp.val.charAt(sp.pos);
if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
  break;
}
sp.pos++;
  }
  return sp.val.substring(id_start, sp.pos);
}

return null;
  }
{code}
Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
for allowing numeric field name defination?


> Solr could not support numeric field name in return
> ---
>
> Key: SOLR-4374
> URL: https://issues.apache.org/jira/browse/SOLR-4374
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.0
>Reporter: Qun Wang
> Fix For: 4.1.1
>
>
> When using numeric field name in schema.xml, like {code:xml} name="1001" type="string"...>{code}, it could not be fetched the specific 
> field name by parameter 'fl' from Solr.
> such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
> would be like: '"docs""[{"1001":1001,...},...]'
> In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
> name defination could not be pure numbers:
> {code:title=org.apache.solr.search.ReturnFields.java|borderStyle=solid}
> // like getId, but also accepts dashes for legacy fields
>   String getFieldName(QueryParsing.StrParser sp) {
> sp.eatws();
> int id_start = sp.pos;
> char ch;
> if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
> Character.isJavaIdentifierStart(ch)) {
>   sp.pos++;
>   while (sp.pos < sp.end) {
> ch = sp.val.charAt(sp.pos);
> if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
>   break;
> }
> sp.pos++;
>   }
>   return sp.val.substring(id_start, sp.pos);
> }
> return null;
>   }
> {code}
> Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
> for allowing numeric field name defination?

--
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-4374) Solr could not support numeric field name in return

[Qun Wang (JIRA)]

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

Qun Wang updated SOLR-4374:
---

Description: 
When using numeric field name in schema.xml, like , it could not be fetched the specific field name by parameter 
'fl' from Solr.
such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
would be like: '"docs""[{"1001":1001,...},...]'
In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
name defination could not be pure numbers:
{code:title=org.apache.solr.search.ReturnFields.java|borderStyle=solid}
// like getId, but also accepts dashes for legacy fields
  String getFieldName(QueryParsing.StrParser sp) {
sp.eatws();
int id_start = sp.pos;
char ch;
if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
Character.isJavaIdentifierStart(ch)) {
  sp.pos++;
  while (sp.pos < sp.end) {
ch = sp.val.charAt(sp.pos);
if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
  break;
}
sp.pos++;
  }
  return sp.val.substring(id_start, sp.pos);
}

return null;
  }
{code}
Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
for allowing numeric field name defination?

  was:
When using numeric field name in schema.xml, like , it could not be fetched the specific field name by parameter 
'fl' from Solr.
such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
would be like: '"docs""[{"1001":1001,...},...]'
In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
name defination could not be pure numbers:
// like getId, but also accepts dashes for legacy fields
  String getFieldName(QueryParsing.StrParser sp) {
sp.eatws();
int id_start = sp.pos;
char ch;
if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
Character.isJavaIdentifierStart(ch)) {
  sp.pos++;
  while (sp.pos < sp.end) {
ch = sp.val.charAt(sp.pos);
if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
  break;
}
sp.pos++;
  }
  return sp.val.substring(id_start, sp.pos);
}

return null;
  }
Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
for allowing numeric field name defination?


> Solr could not support numeric field name in return
> ---
>
> Key: SOLR-4374
> URL: https://issues.apache.org/jira/browse/SOLR-4374
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.0
>Reporter: Qun Wang
> Fix For: 4.1.1
>
>
> When using numeric field name in schema.xml, like  type="string"...>, it could not be fetched the specific field name by 
> parameter 'fl' from Solr.
> such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
> would be like: '"docs""[{"1001":1001,...},...]'
> In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
> name defination could not be pure numbers:
> {code:title=org.apache.solr.search.ReturnFields.java|borderStyle=solid}
> // like getId, but also accepts dashes for legacy fields
>   String getFieldName(QueryParsing.StrParser sp) {
> sp.eatws();
> int id_start = sp.pos;
> char ch;
> if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
> Character.isJavaIdentifierStart(ch)) {
>   sp.pos++;
>   while (sp.pos < sp.end) {
> ch = sp.val.charAt(sp.pos);
> if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
>   break;
> }
> sp.pos++;
>   }
>   return sp.val.substring(id_start, sp.pos);
> }
> return null;
>   }
> {code}
> Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
> for allowing numeric field name defination?

--
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-4374) Solr could not support numeric field name in return

[Qun Wang (JIRA)]

Qun Wang created SOLR-4374:
--

 Summary: Solr could not support numeric field name in return
 Key: SOLR-4374
 URL: https://issues.apache.org/jira/browse/SOLR-4374
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 4.0
Reporter: Qun Wang
 Fix For: 4.1.1


When using numeric field name in schema.xml, like , it could not be fetched the specific field name by parameter 
'fl' from Solr.
such as 'http://localhost:8983/solr/query?q=1001:test&fl=1001', the response 
would be like: '"docs""[{"1001":1001,...},...]'
In org.apache.solr.search.ReturnFields.java, it seems this code limited field 
name defination could not be pure numbers:
// like getId, but also accepts dashes for legacy fields
  String getFieldName(QueryParsing.StrParser sp) {
sp.eatws();
int id_start = sp.pos;
char ch;
if (sp.pos < sp.end && (ch = sp.val.charAt(sp.pos)) != '$' && 
Character.isJavaIdentifierStart(ch)) {
  sp.pos++;
  while (sp.pos < sp.end) {
ch = sp.val.charAt(sp.pos);
if (!Character.isJavaIdentifierPart(ch) && ch != '.' && ch != '-') {
  break;
}
sp.pos++;
  }
  return sp.val.substring(id_start, sp.pos);
}

return null;
  }
Could we replace or remove this check of Character.isJavaIdentifierStart(ch) 
for allowing numeric field name defination?

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

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

[jira] [Created] (LUCENE-4729) Add the ability to benchmark to create per-field analyzers, like Lucene's PerFieldAnalyzerWrapper

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-4729:
--

 Summary: Add the ability to benchmark to create per-field 
analyzers, like Lucene's PerFieldAnalyzerWrapper
 Key: LUCENE-4729
 URL: https://issues.apache.org/jira/browse/LUCENE-4729
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/benchmark
Affects Versions: 4.2
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor


{{AnalyzerFactory}}, added to the benchmark module in LUCENE-4723, is a factory 
of factories: as part of creating an analyzer, each analysis pipeline 
component's factory is invoked to create the component instances.

But unlike in Solr, where all analysis pipelines are explicitly specified 
per-field, benchmark algorithms have no way to specify per-field analyzers - an 
analyzer is always applied to all fields.

I propose a new task {{PerFieldAnalyzerFactoryTask}}, which would invoke 
{{PerFieldAnalyzerFactory}}: a factory of factories of factories.

(I've left "Wrapper" out of the name - it's already verging on overly long, and 
I don't think the meaning is compromised.)

I don't have an implementation yet - I wanted to see if people think there's a 
different/better way to do this.

--
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-3918) Port index sorter to trunk APIs

[Shai Erera (JIRA)]

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

Shai Erera commented on LUCENE-3918:


One of the usecases for IndexSorter is for when you want to e.g. do quick early 
termination for a query. Then, if you sort the index (say by date), and you're 
interested in documents sorted by date, then you can do a fast early 
termination after visiting exactly N docs.

I'm not sure that I understand your proposal though and whether it'll help such 
usecases?

> Port index sorter to trunk APIs
> ---
>
> Key: LUCENE-3918
> URL: https://issues.apache.org/jira/browse/LUCENE-3918
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/other
>Affects Versions: 4.0-ALPHA
>Reporter: Robert Muir
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-3918.patch
>
>
> LUCENE-2482 added an IndexSorter to 3.x, but we need to port this
> functionality to 4.0 apis.

--
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-3918) Port index sorter to trunk APIs

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-3918:
--

I was thinking today that it would be nice if the a document's stored values 
file could be sorted by some field (e.g. a geohash or time or...).  Wouldn't 
that be cool?  Would such a feature obsolete the use of the index sorter that 
this issue speaks of?

> Port index sorter to trunk APIs
> ---
>
> Key: LUCENE-3918
> URL: https://issues.apache.org/jira/browse/LUCENE-3918
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/other
>Affects Versions: 4.0-ALPHA
>Reporter: Robert Muir
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-3918.patch
>
>
> LUCENE-2482 added an IndexSorter to 3.x, but we need to port this
> functionality to 4.0 apis.

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

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

[jira] [Updated] (LUCENE-3138) IW.addIndexes should fail fast if an index is too old/new

[Shai Erera (JIRA)]

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

Shai Erera updated LUCENE-3138:
---

Fix Version/s: (was: 4.2)
   (was: 5.0)

> IW.addIndexes should fail fast if an index is too old/new
> -
>
> Key: LUCENE-3138
> URL: https://issues.apache.org/jira/browse/LUCENE-3138
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Shai Erera
>Priority: Minor
>
> Today IW.addIndexes (both Dir and IR versions) do not check the format of the 
> incoming indexes. Therefore it could add a too old/new index and the app will 
> discover that only later, maybe during commit() or segment merges. We should 
> check that up front and fail fast.
> This issue is relevant only to 4.0 at the moment, which will not support 2.x 
> indexes anymore.

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

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

[jira] [Updated] (LUCENE-2921) Now that we track the code version at the segment level, we can stop tracking it also in each file level

[Shai Erera (JIRA)]

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

Shai Erera updated LUCENE-2921:
---

Fix Version/s: (was: 4.2)
   (was: 5.0)

> Now that we track the code version at the segment level, we can stop tracking 
> it also in each file level
> 
>
> Key: LUCENE-2921
> URL: https://issues.apache.org/jira/browse/LUCENE-2921
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Shai Erera
>
> Now that we track the code version that created the segment at the segment 
> level, we can stop tracking versions in each file. This has several major 
> benefits:
> # Today the constant names that use to track versions are confusing - they do 
> not state since which version it applies to, and so it's harder to determine 
> which formats we can stop supporting when working on the next major release.
> # Those format numbers are usually negative, but in some cases positive 
> (inconsistency) -- we need to remember to increase it "one down" for the 
> negative ones, which I always find confusing.
> # It will remove the format tracking from all the *Writers, and the *Reader 
> will receive the code format (String) and work w/ the appropriate constant 
> (e.g. Constants.LUCENE_30). Centralizing version tracking to SegmentInfo is 
> an advantage IMO.
> It's not urgent that we do it for 3.1 (though it requires an index format 
> change), because starting from 3.1 all segments track their version number 
> anyway (or migrated to track it), so we can safely release it in follow-on 3x 
> release.

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

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

Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_10) - Build # 2463 - Still Failing!

[Steve Rowe]

I committed a fix.  Thanks for running Windows Jenkins, Uwe :)

On Jan 28, 2013, at 11:46 PM, Policeman Jenkins Server  
wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2463/
> Java: 32bit/jdk1.7.0_10 -server -XX:+UseConcMarkSweepGC
> 
> 1 tests failed.
> FAILED:  
> org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory
> 
> Error Message:
> Error: cannot understand algorithm!
> 
> Stack Trace:
> java.lang.Exception: Error: cannot understand algorithm!
>   at 
> __randomizedtesting.SeedInfo.seed([46E0ADF0C0387C8:A774D910189F92F5]:0)
>   at 
> org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
>   at 
> org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
>   at 
> org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1088)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
>   at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.RuntimeException: Line #2: 
>   at 
> org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.

[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_10) - Build # 2463 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2463/
Java: 32bit/jdk1.7.0_10 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory

Error Message:
Error: cannot understand algorithm!

Stack Trace:
java.lang.Exception: Error: cannot understand algorithm!
at 
__randomizedtesting.SeedInfo.seed([46E0ADF0C0387C8:A774D910189F92F5]:0)
at 
org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
at 
org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
at 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1088)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Line #2: 
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.java:392)
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.setParams(AnalyzerFactoryTask.java:233)
at 
org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:145)
at 
org.apache.luc

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2476/
Java: 32bit/jdk1.7.0_10 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory

Error Message:
Error: cannot understand algorithm!

Stack Trace:
java.lang.Exception: Error: cannot understand algorithm!
at 
__randomizedtesting.SeedInfo.seed([E0005D25FB6A0CB7:431A8EEAEFF6198A]:0)
at 
org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
at 
org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
at 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1086)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Line #2: 
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.java:392)
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.setParams(AnalyzerFactoryTask.java:233)
at 
org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:145)
at 
org.apache.lucene.

[jira] [Updated] (SOLR-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-1782:
---

Attachment: SOLR-1782.patch

Wojtek & David...

I spent some time today trying to look over the latest patch ( 
SOLR-1782.2013-01-07.patch ) and had some trouble wrapping my head arround it.

In particular i think the crux of my confusion stems from this comment from 
Wojtek...

bq. New patch uses both UninvertedField and FieldCache.DocTermsIndex for 
multi-valued facet fields

...which doens't really make sense to me.  

If a field is multivalued, then (unless i'm missunderstanding something) a 
DocTermsIndex won't make sense for that field at all.  At best it's wasted RAM 
to build up the DocTermsIndex when UnInvertedField is going to be used instead 
-- but in this patch, as part of the "if (null == uif)" sprinkled throughout 
FieldFacetStats, it looks like term ordinals from the 
UnInvertedField.getTermNumbers method are then being used to look Term values 
from the DocTermsIndex ... i don't understand that at all.

Hopefully this is just a minor bug in the patch, and the call to "si.lookup" in 
the UIF block(s) of FieldFacetStats.facet & FieldFacetStats.facetTermNum are 
ment to be calls to some similar method in UnivertedField, but it's not 
entirely clear.

If that is the case, then it suggests to me that a better way to organize this 
code so that it's more clear what's going on (and to save all that wasted RAM 
used by the DocTermsIndex when going down the UIF code path!) would be to 
refactor an abstract base class out of FieldFacetStats defining the API 
contract and then have two concrete impls: one using DocTermsIndex provided in 
teh constructor, and one using an UnInvertedField provided in it's constructor.

I'm also a little perplexed by the "UnInvertedField.getStats" method which _is_ 
modified in this patch, but seemingly only as an aside so it will still compile 
because of the new param added to the FieldFacetStats constructor.  At a 
glance, I'm not clear on wether this method is even used anywhere, but that 
makes it seem all the more suspicious: it appears that a lot of the logic in 
getTermNumbers was cut/paste from this method -- should these methods be 
refactored to eliminate that duplication? can UIF.getStats just be deprecated & 
removed?  Would be make more sense instead of adding some of these new methods 
to just "fix" UIF.getStats so that it recognizes when another UIF instance is 
needed for the facet field(s)?

Lastly: I noticed that while the patch did include tests, it didn't include the 
original tests I wrote when this issue was filled (see SOLR-1782.test.patch).  
When I attempted to merge those tests in, I got a failure in 
testMicroStatsWithMultiValuedFacetField (even after i fixed the obvious case 
sensitivity problem in the original test) -- hopefully this is just a 
demonstration of the problem i mentioned above about mixing ords from the 
DocTermsIndex and the UnInvertedField, but it may be a symptom of a diff 
problem.

unified patch will all tests attached



> stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued 
> fields
> -
>
> Key: SOLR-1782
> URL: https://issues.apache.org/jira/browse/SOLR-1782
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.4
> Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: 
> CHANGES.txt 906924 2010-02-05 12:43:11Z noble $)
>Reporter: Gerald DeConto
>Assignee: Hoss Man
> Attachments: index.rar, SOLR-1782.2013-01-07.patch, 
> SOLR-1782.2.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.patch, 
> SOLR-1782.test.patch
>
>
> the StatsComponent assumes any field specified in the stats.facet param can 
> be faceted using FieldCache.DEFAULT.getStringIndex.  This can cause problems 
> with a variety of field types, but in the case of multivalued fields it can 
> either cause erroneous false stats when the number of distinct values is 
> small, or it can cause ArrayIndexOutOfBoundsException when the number of 
> distinct values is greater then the number of documents.

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

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

[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_38) - Build # 2462 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2462/
Java: 32bit/jdk1.6.0_38 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory

Error Message:
Error: cannot understand algorithm!

Stack Trace:
java.lang.Exception: Error: cannot understand algorithm!
at 
__randomizedtesting.SeedInfo.seed([1F319A4BBE9E5E54:BC2B4984AA024B69]:0)
at 
org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
at 
org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
at 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1088)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: Line #2: 
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.java:392)
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.setParams(AnalyzerFactoryTask.java:233)
at 
org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:145)
at 
org.apache.lu

[jira] [Updated] (SOLR-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-4373:


Attachment: multicore-bug.zip

Full Solr setup with two cores showing the problem. Disable the second core in 
solr.xml to make the problem go away. Log files for both scenarios are included.

> In multicore, lib directives in solrconfig.xml cause conflict and clobber 
> directives from earlier cores
> ---
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
>Priority: Blocker
>  Labels: lib, multicore
> Fix For: 4.2, 4.1.1
>
> Attachments: multicore-bug.zip
>
>
> Having lib directives in solrconfig.xml seem to wipe out/override the 
> definitions in previous cores.
> The exception (for the earlier core) is:
>   at 
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:177)
>   at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:369)
>   at org.apache.solr.schema.IndexSchema.(IndexSchema.java:113)
>   at 
> org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:1000)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1033)
>   at org.apache.solr.core.CoreContainer$3.call(CoreContainer.java:629)
>   at org.apache.solr.core.CoreContainer$3.call(CoreContainer.java:624)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>   at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.solr.common.SolrException: Plugin init failure for 
> [schema.xml] analyzer/filter: Error loading class 
> 'solr.ICUFoldingFilterFactory'
>   at 
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:177)
>   at 
> org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:377)
>   at 
> org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:95)
>   at 
> org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:43)
>   at 
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151)
> The full replication case is attached.
> If the SECOND core is turned off in solr.xml, the FIRST core loads just fine.

--
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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-4373:
---

 Summary: In multicore, lib directives in solrconfig.xml cause 
conflict and clobber directives from earlier cores
 Key: SOLR-4373
 URL: https://issues.apache.org/jira/browse/SOLR-4373
 Project: Solr
  Issue Type: Bug
  Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
 Fix For: 4.2, 4.1.1


Having lib directives in solrconfig.xml seem to wipe out/override the 
definitions in previous cores.

The exception (for the earlier core) is:
at 
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:177)
at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:369)
at org.apache.solr.schema.IndexSchema.(IndexSchema.java:113)
at 
org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:1000)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1033)
at org.apache.solr.core.CoreContainer$3.call(CoreContainer.java:629)
at org.apache.solr.core.CoreContainer$3.call(CoreContainer.java:624)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.solr.common.SolrException: Plugin init failure for 
[schema.xml] analyzer/filter: Error loading class 'solr.ICUFoldingFilterFactory'
at 
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:177)
at 
org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:377)
at 
org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:95)
at 
org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:43)
at 
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151)

The full replication case is attached.

If the SECOND core is turned off in solr.xml, the FIRST core loads just fine.

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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2475/
Java: 32bit/jdk1.7.0_10 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory

Error Message:
Error: cannot understand algorithm!

Stack Trace:
java.lang.Exception: Error: cannot understand algorithm!
at 
__randomizedtesting.SeedInfo.seed([1D5EF21C8BFCDCB5:BE4421D39F60C988]:0)
at 
org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
at 
org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
at 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1086)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Line #2: 
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.java:392)
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.setParams(AnalyzerFactoryTask.java:233)
at 
org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:145)
at 
org.apache.

[jira] [Closed] (LUCENE-4134) modify release process/scripts to use svn for rc/release publishing (svnpubsub)

[Steve Rowe (JIRA)]

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

Steve Rowe closed LUCENE-4134.
--


> modify release process/scripts to use svn for rc/release publishing 
> (svnpubsub)
> ---
>
> Key: LUCENE-4134
> URL: https://issues.apache.org/jira/browse/LUCENE-4134
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 4.1
>
>
> By the end of 2012, all of www.apache.org *INCLUDING THE DIST DIR* must be 
> entirely managed using "svnpubsub" ... our use of the Apache CMS for 
> lucene.apache.org puts us in compliance for our main website, but the dist 
> dir use for publishing release artifacts also needs to be manaved via svn.

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

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

[jira] [Resolved] (LUCENE-4134) modify release process/scripts to use svn for rc/release publishing (svnpubsub)

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-4134.


   Resolution: Fixed
 Assignee: Steve Rowe
Lucene Fields:   (was: New)

INFRA-5739 has been resolved - svnpubsub for releases has been set up.  And it 
functioned properly for the 4.1 Lucene & Solr releases.

I've taken a first pass at modernizing the [Lucene 
ReleaseTodo|http://wiki.apache.org/lucene-java/ReleaseTodo] documentation,  
including a description of publishing by committing final release distributions 
to the {{dist.apache.org/repos/dist/releases/lucene/}} SVN repo.

I updated Mike McCandless's {{dev-tools/scripts/buildAndPushRelease.py}} script 
to run under Python 3.2 - otherwise it wouldn't run the smoke tester, which 
requires Python 3.2.  I used this script to build, push, and smoke test the RC. 
 It's very nice - it handles lots of tedious details for you.  The flip side of 
this is that what it does could become magic; my recommendation is to fully 
review the script before using it to make a real RC. 

I think enough progress was made here for now.  Further changes can be made via 
new issues.

> modify release process/scripts to use svn for rc/release publishing 
> (svnpubsub)
> ---
>
> Key: LUCENE-4134
> URL: https://issues.apache.org/jira/browse/LUCENE-4134
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 4.1
>
>
> By the end of 2012, all of www.apache.org *INCLUDING THE DIST DIR* must be 
> entirely managed using "svnpubsub" ... our use of the Apache CMS for 
> lucene.apache.org puts us in compliance for our main website, but the dist 
> dir use for publishing release artifacts also needs to be manaved via svn.

--
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-3178) Native MMapDir

[Greg Bowyer (JIRA)]

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

Greg Bowyer commented on LUCENE-3178:
-

So I was going to shut this down today, and just to make sure I ran the 
benchmark on the simplest code possible

... and suddenly I got good results, this is idiopathic :S

https://gist.github.com/0f017853861d050c0b66
{code}
Report after iter 19:
TaskQPS baseline  StdDevQPS mmap_tests  StdDev  
  Pct diff
  OrHighHigh1.68 (11.2%)1.73 (10.3%)
3.0% ( -16% -   27%)
PKLookup  129.89  (5.8%)  135.03  (6.0%)
4.0% (  -7% -   16%)
HighTerm8.09 (13.6%)8.43 (12.8%)
4.2% ( -19% -   35%)
   OrHighMed4.46 (10.4%)4.67  (9.5%)
4.7% ( -13% -   27%)
   OrHighLow4.82 (10.6%)5.09 (10.3%)
5.6% ( -13% -   29%)
HighSpanNear0.92  (8.1%)0.97  (7.3%)
5.9% (  -8% -   23%)
  IntNRQ2.51 (10.2%)2.67  (9.9%)
6.6% ( -12% -   29%)
  HighPhrase0.30 (11.7%)0.32 (12.8%)
6.7% ( -16% -   35%)
   MedPhrase2.93  (6.8%)3.12  (8.2%)
6.7% (  -7% -   23%)
 AndHighHigh5.46  (6.6%)5.86  (7.0%)
7.2% (  -5% -   22%)
 Respell   19.68  (5.9%)   21.15  (6.6%)
7.5% (  -4% -   21%)
   LowPhrase0.46  (9.5%)0.50 (10.2%)
7.6% ( -11% -   30%)
 Prefix35.25  (8.2%)5.66  (7.7%)
7.9% (  -7% -   25%)
HighSloppyPhrase1.54  (8.0%)1.67 (13.1%)
8.5% ( -11% -   32%)
 MedSpanNear5.25  (7.0%)5.72  (8.2%)
9.0% (  -5% -   25%)
Wildcard   12.44  (5.7%)   13.59  (6.5%)
9.2% (  -2% -   22%)
 MedSloppyPhrase2.27  (7.2%)2.49  (8.5%)
9.5% (  -5% -   27%)
 MedTerm   28.16 (10.3%)   30.89  (9.9%)
9.7% (  -9% -   33%)
  Fuzzy1   18.91  (6.0%)   20.82  (6.7%)   
10.1% (  -2% -   24%)
  Fuzzy2   19.69  (6.6%)   21.68  (7.5%)   
10.1% (  -3% -   25%)
  AndHighMed7.79  (7.5%)8.58  (6.1%)   
10.1% (  -3% -   25%)
 LowSpanNear1.45  (5.7%)1.60  (9.3%)   
10.5% (  -4% -   27%)
 LowSloppyPhrase   22.84  (7.7%)   25.45  (9.7%)   
11.4% (  -5% -   31%)
 LowTerm   46.46  (6.8%)   52.90  (7.6%)   
13.9% (   0% -   30%)
  AndHighLow   35.92  (5.3%)   42.38  (7.1%)   
18.0% (   5% -   32%)
{code}

> Native MMapDir
> --
>
> Key: LUCENE-3178
> URL: https://issues.apache.org/jira/browse/LUCENE-3178
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Reporter: Michael McCandless
>  Labels: gsoc2012, lucene-gsoc-12
> Attachments: LUCENE-3178-Native-MMap-implementation.patch, 
> LUCENE-3178-Native-MMap-implementation.patch, 
> LUCENE-3178-Native-MMap-implementation.patch
>
>
> Spinoff from LUCENE-2793.
> Just like we will create native Dir impl (UnixDirectory) to pass the right OS 
> level IO flags depending on the IOContext, we could in theory do something 
> similar with MMapDir.
> The problem is MMap is apparently quite hairy... and to pass the flags the 
> native code would need to invoke mmap (I think?), unlike UnixDir where the 
> code "only" has to open the file handle.

--
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-4372) Search text box in auto-complete/chooser extends outside of the dropdown pane on IE9 & FF 17+

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4372:
-

It's the admin UI. 

> Search text box in auto-complete/chooser extends outside of the dropdown pane 
> on IE9 & FF 17+
> -
>
> Key: SOLR-4372
> URL: https://issues.apache.org/jira/browse/SOLR-4372
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.1, 4.2
> Environment: IE9
>Reporter: Senthuran Sivananthan
>Priority: Minor
> Attachments: chooser_ff17+.png, chooser_ie9.png
>
>
> This is an issue across all of the pages.
> The textbox in auto-complete/chooser extends outside of the dropdown page on 
> IE9 and FF17+.
> Looks like there's an explicit width of 130px being specified on the textbox:
> 

--
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-4372) Search text box in auto-complete/chooser extends outside of the dropdown pane on IE9 & FF 17+

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-4372:
--

Is this the admin UI? the /browse handler? I'm not sure where one should start 
looking.

> Search text box in auto-complete/chooser extends outside of the dropdown pane 
> on IE9 & FF 17+
> -
>
> Key: SOLR-4372
> URL: https://issues.apache.org/jira/browse/SOLR-4372
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.1, 4.2
> Environment: IE9
>Reporter: Senthuran Sivananthan
>Priority: Minor
> Attachments: chooser_ff17+.png, chooser_ie9.png
>
>
> This is an issue across all of the pages.
> The textbox in auto-complete/chooser extends outside of the dropdown page on 
> IE9 and FF17+.
> Looks like there's an explicit width of 130px being specified on the textbox:
> 

--
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-4369) Add information about Solr 4.0 Cookbook to https://lucene.apache.org/solr/

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-4369.
--

Resolution: Fixed
  Assignee: Steve Rowe

Rafał, I committed your patch, added the cover image, and removed the 3.1 
cookbook cover image - I can see it on the production site now.

> Add information about Solr 4.0 Cookbook to https://lucene.apache.org/solr/
> --
>
> Key: SOLR-4369
> URL: https://issues.apache.org/jira/browse/SOLR-4369
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Reporter: Rafał Kuć
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: book_s4c.jpg, SOLR-4369.patch
>
>
> I think it would be good to have the information about new version of 
> Cookbook available. Now the question is, how it is currently handled after 
> moving away from Apache Forrest to the new site based on CMS. 

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

BasicDistributedZkTest.testDistribSearch hang

[Erick Erickson]

I have "ant test" running and have the above message printing out
after 785 seconds. I have stack traces for all the suspect java
programs on my machine, to whit:

7212 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe
7476 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe
7327 org.apache.tools.ant.launch.Launcher .

NOTE: the bad part is that this is happening in my work for SOLR-4196.
If anyone's interested, I'll put up a patch I'll call
(SOLR-4196-distribhang.patch) and the stack traces. I can't, of
course, say whether this i related, but this test fails fairly
regularly w/o my changes so it's a fair bet that it's unrelated to
4196.

Let me know,
Erick

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

[jira] [Commented] (SOLR-4284) admin UI - make core list scrollable separate from the rest of the UI

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4284:
-

Unfortunately, it wasn't IE alone.  Breaks on FF 17 and above too :/.

New issue created:  SOLR-4372

> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: collection_chooser_ie9.png, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4370:
---

Alright - that's really a separate issue and it's bothering me less over time.

I'll commit as is without further input.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4372) Search text box in auto-complete/chooser extends outside of the dropdown pane on IE9 & FF 17+

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4372:


Attachment: chooser_ff17+.png
chooser_ie9.png

> Search text box in auto-complete/chooser extends outside of the dropdown pane 
> on IE9 & FF 17+
> -
>
> Key: SOLR-4372
> URL: https://issues.apache.org/jira/browse/SOLR-4372
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.1, 4.2
> Environment: IE9
>Reporter: Senthuran Sivananthan
>Priority: Minor
> Attachments: chooser_ff17+.png, chooser_ie9.png
>
>
> This is an issue across all of the pages.
> The textbox in auto-complete/chooser extends outside of the dropdown page on 
> IE9 and FF17+.
> Looks like there's an explicit width of 130px being specified on the textbox:
> 

--
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-4372) Search text box in auto-complete/chooser extends outside of the dropdown pane on IE9 & FF 17+

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4372:


Description: 
This is an issue across all of the pages.

The textbox in auto-complete/chooser extends outside of the dropdown page on 
IE9 and FF17+.

Looks like there's an explicit width of 130px being specified on the textbox:




  was:
This is an issue across all of the pages.

The textbox in auto-complete/chooser extends outside of the dropdown page on 
IE9 and FF17.

Looks like there's an explicit width of 130px being specified on the textbox:





> Search text box in auto-complete/chooser extends outside of the dropdown pane 
> on IE9 & FF 17+
> -
>
> Key: SOLR-4372
> URL: https://issues.apache.org/jira/browse/SOLR-4372
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.1, 4.2
> Environment: IE9
>Reporter: Senthuran Sivananthan
>Priority: Minor
> Attachments: chooser_ff17+.png, chooser_ie9.png
>
>
> This is an issue across all of the pages.
> The textbox in auto-complete/chooser extends outside of the dropdown page on 
> IE9 and FF17+.
> Looks like there's an explicit width of 130px being specified on the textbox:
> 

--
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-4372) Search text box in auto-complete/chooser extends outside of the dropdown pane on IE9 & FF 17+

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4372:


Summary: Search text box in auto-complete/chooser extends outside of the 
dropdown pane on IE9 & FF 17+  (was: Search text box in auto-complete/chooser 
extends outside of the dropdown pane on IE9 & FF 17)

> Search text box in auto-complete/chooser extends outside of the dropdown pane 
> on IE9 & FF 17+
> -
>
> Key: SOLR-4372
> URL: https://issues.apache.org/jira/browse/SOLR-4372
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.1, 4.2
> Environment: IE9
>Reporter: Senthuran Sivananthan
>Priority: Minor
> Attachments: chooser_ff17+.png, chooser_ie9.png
>
>
> This is an issue across all of the pages.
> The textbox in auto-complete/chooser extends outside of the dropdown page on 
> IE9 and FF17.
> Looks like there's an explicit width of 130px being specified on the textbox:
> 

--
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-4372) Search text box in auto-complete/chooser extends outside of the dropdown pane on IE9 & FF 17

[Senthuran Sivananthan (JIRA)]

Senthuran Sivananthan created SOLR-4372:
---

 Summary: Search text box in auto-complete/chooser extends outside 
of the dropdown pane on IE9 & FF 17
 Key: SOLR-4372
 URL: https://issues.apache.org/jira/browse/SOLR-4372
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1, 4.2
 Environment: IE9
Reporter: Senthuran Sivananthan
Priority: Minor


This is an issue across all of the pages.

The textbox in auto-complete/chooser extends outside of the dropdown page on 
IE9 and FF17.

Looks like there's an explicit width of 130px being specified on the textbox:




--
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-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4370:
---

Yes, the commitWithin and auto commit code is tied up as an impl detail, but 
not from a user perspective. You shouldn't have to know a thing about auto 
commit or have any config for it to work fully with commitWithin.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4370:
-

At the same time, if we don't commit during update, isn't it the auto commit 
that's actually doing the commit based on maxTime, maxDoc or commitWithin?

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) commented on SOLR-4284:
-

Uhm yeah .. like i love these Internet Exploder Issues .. [~senthuran] would 
you mind opening a new Issue for that? I'm pretty sure it does look/behave the 
same for all other Places (Analysis & Schema-Browser) where we're already using 
the Dropdown-Replacement?

> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: collection_chooser_ie9.png, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4370:
---

Hmm, that is odd though. Seems rather unintuitive that auto commit settings 
would apply to commitWithin.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4284:


Attachment: collection_chooser_ie9.png

The search text box spans outside of the chooser on IE9.  Chrome and FF look 
good.  Attached is a screenshot.

> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: collection_chooser_ie9.png, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4370:
-

The 2 issues that I saw are now resolved.

I needed to set openSearcher = true (by default it was false in my config).

Thanks for the quick turnaround Mark.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4355) SolrException & SolrServerException message should retun root cause

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-4355:


bq. I think the best way to do this would be to first create a custom error 
page for solr, with an option to return the error in plain text, 

Solr already uses the specified response writer to format any error responses, 
so clients asking for results in XML get an XML formated error response, 
clients asking for results in JSON get a JSON formatted error response, etc...

The issue here is simply that the code in SolrJ for dealing with non 200 HTTP 
responses needs to be updated to (try to) use the appropriate response parsing 
codec to see if the response can be parsed, and if so pull out hte error 
information to populate the SolrServerException  (when most of this code was 
writen, solr still relied on the serlvet container to format the response, so 
the body was largely useles, hence no one ever worried about it).

patches towards this goal would certainly be welcome.

> SolrException & SolrServerException message should retun root cause
> ---
>
> Key: SOLR-4355
> URL: https://issues.apache.org/jira/browse/SOLR-4355
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0, 4.1
>Reporter: Magnus Ebbesson
>
> A mall/illformed SolrQuery will raise a SolrException when executed on 
> SolrServer.query(...). 
> The only message retreivable from this exception is that 
> "org.apache.solr.common.SolrException: Server at http://servername/solr/core0 
> returned non ok status:500, message:Internal Server Error" 
> Using the same query and posting in a web browser directly against Solr I'm 
> presented with the proper root cause. 
> It would be very much appreciated if the Search client itself would be able 
> to return the same message. 

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4370:
-

OK, I just saw what you meant by openSearcher=false

I updated:

  
   15000 
   false 
 

to

  
   15000 
   true 
 

and that seem to do the trick.  I'll test and let you know.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4370:


Attachment: without_commit.txt
with_commit.txt

These the snippets from the logs.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan edited comment on SOLR-4370 at 1/28/13 10:40 PM:
---

Logs attached.

  was (Author: senthuran):
These the snippets from the logs.
  
> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4370:
-

Mark, I just updated my comment about (didn't see your post till now).  Can you 
see if it makes sense or whether you need additional info?

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch, with_commit.txt, without_commit.txt
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan edited comment on SOLR-4370 at 1/28/13 10:38 PM:
---

Tested the patch on 4.2 from 
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/ and found a 
couple issues when solr.commitwithin.softcommit = false.  The setting allows 
the slaves to replicate the indices and I can see the index files updated after 
commitWithin timeframe.

The issues are:

1/ Stats on the collection overview page doesn't get updated.  This includes 
the generation & version info.  An explicit commit (i.e. 
http://localhost:8983/solr/collection1/update?commit=true) will update the 
stats.

2/ Can't find the indexed docs on the master.  An explicit commit solves the 
issue.

I think the patch solves the original request but introduced a couple of 
side-effects.



Additional info
---

I did a quick diff between explicit commit (commit=true) vs. commitWithin=2000 
vs. HardAutoCommitTest and here's what I found.  May be I'm off track, but 
thought I share:

1.  commit = true

* A new searcher is registered

Jan 28, 2013 5:30:39 PM org.apache.solr.search.SolrIndexSearcher 
INFO: Opening Searcher@47955387 main
Jan 28, 2013 5:30:39 PM org.apache.solr.core.CachingDirectoryFactory close
INFO: Releasing 
directory:D:\Tools\Solr\dev\branch_4x\solr\example\solr\collection1\data\index
Jan 28, 2013 5:30:39 PM org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener sending requests to Searcher@47955387 
main{StandardDirectoryReader(segments_4:9:nrt _0(4.2):C2 _2(4.2):C3)}
Jan 28, 2013 5:30:39 PM org.apache.solr.update.DirectUpdateHandler2 commit
INFO: end_commit_flush
Jan 28, 2013 5:30:39 PM org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener done.
Jan 28, 2013 5:30:39 PM org.apache.solr.core.SolrCore registerSearcher
INFO: [collection1] Registered new searcher Searcher@47955387 
main{StandardDirectoryReader(segments_4:9:nrt _0(4.2):C2 _2(4.2):C3)}


2.  commitWithin=N

New search isn't registered

Jan 28, 2013 5:31:47 PM org.apache.solr.search.SolrIndexSearcher 
INFO: Opening Searcher@4d000e49 realtime
Jan 28, 2013 5:31:47 PM org.apache.solr.update.DirectUpdateHandler2 commit
INFO: end_commit_flush

3.  HardAutoCommitTest

23619 T18 oasc.CachingDirectoryFactory.close Releasing 
directory:C:\Users\SENTHU~1\AppData\Local\Temp\solrtest-HardAutoCommitTest-1359411964946
23640 T18 oass.SolrIndexSearcher. Opening Searcher@3b0d579 main
23642 T18 oasu.DirectUpdateHandler2.commit end_commit_flush
23654 T17 oasc.SolrCore.registerSearcher [collection1] Registered new searcher 
Searcher@3b0d579 main{StandardDirectoryReader(segments_2:4:nrt _0(4.2):C1)}
23655 T17 oasc.CachingDirectoryFactory.close Releasing 
directory:C:\Users\SENTHU~1\AppData\Local\Temp\solrtest-HardAutoCommitTest-1359411964946\index
29234 T15 C1 REQ [collection1] webapp=null path=null 
params={start=0&q=id:529&qt=standard&rows=20&version=2.2} hits=1 status=0 
QTime=4 

Any way to register a new searcher?

  was (Author: senthuran):
Tested the patch on 4.2 from 
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/ and found a 
couple issues when solr.commitwithin.softcommit = false.  The setting allows 
the slaves to replicate the indices and I can see the index files updated after 
commitWithin timeframe.

The issues are:

1/ Stats on the collection overview page doesn't get updated.  This includes 
the generation & version info.  An explicit commit (i.e. 
http://localhost:8983/solr/collection1/update?commit=true) will update the 
stats.

2/ Can't find the indexed docs on the master.  An explicit commit solves the 
issue.

I think the patch solves the original request but introduced a couple of 
side-effects.
  
> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> ch

[jira] [Commented] (SOLR-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4370:
---

Sounds like openSearcher is set to false. Can you pull the commit lines from 
your logs (that show the params)?

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4728) Allow CommonTermsQuery to be highlighted

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4728:
-

In the case of these highlighters with huge instanceof's across all queries, 
instead of doing things like:

{noformat}
+} else if (sourceQuery instanceof CommonTermsQuery) {
+  flatten(sourceQuery.rewrite(reader), reader, flatQueries);
 }
{noformat}

can't it just be something like:
{noformat}
+} else if (!sourceQuery instanceof MultiTermQuery) {
+  // an unknown query type, see if it rewrites into something we know.
+  flatten(sourceQuery.rewrite(reader), reader, flatQueries);
 }
{noformat}

then we wouldn't need explicit dependencies in these highlighters on *every 
single query*

> Allow CommonTermsQuery to be highlighted
> 
>
> Key: LUCENE-4728
> URL: https://issues.apache.org/jira/browse/LUCENE-4728
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 4.1
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4728.patch
>
>
> Add support for CommonTermsQuery to all highlighter impls. 
> This might add a dependency (query-jar) to the highlighter so we might think 
> about adding it to core?

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4370:
-

Tested the patch on 4.2 from 
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/ and found a 
couple issues when solr.commitwithin.softcommit = false.  The setting allows 
the slaves to replicate the indices and I can see the index files updated after 
commitWithin timeframe.

The issues are:

1/ Stats on the collection overview page doesn't get updated.  This includes 
the generation & version info.  An explicit commit (i.e. 
http://localhost:8983/solr/collection1/update?commit=true) will update the 
stats.

2/ Can't find the indexed docs on the master.  An explicit commit solves the 
issue.

I think the patch solves the original request but introduced a couple of 
side-effects.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-4284:
--

Stefan:

Tried it and it looks great!, Thanks! I'll be trying things out for a few days, 
but so far so good.

Erick

> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-3071) When you change the config for a collection, all nodes in the collection should reload their SolrCore.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-3071:
--

Assignee: (was: Mark Miller)

> When you change the config for a collection, all nodes in the collection 
> should reload their SolrCore.
> --
>
> Key: SOLR-3071
> URL: https://issues.apache.org/jira/browse/SOLR-3071
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> This will make it much easier to make configuration updates.

--
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-3248) CloudSolrServer should add methods to make it easier to set the collection on a per request basis

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-3248:
--

Assignee: (was: Mark Miller)

> CloudSolrServer should add methods to make it easier to set the collection on 
> a per request basis
> -
>
> Key: SOLR-3248
> URL: https://issues.apache.org/jira/browse/SOLR-3248
> Project: Solr
>  Issue Type: Improvement
>Reporter: Grant Ingersoll
>Priority: Minor
>
> It would be good if CloudSolrServer would add methods that make it easier for 
> specifying the collection, such as when adding documents.  Right now, one has 
> to use the UpdateRequest approach, which is more cumbersome.

--
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-2633) Make SolrDispatchFilter testable and add tests

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-2633:
--

Assignee: (was: Mark Miller)

> Make SolrDispatchFilter testable and add tests
> --
>
> Key: SOLR-2633
> URL: https://issues.apache.org/jira/browse/SOLR-2633
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 3.1, 3.2, 3.3
>Reporter: Edoardo Tosca
>Priority: Minor
> Attachments: SOLR-2633-tests-only.patch, SOLR-2633-tests-only.patch
>
>
> I have ideas for possible extensions/enhancements to the SolrDispatchFilter. 
> However, as it doesn't have any tests, making safe enhancements is difficult. 
> Given its monolithic nature, it is hard to test. Therefore, I am proposing to 
> refactor it to make it testable, and to provide tests for it.

--
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-2646) Integrate Solr benchmarking support into the Benchmark module

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-2646:
--

Assignee: (was: Mark Miller)

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

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

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

[jira] [Resolved] (SOLR-4202) Relax rules around accepting updates when not connected to zookeeper.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-4202.
---

Resolution: Won't Fix

> Relax rules around accepting updates when not connected to zookeeper.
> -
>
> Key: SOLR-4202
> URL: https://issues.apache.org/jira/browse/SOLR-4202
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> We are pretty tight about this currently - I think it might be a bit nicer if 
> we relax a little.
> Right now, as soon we realize we cannot talk to zookeeper, we stop accepting 
> updates in all cases.
> I think it might be better if we change that a bit for a non leader. It might 
> be nicer if it would still accept updates from the leader, but fail them. 
> This way, there is some chance that if the problem was simply a connection 
> loss with zookeeper, when the leader asks the replica to recover because it 
> failed the update, it's more likely to just take a peersync to catch up.
> Thoughts?

--
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-3604) The wiki claims all comments are wiped from solr.xml on save - we should fix this.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-3604.
---

Resolution: Won't Fix

Given solr.xml is going away, I won't be working on this.

> The wiki claims all comments are wiped from solr.xml on save - we should fix 
> this.
> --
>
> Key: SOLR-3604
> URL: https://issues.apache.org/jira/browse/SOLR-3604
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
>


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

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

[jira] [Updated] (LUCENE-4728) Allow CommonTermsQuery to be highlighted

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-4728:


Attachment: LUCENE-4728.patch

patch adding support and tests

> Allow CommonTermsQuery to be highlighted
> 
>
> Key: LUCENE-4728
> URL: https://issues.apache.org/jira/browse/LUCENE-4728
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 4.1
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4728.patch
>
>
> Add support for CommonTermsQuery to all highlighter impls. 
> This might add a dependency (query-jar) to the highlighter so we might think 
> about adding it to core?

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

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

[jira] [Updated] (LUCENE-4728) Allow CommonTermsQuery to be highlighted

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-4728:


Lucene Fields: New,Patch Available  (was: New)
 Assignee: Simon Willnauer
   Issue Type: Improvement  (was: Bug)

> Allow CommonTermsQuery to be highlighted
> 
>
> Key: LUCENE-4728
> URL: https://issues.apache.org/jira/browse/LUCENE-4728
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 4.1
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.2, 5.0
>
>
> Add support for CommonTermsQuery to all highlighter impls. 
> This might add a dependency (query-jar) to the highlighter so we might think 
> about adding it to core?

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

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

[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_10) - Build # 2461 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2461/
Java: 64bit/jdk1.7.0_10 -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory

Error Message:
Error: cannot understand algorithm!

Stack Trace:
java.lang.Exception: Error: cannot understand algorithm!
at 
__randomizedtesting.SeedInfo.seed([75F69678A092B8C1:D6EC45B7B40EADFC]:0)
at 
org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
at 
org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
at 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1088)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Line #2: 
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.java:392)
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.setParams(AnalyzerFactoryTask.java:233)
at 
org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:145)
at 
org.apache.lucene.benchmark.

[jira] [Created] (LUCENE-4728) Allow CommonTermsQuery to be highlighted

[Simon Willnauer (JIRA)]

Simon Willnauer created LUCENE-4728:
---

 Summary: Allow CommonTermsQuery to be highlighted
 Key: LUCENE-4728
 URL: https://issues.apache.org/jira/browse/LUCENE-4728
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.1
Reporter: Simon Willnauer
 Fix For: 4.2, 5.0


Add support for CommonTermsQuery to all highlighter impls. 
This might add a dependency (query-jar) to the highlighter so we might think 
about adding it to core?

--
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-4193) A ZooKeeper RequestHandler that allows you to post config files to a collections linked config set or a specific config set.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4193:
---

bq. And it seems like we should support multiple config files at once - say you 
add a field that references stopwords2.txt to schema.xml and want to upload the 
stopwords2.txt at the same time?

I added a test for this - turns out it already works no problem.

> A ZooKeeper RequestHandler that allows you to post config files to a 
> collections linked config set or a specific config set.
> 
>
> Key: SOLR-4193
> URL: https://issues.apache.org/jira/browse/SOLR-4193
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4193.patch, SOLR-4193.patch
>
>
> Could have an admin zk handler and one per core?
> An admin zk handler would allow you to access it without specifying an 
> existing core if done right.
> One per core lets you do things like:
> post solrconfig.xml to localhost:8983:/solr/collection1/zkhandler
> Then we look up what config set we linked to and overwrite the solrconfig.xml.
> You can already GET config files through another handler, so at the moment 
> I'd avoid duplicating that.
> Could imagine adding commands over time though.

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

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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_10) - Build # 2474 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2474/
Java: 64bit/jdk1.7.0_10 -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory

Error Message:
Error: cannot understand algorithm!

Stack Trace:
java.lang.Exception: Error: cannot understand algorithm!
at 
__randomizedtesting.SeedInfo.seed([7077F204B129B99C:D36D21CBA5B5ACA1]:0)
at 
org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:64)
at 
org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:82)
at 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testAnalyzerFactory(TestPerfTasksLogic.java:1086)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Line #2: 
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.createAnalysisPipelineComponent(AnalyzerFactoryTask.java:392)
at 
org.apache.lucene.benchmark.byTask.tasks.AnalyzerFactoryTask.setParams(AnalyzerFactoryTask.java:233)
at 
org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:145)
at 
org.apache.lucene.benchm

[jira] [Commented] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4052:
---

Yeah, I think you have to use flash or something to select a directory. Pretty 
annoying.

A tar/zip file is not a terrible compromise.

This would be a good feature I think - it complements SOLR-4193

> Upload files to ZooKeeper from Solr Admin interface
> ---
>
> Key: SOLR-4052
> URL: https://issues.apache.org/jira/browse/SOLR-4052
> Project: Solr
>  Issue Type: Improvement
>Reporter: Eric Pugh
> Attachments: zookeeper_edit.patch, ZookeeperInfoServletTest.java
>
>
> It would be nice if you could add files to ZooKeeper through the solr admin 
> tool instead of having to use the zkCli.  Steffan and I talked about this at 
> ApacheCon Euro, and he suggested that if I put the java code in place, he'll 
> put in the pretty GUI aspects!  This patch is based around using a tool like 
> http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet.  I 
> hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't 
> have a better sense of where it should go.   A *very* annoying thing is that 
> it seems like from the browser side you can't select a directory of files and 
> upload it, which would make loading a new solr core configuration split 
> across many directory VERY annoying.   Also, this doesn't really feel like a 
> solid solution to just pulling up a file in the ZK tree browser webpage, 
> editing it (maybe via a big text box) and then posting the contents back.

--
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-4371) Admin UI - Analysis Screen shows empty result

[Stefan Matheis (steffkes) (JIRA)]

Stefan Matheis (steffkes) created SOLR-4371:
---

 Summary: Admin UI - Analysis Screen shows empty result
 Key: SOLR-4371
 URL: https://issues.apache.org/jira/browse/SOLR-4371
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Priority: Minor


Poking around for an change to FieldAnalysisRequestHandler hoss mentioned 
SOLR-4336, which documents the cause of this.

bq. 
/solr/collection1/analysis/field?wt=json&analysis.showmatch=true&analysis.fieldvalue=foo&analysis.query=&analysis.fieldname=cat

the output will contain this:

{code}"field_names": {
"cat": {
"index": [...],
"query": [
"org.apache.solr.schema.FieldType$DefaultAnalyzer$1",
[
]
]
}
}{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] [Updated] (SOLR-3274) ZooKeeper related SolrCloud problems

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-3274:
--

Assignee: (was: Mark Miller)

> ZooKeeper related SolrCloud problems
> 
>
> Key: SOLR-3274
> URL: https://issues.apache.org/jira/browse/SOLR-3274
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-ALPHA
> Environment: Any
>Reporter: Per Steffensen
>
> Same setup as in SOLR-3273. Well if I have to tell the entire truth we have 7 
> Solr servers, running 28 slices of the same collection (collA) - all slices 
> have one replica (two shards all in all - leader + replica) - 56 cores all in 
> all (8 shards on each solr instance). But anyways...
> Besides the problem reported in SOLR-3273, the system seems to run fine under 
> high load for several hours, but eventually errors like the ones shown below 
> start to occur. I might be wrong, but they all seem to indicate some kind of 
> unstability in the collaboration between Solr and ZooKeeper. I have to say 
> that I havnt been there to check ZooKeeper "at the moment where those 
> exception occur", but basically I dont believe the exceptions occur because 
> ZooKeeper is not running stable - at least when I go and check ZooKeeper 
> through other "channels" (e.g. my eclipse ZK plugin) it is always accepting 
> my connection and generally seems to be doing fine.
> Exception 1) Often the first error we see in solr.log is something like this
> {code}
> Mar 22, 2012 5:06:43 AM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot talk to ZooKeeper - 
> Updates are disabled.
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.zkCheck(DistributedUpdateProcessor.java:678)
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:250)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:80)
> at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:407)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
> at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
> at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
> at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
> at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
> at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> I believe this error basically occurs because SolrZkClient.isConnected 
> reports false, which means that its internal "keeper.getState" does not 
> return ZooKeeper.States.CONNECTED. Im pretty sure that it has been CONNECTED 
> for a long time, since this error starts occuring after several hours of 
> processing without this problem showing. But why is it suddenly not connected 
> anymore?!
> Exception 2) We also see errors like the following, and if Im not mistaken, 
> they start occuring shortly after "Exception 1)" (above) shows for the fist 
> time
> {code}
> Mar 22, 2012 5:07:26 AM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: no servers hosting shard: 
> at 
> org.apache.solr.handler.component.Http

[jira] [Updated] (SOLR-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-4370:
--

Attachment: SOLR-4370.patch

Patch attached.

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4370.patch
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4284:
--

[branch_4x commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1439603

SOLR-4284: Admin UI - make core list scrollable separate from the rest of the 
UI (merge r1439602)


> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-3638) Height in admin ui is fixed. Should be dynamic to window height

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-3638.
-

   Resolution: Fixed
Fix Version/s: 5.0
   4.2
 Assignee: Stefan Matheis (steffkes)

Fixed as part of SOLR-4284

> Height in admin ui is fixed. Should be dynamic to window height
> ---
>
> Key: SOLR-3638
> URL: https://issues.apache.org/jira/browse/SOLR-3638
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Antony Stubbs
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> It's very frustrating that the admin interface doesn't expand to my entire 
> window size. Is there a good reason why it's restricted? Should be a simple 
> fix.

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-4284.
-

Resolution: Implemented
  Assignee: Stefan Matheis (steffkes)

> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4284:
--

[trunk commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1439602

SOLR-4284: Admin UI - make core list scrollable separate from the rest of the UI


> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-4370:
--

Fix Version/s: 5.0
   4.2

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-4370:
-

Assignee: Mark Miller

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>Assignee: Mark Miller
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4365) Make positionIncrementGap=100 the default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4365:
---

You can use Version to work with back compat, no?

> Make positionIncrementGap=100 the default
> -
>
> Key: SOLR-4365
> URL: https://issues.apache.org/jira/browse/SOLR-4365
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: David Smiley
>Priority: Minor
>
> Instead of every field type defining the same positionIncrementGap of 100, 
> why not make 100 the default?  It'll remove redundant noise in the file.  
> I've never bothered to change it.

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

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

[jira] [Resolved] (LUCENE-4723) Add AnalyzerFactoryTask to benchmark, and enable analyzer creation via the resulting factories using NewAnalyzerTask

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-4723.


   Resolution: Fixed
Fix Version/s: 4.2

Committed to trunk and branch_4x.

> Add AnalyzerFactoryTask to benchmark, and enable analyzer creation via the 
> resulting factories using NewAnalyzerTask
> 
>
> Key: LUCENE-4723
> URL: https://issues.apache.org/jira/browse/LUCENE-4723
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/benchmark
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 4.2
>
> Attachments: LUCENE-4723.patch, LUCENE-4723.patch
>
>
> Benchmark algorithms can't currently use analysis factories.  Instead, one 
> must rely on pre-existing analyzers, or write specialized tasks to construct 
> them.
> Now that all analysis components have factories, benchmark algorithms should 
> be able to use them.

--
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-4365) Make positionIncrementGap=100 the default

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-4365:


bq. why not make 100 the default?

-1

The current default is "0", changing the default to "100" would break back 
compat for any users who has every definied their own fieldType and left off 
the positionIncremment attribute (ie: phrase queries that previously matched 
documents would no longer match)

> Make positionIncrementGap=100 the default
> -
>
> Key: SOLR-4365
> URL: https://issues.apache.org/jira/browse/SOLR-4365
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: David Smiley
>Priority: Minor
>
> Instead of every field type defining the same positionIncrementGap of 100, 
> why not make 100 the default?  It'll remove redundant noise in the file.  
> I've never bothered to change it.

--
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-4342) stats of SolrInfoMBeanHandler have mixed structure

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4342:
--

[branch_4x commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1439544

SOLR-4342: Fix DataImportHandler stats to be a prper Map (merge r1439536)


> stats of SolrInfoMBeanHandler have mixed structure
> --
>
> Key: SOLR-4342
> URL: https://issues.apache.org/jira/browse/SOLR-4342
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Hoss Man
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> Not sure which Component fits for this?!
> Calling {{/admin/mbeans?stats=true&wt=json}} normally gives this for an entry:
> {code}"/admin/mbeans": {
>   "class": "org.apache.solr.handler.admin.SolrInfoMBeanHandler",
>   "version": "5.0.0.2013.01.22.17.57.48",
>   "description": "Get Info (and statistics) for registered SolrInfoMBeans",
>   "src": "$URL: 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/SolrInfoMBeanHandler.java
>  $",
>   "stats": {
> "handlerStart": 1358960935983,
> "requests": 16,
> "errors": 0,
> "timeouts": 0,
> "totalTime": 238.636824,
> "avgRequestsPerSecond": 0.0010339617096334008,
> "5minRateReqsPerSecond": 0.009435751279543023,
> "15minRateReqsPerSecond": 0.008764046777884586,
> "avgTimePerRequest": 15.9091215,
> "medianRequestTime": 15.43261,
> "75thPcRequestTime": 16.544159,
> "95thPcRequestTime": 24.570421,
> "99thPcRequestTime": 24.570421,
> "999thPcRequestTime": 24.570421
>   }
> },{code}
> but for instances of {{DataImportHandler}} it looks like this:
> {code}"/dataimport": {
>   "class": "org.apache.solr.handler.dataimport.DataImportHandler",
>   "version": "5.0.0.2013.01.12.19.48.17",
>   "description": "Manage data import from databases to Solr",
>   "src": "$URL: 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
>  $",
>   "stats": [
> "Status",
> "IDLE",
> "Total Documents Processed",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Requests made to DataSource",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Rows Fetched",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Documents Deleted",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Documents Skipped",
> "java.util.concurrent.atomic.AtomicLong:0",
> "handlerStart",
> 1358960935773,
> "requests",
> 1,
> "errors",
> 0,
> "timeouts",
> 0,
> "totalTime",
> 0.946654,
> "avgRequestsPerSecond",
> 0.6892979803330725,
> "5minRateReqsPerSecond",
> 8.281462403544473e-23,
> "15minRateReqsPerSecond",
> 3.2421452678347006e-10,
> "avgTimePerRequest",
> 0.946654,
> "medianRequestTime",
> 0.946654,
> "75thPcRequestTime",
> 0.946654,
> "95thPcRequestTime",
> 0.946654,
> "99thPcRequestTime",
> 0.946654,
> "999thPcRequestTime",
> 0.946654
>   ]
> },{code}
> if i recall another issue correctly, that has something to do with using (or 
> otherwise not using) {{SimpleOrderedMap}} oO

--
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-4342) stats of SolrInfoMBeanHandler have mixed structure

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-4342.


   Resolution: Fixed
Fix Version/s: 5.0
   4.2
 Assignee: Hoss Man

Committed revision 1439536.
Committed revision 1439544.


> stats of SolrInfoMBeanHandler have mixed structure
> --
>
> Key: SOLR-4342
> URL: https://issues.apache.org/jira/browse/SOLR-4342
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Hoss Man
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> Not sure which Component fits for this?!
> Calling {{/admin/mbeans?stats=true&wt=json}} normally gives this for an entry:
> {code}"/admin/mbeans": {
>   "class": "org.apache.solr.handler.admin.SolrInfoMBeanHandler",
>   "version": "5.0.0.2013.01.22.17.57.48",
>   "description": "Get Info (and statistics) for registered SolrInfoMBeans",
>   "src": "$URL: 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/SolrInfoMBeanHandler.java
>  $",
>   "stats": {
> "handlerStart": 1358960935983,
> "requests": 16,
> "errors": 0,
> "timeouts": 0,
> "totalTime": 238.636824,
> "avgRequestsPerSecond": 0.0010339617096334008,
> "5minRateReqsPerSecond": 0.009435751279543023,
> "15minRateReqsPerSecond": 0.008764046777884586,
> "avgTimePerRequest": 15.9091215,
> "medianRequestTime": 15.43261,
> "75thPcRequestTime": 16.544159,
> "95thPcRequestTime": 24.570421,
> "99thPcRequestTime": 24.570421,
> "999thPcRequestTime": 24.570421
>   }
> },{code}
> but for instances of {{DataImportHandler}} it looks like this:
> {code}"/dataimport": {
>   "class": "org.apache.solr.handler.dataimport.DataImportHandler",
>   "version": "5.0.0.2013.01.12.19.48.17",
>   "description": "Manage data import from databases to Solr",
>   "src": "$URL: 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
>  $",
>   "stats": [
> "Status",
> "IDLE",
> "Total Documents Processed",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Requests made to DataSource",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Rows Fetched",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Documents Deleted",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Documents Skipped",
> "java.util.concurrent.atomic.AtomicLong:0",
> "handlerStart",
> 1358960935773,
> "requests",
> 1,
> "errors",
> 0,
> "timeouts",
> 0,
> "totalTime",
> 0.946654,
> "avgRequestsPerSecond",
> 0.6892979803330725,
> "5minRateReqsPerSecond",
> 8.281462403544473e-23,
> "15minRateReqsPerSecond",
> 3.2421452678347006e-10,
> "avgTimePerRequest",
> 0.946654,
> "medianRequestTime",
> 0.946654,
> "75thPcRequestTime",
> 0.946654,
> "95thPcRequestTime",
> 0.946654,
> "99thPcRequestTime",
> 0.946654,
> "999thPcRequestTime",
> 0.946654
>   ]
> },{code}
> if i recall another issue correctly, that has something to do with using (or 
> otherwise not using) {{SimpleOrderedMap}} oO

--
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-4369) Add information about Solr 4.0 Cookbook to https://lucene.apache.org/solr/

[JIRA]

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

Rafał Kuć updated SOLR-4369:


Attachment: SOLR-4369.patch
book_s4c.jpg

Attaching a patch and a cover for the book. The cover is 150px x 180px so it 
should be OK. 

> Add information about Solr 4.0 Cookbook to https://lucene.apache.org/solr/
> --
>
> Key: SOLR-4369
> URL: https://issues.apache.org/jira/browse/SOLR-4369
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Reporter: Rafał Kuć
>Priority: Minor
> Attachments: book_s4c.jpg, SOLR-4369.patch
>
>
> I think it would be good to have the information about new version of 
> Cookbook available. Now the question is, how it is currently handled after 
> moving away from Apache Forrest to the new site based on CMS. 

--
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: svn commit: r1439532 - /lucene/dev/branches/lucene4547/lucene/core/src/test/org/apache/lucene/util/packed/TestPackedInts.java

[Robert Muir]

Thanks Adrien!

On Mon, Jan 28, 2013 at 1:05 PM, Adrien Grand  wrote:
> On Mon, Jan 28, 2013 at 6:59 PM,   wrote:
>> Author: rmuir
>> Date: Mon Jan 28 17:59:33 2013
>> New Revision: 1439532
>>
>> URL: http://svn.apache.org/viewvc?rev=1439532&view=rev
>> Log:
>> add nocommit
>
> Looks like we committed at the same time. :-) I committed a fix in r1439530.
>
> --
> 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: svn commit: r1439532 - /lucene/dev/branches/lucene4547/lucene/core/src/test/org/apache/lucene/util/packed/TestPackedInts.java

[Adrien Grand]

On Mon, Jan 28, 2013 at 6:59 PM,   wrote:
> Author: rmuir
> Date: Mon Jan 28 17:59:33 2013
> New Revision: 1439532
>
> URL: http://svn.apache.org/viewvc?rev=1439532&view=rev
> Log:
> add nocommit

Looks like we committed at the same time. :-) I committed a fix in r1439530.

-- 
Adrien

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

[jira] [Commented] (SOLR-4342) stats of SolrInfoMBeanHandler have mixed structure

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4342:
--

[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1439536

SOLR-4342: Fix DataImportHandler stats to be a prper Map


> stats of SolrInfoMBeanHandler have mixed structure
> --
>
> Key: SOLR-4342
> URL: https://issues.apache.org/jira/browse/SOLR-4342
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Stefan Matheis (steffkes)
>Priority: Minor
>
> Not sure which Component fits for this?!
> Calling {{/admin/mbeans?stats=true&wt=json}} normally gives this for an entry:
> {code}"/admin/mbeans": {
>   "class": "org.apache.solr.handler.admin.SolrInfoMBeanHandler",
>   "version": "5.0.0.2013.01.22.17.57.48",
>   "description": "Get Info (and statistics) for registered SolrInfoMBeans",
>   "src": "$URL: 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/SolrInfoMBeanHandler.java
>  $",
>   "stats": {
> "handlerStart": 1358960935983,
> "requests": 16,
> "errors": 0,
> "timeouts": 0,
> "totalTime": 238.636824,
> "avgRequestsPerSecond": 0.0010339617096334008,
> "5minRateReqsPerSecond": 0.009435751279543023,
> "15minRateReqsPerSecond": 0.008764046777884586,
> "avgTimePerRequest": 15.9091215,
> "medianRequestTime": 15.43261,
> "75thPcRequestTime": 16.544159,
> "95thPcRequestTime": 24.570421,
> "99thPcRequestTime": 24.570421,
> "999thPcRequestTime": 24.570421
>   }
> },{code}
> but for instances of {{DataImportHandler}} it looks like this:
> {code}"/dataimport": {
>   "class": "org.apache.solr.handler.dataimport.DataImportHandler",
>   "version": "5.0.0.2013.01.12.19.48.17",
>   "description": "Manage data import from databases to Solr",
>   "src": "$URL: 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
>  $",
>   "stats": [
> "Status",
> "IDLE",
> "Total Documents Processed",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Requests made to DataSource",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Rows Fetched",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Documents Deleted",
> "java.util.concurrent.atomic.AtomicLong:0",
> "Total Documents Skipped",
> "java.util.concurrent.atomic.AtomicLong:0",
> "handlerStart",
> 1358960935773,
> "requests",
> 1,
> "errors",
> 0,
> "timeouts",
> 0,
> "totalTime",
> 0.946654,
> "avgRequestsPerSecond",
> 0.6892979803330725,
> "5minRateReqsPerSecond",
> 8.281462403544473e-23,
> "15minRateReqsPerSecond",
> 3.2421452678347006e-10,
> "avgTimePerRequest",
> 0.946654,
> "medianRequestTime",
> 0.946654,
> "75thPcRequestTime",
> 0.946654,
> "95thPcRequestTime",
> 0.946654,
> "99thPcRequestTime",
> 0.946654,
> "999thPcRequestTime",
> 0.946654
>   ]
> },{code}
> if i recall another issue correctly, that has something to do with using (or 
> otherwise not using) {{SimpleOrderedMap}} oO

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4370:


Description: 
We need the ability to control the hard/soft commit behaviour of commitWithin 
parameter.

Since Solr 4.0, the commitWithin's performs a soft-commit which prevents slaves 
from picking up the changes in a master/slave configuration.

The behaviour I'm thinking is as follows:

1.  By default, commitWithin will trigger soft commits.

2.  But this behaviour can be overwritten in solrconfig.xml to allow 
commitWithin to perform hard commits, which will allow slaves to pick up the 
changes.


true 


Related to SOLR-4100

  was:
We need the ability to control the hard/soft commit behaviour of commitWithin 
parameter.

Since Solr 4.0, the commitWithin's performs a soft-commit which prevents slaves 
from picking up the changes in a master/slave configuration.

The behaviour I'm thinking is as follows:

1.  By default, commitWithin will perform a soft-commit.

2.  But this behaviour can be overwritten in solrconfig.xml to allow 
commitWithin to perform hard commits, which will allow slaves to pick up the 
changes.


true 


Related to SOLR-4100


> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will trigger soft commits.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4370:


Description: 
We need the ability to control the hard/soft commit behaviour of commitWithin 
parameter.

Since Solr 4.0, the commitWithin's performs a soft-commit which prevents slaves 
from picking up the changes in a master/slave configuration.

The behaviour I'm thinking is as follows:

1.  By default, commitWithin will perform a soft-commit.

2.  But this behaviour can be overwritten in solrconfig.xml to allow 
commitWithin to perform hard commits, which will allow slaves to pick up the 
changes.


true 


Related to SOLR-4100

  was:
We need the ability to control the hard/soft commit behaviour of commitWithin 
parameter.

Since Solr 4.0, the commitWithin's performs a soft-commit which prevents slaves 
from picking up the changes in a master/slave configuration.

The behaviour I'm thinking is as follows:

1.  By default, commitWithin will perform a soft-commit that will help with NRT.

2.  But this behaviour can be overwritten in solrconfig.xml to allow 
commitWithin to perform hard commits, which will allow slaves to pick up the 
changes.


true 


Related to SOLR-4100


> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will perform a soft-commit.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4100) commitWithin (soft commit = true): version number of master index not changed => no replication to slave is done!

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan commented on SOLR-4100:
-

I've created a new feature request to modify the default behaviour.  Please see 
SOLR-4370.  Thanks!

> commitWithin (soft commit = true): version number of master index not changed 
> => no replication to slave is done!
> -
>
> Key: SOLR-4100
> URL: https://issues.apache.org/jira/browse/SOLR-4100
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.0
>Reporter: Roland Deck
>
> I have a master and a slave solr instance. In solrconfig.xml, a replication 
> handler is present (slave points to master via masterUrl).
> 1) If you add a document to the master solr via curl http:// : This works 
> and the document is replicated to the slave.
> 2) If you add a document in Java via solrj and use the following code snippet:
> public static void main(String[] args) throws Exception {
> ConcurrentUpdateSolrServer solrServer = 
> SolrServerFactory.createSolrServerForUpdate("localhost", "9100",  
> "/solr", "eventlocation", 5, 2);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", "TEST_ID");
> doc.addField("title", "some test title");
> UpdateResponse urep = solrServer.add(doc);
> System.out.println("response status: "+urep.getStatus());
> solrServer.commit();
> }
>   
> This works and the document is replicated to the slave.
> The logfile states as following:
> INFO: [eventlocation] webapp=/solr path=/update params={wt=javabin&version=2} 
> {add=[TEST_ID]} 0 249
> 21.11.2012 08:31:19 org.apache.solr.update.DirectUpdateHandler2 commit
> INFO: start 
> commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
> 21.11.2012 08:31:19 org.apache.solr.core.SolrDeletionPolicy onCommit
> INFO: SolrDeletionPolicy.onCommit: commits:num=2
>   
> commit{dir=C:\temp\nimela\searchapp\master\nimela\solr\eventlocation\data\index,segFN=segments_2,generation=2,filenames=[_0_Lucene40_0.tim,
>  _0.fnm, _0_Lucene40_0.frq, _0_nrm.cfe, _0_1.del, segments_2, _0.fdx, 
> _0_nrm.cfs, _0.si, _0_Lucene40_0.prx, _0.fdt, _0_Lucene40_0.tip]
>   
> commit{dir=C:\temp\nimela\searchapp\master\nimela\solr\eventlocation\data\index,segFN=segments_3,generation=3,filenames=[_1_Lucene40_0.tim,
>  _1_nrm.cfs, _0_Lucene40_0.tim, _0.fnm, _1_Lucene40_0.frq, _0_1.del, 
> _0_nrm.cfs, _0_Lucene40_0.prx, _1.fnm, _1_Lucene40_0.prx, _1_Lucene40_0.tip, 
> _1_nrm.cfe, _0_Lucene40_0.tip, _1.fdx, _0_Lucene40_0.frq, _1.fdt, _1.si, 
> _0_nrm.cfe, _0.fdx, _0.si, segments_3, _0.fdt]
> 21.11.2012 08:31:19 org.apache.solr.core.SolrDeletionPolicy updateCommits
> INFO: newest commit = 3
> 3) If you add a document in Java via solrj and use the following code snippet:
> public static void main(String[] args) throws Exception {
> ConcurrentUpdateSolrServer solrServer = 
> SolrServerFactory.createSolrServerForUpdate("localhost", "9100",  
> "/solr", "eventlocation", 5, 2);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", "TEST_ID_DUE");
> doc.addField("title", "some test title for due");
> UpdateResponse urep = solrServer.add(doc, 1); //commit within 10s.
> System.out.println("response status: "+urep.getStatus());
> }
> This works on the master, but the version number is left the same, so that 
> replication doesn't take place, leaving the slave in the previous state. 
> This is certainly a bug and should be fixed.
> The logfile states as following:
> INFO: [eventlocation] webapp=/solr path=/update params={wt=javabin&version=2} 
> {add=[TEST_ID_DUE]} 0 249
> INFO: start 
> commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true}
> 21.11.2012 08:37:30 org.apache.solr.search.SolrIndexSearcher 
> INFO: Opening Searcher@18590c5 main
> 21.11.2012 08:37:30 org.apache.solr.update.DirectUpdateHandler2 commit
> INFO: end_commit_flush
> It seams to me that this softCommit mechanism doesn't work properly 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-4370) Ability to control the commit behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

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

Senthuran Sivananthan updated SOLR-4370:


Summary: Ability to control the commit behaviour of commitWithin  (was: 
Ability to control the behaviour of commitWithin)

> Ability to control the commit behaviour of commitWithin
> ---
>
> Key: SOLR-4370
> URL: https://issues.apache.org/jira/browse/SOLR-4370
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Affects Versions: 4.0, 4.1
>Reporter: Senthuran Sivananthan
>
> We need the ability to control the hard/soft commit behaviour of commitWithin 
> parameter.
> Since Solr 4.0, the commitWithin's performs a soft-commit which prevents 
> slaves from picking up the changes in a master/slave configuration.
> The behaviour I'm thinking is as follows:
> 1.  By default, commitWithin will perform a soft-commit that will help with 
> NRT.
> 2.  But this behaviour can be overwritten in solrconfig.xml to allow 
> commitWithin to perform hard commits, which will allow slaves to pick up the 
> changes.
>   
>   true 
>   
> Related to SOLR-4100

--
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-4370) Ability to control the behaviour of commitWithin

[Senthuran Sivananthan (JIRA)]

Senthuran Sivananthan created SOLR-4370:
---

 Summary: Ability to control the behaviour of commitWithin
 Key: SOLR-4370
 URL: https://issues.apache.org/jira/browse/SOLR-4370
 Project: Solr
  Issue Type: New Feature
  Components: replication (java)
Affects Versions: 4.1, 4.0
Reporter: Senthuran Sivananthan


We need the ability to control the hard/soft commit behaviour of commitWithin 
parameter.

Since Solr 4.0, the commitWithin's performs a soft-commit which prevents slaves 
from picking up the changes in a master/slave configuration.

The behaviour I'm thinking is as follows:

1.  By default, commitWithin will perform a soft-commit that will help with NRT.

2.  But this behaviour can be overwritten in solrconfig.xml to allow 
commitWithin to perform hard commits, which will allow slaves to pick up the 
changes.


true 


Related to SOLR-4100

--
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-4284) admin UI - make core list scrollable separate from the rest of the UI

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-4284:


Attachment: SOLR-4284.patch

> admin UI - make core list scrollable separate from the rest of the UI
> -
>
> Key: SOLR-4284
> URL: https://issues.apache.org/jira/browse/SOLR-4284
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4284.patch, SOLR-4284.patch, SOLR-4284.patch, 
> SOLR-4284.patch, SOLR-4284.patch
>
>
> If the list of cores goes beyond the bottom of the browser window, it would 
> be nice if the user could scroll through that list with the mouse wheel 
> without making the main part of the window move.  This would particularly 
> important for someone with hundreds or thousands of cores.
> I'm not sure if this is even possible.

--
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: Build failed in Jenkins: the_4547_machine_gun_with_no_spaces_in_its_name #1114

[Robert Muir]

I fixed these

On Mon, Jan 28, 2013 at 12:27 PM, Charlie Cron
 wrote:
> See 
> 
>
> --
> [...truncated 2269 lines...]
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> [junit4:junit4]>at java.lang.Thread.run(Thread.java:722)
> [junit4:junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestPerFieldDocValuesFormat -Dtests.method=testThreeFieldsMixed 
> -Dtests.seed=93F87BE9057740B4 -Dtests.slow=true -Dtests.locale=th_TH 
> -Dtests.timezone=Etc/GMT+12 -Dtests.file.encoding=UTF-8
> [junit4:junit4] ERROR   0.01s J0 | 
> TestPerFieldDocValuesFormat.testThreeFieldsMixed <<<
> [junit4:junit4]> Throwable #1: java.lang.NullPointerException
> [junit4:junit4]>at 
> __randomizedtesting.SeedInfo.seed([93F87BE9057740B4:78CA989E33E3990]:0)
> [junit4:junit4]>at 
> org.apache.lucene.index.StoredFieldsProcessor.initFieldsWriter(StoredFieldsProcessor.java:86)
> [junit4:junit4]>at 
> org.apache.lucene.index.StoredFieldsProcessor.finishDocument(StoredFieldsProcessor.java:119)
> [junit4:junit4]>at 
> org.apache.lucene.index.TwoStoredFieldsConsumers.finishDocument(TwoStoredFieldsConsumers.java:65)
> [junit4:junit4]>at 
> org.apache.lucene.index.DocFieldProcessor.finishDocument(DocFieldProcessor.java:290)
> [junit4:junit4]>at 
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:274)
> [junit4:junit4]>at 
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:376)
> [junit4:junit4]>at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1471)
> [junit4:junit4]>at 
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1146)
> [junit4:junit4]>at 
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1127)
> [junit4:junit4]>at 
> org.apache.lucene.index.BaseDocValuesFormatTestCase.testThreeFieldsMixed(BaseDocValuesFormatTestCase.java:235)
> [junit4:junit4]>at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4:junit4]>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [junit4:junit4]>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4:junit4]>at java.lang.reflect.Method.invoke(Method.java:601)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> [junit4:junit4]>at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> [junit4:junit4]>at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> [junit4:junit4]>at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> [junit4:junit4] 

[jira] [Commented] (SOLR-4100) commitWithin (soft commit = true): version number of master index not changed => no replication to slave is done!

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4100:
---

This feature is related to nrt, not SolrCloud. I'd suggest opening a feature 
request that let's you modify the default behavior.

> commitWithin (soft commit = true): version number of master index not changed 
> => no replication to slave is done!
> -
>
> Key: SOLR-4100
> URL: https://issues.apache.org/jira/browse/SOLR-4100
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.0
>Reporter: Roland Deck
>
> I have a master and a slave solr instance. In solrconfig.xml, a replication 
> handler is present (slave points to master via masterUrl).
> 1) If you add a document to the master solr via curl http:// : This works 
> and the document is replicated to the slave.
> 2) If you add a document in Java via solrj and use the following code snippet:
> public static void main(String[] args) throws Exception {
> ConcurrentUpdateSolrServer solrServer = 
> SolrServerFactory.createSolrServerForUpdate("localhost", "9100",  
> "/solr", "eventlocation", 5, 2);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", "TEST_ID");
> doc.addField("title", "some test title");
> UpdateResponse urep = solrServer.add(doc);
> System.out.println("response status: "+urep.getStatus());
> solrServer.commit();
> }
>   
> This works and the document is replicated to the slave.
> The logfile states as following:
> INFO: [eventlocation] webapp=/solr path=/update params={wt=javabin&version=2} 
> {add=[TEST_ID]} 0 249
> 21.11.2012 08:31:19 org.apache.solr.update.DirectUpdateHandler2 commit
> INFO: start 
> commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
> 21.11.2012 08:31:19 org.apache.solr.core.SolrDeletionPolicy onCommit
> INFO: SolrDeletionPolicy.onCommit: commits:num=2
>   
> commit{dir=C:\temp\nimela\searchapp\master\nimela\solr\eventlocation\data\index,segFN=segments_2,generation=2,filenames=[_0_Lucene40_0.tim,
>  _0.fnm, _0_Lucene40_0.frq, _0_nrm.cfe, _0_1.del, segments_2, _0.fdx, 
> _0_nrm.cfs, _0.si, _0_Lucene40_0.prx, _0.fdt, _0_Lucene40_0.tip]
>   
> commit{dir=C:\temp\nimela\searchapp\master\nimela\solr\eventlocation\data\index,segFN=segments_3,generation=3,filenames=[_1_Lucene40_0.tim,
>  _1_nrm.cfs, _0_Lucene40_0.tim, _0.fnm, _1_Lucene40_0.frq, _0_1.del, 
> _0_nrm.cfs, _0_Lucene40_0.prx, _1.fnm, _1_Lucene40_0.prx, _1_Lucene40_0.tip, 
> _1_nrm.cfe, _0_Lucene40_0.tip, _1.fdx, _0_Lucene40_0.frq, _1.fdt, _1.si, 
> _0_nrm.cfe, _0.fdx, _0.si, segments_3, _0.fdt]
> 21.11.2012 08:31:19 org.apache.solr.core.SolrDeletionPolicy updateCommits
> INFO: newest commit = 3
> 3) If you add a document in Java via solrj and use the following code snippet:
> public static void main(String[] args) throws Exception {
> ConcurrentUpdateSolrServer solrServer = 
> SolrServerFactory.createSolrServerForUpdate("localhost", "9100",  
> "/solr", "eventlocation", 5, 2);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", "TEST_ID_DUE");
> doc.addField("title", "some test title for due");
> UpdateResponse urep = solrServer.add(doc, 1); //commit within 10s.
> System.out.println("response status: "+urep.getStatus());
> }
> This works on the master, but the version number is left the same, so that 
> replication doesn't take place, leaving the slave in the previous state. 
> This is certainly a bug and should be fixed.
> The logfile states as following:
> INFO: [eventlocation] webapp=/solr path=/update params={wt=javabin&version=2} 
> {add=[TEST_ID_DUE]} 0 249
> INFO: start 
> commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true}
> 21.11.2012 08:37:30 org.apache.solr.search.SolrIndexSearcher 
> INFO: Opening Searcher@18590c5 main
> 21.11.2012 08:37:30 org.apache.solr.update.DirectUpdateHandler2 commit
> INFO: end_commit_flush
> It seams to me that this softCommit mechanism doesn't work properly 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-4306) Utilize indexInfo=false when gathering core names in UI

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4306:
--

[trunk commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1439516

SOLR-4306: Utilize indexInfo=false when gathering core names in UI


> Utilize indexInfo=false when gathering core names in UI
> ---
>
> Key: SOLR-4306
> URL: https://issues.apache.org/jira/browse/SOLR-4306
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4306.patch, SOLR-4306.patch
>
>
> The capability added by SOLR-4302 could be used to speed up loading the UI, 
> by not gathering full information from the core admin.

--
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-4306) Utilize indexInfo=false when gathering core names in UI

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4306:
--

[branch_4x commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1439518

SOLR-4306: Utilize indexInfo=false when gathering core names in UI (merge 
r1439516)


> Utilize indexInfo=false when gathering core names in UI
> ---
>
> Key: SOLR-4306
> URL: https://issues.apache.org/jira/browse/SOLR-4306
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4306.patch, SOLR-4306.patch
>
>
> The capability added by SOLR-4302 could be used to speed up loading the UI, 
> by not gathering full information from the core admin.

--
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-4306) Utilize indexInfo=false when gathering core names in UI

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-4306.
-

Resolution: Implemented

> Utilize indexInfo=false when gathering core names in UI
> ---
>
> Key: SOLR-4306
> URL: https://issues.apache.org/jira/browse/SOLR-4306
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4306.patch, SOLR-4306.patch
>
>
> The capability added by SOLR-4302 could be used to speed up loading the UI, 
> by not gathering full information from the core admin.

--
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-4306) Utilize indexInfo=false when gathering core names in UI

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-4306:


 Assignee: Stefan Matheis (steffkes)
Affects Version/s: (was: 4.0)
   4.1

> Utilize indexInfo=false when gathering core names in UI
> ---
>
> Key: SOLR-4306
> URL: https://issues.apache.org/jira/browse/SOLR-4306
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.1
>Reporter: Shawn Heisey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4306.patch, SOLR-4306.patch
>
>
> The capability added by SOLR-4302 could be used to speed up loading the UI, 
> by not gathering full information from the core admin.

--
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-4723) Add AnalyzerFactoryTask to benchmark, and enable analyzer creation via the resulting factories using NewAnalyzerTask

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4723:


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

LUCENE-4723: Add AnalyzerFactoryTask to benchmark, and enable analyzer creation 
via the resulting factories using NewAnalyzerTask. (merged trunk r* 
LUCENE-4723: Add AnalyzerFactoryTask to benchmark, and enable analyzer)


> Add AnalyzerFactoryTask to benchmark, and enable analyzer creation via the 
> resulting factories using NewAnalyzerTask
> 
>
> Key: LUCENE-4723
> URL: https://issues.apache.org/jira/browse/LUCENE-4723
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/benchmark
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-4723.patch, LUCENE-4723.patch
>
>
> Benchmark algorithms can't currently use analysis factories.  Instead, one 
> must rely on pre-existing analyzers, or write specialized tasks to construct 
> them.
> Now that all analysis components have factories, benchmark algorithms should 
> be able to use them.

--
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-3188) New admin page: "Enable Polling" button disappears after disabling polling and reloading page

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-3188.
-

Resolution: Invalid

Still no Feedback from the Issue-Owner, resolving this as 'invalid' - otherwise 
don't mind to reopen it.

> New admin page: "Enable Polling" button disappears after disabling polling 
> and reloading page
> -
>
> Key: SOLR-3188
> URL: https://issues.apache.org/jira/browse/SOLR-3188
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Neil Hooey
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
>  Labels: admin
>
> When you go to this URL on a slave:
> http://localhost:8983/solr/#/singlecore/replication
> And click the "Disable Polling" button, you see a red bar that says 
> "invalid_master". I'm not sure why I get this red bar, as I haven't tested it 
> outside of my own installation, but it seems normal.
> If you then refresh the page, the "Replicate Now" and "Enable Polling" 
> buttons disappear. It seems like their generation is being interrupted by the 
> "invalid_master" error.

--
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-3640) Core Admin UI issues on Chrome

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) commented on SOLR-3640:
-

[~astubbs] your last comment from july suggest that it worked (again), so can 
we close this issue?

> Core Admin UI issues on Chrome
> --
>
> Key: SOLR-3640
> URL: https://issues.apache.org/jira/browse/SOLR-3640
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Antony Stubbs
>Priority: Minor
> Attachments: ASF.LICENSE.NOT.GRANTED--screenshot-1.jpg, Screen Shot 
> 2012-07-18 at 3.05.10 PM.png, TermInfo.png
>
>
> Trying to click on any of the buttons apparently has no affect. They also 
> have no icons next to them anymore and appear down the left.

--
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: the_4547_machine_gun_with_no_spaces_in_its_name #1114

[Charlie Cron]

See 


--
[...truncated 2269 lines...]
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4]>at java.lang.Thread.run(Thread.java:722)
[junit4:junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPerFieldDocValuesFormat -Dtests.method=testThreeFieldsMixed 
-Dtests.seed=93F87BE9057740B4 -Dtests.slow=true -Dtests.locale=th_TH 
-Dtests.timezone=Etc/GMT+12 -Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR   0.01s J0 | 
TestPerFieldDocValuesFormat.testThreeFieldsMixed <<<
[junit4:junit4]> Throwable #1: java.lang.NullPointerException
[junit4:junit4]>at 
__randomizedtesting.SeedInfo.seed([93F87BE9057740B4:78CA989E33E3990]:0)
[junit4:junit4]>at 
org.apache.lucene.index.StoredFieldsProcessor.initFieldsWriter(StoredFieldsProcessor.java:86)
[junit4:junit4]>at 
org.apache.lucene.index.StoredFieldsProcessor.finishDocument(StoredFieldsProcessor.java:119)
[junit4:junit4]>at 
org.apache.lucene.index.TwoStoredFieldsConsumers.finishDocument(TwoStoredFieldsConsumers.java:65)
[junit4:junit4]>at 
org.apache.lucene.index.DocFieldProcessor.finishDocument(DocFieldProcessor.java:290)
[junit4:junit4]>at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:274)
[junit4:junit4]>at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:376)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1471)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1146)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1127)
[junit4:junit4]>at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testThreeFieldsMixed(BaseDocValuesFormatTestCase.java:235)
[junit4:junit4]>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
[junit4:junit4]>at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit4:junit4]>at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4:junit4]>at java.lang.reflect.Method.invoke(Method.java:601)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
[junit4:junit4]>at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
[ju

[jira] [Commented] (LUCENE-4642) TokenizerFactory should provide a create method with a given AttributeSource

[Renaud Delbru (JIRA)]

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

Renaud Delbru commented on LUCENE-4642:
---

Great, I think that AttributeFactory hack could work for us. Would you agree to 
add a TokenizerFactory.create(AttributeFactory) method ? I could prepare a 
patch for that.

> TokenizerFactory should provide a create method with a given AttributeSource
> 
>
> Key: LUCENE-4642
> URL: https://issues.apache.org/jira/browse/LUCENE-4642
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 4.1
>Reporter: Renaud Delbru
>Assignee: Steve Rowe
>  Labels: analysis, attribute, tokenizer
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4642.patch, LUCENE-4642.patch, 
> TrieTokenizerFactory.java.patch
>
>
> All tokenizer implementations have a constructor that takes a given 
> AttributeSource as parameter (LUCENE-1826). However, the TokenizerFactory 
> does not provide an API to create tokenizers with a given AttributeSource.
> Side note: There are still a lot of tokenizers that do not provide 
> constructors that take AttributeSource and AttributeFactory.

--
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: the_4547_machine_gun_with_no_spaces_in_its_name #1113

[Charlie Cron]

See 


--
[...truncated 2272 lines...]
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4]>at java.lang.Thread.run(Thread.java:722)
[junit4:junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPerFieldDocValuesFormat -Dtests.method=testCodecUsesOwnBytes 
-Dtests.seed=91741335D528C776 -Dtests.slow=true -Dtests.locale=ar_LB 
-Dtests.timezone=PST8PDT -Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR   0.01s J2 | 
TestPerFieldDocValuesFormat.testCodecUsesOwnBytes <<<
[junit4:junit4]> Throwable #1: java.lang.NullPointerException
[junit4:junit4]>at 
__randomizedtesting.SeedInfo.seed([91741335D528C776:424B31F8CE29FA07]:0)
[junit4:junit4]>at 
org.apache.lucene.index.StoredFieldsProcessor.initFieldsWriter(StoredFieldsProcessor.java:86)
[junit4:junit4]>at 
org.apache.lucene.index.StoredFieldsProcessor.finishDocument(StoredFieldsProcessor.java:119)
[junit4:junit4]>at 
org.apache.lucene.index.TwoStoredFieldsConsumers.finishDocument(TwoStoredFieldsConsumers.java:65)
[junit4:junit4]>at 
org.apache.lucene.index.DocFieldProcessor.finishDocument(DocFieldProcessor.java:290)
[junit4:junit4]>at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:274)
[junit4:junit4]>at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:376)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1471)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1146)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1127)
[junit4:junit4]>at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testCodecUsesOwnBytes(BaseDocValuesFormatTestCase.java:848)
[junit4:junit4]>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
[junit4:junit4]>at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit4:junit4]>at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4:junit4]>at java.lang.reflect.Method.invoke(Method.java:601)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
[junit4:junit4]>at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.

[jira] [Commented] (SOLR-3986) index version and generation not changed in admin UI after delete by query on master

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) commented on SOLR-3986:
-

[~billa] is the still valid? Even for 4.1 and maybe trunk as well?

> index version and generation not changed in admin UI after delete by query on 
> master
> 
>
> Key: SOLR-3986
> URL: https://issues.apache.org/jira/browse/SOLR-3986
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Bill Au
>Priority: Minor
>
> Here are the steps to reproduce this:
> - follow steps in Solr 4.0 tutorial to set up a master and a slave to use 
> Java/HTTP replication
> - index example documents on master:
> java -jar post.jar *.xml
> - make a note of the index version and generation the on both the replication 
> section of the summary screen of core collection1 and the replication screen 
> on both the master and slave
> - run a delete by query on the master
> java -Ddata=args -jar post.jar "name:DDR"
> - on master reload the summary screen for core collection1.  The Num Docs 
> field decreased but the index version and generation are unchanged in the 
> replication section.  The index version and generation are also unchanged in 
> the replication screen.
> - on the slave, wait for replication to kick in or trigger it manually.  On 
> the summary screen for core collection1, the Num DOcs field decreased to 
> match what's on the master.  The index version and generation of the master 
> remain unchanged but the index version and generation of the slave both 
> changed.  The same goes for the index version and generation of the master 
> and slave on the replication screen.
> The replication handler on the master does report changed index version and 
> generation:
> localhost:8983/solr/collection1/replication?command=indexversion
> It is only the admin UI that reporting the older index version and generation 
> on both the core summary screen and replication screen.
> This only happens with delete by query.  There is no problem with delete with 
> id or add.
> Both the index version and generation do get updated on subsequent delete by 
> query but both remain one cycle behind on the master.

--
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: the_4547_machine_gun_with_no_spaces_in_its_name #1112

[Charlie Cron]

See 


--
[...truncated 2272 lines...]
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered
[junit4:junit4] Completed on J3 in 0.18s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.automaton.TestSpecialOperations
[junit4:junit4] Completed on J2 in 0.04s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J1 in 0.15s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
[junit4:junit4] Completed on J0 in 0.08s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSmallFloat
[junit4:junit4] Completed on J3 in 0.04s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
[junit4:junit4] Completed on J2 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
[junit4:junit4] Completed on J1 in 0.13s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
[junit4:junit4] Completed on J0 in 0.03s, 9 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector
[junit4:junit4] Completed on J3 in 0.09s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
[junit4:junit4] Completed on J2 in 0.03s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring
[junit4:junit4] Completed on J1 in 0.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
[junit4:junit4] Completed on J0 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs
[junit4:junit4] Completed on J3 in 0.03s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
[junit4:junit4] Completed on J2 in 0.03s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSegmentTermEnum
[junit4:junit4] Completed on J1 in 0.13s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
[junit4:junit4] Completed on J0 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
[junit4:junit4] Completed on J3 in 0.07s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
[junit4:junit4] Completed on J2 in 0.13s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestPhrasePrefixQuery
[junit4:junit4] Completed on J1 in 0.12s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearch
[junit4:junit4] Completed on J0 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelTermEnum
[junit4:junit4] Completed on J3 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestReaderClosed
[junit4:junit4] Completed on J2 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestExplanations
[junit4:junit4] Completed on J1 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarity
[junit4:junit4] Completed on J0 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarityProvider
[junit4:junit4] Completed on J3 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQueryUnicode
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDateSort
[junit4:junit4] Completed on J1 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterOnJRECrash
[junit4:junit4] IGNOR/A 0.00s J0 | TestIndexWriterOnJRECrash.testNRTThreads
[junit4:junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J0 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestCachingCollector
[junit4:junit4] Completed on J3 in 0.03s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestDemo
[junit4:junit4] Completed on J2 in 0.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestBinaryDocument
[junit4:junit4] Completed on J1 in 0.03s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestPrefixQuery
[junit4:junit4] Completed on J0 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTopScoreDocCollector
[junit4:junit4] Completed on J3 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestLock
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestPriorityQueue
[junit4:junit4] Completed on J1 in 0

[jira] [Commented] (LUCENE-4723) Add AnalyzerFactoryTask to benchmark, and enable analyzer creation via the resulting factories using NewAnalyzerTask

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4723:


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

LUCENE-4723: Add AnalyzerFactoryTask to benchmark, and enable analyzer creation 
via the resulting factories using NewAnalyzerTask.


> Add AnalyzerFactoryTask to benchmark, and enable analyzer creation via the 
> resulting factories using NewAnalyzerTask
> 
>
> Key: LUCENE-4723
> URL: https://issues.apache.org/jira/browse/LUCENE-4723
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/benchmark
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-4723.patch, LUCENE-4723.patch
>
>
> Benchmark algorithms can't currently use analysis factories.  Instead, one 
> must rely on pre-existing analyzers, or write specialized tasks to construct 
> them.
> Now that all analysis components have factories, benchmark algorithms should 
> be able to use them.

--
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: the_4547_machine_gun_with_no_spaces_in_its_name #1111

[Charlie Cron]

See 


--
[...truncated 2266 lines...]
[junit4:junit4] Completed on J0 in 0.04s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J3 in 0.18s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
[junit4:junit4] Completed on J2 in 0.16s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
[junit4:junit4] Completed on J1 in 0.23s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestDocument
[junit4:junit4] Completed on J0 in 0.13s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
[junit4:junit4] Completed on J3 in 0.02s, 9 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
[junit4:junit4] Completed on J2 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch
[junit4:junit4] Completed on J1 in 0.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestNoDeletionPolicy
[junit4:junit4] Completed on J0 in 0.03s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter
[junit4:junit4] Completed on J3 in 0.10s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
[junit4:junit4] IGNOR/A 0.00s J1 | Test2BPostings.test
[junit4:junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J1 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
[junit4:junit4] Completed on J0 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
[junit4:junit4] Completed on J3 in 0.03s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
[junit4:junit4] Completed on J2 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestRecyclingByteBlockAllocator
[junit4:junit4] Completed on J1 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestDateTools
[junit4:junit4] Completed on J0 in 0.02s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestJUnitRuleOrder
[junit4:junit4] Completed on J3 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
[junit4:junit4] Completed on J2 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestReaderClosed
[junit4:junit4] Completed on J1 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition
[junit4:junit4] Completed on J0 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestExplanations
[junit4:junit4] Completed on J3 in 0.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldCacheTermsFilter
[junit4:junit4] Completed on J2 in 0.18s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestNot
[junit4:junit4] Completed on J1 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarity
[junit4:junit4] Completed on J0 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarityProvider
[junit4:junit4] Completed on J3 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDateSort
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestBinaryDocument
[junit4:junit4] Completed on J1 in 0.01s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTopScoreDocCollector
[junit4:junit4] Completed on J0 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpanFirstQuery
[junit4:junit4] Completed on J3 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestLock
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestBytesRef
[junit4:junit4] Completed on J1 in 0.01s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestVirtualMethod
[junit4:junit4] Completed on J0 in 0.01s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestRamUsageEstimator
[junit4:junit4] Completed on J3 in 0.01s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.analysis.TestMockCharFilter
[junit4:junit4] Completed on J2 in 0.01s, 1 test
[junit4:junit4] 
[junit4:j

Build failed in Jenkins: the_4547_machine_gun_with_no_spaces_in_its_name #1110

[Charlie Cron]

See 


--
[...truncated 2267 lines...]
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
[junit4:junit4]>at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]>at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4]>at java.lang.Thread.run(Thread.java:722)
[junit4:junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPerFieldDocValuesFormat -Dtests.method=testSortedBytes 
-Dtests.seed=D40D2D126CE76C6A -Dtests.slow=true -Dtests.locale=pt_BR 
-Dtests.timezone=America/Port_of_Spain -Dtests.file.encoding=US-ASCII
[junit4:junit4] ERROR   0.01s J0 | TestPerFieldDocValuesFormat.testSortedBytes 
<<<
[junit4:junit4]> Throwable #1: java.lang.NullPointerException
[junit4:junit4]>at 
__randomizedtesting.SeedInfo.seed([D40D2D126CE76C6A:756F6F3406EB06F3]:0)
[junit4:junit4]>at 
org.apache.lucene.index.StoredFieldsProcessor.initFieldsWriter(StoredFieldsProcessor.java:86)
[junit4:junit4]>at 
org.apache.lucene.index.StoredFieldsProcessor.finishDocument(StoredFieldsProcessor.java:119)
[junit4:junit4]>at 
org.apache.lucene.index.TwoStoredFieldsConsumers.finishDocument(TwoStoredFieldsConsumers.java:65)
[junit4:junit4]>at 
org.apache.lucene.index.DocFieldProcessor.finishDocument(DocFieldProcessor.java:290)
[junit4:junit4]>at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:274)
[junit4:junit4]>at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:376)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1471)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1146)
[junit4:junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1127)
[junit4:junit4]>at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testSortedBytes(BaseDocValuesFormatTestCase.java:527)
[junit4:junit4]>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
[junit4:junit4]>at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit4:junit4]>at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4:junit4]>at java.lang.reflect.Method.invoke(Method.java:601)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
[junit4:junit4]>at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8