[jira] [Commented] (LUCENE-3973) Incorporate PMD / FindBugs

[Dawid Weiss (Commented) (JIRA)]

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

Dawid Weiss commented on LUCENE-3973:
-

bq. Unless you run into the same taskdef/classloader/sub-build/permgen-OOM

I was just saying to fetch them via ivy and then spawn a separate jvm to run 
them, much like you'd do anyway if they are separate installations. 

Besides -- we already have an 'ivy warning with instructions', the same can be 
done with permgen/OOM problems -- detect the current (ANT's) VM's settings (can 
be done via mx bean) and warn/ fail the build if the defaults are too low, 
instructing the user to set up ANT_OPTS properly...

I'm not pressing on this, this is a no-issue.

> Incorporate PMD / FindBugs
> --
>
> Key: LUCENE-3973
> URL: https://issues.apache.org/jira/browse/LUCENE-3973
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Chris Male
>
> This has been touched on a few times over the years.  Having static analysis 
> as part of our build seems like a big win.  For example, we could use PMD to 
> look at {{System.out.println}} statements like discussed in LUCENE-3877 and 
> we could possibly incorporate the nocommit / @author checks as well.
> There are a few things to work out as part of this:
> - Should we use both PMD and FindBugs or just one of them? They look at code 
> from different perspectives (bytecode vs source code) and target different 
> issues.  At the moment I'm in favour of trying both but that might be too 
> heavy handed for our needs.
> - What checks should we use? There's no point having the analysis if it's 
> going to raise too many false-positives or problems we don't deem 
> problematic.  
> - How should the analysis be integrated in our build? Need to work out when 
> the analysis should run, how it should be incorporated in Ant and/or Maven, 
> what impact errors should have.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tests-only-trunk - Build # 13065 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13065/

2 tests failed.
REGRESSION:  org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch

Error Message:
java.lang.AssertionError: 
org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane 
FieldCache usage(s) found expected:<0> but was:<1>

Stack Trace:
java.lang.RuntimeException: java.lang.AssertionError: 
org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane 
FieldCache usage(s) found expected:<0> but was:<1>
at 
org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:819)
at 
org.apache.lucene.util.LuceneTestCase.access$900(LuceneTestCase.java:138)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:676)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
at 
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: java.lang.AssertionError: 
org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane 
FieldCache usage(s) found expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:930)
at 
org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:809)
... 28 more


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=91 closes=89

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 
closes=89
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974)
at junit.framework.TestResult.addError(TestResult.java:38)
at 
junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51)
at 
org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
at 
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at 
org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
at 
org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:306)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:

[jira] [Commented] (LUCENE-3978) redo how our download redirect pages work

[Uwe Schindler (Commented) (JIRA)]

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

Uwe Schindler commented on LUCENE-3978:
---

Hoss: That's the problem. For links on external pages to our downloads we 
cannot track, only with a redirect page. But people adding links to their pages 
will always link-through, so we cannot enforce that they go through analytics 
code.

But analytics should track page usage (means the action "clicking link on our 
homepage") and not download usage in general (which is diametral somehow). 
Tracking of downloads is in Apache's responsibility.

> redo how our download redirect pages work
> -
>
> Key: LUCENE-3978
> URL: https://issues.apache.org/jira/browse/LUCENE-3978
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 4.0
>
>
> the download "latest" redirect pages are kind of a pain to change when we 
> release a new version...
> http://lucene.apache.org/core/mirrors-core-latest-redir.html
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (LUCENE-3978) redo how our download redirect pages work

[Hoss Man (Issue Comment Edited) (JIRA)]

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

Hoss Man edited comment on LUCENE-3978 at 4/13/12 5:34 AM:
---

when we released 3.6, we ran into a few annoyances...

* these pages require that you edit the template (not availbale in the 
bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL
* these pages were in browser caches, so they weren't seeing the cahnges in the 
javascript redirect (rmuir added some no-cache metadata headers, so hopefully 
this won't be a problem again)

My suggestion for the future...

* eliminate these templates and their mdtext pages entirely
* replace them with a .htaccess redirect rule that looks like:{code}
/([^/*)/mirrors-(.*)-latest-redir.html /$1/mirrors-$2-redir.html?3.6.0
{code}
* update the templates for mirrors-solr-redir.mdtext and 
mirrors-core-redir.mdtext so that the javascript will use the query string when 
building the final URL

...that way whenever we release a new version, we can just tweak the .htaccess 
rule, and the only "html pages" that might ever show up in an http or browser 
caches will have unique URLs per version.

(EDIT: 1. fix fucking code markup, 2. didn't mean for redir rule to include 
"latest" ... sigh: 3. only ment to remove latest from the redir dest)

  was (Author: hossman):
when we released 3.6, we ran into a few annoyances...

* these pages require that you edit the template (not availbale in the 
bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL
* these pages were in browser caches, so they weren't seeing the cahnges in the 
javascript redirect (rmuir added some no-cache metadata headers, so hopefully 
this won't be a problem again)

My suggestion for the future...

* eliminate these templates and their mdtext pages entirely
* replace them with a .htaccess redirect rule that looks like:{code}
/([^/*)/mirrors-(.*)-redir.html /$1/mirrors-$2-redir.html?3.6.0
{code}
* update the templates for mirrors-solr-redir.mdtext and 
mirrors-core-redir.mdtext so that the javascript will use the query string when 
building the final URL

...that way whenever we release a new version, we can just tweak the .htaccess 
rule, and the only "html pages" that might ever show up in an http or browser 
caches will have unique URLs per version.

(EDIT: 1. fix fucking code markup, 2. didn't mean for redir rule to include 
"latest")
  
> redo how our download redirect pages work
> -
>
> Key: LUCENE-3978
> URL: https://issues.apache.org/jira/browse/LUCENE-3978
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 4.0
>
>
> the download "latest" redirect pages are kind of a pain to change when we 
> release a new version...
> http://lucene.apache.org/core/mirrors-core-latest-redir.html
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (LUCENE-3978) redo how our download redirect pages work

[Hoss Man (Issue Comment Edited) (JIRA)]

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

Hoss Man edited comment on LUCENE-3978 at 4/13/12 5:32 AM:
---

when we released 3.6, we ran into a few annoyances...

* these pages require that you edit the template (not availbale in the 
bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL
* these pages were in browser caches, so they weren't seeing the cahnges in the 
javascript redirect (rmuir added some no-cache metadata headers, so hopefully 
this won't be a problem again)

My suggestion for the future...

* eliminate these templates and their mdtext pages entirely
* replace them with a .htaccess redirect rule that looks like:{code}
/([^/*)/mirrors-(.*)-redir.html /$1/mirrors-$2-redir.html?3.6.0
{code}
* update the templates for mirrors-solr-redir.mdtext and 
mirrors-core-redir.mdtext so that the javascript will use the query string when 
building the final URL

...that way whenever we release a new version, we can just tweak the .htaccess 
rule, and the only "html pages" that might ever show up in an http or browser 
caches will have unique URLs per version.

(EDIT: 1. fix fucking code markup, 2. didn't mean for redir rule to include 
"latest")

  was (Author: hossman):
when we released 3.6, we ran into a few annoyances...

* these pages require that you edit the template (not availbale in the 
bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL
* these pages were in browser caches, so they weren't seeing the cahnges in the 
javascript redirect (rmuir added some no-cache metadata headers, so hopefully 
this won't be a problem again)

My suggestion for the future...

* eliminate these templates and their mdtext pages entirely
* replace them with a .htaccess redirect rule that looks like: 
{{/([^/*)/(.*)-latest-redir.html /$1/$2-redir.html?3.6.0}}
* update the templates for mirrors-solr-redir.mdtext and 
mirrors-core-redir.mdtext so that the javascript will use the query string when 
building the final URL

...that way whenever we release a new version, we can just tweak the .htaccess 
rule, and the only "html pages" that might ever show up in an http or browser 
caches will have unique URLs per version.

  
> redo how our download redirect pages work
> -
>
> Key: LUCENE-3978
> URL: https://issues.apache.org/jira/browse/LUCENE-3978
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 4.0
>
>
> the download "latest" redirect pages are kind of a pain to change when we 
> release a new version...
> http://lucene.apache.org/core/mirrors-core-latest-redir.html
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3978) redo how our download redirect pages work

[Hoss Man (Commented) (JIRA)]

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

Hoss Man commented on LUCENE-3978:
--

Uwe: if i'm understanding that page correctly, this would only be possible for 
links where:
 a) link html is on our site
 b) we can control the html used to generate them
...which isfine for the bug buttons on lucene.apache.org, and any other 
download links we might want to include on those CMS pages, but not for things 
like links from wiki.apache.org, or the URLs we include in our plain text 
release announcement emails (that users just cut/paste) or that we submit to 
any other site to promote the release.


> redo how our download redirect pages work
> -
>
> Key: LUCENE-3978
> URL: https://issues.apache.org/jira/browse/LUCENE-3978
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 4.0
>
>
> the download "latest" redirect pages are kind of a pain to change when we 
> release a new version...
> http://lucene.apache.org/core/mirrors-core-latest-redir.html
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3317) Admin UI: Improve request handler / qt in query form

[David Smiley (Updated) (JIRA)]

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

David Smiley updated SOLR-3317:
---

Attachment: SOLR-3317.patch

Looks good.  I am supplying an updated patch with other changes/cleanup and 
some questions for you:
* Some  tags were not closed so I closed them.
* Some id="..." attributes were not unique notably dismax & edismax since they 
share many parameters. So I added a differentiating prefix to keep them unique.
* I added title="..." tags to _some_ of the input elements to offer basic 
tooltip help.  I didn't do all of them -- I'm getting tired ;-)

Question:
* Why surround the labels to these fields in anchor tags when the label tag 
alone will work; right?  Notice 'q' is done this way, unlike most fields.  And 
*if* the anchor tags serve a useful purpose, then what does rel="help" add?


> Admin UI: Improve request handler / qt in query form
> 
>
> Key: SOLR-3317
> URL: https://issues.apache.org/jira/browse/SOLR-3317
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: David Smiley
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: SOLR-3317.patch, SOLR-3317.patch
>
>
> The query form in the admin UI could use an improvement regarding how the 
> request handler is chosen; presently all there is is a text input for 'qt'. 
> The first choice to make in the form above the query should really be the 
> request handler since it actually handles the request before any other 
> parameters do anything.  I think it'd be nice if it was filled with "/select" 
> by default to make it very clear what's there, although I realize most of 
> this query form seems to prefer blank values as defaults.  When the form 
> creates the URL to submit to Solr for the search, it needs to do something 
> different depending on wether this value starts with a '/'.  If it does, this 
> goes where "/select" goes in the URL normally (i.e. it's the tail end of the 
> path after the core).  If it doesn't then it goes into the 'qt' URL parameter.
> I did something similar to the old 3x UI in SOLR-3161 that got committed to 
> 3.6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3327) Logging UI should indicate which loggers are set vs implicit

[Shawn Heisey (Commented) (JIRA)]

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

Shawn Heisey commented on SOLR-3327:


Is there any way to give users the slf4j level options and have those 
translated automatically behind the scenes into the correct levels for the 
framework that's actually in use?


> Logging UI should indicate which loggers are set vs implicit
> 
>
> Key: SOLR-3327
> URL: https://issues.apache.org/jira/browse/SOLR-3327
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3327.patch, logging.png
>
>
> The new logging UI looks great!
> http://localhost:8983/solr/#/~logging
> It would be nice to indicate which ones are set explicitly vs implicit -- 
> perhaps making the line bold when set=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3978) redo how our download redirect pages work

[Uwe Schindler (Commented) (JIRA)]

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

Uwe Schindler commented on LUCENE-3978:
---

Hi Hoss,
I have seen your commit and I now understand the reason for the redirect pages 
(to also count downloads by Google Analytics). As I also did GA tracking for 
webpages not long ago, there is a better/more correct solution to track 
downloads. The trick is to add some javascript to the source link that tells 
Google Analytics to create a "virtual pageview" when clicking on the link. The 
virtual pageview is counted on a "virtual" URI (e.g., the current URL with the 
redirect page, without http and hostname): 
http://support.google.com/googleanalytics/bin/answer.py?hl=en&answer=55529 In 
fact, the trick is to execute the analytics javascript on the link click and 
pass a "custom" url instead the default one from the current page.

> redo how our download redirect pages work
> -
>
> Key: LUCENE-3978
> URL: https://issues.apache.org/jira/browse/LUCENE-3978
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 4.0
>
>
> the download "latest" redirect pages are kind of a pain to change when we 
> release a new version...
> http://lucene.apache.org/core/mirrors-core-latest-redir.html
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3979) NGramTokenizer strips whitespace, with no option to keep leading and trailing whitespace

[David Mason (Updated) (JIRA)]

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

David Mason updated LUCENE-3979:


Summary: NGramTokenizer strips whitespace, with no option to keep leading 
and trailing whitespace  (was: NGramTokenizer)

> NGramTokenizer strips whitespace, with no option to keep leading and trailing 
> whitespace
> 
>
> Key: LUCENE-3979
> URL: https://issues.apache.org/jira/browse/LUCENE-3979
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 2.9.2, 3.0
> Environment: n/a
>Reporter: David Mason
>Priority: Minor
>  Labels: tokenizer, whitespace
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> org.apache.lucene.analysis.ngram.NGramTokenizer removes whitespace, making a 
> search for literal strings like " test" and "test " equivalent to "test". 
> Searching with relevant whitespace is sometimes desired, particularly where 
> ngrams are used.
> This could be fixed by either removing .trim() from the line shown below, or 
> by providing a flag to specifically set trimming behaviour (keeping trim=true 
> as the default so that existing code using this analyzer is not broken).
> 111: inStr = new String(chars).trim();  // remove any trailing empty strings 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3979) NGramTokenizer

[David Mason (Commented) (JIRA)]

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

David Mason commented on LUCENE-3979:
-

I'm happy to submit a patch for this, but haven't done so for this or similar 
projects so will take a while to go through the wiki and get set up to make a 
patch.

> NGramTokenizer
> --
>
> Key: LUCENE-3979
> URL: https://issues.apache.org/jira/browse/LUCENE-3979
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 2.9.2, 3.0
> Environment: n/a
>Reporter: David Mason
>Priority: Minor
>  Labels: tokenizer, whitespace
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> org.apache.lucene.analysis.ngram.NGramTokenizer removes whitespace, making a 
> search for literal strings like " test" and "test " equivalent to "test". 
> Searching with relevant whitespace is sometimes desired, particularly where 
> ngrams are used.
> This could be fixed by either removing .trim() from the line shown below, or 
> by providing a flag to specifically set trimming behaviour (keeping trim=true 
> as the default so that existing code using this analyzer is not broken).
> 111: inStr = new String(chars).trim();  // remove any trailing empty strings 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3979) NGramTokenizer

[David Mason (Created) (JIRA)]

NGramTokenizer
--

 Key: LUCENE-3979
 URL: https://issues.apache.org/jira/browse/LUCENE-3979
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 3.0, 2.9.2
 Environment: n/a
Reporter: David Mason
Priority: Minor


org.apache.lucene.analysis.ngram.NGramTokenizer removes whitespace, making a 
search for literal strings like " test" and "test " equivalent to "test". 
Searching with relevant whitespace is sometimes desired, particularly where 
ngrams are used.

This could be fixed by either removing .trim() from the line shown below, or by 
providing a flag to specifically set trimming behaviour (keeping trim=true as 
the default so that existing code using this analyzer is not broken).

111: inStr = new String(chars).trim();  // remove any trailing empty strings 


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3355) Add shard name to SolrCore statistics

[Mark Miller (Updated) (JIRA)]

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

Mark Miller updated SOLR-3355:
--

Affects Version/s: (was: 4.0)
Fix Version/s: 4.0

> Add shard name to SolrCore statistics
> -
>
> Key: SOLR-3355
> URL: https://issues.apache.org/jira/browse/SOLR-3355
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Michael Garski
>Assignee: Mark Miller
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3355.patch
>
>
> The JMX stats of the core do not expose the shard name that it is hosting, 
> which could be of use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3355) Add shard name to SolrCore statistics

[Mark Miller (Assigned) (JIRA)]

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

Mark Miller reassigned SOLR-3355:
-

Assignee: Mark Miller

> Add shard name to SolrCore statistics
> -
>
> Key: SOLR-3355
> URL: https://issues.apache.org/jira/browse/SOLR-3355
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Michael Garski
>Assignee: Mark Miller
>Priority: Trivial
> Attachments: SOLR-3355.patch
>
>
> The JMX stats of the core do not expose the shard name that it is hosting, 
> which could be of use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3238) Sequel of Admin UI

[dylan (Commented) (JIRA)]

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

dylan commented on SOLR-3238:
-

Chinese words collected by admin ui are not correctly recognized by 
/analysis/field or /select.
1. open admin ui. Singlre Core > Query.
add q: name:中文
and I get the following information in tomcat's log:
path=/select params={wt=xml&rows=10&start=0&q=name:?￥} hits=0 status=0 
QTime=2

2.  open admin ui. Singlre Core > Analysis.
FieldValue: 中文
and I get the following information in tomcat's log:
path=/analysis/field 
params={analysis.showmatch=true&analysis.query=&analysis.fieldname=ageseg&analysis.fieldvalue=?￥&wt=json}
 status=0 QTime=2


> Sequel of Admin UI
> --
>
> Key: SOLR-3238
> URL: https://issues.apache.org/jira/browse/SOLR-3238
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: SOLR-3238.patch, SOLR-3238.patch, SOLR-3238.patch, 
> solradminbug.png
>
>
> Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

Screencasts on the tutorial page?

[Chris Hostetter]

So, back when we started redoing the website to eliminate forrest, and 
discussing the "versioned" versions of the tutorial page (SOLR-3210 - 
because eventually it will be important to link to both the 3.6 and 4.0 
versions on the site) I had this great idea that we could embed YouTube 
video clips walking through the tutorial on the main tutorial landing 
page.


Seems like a no brainer cool content idea right?

So now that 3.6 is official, i spent ~1 hour rehersing, and then ~30 
minutes recording some video.  I flubbed a bunch, so in order to salvage 
anything from this it would have be cropped and edited (and might work 
better as many little clips instead of one long clip) but even if we 
did that, i'm worried that it still wouldn't be useful to post on the 
site...


  1) i feel like it's really dry, and bland
  2) the tutorial is already *REALLY* straight forward
  3) there's really nothing in this that the user couldn't see on their
 own machine doing a cut/paste of a command or URL.

So anyway, i tossed the raw footage (338MB) online...

   http://fucit.org/solr-3.6-screencast-raw.mkv

a) does anyone think this is worth trying to edit down?
b) does anyone with better video editing skills then me (ie: none) want
   to take a crack at editing it?
c) does anyone with a less boring voice then me wnat to take a crack at a
   whole new run through?


-Hoss

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

[jira] [Updated] (SOLR-3356) Logging UI (and LogLevelHandler) should support Log4j

[Ryan McKinley (Updated) (JIRA)]

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

Ryan McKinley updated SOLR-3356:


Attachment: SOLR-3356-log4j.patch

this uses reflection to make the Log4j setLevel call

It also adds info to the header that says which framework is enabled:

{code:xml}
java.util.logging
org.slf4j.impl.JDK14LoggerFactory
{code}

{code:xml}
log4j
org.slf4j.impl.Log4jLoggerFactory
{code}

> Logging UI (and LogLevelHandler) should support Log4j
> -
>
> Key: SOLR-3356
> URL: https://issues.apache.org/jira/browse/SOLR-3356
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3356-log4j.patch
>
>
> The Logging UI and LogLevelHandler can work using Log4j rather then just JUL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3356) Logging UI (and LogLevelHandler) should support Log4j

[Ryan McKinley (Created) (JIRA)]

Logging UI (and LogLevelHandler) should support Log4j
-

 Key: SOLR-3356
 URL: https://issues.apache.org/jira/browse/SOLR-3356
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 4.0


The Logging UI and LogLevelHandler can work using Log4j rather then just JUL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3977) generated/duplicated javadocs are wasteful and bloat the release

[Robert Muir (Commented) (JIRA)]

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

Robert Muir commented on LUCENE-3977:
-

{quote}
at this point in my life, i don't really have an opinion, as long as we include 
at least one copy in the bin release
{quote}

Well I was thinking, the javadocs-all really tries to be what the 'individual 
modules' version is! It tries (and fails) to separate packages according to 
contrib modules that "own" them, but this is all screwed up, sure 
o.a.l.index.pruning is marked underneath the pruning module but the 
PruningReader is actually in o.a.l.index.

There are many other examples. So it seems to me that if they individual 
modules javadocs actually linked to each other correctly, then to the user it 
really gives us that same result, but without the duplication. Hell, if that 
still isn't good enough we could figure out some way to make 'massive useless 
class list' that links to all the correct places but I think thats not useful 
(thus, the crazy logic in build.xml to try to separate contribs into packages).

{quote}
oh god yes, i didn't even realize we were building that useless pile of crap
{quote}

Ok, I don't think this one is controversial: its an easy win, I'll commit it 
tonight or tomorrow (even though i still want to nuke the other 80MB from the 
duplication issue... thats harder)



> generated/duplicated javadocs are wasteful and bloat the release
> 
>
> Key: LUCENE-3977
> URL: https://issues.apache.org/jira/browse/LUCENE-3977
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Robert Muir
>Priority: Blocker
> Fix For: 4.0
>
>
> Some stats for the generated javadocs of 3.6:
> * 9,146 files
> * 161,872 KB uncompressed
> * 25MB compressed (this is responsible for nearly half of our binary release)
> The fact we intentionally double our javadocs size with the 'javadocs-all' 
> thing
> is truly wasteful and compression doesn't help at all. Just testing, i nuked 
> 'all'
> and found:
> * 4,944 files
> * 81,084 KB uncompressed
> * 12.8MB compressed
> We need to clean this up for 4.0. We only need to ship javadocs 'one way'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3327) Logging UI should indicate which loggers are set vs implicit

[Hoss Man (Commented) (JIRA)]

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

Hoss Man commented on SOLR-3327:


bq. It should state on top that these are the JDK logging levels. If people 
switch logging through SLF4J it won't work

i wonder if there is a way for the LoggingServlet (request handler?) to detect 
which SL4J binding is in use, and spit out a warning if it's not JDK, so the UI 
can conditionally display that warning if it exists.

> Logging UI should indicate which loggers are set vs implicit
> 
>
> Key: SOLR-3327
> URL: https://issues.apache.org/jira/browse/SOLR-3327
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3327.patch, logging.png
>
>
> The new logging UI looks great!
> http://localhost:8983/solr/#/~logging
> It would be nice to indicate which ones are set explicitly vs implicit -- 
> perhaps making the line bold when set=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3977) generated/duplicated javadocs are wasteful and bloat the release

[Hoss Man (Commented) (JIRA)]

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

Hoss Man commented on LUCENE-3977:
--

bq. Really if we have different modules like contrib-analyzers, why can't they 
link to the things they depend on (e.g. lucene-core) just like the solr 
javadocs do?

i think the original argument in favor of having both styles was:

* the all version makes it easy to see (in the left pane) all the classes that 
are available when people are working with the entire code base
* the individual module versions, even when cross linked with eachother, make 
it easy to see exactly what is included in a single module (via the left pane)

at this point in my life, i don't really have an opinion, as long as we include 
at least one copy in the bin release.

bq. We can save 10MB with this patch, which nukes the 'index

oh god yes, i didn't even realize we were building that useless pile of crap

> generated/duplicated javadocs are wasteful and bloat the release
> 
>
> Key: LUCENE-3977
> URL: https://issues.apache.org/jira/browse/LUCENE-3977
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Robert Muir
>Priority: Blocker
> Fix For: 4.0
>
>
> Some stats for the generated javadocs of 3.6:
> * 9,146 files
> * 161,872 KB uncompressed
> * 25MB compressed (this is responsible for nearly half of our binary release)
> The fact we intentionally double our javadocs size with the 'javadocs-all' 
> thing
> is truly wasteful and compression doesn't help at all. Just testing, i nuked 
> 'all'
> and found:
> * 4,944 files
> * 81,084 KB uncompressed
> * 12.8MB compressed
> We need to clean this up for 4.0. We only need to ship javadocs 'one way'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3978) redo how our download redirect pages work

[Hoss Man (Commented) (JIRA)]

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

Hoss Man commented on LUCENE-3978:
--

when we released 3.6, we ran into a few annoyances...

* these pages require that you edit the template (not availbale in the 
bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL
* these pages were in browser caches, so they weren't seeing the cahnges in the 
javascript redirect (rmuir added some no-cache metadata headers, so hopefully 
this won't be a problem again)

My suggestion for the future...

* eliminate these templates and their mdtext pages entirely
* replace them with a .htaccess redirect rule that looks like: 
{{/([^/*)/(.*)-latest-redir.html /$1/$2-redir.html?3.6.0}}
* update the templates for mirrors-solr-redir.mdtext and 
mirrors-core-redir.mdtext so that the javascript will use the query string when 
building the final URL

...that way whenever we release a new version, we can just tweak the .htaccess 
rule, and the only "html pages" that might ever show up in an http or browser 
caches will have unique URLs per version.


> redo how our download redirect pages work
> -
>
> Key: LUCENE-3978
> URL: https://issues.apache.org/jira/browse/LUCENE-3978
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 4.0
>
>
> the download "latest" redirect pages are kind of a pain to change when we 
> release a new version...
> http://lucene.apache.org/core/mirrors-core-latest-redir.html
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3978) redo how our download redirect pages work

[Hoss Man (Created) (JIRA)]

redo how our download redirect pages work
-

 Key: LUCENE-3978
 URL: https://issues.apache.org/jira/browse/LUCENE-3978
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Hoss Man
 Fix For: 4.0


the download "latest" redirect pages are kind of a pain to change when we 
release a new version...

http://lucene.apache.org/core/mirrors-core-latest-redir.html
http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3977) generated/duplicated javadocs are wasteful and bloat the release

[Robert Muir (Commented) (JIRA)]

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

Robert Muir commented on LUCENE-3977:
-

Besides the trivial patch above (which I think we should do), looking at the 
big picture
with the 2x duplication, I really think we should totally nuke these 
javadocs-all tasks.

Really if we have different modules like contrib-analyzers, why can't they link 
to
the things they depend on (e.g. lucene-core) just like the solr javadocs do?

This is just a matter of fixing the build system and then working towards making
our downloads reasonable right?

> generated/duplicated javadocs are wasteful and bloat the release
> 
>
> Key: LUCENE-3977
> URL: https://issues.apache.org/jira/browse/LUCENE-3977
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Robert Muir
>Priority: Blocker
> Fix For: 4.0
>
>
> Some stats for the generated javadocs of 3.6:
> * 9,146 files
> * 161,872 KB uncompressed
> * 25MB compressed (this is responsible for nearly half of our binary release)
> The fact we intentionally double our javadocs size with the 'javadocs-all' 
> thing
> is truly wasteful and compression doesn't help at all. Just testing, i nuked 
> 'all'
> and found:
> * 4,944 files
> * 81,084 KB uncompressed
> * 12.8MB compressed
> We need to clean this up for 4.0. We only need to ship javadocs 'one way'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3327) Logging UI should indicate which loggers are set vs implicit

[Commented]

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

Jan Høydahl commented on SOLR-3327:
---

This looks great!

Two more comments about the logging GUI:
* It should state on top that these are the JDK logging levels. If people 
switch logging through SLF4J it won't work
* Clicking multiple lines without making a selection leaves hanging popups

> Logging UI should indicate which loggers are set vs implicit
> 
>
> Key: SOLR-3327
> URL: https://issues.apache.org/jira/browse/SOLR-3327
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3327.patch, logging.png
>
>
> The new logging UI looks great!
> http://localhost:8983/solr/#/~logging
> It would be nice to indicate which ones are set explicitly vs implicit -- 
> perhaps making the line bold when set=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3355) Add shard name to SolrCore statistics

[Michael Garski (Updated) (JIRA)]

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

Michael Garski updated SOLR-3355:
-

Attachment: SOLR-3355.patch

I could not find any tests that cover the SolrCore.getStatistics call, so this 
patch only adds the core name to the stats if possible.

> Add shard name to SolrCore statistics
> -
>
> Key: SOLR-3355
> URL: https://issues.apache.org/jira/browse/SOLR-3355
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Michael Garski
>Priority: Trivial
> Attachments: SOLR-3355.patch
>
>
> The JMX stats of the core do not expose the shard name that it is hosting, 
> which could be of use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3355) Add shard name to SolrCore statistics

[Michael Garski (Created) (JIRA)]

Add shard name to SolrCore statistics
-

 Key: SOLR-3355
 URL: https://issues.apache.org/jira/browse/SOLR-3355
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Michael Garski
Priority: Trivial


The JMX stats of the core do not expose the shard name that it is hosting, 
which could be of use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3973) Incorporate PMD / FindBugs

[Hoss Man (Commented) (JIRA)]

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

Hoss Man commented on LUCENE-3973:
--

bq. I believe both pmd and findbugs are on maven repos so one could use ivy to 
fetch them automatically. One thing less to think about.

Unless you run into the same taskdef/classloader/sub-build/permgen-OOM problem 
we had with clover, and the maven-ant-tasks, and ivy that have prevented us 
from doing the same thing with them.



> Incorporate PMD / FindBugs
> --
>
> Key: LUCENE-3973
> URL: https://issues.apache.org/jira/browse/LUCENE-3973
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Chris Male
>
> This has been touched on a few times over the years.  Having static analysis 
> as part of our build seems like a big win.  For example, we could use PMD to 
> look at {{System.out.println}} statements like discussed in LUCENE-3877 and 
> we could possibly incorporate the nocommit / @author checks as well.
> There are a few things to work out as part of this:
> - Should we use both PMD and FindBugs or just one of them? They look at code 
> from different perspectives (bytecode vs source code) and target different 
> issues.  At the moment I'm in favour of trying both but that might be too 
> heavy handed for our needs.
> - What checks should we use? There's no point having the analysis if it's 
> going to raise too many false-positives or problems we don't deem 
> problematic.  
> - How should the analysis be integrated in our build? Need to work out when 
> the analysis should run, how it should be incorporated in Ant and/or Maven, 
> what impact errors should have.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3971) MappingCharFilter rarely has wrong correctOffset (for finalOffset)

[Robert Muir (Commented) (JIRA)]

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

Robert Muir commented on LUCENE-3971:
-

Thanks Dawid!

Well the random test isnt totally efficient (it passes often and sometimes 
doesnt find the corner case).
But I'll happily test the patch with it (I think if i just run it 100 times and 
it passes I'm sold).



> MappingCharFilter rarely has wrong correctOffset (for finalOffset) 
> ---
>
> Key: LUCENE-3971
> URL: https://issues.apache.org/jira/browse/LUCENE-3971
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-3971.patch, LUCENE-3971_test.patch
>
>
> Found this bug over on LUCENE-3969, but I'm currently tracking a ton of bugs, 
> so
> I figure I would open an issue and see if this one is obvious to anyone:
> Consider this input string: "gzw f quaxot" (length = 12) with a 
> WhitespaceTokenizer.
> If i have mapping rules like this, then it works!:
> {noformat}
> "t" => ""
> {noformat}
> But if I have mapping rules like this:
> {noformat}
> "t" => ""
> "tmakdbl" => "c"
> {noformat}
> Then it will compute final offset wrong:
> {noformat}
> [junit] junit.framework.AssertionFailedError: finalOffset  expected:<12> 
> but was:<11>
> {noformat}
> Looks like some logic/recursion bug in the correctOffset method? The second 
> rule is not even "used" for this string,
> it just happens to also start with 't'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3210) 3.6 POST RELEASE TASK: update site tutorial.html to link to versioned tutorial

[Hoss Man (Resolved) (JIRA)]

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

Hoss Man resolved SOLR-3210.


   Resolution: Fixed
Fix Version/s: (was: 4.0)
   3.6

> 3.6 POST RELEASE TASK: update site tutorial.html to link to versioned tutorial
> --
>
> Key: SOLR-3210
> URL: https://issues.apache.org/jira/browse/SOLR-3210
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 3.6
>
>
> Unless we have an alternate strategy in place for dealing with versioned docs 
> by the time 3.6 is released, then as a post-release task, once the 3.6 
> javadocs are snapshoted online (ie: http://lucene.apache.org/solr/api/) the 
> current "online" copy of the tutorial 
> (http://lucene.apache.org/solr/tutorial.html) should be pruned down so that 
> it is just a link to the snapshot version released with 3.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

[ANNOUNCE] Apache Solr 3.6 released

[Robert Muir]

12 April 2012, Apache Solr™ 3.6.0 available
The Lucene PMC is pleased to announce the release of Apache Solr 3.6.0.

Solr is the popular, blazing fast open source enterprise search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search, dynamic clustering, database
integration, rich document (e.g., Word, PDF) handling, and geospatial search.
Solr is highly scalable, providing distributed search and index replication,
and it powers the search and navigation features of many of the world's
largest internet sites.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below.  The release
is available for immediate download at:
   http://lucene.apache.org/solr/mirrors-solr-latest-redir.html (see
note below).

See the CHANGES.txt file included with the release for a full list of
details.

Solr 3.6.0 Release Highlights:

 * New SolrJ client connector using Apache Http Components http client
   (SOLR-2020)

 * Many analyzer factories are now "multi term query aware" allowing for things
   like field type aware lowercasing when building prefix & wildcard queries.
   (SOLR-2438)

 * New Kuromoji morphological analyzer tokenizes Japanese text, producing
   both compound words and their segmentation. (SOLR-3056)

 * Range Faceting (Dates & Numbers) is now supported in distributed search
   (SOLR-1709)

 * HTMLStripCharFilter has been completely re-implemented, fixing many bugs
   and greatly improving the performance (LUCENE-3690)

 * StreamingUpdateSolrServer now supports the javabin format (SOLR-1565)

 * New LFU Cache option for use in Solr's internal caches. (SOLR-2906)

 * Memory performance improvements to all FST based suggesters (SOLR-2888)

 * New WFSTLookupFactory suggester supports finer-grained ranking for
   suggestions. (LUCENE-3714)

 * New options for configuring the amount of concurrency used in distributed
   searches (SOLR-3221)

 * Many bug fixes

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases.  It is possible that the mirror you are using may not
have replicated the release yet.  If that is the case, please try another
mirror.  This also goes for Maven access.

Happy searching,

Lucene/Solr developers

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

[ANNOUNCE] Apache Lucene 3.6 released.

[Robert Muir]

12 April 2012, Apache Lucene™ 3.6.0 available
The Lucene PMC is pleased to announce the release of Apache Lucene 3.6.0.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below.  The release
is available for immediate download at:
   http://lucene.apache.org/core/mirrors-core-latest-redir.html (see
note below).

See the CHANGES.txt file included with the release for a full list of
details.

Lucene 3.6.0 Release Highlights:

  * In addition to Java 5 and Java 6, this release has now
full Java 7 support (minimum JDK 7u1 required).

  * TypeTokenFilter filters tokens based on their TypeAttribute.

  * Fixed offset bugs in a number of CharFilters, Tokenizers and TokenFilters
that could lead to exceptions during highlighting.

  * Added phonetic encoders: Metaphone, Soundex, Caverphone,
Beider-Morse, etc.

  * CJKBigramFilter and CJKWidthFilter replace CJKTokenizer.

  * Kuromoji morphological analyzer tokenizes Japanese text, producing
both compound words and their segmentation.

  * Static index pruning (Carmel pruning) removes postings with low
within-document term frequency.

  * QueryParser now interprets '*' as an open end for range
queries.

  * FieldValueFilter excludes documents missing the specified field.

  * CheckIndex and IndexUpgrader allow you to specify the
specific FSDirectory implementation to use with the new -dir-impl
command-line option.

  * FSTs can now do reverse lookup (by output) in certain cases and
can be packed to reduce their size.  There is now a method to
retrieve top N shortest paths from a start node in an FST.

  * New WFSTCompletionLookup suggester supports finer-grained
ranking for suggestions.

  * FST based suggesters now use an offline (disk-based) sort, instead
of in-memory sort, when pre-sorting the suggestions.

  * ToChildBlockJoinQuery joins in the opposite direction (parent down
to child documents).

  * New query-time joining is more flexible (but less performant) than
index-time joins.

  * Added HTMLStripCharFilter to strip HTML markup.

  * Security fix: Better prevention of virtual machine SIGSEGVs when
using MMapDirectory: Code using cloned IndexInputs of already
closed indexes could possibly crash VM, allowing DoS attacks to
your application.

  * Many bug fixes...

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases.  It is possible that the mirror you are using may not
have replicated the release yet.  If that is the case, please try another
mirror.  This also goes for Maven access.

Happy searching,

Apache Lucene/Solr Developers

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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13054 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13054/

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ERROR: SolrIndexSearcher opens=74 closes=73

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=74 
closes=73
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974)
at junit.framework.TestResult.addError(TestResult.java:38)
at 
junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51)
at 
org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
at 
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at 
org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
at 
org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:306)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=74 closes=73
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:210)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:99)
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:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
... 4 more




Build Log (for compile errors):
[...truncated 9277 lines...]



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

Re: buildbot failure in ASF Buildbot on lucene-site-staging

[Robert Muir]

I figured it out... its ok to svn mv things, but dont do anything that
would case a replace (R). buildbot doesn't like that!

On Thu, Apr 12, 2012 at 4:28 PM, Mark Miller  wrote:
> He is evil - we should kill him. It's a staging assassin spam bot.
>
> On Apr 12, 2012, at 3:42 PM, Robert Muir wrote:
>
>> I don't think buildbot liked my svn moves... I'll see if I can make
>> him happy again.
>>
>> On Thu, Apr 12, 2012 at 3:38 PM,   wrote:
>>> The Buildbot has detected a new failure on builder lucene-site-staging 
>>> while building ASF Buildbot.
>>> Full details are available at:
>>>  http://ci.apache.org/builders/lucene-site-staging/builds/168
>>>
>>> Buildbot URL: http://ci.apache.org/
>>>
>>> Buildslave for this Build: bb-cms-slave
>>>
>>> Build Reason: scheduler
>>> Build Source Stamp: [branch lucene/cms] 1325460
>>> Blamelist: rmuir
>>>
>>> BUILD FAILED: failed compile
>>>
>>> sincerely,
>>>  -The Buildbot
>>>
>>>
>>>
>>
>>
>>
>> --
>> lucidimagination.com
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> - Mark Miller
> lucidimagination.com
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
lucidimagination.com

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

[jira] [Updated] (LUCENE-3971) MappingCharFilter rarely has wrong correctOffset (for finalOffset)

[Dawid Weiss (Updated) (JIRA)]

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

Dawid Weiss updated LUCENE-3971:


Attachment: LUCENE-3971.patch

This code is one hairy bastard... the LinkedList is scary and so is 
the logic of counting position offset updates... 

This patch fixes the failing tests but I wouldn't guarantee it fixes all the 
problems.

Definitely a candidate for clean rewrite.

> MappingCharFilter rarely has wrong correctOffset (for finalOffset) 
> ---
>
> Key: LUCENE-3971
> URL: https://issues.apache.org/jira/browse/LUCENE-3971
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-3971.patch, LUCENE-3971_test.patch
>
>
> Found this bug over on LUCENE-3969, but I'm currently tracking a ton of bugs, 
> so
> I figure I would open an issue and see if this one is obvious to anyone:
> Consider this input string: "gzw f quaxot" (length = 12) with a 
> WhitespaceTokenizer.
> If i have mapping rules like this, then it works!:
> {noformat}
> "t" => ""
> {noformat}
> But if I have mapping rules like this:
> {noformat}
> "t" => ""
> "tmakdbl" => "c"
> {noformat}
> Then it will compute final offset wrong:
> {noformat}
> [junit] junit.framework.AssertionFailedError: finalOffset  expected:<12> 
> but was:<11>
> {noformat}
> Looks like some logic/recursion bug in the correctOffset method? The second 
> rule is not even "used" for this string,
> it just happens to also start with 't'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: buildbot failure in ASF Buildbot on lucene-site-staging

[Mark Miller]

He is evil - we should kill him. It's a staging assassin spam bot.

On Apr 12, 2012, at 3:42 PM, Robert Muir wrote:

> I don't think buildbot liked my svn moves... I'll see if I can make
> him happy again.
> 
> On Thu, Apr 12, 2012 at 3:38 PM,   wrote:
>> The Buildbot has detected a new failure on builder lucene-site-staging while 
>> building ASF Buildbot.
>> Full details are available at:
>>  http://ci.apache.org/builders/lucene-site-staging/builds/168
>> 
>> Buildbot URL: http://ci.apache.org/
>> 
>> Buildslave for this Build: bb-cms-slave
>> 
>> Build Reason: scheduler
>> Build Source Stamp: [branch lucene/cms] 1325460
>> Blamelist: rmuir
>> 
>> BUILD FAILED: failed compile
>> 
>> sincerely,
>>  -The Buildbot
>> 
>> 
>> 
> 
> 
> 
> -- 
> lucidimagination.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

- Mark Miller
lucidimagination.com












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

Re: Responding to Requests with Chunks/Streaming

[Mikhail Khludnev]

Hello Developers,

I just want to ask don't you think that response streaming can be useful
for things like OLAP, e.g. is you have sharded index presorted and
pre-joined by BJQ way you can calculate counts in many cube cells in
parallel?
Essential distributed test for response streaming just passed.
https://github.com/m-khl/solr-patches/blob/ec4db7c0422a5515392a7019c5bd23ad3f546e4b/solr/core/src/test/org/apache/solr/response/RespStreamDistributedTest.java

branch is https://github.com/m-khl/solr-patches/tree/streaming

Regards

On Mon, Apr 2, 2012 at 10:55 AM, Mikhail Khludnev <
mkhlud...@griddynamics.com> wrote:

>
> Hello,
>
> Small update - reading streamed response is done via callback. No
> SolrDocumentList in memory.
> https://github.com/m-khl/solr-patches/tree/streaming
> here is the test
> https://github.com/m-khl/solr-patches/blob/d028d4fabe0c20cb23f16098637e2961e9e2366e/solr/core/src/test/org/apache/solr/response/ResponseStreamingTest.java#L138
>
> no progress in distributed search via streaming yet.
>
> Pls let me know if you don't want to have updates from my playground.
>
> Regards
>
>
> On Thu, Mar 29, 2012 at 1:02 PM, Mikhail Khludnev <
> mkhlud...@griddynamics.com> wrote:
>
>> @All
>> Why nobody desires such a pretty cool feature?
>>
>> Nicholas,
>> I have a tiny progress: I'm able to stream in javabin codec format while
>> searching, It implies sorting by _docid_
>>
>> here is the diff
>>
>> https://github.com/m-khl/solr-patches/commit/2f9ff068c379b3008bb983d0df69dff714ddde95
>>
>> The current issue is that reading response by SolrJ is done as whole.
>> Reading by callback is supported by EmbeddedServer only. Anyway it should
>> not a big deal. ResponseStreamingTest.java somehow works.
>> I'm stuck on introducing response streaming in distributes search, it's
>> actually more challenging  - RespStreamDistributedTest fails
>>
>> Regards
>>
>>
>> On Fri, Mar 16, 2012 at 3:51 PM, Nicholas Ball > > wrote:
>>
>>>
>>> Mikhail & Ludovic,
>>>
>>> Thanks for both your replies, very helpful indeed!
>>>
>>> Ludovic, I was actually looking into just that and did some tests with
>>> SolrJ, it does work well but needs some changes on the Solr server if we
>>> want to send out individual documents a various times. This could be done
>>> with a write() and flush() to the FastOutputStream (daos) in
>>> JavBinCodec. I
>>> therefore think that a combination of this and Mikhail's solution would
>>> work best!
>>>
>>> Mikhail, you mention that your solution doesn't currently work and not
>>> sure why this is the case, but could it be that you haven't flushed the
>>> data (os.flush()) you've written in the collect method of
>>> DocSetStreamer? I
>>> think placing the output stream into the SolrQueryRequest is the way to
>>> go,
>>> so that we can access it and write to it how we intend. However, I think
>>> using the JavaBinCodec would be ideal so that we can work with SolrJ
>>> directly, and not mess around with the encoding of the docs/data etc...
>>>
>>> At the moment the entry point to JavaBinCodec is through the
>>> BinaryResponseWriter which calls the highest level marshal() method which
>>> decodes and sends out the entire SolrQueryResponse (line 49 @
>>> BinaryResponseWriter). What would be ideal is to be able to break up the
>>> response and call the JavaBinCodec for pieces of it with a flush after
>>> each
>>> call. Did a few tests with a simple Thread.sleep and a flush to see if
>>> this
>>> would actually work and looks like it's working out perfectly. Just
>>> trying
>>> to figure out the best way to actually do it now :) any ideas?
>>>
>>> An another note, for a solution to work with the chunked transfer
>>> encoding
>>> (and therefore web browsers), a lot more development is going to be
>>> needed.
>>> Not sure if it's worth trying yet but might look into it later down the
>>> line.
>>>
>>> Nick
>>>
>>> On Fri, 16 Mar 2012 07:29:20 +0300, Mikhail Khludnev
>>>  wrote:
>>> > Ludovic,
>>> >
>>> > I looked through. First of all, it seems to me you don't amend regular
>>> > "servlet" solr server, but the only embedded one.
>>> > Anyway, the difference is that you stream DocList via callback, but it
>>> > means that you've instantiated it in memory and keep it there until it
>>> will
>>> > be completely consumed. Think about a billion numfound. Core idea of my
>>> > approach is keep almost zero memory for response.
>>> >
>>> > Regards
>>> >
>>> > On Fri, Mar 16, 2012 at 12:12 AM, lboutros  wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I was looking for something similar.
>>> >>
>>> >> I tried this patch :
>>> >>
>>> >> https://issues.apache.org/jira/browse/SOLR-2112
>>> >>
>>> >> it's working quite well (I've back-ported the code in Solr 3.5.0...).
>>> >>
>>> >> Is it really different from what you are trying to achieve ?
>>> >>
>>> >> Ludovic.
>>> >>
>>> >> -
>>> >> Jouve
>>> >> France.
>>> >> --
>>> >> View this message in context:
>>> >>
>>>
>>> http://lucene.472066.n3.nabble.com/Responding-to-Requests-

Re: buildbot failure in ASF Buildbot on lucene-site-staging

[Robert Muir]

I don't think buildbot liked my svn moves... I'll see if I can make
him happy again.

On Thu, Apr 12, 2012 at 3:38 PM,   wrote:
> The Buildbot has detected a new failure on builder lucene-site-staging while 
> building ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/lucene-site-staging/builds/168
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: bb-cms-slave
>
> Build Reason: scheduler
> Build Source Stamp: [branch lucene/cms] 1325460
> Blamelist: rmuir
>
> BUILD FAILED: failed compile
>
> sincerely,
>  -The Buildbot
>
>
>



-- 
lucidimagination.com

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

Re: VOTE: Lucene/Solr 3.6 (take two)

[Mark Miller]

It's already on many mirrors. The announce will be soon.

On Apr 12, 2012, at 1:19 PM, Bill Bell wrote:

> When is it going out?
> 
> Sent from my Mobile device
> 720-256-8076
> 
> On Apr 11, 2012, at 12:30 PM, Robert Muir  wrote:
> 
>> Vote has passed. Thanks everyone.
>> 
>> On Tue, Apr 10, 2012 at 9:50 AM, Yonik Seeley
>>  wrote:
>>> +1
>>> 
>>> -Yonik
>>> lucenerevolution.com - Lucene/Solr Open Source Search Conference.
>>> Boston May 7-10
>>> 
>>> 
>>> On Fri, Apr 6, 2012 at 1:27 PM, Robert Muir  wrote:
 Artifacts here: http://s.apache.org/lusolr36rc1
 
 I tested with smoketester, (including newly added checks), so here is my 
 +1.
 Note: smoketester currently does not support windows (use a linux system)
 
 --
 lucidimagination.com
 
 -
 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
>>> 
>> 
>> 
>> 
>> -- 
>> lucidimagination.com
>> 
>> -
>> 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
> 

- Mark Miller
lucidimagination.com












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

[jira] [Commented] (LUCENE-3973) Incorporate PMD / FindBugs

[Dawid Weiss (Commented) (JIRA)]

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

Dawid Weiss commented on LUCENE-3973:
-

I believe both pmd and findbugs are on maven repos so one could use ivy to 
fetch them automatically. One thing less to think about.

> Incorporate PMD / FindBugs
> --
>
> Key: LUCENE-3973
> URL: https://issues.apache.org/jira/browse/LUCENE-3973
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Chris Male
>
> This has been touched on a few times over the years.  Having static analysis 
> as part of our build seems like a big win.  For example, we could use PMD to 
> look at {{System.out.println}} statements like discussed in LUCENE-3877 and 
> we could possibly incorporate the nocommit / @author checks as well.
> There are a few things to work out as part of this:
> - Should we use both PMD and FindBugs or just one of them? They look at code 
> from different perspectives (bytecode vs source code) and target different 
> issues.  At the moment I'm in favour of trying both but that might be too 
> heavy handed for our needs.
> - What checks should we use? There's no point having the analysis if it's 
> going to raise too many false-positives or problems we don't deem 
> problematic.  
> - How should the analysis be integrated in our build? Need to work out when 
> the analysis should run, how it should be incorporated in Ant and/or Maven, 
> what impact errors should have.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3973) Incorporate PMD / FindBugs

[Hoss Man (Commented) (JIRA)]

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

Hoss Man commented on LUCENE-3973:
--

bq. How should the analysis be integrated in our build? Need to work out when 
the analysis should run, how it should be incorporated in Ant and/or Maven, 
what impact errors should have.

i would suggest going about it incrementally...

* hook into build.xml as optional targets that can be run if you have the 
neccessary libs installed, don't fail the build just generate the XML report 
files
* put the needed libs on builds.apache.org, and hook it into the jenkins 
nightly target, and configure jenkins to display it's pretty version of the xml 
reports so people can at least see what's going on.
* start adding/tweaking custom rule sets in dev-tools to eliminate rules we 
don't care about, add rules we want that don't exist, or change the severity of 
rules we think are more/less important
* tweak the build.xml to fail if anything above some arbitrary severity is 
tripped
* worry about maven





> Incorporate PMD / FindBugs
> --
>
> Key: LUCENE-3973
> URL: https://issues.apache.org/jira/browse/LUCENE-3973
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Chris Male
>
> This has been touched on a few times over the years.  Having static analysis 
> as part of our build seems like a big win.  For example, we could use PMD to 
> look at {{System.out.println}} statements like discussed in LUCENE-3877 and 
> we could possibly incorporate the nocommit / @author checks as well.
> There are a few things to work out as part of this:
> - Should we use both PMD and FindBugs or just one of them? They look at code 
> from different perspectives (bytecode vs source code) and target different 
> issues.  At the moment I'm in favour of trying both but that might be too 
> heavy handed for our needs.
> - What checks should we use? There's no point having the analysis if it's 
> going to raise too many false-positives or problems we don't deem 
> problematic.  
> - How should the analysis be integrated in our build? Need to work out when 
> the analysis should run, how it should be incorporated in Ant and/or Maven, 
> what impact errors should have.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

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

[Shawn Heisey (Commented) (JIRA)]

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

Shawn Heisey commented on SOLR-1972:


Let's have everyone pretend for a minute that I have a slightly better grasp of 
Solr/Lucene internals than I actually do.  Perhaps I will one day be able to 
take what you say and figure out what it means.  I am very interested in having 
these stats available without patching Solr on my own.

What would be the right way to go about re-implementing this as a module (along 
with some unit tests) so the code could be committed?


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: eDismax pf2 and pf3

[Chris Hostetter]

: Just glancing at it quickly... but it seems like the original code
: quoted above would add phrases if there were 2 terms (keeping in mind
: that "pf" in the original patch was eventually changed to "pf2".)

BAH ... you are absolutely correct ... 

aparently i made the same mistake *twice* ... once when refactoring it, 
and once yesterday when reading it to see if i screwed up the refactoring.

-Hoss

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

Re: http://wiki.apache.org/solr/WritingDistributedSearchComponents

[Mikhail Khludnev]

Btw, I always wanted to ask why it's always done in two stages. It seems to
me that it's purposed for the specific usecase. But shouldn't we have an
option to do it in the single stage? eg. if I have a few fields to retrieve
and not really deep paging, I'd like to retrieve whole fl-s and merge them
by PKs.

Benson,
Thanks for contributing the doc for community. I spend a lot of time to get
into that machinery on my own.

Regards

On Thu, Apr 12, 2012 at 4:17 AM, Yonik Seeley wrote:

> On Wed, Apr 11, 2012 at 8:15 PM, Benson Margulies 
> wrote:
> > I'd like to add some more information to this; to that end, I'd
> > appreciate a correctness review of the following:
> >
> > * QueryComponent distribution algorithm
> >
> > The query component distributes queries in two passes. First, it sends
> > the query out to the shards with the field list trimmed to be just the
> > score and the doc ID. Upon receipt of these results, it merges the
> > lists, and then issues new queries out to the shards with
> > ids=id1,id2,... to retrieve the remaining fields. The results are
> > packaged up and flow out through the result writer.
>
> Yep.
>
> -Yonik
> lucenerevolution.com - Lucene/Solr Open Source Search Conference.
> Boston May 7-10
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Sincerely yours
Mikhail Khludnev
ge...@yandex.ru


 

[jira] [Commented] (SOLR-3324) Put field name/type in the analysis URL

[Ryan McKinley (Commented) (JIRA)]

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

Ryan McKinley commented on SOLR-3324:
-

This looks good -- can the URL update when you click "Analyse Values" so that 
it is easy to know the bookmarkable URL?  

Can verbose also be in the URL?

Looking at this a bit more, how does 'type_or_name' work?  I have field names 
that are the same as the type name -- typically they use the same type, so it 
does not really matter... but it seems better to avoid that assumption.

Perhaps the param could look like:
 f=type.pint
or
 f=name.id







> Put field name/type in the analysis URL 
> 
>
> Key: SOLR-3324
> URL: https://issues.apache.org/jira/browse/SOLR-3324
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-3324.patch
>
>
> It would be nice to be able to link directly to a page that loads the right 
> field in the analysis UI.
> This will also let us link the query-browser page to the analysis page

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: Patch format

[Mikhail Khludnev]

FWIW,
I'm using git-svn-diff.sh to prepare patches before submitting
http://markjaquith.wordpress.com/2011/05/26/developing-on-wordpress-using-git/


Regards

On Wed, Apr 11, 2012 at 10:25 PM, Dawid Weiss
wrote:

> I don't think there are any differences other than:
>
> 1) prefix added by git which can be stripped with -p1,
> 2) binary patches incompatibility (doesn't seem to be of much
> importance since we don't have jars anymore and binary test files can
> be added separately).
>
> Dawid
>
> On Wed, Apr 11, 2012 at 8:21 PM, Benson Margulies 
> wrote:
> > On Wed, Apr 11, 2012 at 2:19 PM, Robert Muir  wrote:
> >> If its a patch from git/hg/etc, I just apply with patch -p1...
> >> (ignoring the a/, b/ stuff)... are there any other traps? I've never
> >> had any issue with that.
> >
> > Dunno. Perhaps Jan Høydahl would care to elaborate, as he is the
> > person who suggested sticking to 'svn diff'?
> >
> >
> >>
> >> On Wed, Apr 11, 2012 at 2:14 PM, Benson Margulies <
> bimargul...@gmail.com> wrote:
> >>> I'm using the git mirror when making patches. Has anyone worked out a
> >>> good way to get patches in the usual highly digestible subversion
> >>> format when operating in this mode?
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> lucidimagination.com
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Sincerely yours
Mikhail Khludnev
ge...@yandex.ru


 

[jira] [Resolved] (SOLR-3325) Linking to query page in UI with parameters should execute the query

[Ryan McKinley (Resolved) (JIRA)]

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

Ryan McKinley resolved SOLR-3325.
-

Resolution: Fixed
  Assignee: Stefan Matheis (steffkes)

Thanks Stefan

added in r1325390

> Linking to query page in UI with parameters should execute the query
> 
>
> Key: SOLR-3325
> URL: https://issues.apache.org/jira/browse/SOLR-3325
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: SOLR-3325.patch
>
>
> When linking to the query page with parameters, this should execute the query.
> Right now linking to:
> http://localhost:8983/solr/#/singlecore/query?q=id:[*%20TO%20*]
> requires you to then hit the 'Execute Query' button

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: VOTE: Lucene/Solr 3.6 (take two)

[Bill Bell]

When is it going out?

Sent from my Mobile device
720-256-8076

On Apr 11, 2012, at 12:30 PM, Robert Muir  wrote:

> Vote has passed. Thanks everyone.
> 
> On Tue, Apr 10, 2012 at 9:50 AM, Yonik Seeley
>  wrote:
>> +1
>> 
>> -Yonik
>> lucenerevolution.com - Lucene/Solr Open Source Search Conference.
>> Boston May 7-10
>> 
>> 
>> On Fri, Apr 6, 2012 at 1:27 PM, Robert Muir  wrote:
>>> Artifacts here: http://s.apache.org/lusolr36rc1
>>> 
>>> I tested with smoketester, (including newly added checks), so here is my +1.
>>> Note: smoketester currently does not support windows (use a linux system)
>>> 
>>> --
>>> lucidimagination.com
>>> 
>>> -
>>> 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
>> 
> 
> 
> 
> -- 
> lucidimagination.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Updated] (SOLR-3327) Logging UI should indicate which loggers are set vs implicit

[Ryan McKinley (Updated) (JIRA)]

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

Ryan McKinley updated SOLR-3327:


Attachment: logging.png

The bold looks good, but it seems like it is getting applied to more then just 
the things that are "set"

For example, if I take the default config and change just the javax value, the 
text value looks right, but the level value gets bold for everything below it

!logging.png!

> Logging UI should indicate which loggers are set vs implicit
> 
>
> Key: SOLR-3327
> URL: https://issues.apache.org/jira/browse/SOLR-3327
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3327.patch, logging.png
>
>
> The new logging UI looks great!
> http://localhost:8983/solr/#/~logging
> It would be nice to indicate which ones are set explicitly vs implicit -- 
> perhaps making the line bold when set=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3174) Visualize Cluster State

[Mark Miller (Commented) (JIRA)]

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

Mark Miller commented on SOLR-3174:
---

just looked - currently there is also recovery_failed.

So perhaps down should be orange (it's not sure to be terrible if you are down 
- you might still recover)
and then recovery_failed should be red.

> Visualize Cluster State
> ---
>
> Key: SOLR-3174
> URL: https://issues.apache.org/jira/browse/SOLR-3174
> Project: Solr
>  Issue Type: New Feature
>  Components: web gui
>Reporter: Ryan McKinley
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png, 
> SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch, 
> SOLR-3174.patch
>
>
> It would be great to visualize the cluster state in the new UI. 
> See Mark's wish:
> https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3174) Visualize Cluster State

[Mark Miller (Commented) (JIRA)]

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

Mark Miller commented on SOLR-3174:
---

bq. Perhaps we need to tweak the colors in the UI to make it more clear if 
something is active/gone/down and which one is the master?

+1

I think that logic looks okay. Another possible status is Recovering.

An idea for colors:
active - green
down - red
gone - gray
recovering - yellow

> Visualize Cluster State
> ---
>
> Key: SOLR-3174
> URL: https://issues.apache.org/jira/browse/SOLR-3174
> Project: Solr
>  Issue Type: New Feature
>  Components: web gui
>Reporter: Ryan McKinley
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png, 
> SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch, 
> SOLR-3174.patch
>
>
> It would be great to visualize the cluster state in the new UI. 
> See Mark's wish:
> https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2459) Implement LogLevelSelection as a RequestHandler

[Ryan McKinley (Resolved) (JIRA)]

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

Ryan McKinley resolved SOLR-2459.
-

   Resolution: Fixed
Fix Version/s: 4.0

> Implement LogLevelSelection as a RequestHandler
> ---
>
> Key: SOLR-2459
> URL: https://issues.apache.org/jira/browse/SOLR-2459
> Project: Solr
>  Issue Type: Wish
>  Components: web gui
>Reporter: Stefan Matheis (steffkes)
>Assignee: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LogLevelHandler.patch, SOLR-2459-LogLevel.patch, 
> SOLR-2459-LogLevel.patch, sample-output.json, sample-output.xml
>
>
> The current available Output of the LogLevelSelection Servlet is plain HTML, 
> which made it unpossible, to integrate the Logging-Information in the new 
> Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
> be really nice!
> Just as an Idea for a future structure, the new admin-ui is [actually based 
> on that 
> json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
>  :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Martijn van Groningen (Commented) (JIRA)]

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

Martijn van Groningen commented on LUCENE-3972:
---

bq. If you have fewer unique groups (and as the number of docs collected goes 
up), I think the current impl should be faster...?
This is true. I ran a few tests on an index containing 10M docs:
||Run||Num unique groups||Perf. collector in patch||Perf. committed collector|| 
|1|~65000|892 ms|132 ms|
|2|~645000|1183 ms|878 ms|
|3|~953000|1291 ms|1517 ms|
|4|~1819000|1783 ms|3762 ms|
|5|~3332000|2703 ms|4882 ms|
|6|~6668000|4840 ms|18989 ms|

All the times are the average over 10 executions with a match all query.

bq. the time is likely dominated by re-ord'ing for each segment?
During run 4 I noticed that 3470 ms of the total 3762 ms was spend on 
re-ord'ing groups for segments.

It seems that the implementation in the patch is only usable if a search yields 
many unique groups as result.  

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3977) generated/duplicated javadocs are wasteful and bloat the release

[Robert Muir (Commented) (JIRA)]

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

Robert Muir commented on LUCENE-3977:
-

We can save 10MB with this patch, which nukes the 'index'.
I guarantee you nobody will miss it. Just click this thing and see how 
useless it is (since its every method etc in all of lucene).

{noformat}
Index: common-build.xml
===
--- common-build.xml(revision 1310449)
+++ common-build.xml(working copy)
@@ -996,6 +996,7 @@
   encoding="${build.encoding}"
   charset="${javadoc.charset}"
   docencoding="${javadoc.charset}"
+  noindex="true"
   author="true"
   version="true"
   use="true"
{noformat}


> generated/duplicated javadocs are wasteful and bloat the release
> 
>
> Key: LUCENE-3977
> URL: https://issues.apache.org/jira/browse/LUCENE-3977
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Robert Muir
>Priority: Blocker
> Fix For: 4.0
>
>
> Some stats for the generated javadocs of 3.6:
> * 9,146 files
> * 161,872 KB uncompressed
> * 25MB compressed (this is responsible for nearly half of our binary release)
> The fact we intentionally double our javadocs size with the 'javadocs-all' 
> thing
> is truly wasteful and compression doesn't help at all. Just testing, i nuked 
> 'all'
> and found:
> * 4,944 files
> * 81,084 KB uncompressed
> * 12.8MB compressed
> We need to clean this up for 4.0. We only need to ship javadocs 'one way'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3353) Commented examples in solrconfig.xml don't account for SolrCloud in URP chains

[Mark Miller (Commented) (JIRA)]

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

Mark Miller commented on SOLR-3353:
---

Nice catch!

> Commented examples in solrconfig.xml don't account for SolrCloud in URP chains
> --
>
> Key: SOLR-3353
> URL: https://issues.apache.org/jira/browse/SOLR-3353
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Benson Margulies
>Assignee: Mark Miller
>
> The example solrconfig.xml includes several items like:
> {code}
>  
> class="org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory">
>  text,title,subject,description
>  language_s
>  en
>
>
>
>  
> {code}
> that leave out the DistributedUpdateProcessorFactory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3353) Commented examples in solrconfig.xml don't account for SolrCloud in URP chains

[Mark Miller (Assigned) (JIRA)]

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

Mark Miller reassigned SOLR-3353:
-

Assignee: Mark Miller

> Commented examples in solrconfig.xml don't account for SolrCloud in URP chains
> --
>
> Key: SOLR-3353
> URL: https://issues.apache.org/jira/browse/SOLR-3353
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Benson Margulies
>Assignee: Mark Miller
>
> The example solrconfig.xml includes several items like:
> {code}
>  
> class="org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory">
>  text,title,subject,description
>  language_s
>  en
>
>
>
>  
> {code}
> that leave out the DistributedUpdateProcessorFactory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3977) generated/duplicated javadocs are wasteful and bloat the release

[Robert Muir (Created) (JIRA)]

generated/duplicated javadocs are wasteful and bloat the release


 Key: LUCENE-3977
 URL: https://issues.apache.org/jira/browse/LUCENE-3977
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/javadocs
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.0


Some stats for the generated javadocs of 3.6:
* 9,146 files
* 161,872 KB uncompressed
* 25MB compressed (this is responsible for nearly half of our binary release)

The fact we intentionally double our javadocs size with the 'javadocs-all' thing
is truly wasteful and compression doesn't help at all. Just testing, i nuked 
'all'
and found:
* 4,944 files
* 81,084 KB uncompressed
* 12.8MB compressed

We need to clean this up for 4.0. We only need to ship javadocs 'one way'.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3354) LeaderElectionIntegrationTest

[Dawid Weiss (Created) (JIRA)]

LeaderElectionIntegrationTest
-

 Key: SOLR-3354
 URL: https://issues.apache.org/jira/browse/SOLR-3354
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
 Fix For: 4.0


>From my build server.
{noformat}
12-Apr-2012 02:29:21[junit] Testcase: 
testSimpleSliceLeaderElection(org.apache.solr.cloud.LeaderElectionIntegrationTest):
FAILED
12-Apr-2012 02:29:21[junit] We didn't find a new leader! 7004 was 
shutdown, but it's still showing as the leader
12-Apr-2012 02:29:21[junit] junit.framework.AssertionFailedError: We 
didn't find a new leader! 7004 was shutdown, but it's still showing as the 
leader
12-Apr-2012 02:29:21[junit] at 
org.junit.Assert.fail(Assert.java:93)
12-Apr-2012 02:29:21[junit] at 
org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:174)
12-Apr-2012 02:29:21[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12-Apr-2012 02:29:21[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
12-Apr-2012 02:29:21[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
12-Apr-2012 02:29:21[junit] at 
java.lang.reflect.Method.invoke(Method.java:597)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
12-Apr-2012 02:29:21[junit] at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
12-Apr-2012 02:29:21[junit] at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
12-Apr-2012 02:29:21[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
12-Apr-2012 02:29:21[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
12-Apr-2012 02:29:21[junit] at 
org.junit.rules.RunRules.evaluate(RunRules.java:18)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
12-Apr-2012 02:29:21[junit] at 
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
12-Apr-2012 02:29:21[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
12-Apr-2012 02:29:21[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
12-Apr-2012 02:29:21[junit] at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtE

Re: LeaderElectionIntegrationTest failure

[Dawid Weiss]

SOLR-3354

I allowed myself to initially assign it to you, Sami :).

Dawid

On Thu, Apr 12, 2012 at 11:51 AM, Sami Siren  wrote:
> On Thu, Apr 12, 2012 at 10:01 AM, Dawid Weiss  wrote:
>> Anybody has a clue if it's something I should file as a bug?
>
> Please do so, i have seen this happen locally too.
>
> --
>  Sami Siren
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (LUCENE-3972) Improve AllGroupsCollector implementations

[Michael McCandless (Commented) (JIRA)]

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

Michael McCandless commented on LUCENE-3972:


Actually, we are storing term ords here, not docIDs.

I think the high number of unique groups explains why the new patch is
faster: the time is likely dominated by re-ord'ing for each segment?

If you have fewer unique groups (and as the number of docs collected goes up),
I think the current impl should be faster...?


> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Dawid Weiss (Commented) (JIRA)]

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

Dawid Weiss commented on LUCENE-3972:
-

Hmmm... it's not collisions then, it was worth a try. I still find the 
difference puzzling -- I can't justify your version being 3x faster. Curious 
what it might be.

bq. But we know a lot about docids, and extra hashing should just lead to an 
average-case slowdown.

Ok.

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

Test for NoSQL databases?

[Patrick Durusau]

Greetings!

I had yet another NoSQL database release come through my inbox today 
with interesting claims about data handling.


The thought occurred to me that perhaps some of the NoSQL 
vendors/projects could be enlisted to create a test data suite from some 
of the material that Grant has already uploaded?


At first probably just the raw data files at first but once imports are 
available, perhaps more people would start exploring the data set and 
creating richer versions for particular tests.


Don't know if anyone would even be interested but thought it might be a 
way to get more hands on deck.


Thoughts?

Hope everyone is having a great week!

Patrick

--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
OASIS Technical Advisory Board (TAB) - member

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

[jira] [Created] (SOLR-3353) Commented examples in solrconfig.xml don't account for SolrCloud in URP chains

[Benson Margulies (Created) (JIRA)]

Commented examples in solrconfig.xml don't account for SolrCloud in URP chains
--

 Key: SOLR-3353
 URL: https://issues.apache.org/jira/browse/SOLR-3353
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Benson Margulies


The example solrconfig.xml includes several items like:

{code}
 
   
 text,title,subject,description
 language_s
 en
   
   
   
 
{code}

that leave out the DistributedUpdateProcessorFactory.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Yonik Seeley (Commented) (JIRA)]

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

Yonik Seeley commented on LUCENE-3972:
--

bq. I would also patch it for the future in either case. 

Hmmm, if you don't know anything about the integer keys, then a little extra 
hashing by default is a good idea.
But we know a lot about docids, and extra hashing should just lead to an 
average-case slowdown.


> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Martijn van Groningen (Commented) (JIRA)]

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

Martijn van Groningen commented on LUCENE-3972:
---

I ran a test with the changes to SentinelIntSet and one without. Performance 
difference between the two tests are minimal. The test with the changes is 
somewhat slower (15.7 s) than the one without the changes (15.3 s).

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Dawid Weiss (Commented) (JIRA)]

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

Dawid Weiss commented on LUCENE-3972:
-

Yes, sorry -- hash of course. The hash method that should redistribute keys 
space into buckets (but currently doesn't).

As for BytesRefHash vs. BytesRef instances -- maybe it's the source of the 
speedup, who knows. I would try the hash method though, if nothing else just 
for curiosity. I would also patch it for the future in either case. Not 
rehashing input keys is a flaw in my opinion (again -- backed by real life 
experience from HPPC).

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Martijn van Groningen (Commented) (JIRA)]

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

Martijn van Groningen commented on LUCENE-3972:
---

The major difference between the committed TermAllGroupsCollector and one in 
the patch is that committed TermAllGroupsCollector creates a BytesRef instance 
for each unique group and puts it in a ArrayList (5M in my case). The version 
in the patch reuses a single BytesRef instance. The BytesRef bytes are copied 
into the BytesRefHash big bytes array via the BytesRefHash#add(...) method. I 
think the many BytesRef instances makes the committed TermAllGroupsCollector 
slow.

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3301) Migrate enable/disable Ping from JSP to PingRequestHandler

[Stefan Matheis (steffkes) (Commented) (JIRA)]

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

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

Would you mind to create one (combined) Patch for me? Then i'd go ahead and 
commit this one

> Migrate enable/disable Ping from JSP to PingRequestHandler
> --
>
> Key: SOLR-3301
> URL: https://issues.apache.org/jira/browse/SOLR-3301
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Eric Pugh
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: PingRequestHandlerTest.java, healthcheck-ui.png, 
> healthcheckenable.patch, ping_request_handler.patch
>
>
> My colleague @omnifroodle and I noticed that you can't enable/disable pings 
> in 4.0 because action.jsp doesn't run.  This patch attaches the functionality 
> to the PingRequestHandler.  We debated creating a new 
> HealthcheckRequestHandler as well.   We added some basic unit tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3312) Allows Solr Admin GUI to display schema and solrconfig files that aren't named "schema.xml" or "solrconfig.xml"

[Stefan Matheis (steffkes) (Resolved) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-3312.
-

Resolution: Fixed

Committed in r1325268

> Allows Solr Admin GUI to display schema and solrconfig files that aren't 
> named "schema.xml" or "solrconfig.xml"
> ---
>
> Key: SOLR-3312
> URL: https://issues.apache.org/jira/browse/SOLR-3312
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Eric Pugh
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: admin-cores-example.json, 
> handle_differently_named_schema_solrconfig_files.patch, 
> handle_differently_named_schema_solrconfig_files2.patch
>
>
> The admin.html file hardcodes the path for the admin/file handler to use for 
> schema and solrconfig.xml.   This patch allows you to get back the file names 
> from /admin/cores?action=status, and use them in the subsequent lookup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Martijn van Groningen (Commented) (JIRA)]

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

Martijn van Groningen commented on LUCENE-3972:
---

Dawid - Do you mean the hash method instead of rehash method in SentinelIntSet? 
The rehash methods doesn't have any parameters. 

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3312) Allows Solr Admin GUI to display schema and solrconfig files that aren't named "schema.xml" or "solrconfig.xml"

[Stefan Matheis (steffkes) (Assigned) (JIRA)]

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

Stefan Matheis (steffkes) reassigned SOLR-3312:
---

Assignee: Stefan Matheis (steffkes)

> Allows Solr Admin GUI to display schema and solrconfig files that aren't 
> named "schema.xml" or "solrconfig.xml"
> ---
>
> Key: SOLR-3312
> URL: https://issues.apache.org/jira/browse/SOLR-3312
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Eric Pugh
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: admin-cores-example.json, 
> handle_differently_named_schema_solrconfig_files.patch, 
> handle_differently_named_schema_solrconfig_files2.patch
>
>
> The admin.html file hardcodes the path for the admin/file handler to use for 
> schema and solrconfig.xml.   This patch allows you to get back the file names 
> from /admin/cores?action=status, and use them in the subsequent lookup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3301) Migrate enable/disable Ping from JSP to PingRequestHandler

[Stefan Matheis (steffkes) (Assigned) (JIRA)]

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

Stefan Matheis (steffkes) reassigned SOLR-3301:
---

Assignee: Stefan Matheis (steffkes)

> Migrate enable/disable Ping from JSP to PingRequestHandler
> --
>
> Key: SOLR-3301
> URL: https://issues.apache.org/jira/browse/SOLR-3301
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Eric Pugh
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: PingRequestHandlerTest.java, healthcheck-ui.png, 
> healthcheckenable.patch, ping_request_handler.patch
>
>
> My colleague @omnifroodle and I noticed that you can't enable/disable pings 
> in 4.0 because action.jsp doesn't run.  This patch attaches the functionality 
> to the PingRequestHandler.  We debated creating a new 
> HealthcheckRequestHandler as well.   We added some basic unit tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (LUCENE-3972) Improve AllGroupsCollector implementations

[Dawid Weiss (Issue Comment Edited) (JIRA)]

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

Dawid Weiss edited comment on LUCENE-3972 at 4/12/12 1:52 PM:
--

This is curious indeed. One thing to check would be this: SentinelIntSet uses 
no key rehashing (rehash simply returns the key). This resulted in very poor 
performance for certain regular integer sets (my experience from implementing 
HPPC). So while rehashing may seem like an additional overhead, it actually 
boosts performance.

Martijn -- could you patch the trunk's SentinelIntSet#rehash with, for example, 
this (murmur hash3 tail):
{noformat}
public static int rehash(int k)
{
k ^= k >>> 16;
k *= 0x85ebca6b;
k ^= k >>> 13;
k *= 0xc2b2ae35;
k ^= k >>> 16;
return k;
}
{noformat}
and retry your test? Btw. I'm not saying it'll be faster :)

  was (Author: dweiss):
This is curious indeed. One thing to check would be this: SentinelIntSet 
uses no key rehashing (rehash simply returns the key). This resulted in very 
poor performance for certain regular integer sets (my experience from 
implementing HPPC). So while rehashing may seem like an additional overhead, it 
actually boosts performance.

Martijn -- could you patch the trunk's SentinelIntSet#rehash with, for example, 
this (murmur hash3 tail):
{noformat}
public static int rehash(int k)
{
k ^= k >>> 16;
k *= 0x85ebca6b;
k ^= k >>> 13;
k *= 0xc2b2ae35;
k ^= k >>> 16;
return k;
}
{noformat}
  
> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3317) Admin UI: Improve request handler / qt in query form

[Stefan Matheis (steffkes) (Updated) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-3317:


Attachment: SOLR-3317.patch

Um sorry, i thought this ticket was about something else - patch attached, 
David would you give a try?

> Admin UI: Improve request handler / qt in query form
> 
>
> Key: SOLR-3317
> URL: https://issues.apache.org/jira/browse/SOLR-3317
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: David Smiley
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: SOLR-3317.patch
>
>
> The query form in the admin UI could use an improvement regarding how the 
> request handler is chosen; presently all there is is a text input for 'qt'. 
> The first choice to make in the form above the query should really be the 
> request handler since it actually handles the request before any other 
> parameters do anything.  I think it'd be nice if it was filled with "/select" 
> by default to make it very clear what's there, although I realize most of 
> this query form seems to prefer blank values as defaults.  When the form 
> creates the URL to submit to Solr for the search, it needs to do something 
> different depending on wether this value starts with a '/'.  If it does, this 
> goes where "/select" goes in the URL normally (i.e. it's the tail end of the 
> path after the core).  If it doesn't then it goes into the 'qt' URL parameter.
> I did something similar to the old 3x UI in SOLR-3161 that got committed to 
> 3.6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Dawid Weiss (Commented) (JIRA)]

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

Dawid Weiss commented on LUCENE-3972:
-

This is curious indeed. One thing to check would be this: SentinelIntSet uses 
no key rehashing (rehash simply returns the key). This resulted in very poor 
performance for certain regular integer sets (my experience from implementing 
HPPC). So while rehashing may seem like an additional overhead, it actually 
boosts performance.

Martijn -- could you patch the trunk's SentinelIntSet#rehash with, for example, 
this (murmur hash3 tail):
{noformat}
public static int rehash(int k)
{
k ^= k >>> 16;
k *= 0x85ebca6b;
k ^= k >>> 13;
k *= 0xc2b2ae35;
k ^= k >>> 16;
return k;
}
{noformat}

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3301) Migrate enable/disable Ping from JSP to PingRequestHandler

[Eric Pugh (Commented) (JIRA)]

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

Eric Pugh commented on SOLR-3301:
-

Can this be committed?

> Migrate enable/disable Ping from JSP to PingRequestHandler
> --
>
> Key: SOLR-3301
> URL: https://issues.apache.org/jira/browse/SOLR-3301
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Eric Pugh
> Fix For: 4.0
>
> Attachments: PingRequestHandlerTest.java, healthcheck-ui.png, 
> healthcheckenable.patch, ping_request_handler.patch
>
>
> My colleague @omnifroodle and I noticed that you can't enable/disable pings 
> in 4.0 because action.jsp doesn't run.  This patch attaches the functionality 
> to the PingRequestHandler.  We debated creating a new 
> HealthcheckRequestHandler as well.   We added some basic unit tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3312) Allows Solr Admin GUI to display schema and solrconfig files that aren't named "schema.xml" or "solrconfig.xml"

[Eric Pugh (Commented) (JIRA)]

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

Eric Pugh commented on SOLR-3312:
-

Any chance of getting this committed?  

> Allows Solr Admin GUI to display schema and solrconfig files that aren't 
> named "schema.xml" or "solrconfig.xml"
> ---
>
> Key: SOLR-3312
> URL: https://issues.apache.org/jira/browse/SOLR-3312
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Eric Pugh
> Fix For: 4.0
>
> Attachments: admin-cores-example.json, 
> handle_differently_named_schema_solrconfig_files.patch, 
> handle_differently_named_schema_solrconfig_files2.patch
>
>
> The admin.html file hardcodes the path for the admin/file handler to use for 
> schema and solrconfig.xml.   This patch allows you to get back the file names 
> from /admin/cores?action=status, and use them in the subsequent lookup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Martijn van Groningen (Updated) (JIRA)]

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

Martijn van Groningen updated LUCENE-3972:
--

Attachment: LUCENE-3972.patch

Tested the current patch on a index containing 10M documents that has ~5M 
unique groups. The already existing implementation needs ~15.3 seconds to get 
the total group count and the new impl in the patch needs ~4.4 seconds to get 
the total group count.

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch, LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2459) Implement LogLevelSelection as a RequestHandler

[Stefan Matheis (steffkes) (Assigned) (JIRA)]

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

Stefan Matheis (steffkes) reassigned SOLR-2459:
---

Assignee: Ryan McKinley

Ryan, i guess we can close this, do we?

> Implement LogLevelSelection as a RequestHandler
> ---
>
> Key: SOLR-2459
> URL: https://issues.apache.org/jira/browse/SOLR-2459
> Project: Solr
>  Issue Type: Wish
>  Components: web gui
>Reporter: Stefan Matheis (steffkes)
>Assignee: Ryan McKinley
>Priority: Trivial
> Attachments: LogLevelHandler.patch, SOLR-2459-LogLevel.patch, 
> SOLR-2459-LogLevel.patch, sample-output.json, sample-output.xml
>
>
> The current available Output of the LogLevelSelection Servlet is plain HTML, 
> which made it unpossible, to integrate the Logging-Information in the new 
> Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
> be really nice!
> Just as an Idea for a future structure, the new admin-ui is [actually based 
> on that 
> json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
>  :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3972) Improve AllGroupsCollector implementations

[Michael McCandless (Commented) (JIRA)]

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

Michael McCandless commented on LUCENE-3972:


Curious that it's so much faster ... BytesRefHash operates on the byte[] term 
while the current approach operates on int ord.

How large was the index?  If it was smallish, maybe the time was dominated by 
re-ord'ing after each reader...?

> Improve AllGroupsCollector implementations
> --
>
> Key: LUCENE-3972
> URL: https://issues.apache.org/jira/browse/LUCENE-3972
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Martijn van Groningen
> Attachments: LUCENE-3972.patch
>
>
> I think that the performance of TermAllGroupsCollectorm, 
> DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by 
> using BytesRefHash to store the groups instead of an ArrayList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: LeaderElectionIntegrationTest failure

[Sami Siren]

On Thu, Apr 12, 2012 at 10:01 AM, Dawid Weiss  wrote:
> Anybody has a clue if it's something I should file as a bug?

Please do so, i have seen this happen locally too.

--
 Sami Siren

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

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

[Commented]

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

Jan Høydahl commented on SOLR-2368:
---

Today we can use pf, pf2, pf3 to *boost* only, as qf is required and always 
adds a MUST clause.
I think it would be useful to allow "pf/pf2/pf3" to give results if "qf" is not 
specified, i.e. empty qf must not add any MUST clause to the query.

Then this would generate a query with one SHOULD clause returning *only* docs 
where foo and bar exist within 100 terms.
{noformat}
q=foo bar&qf=&pf=text&ps=100
{noformat}

In fact, it is impossible to say qf= to specify an empty qf, it still falls 
back to schema's defaultSearchField..

> Improve extended dismax (edismax) parser
> 
>
> Key: SOLR-2368
> URL: https://issues.apache.org/jira/browse/SOLR-2368
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Yonik Seeley
>  Labels: QueryParser
>
> This is a "mother" issue to track further improvements for eDismax parser.
> The goal is to be able to deprecate and remove the old dismax once edismax 
> satisfies all usecases of dismax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3976) Improve error messages for unsupported Hunspell formats

[Chris Male (Created) (JIRA)]

Improve error messages for unsupported Hunspell formats
---

 Key: LUCENE-3976
 URL: https://issues.apache.org/jira/browse/LUCENE-3976
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Chris Male


Our hunspell implementation is never going to be able to support the huge 
variety of formats that are out there, especially since our impl is based on 
papers written on the topic rather than being a pure port.

Recently we ran into the following suffix rule:

{noformat}SFX CA 0 /CaCp{noformat}

Due to the missing regex conditional, an AOE was being thrown, which made it 
difficult to diagnose the problem.

We should instead try to provide better error messages showing what we were 
unable to parse.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3350) TextField's parseFieldQuery method not using analyzer's enablePosIncr parameter

[Tommaso Teofili (Commented) (JIRA)]

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

Tommaso Teofili commented on SOLR-3350:
---

Hi Robert,
For TextField having enablePositionIncrements just set to true and then 
evaluating an always true condition seems just wrong (code wise) so we should 
discuss if the issue is either in the true constant or in the code switching on 
it.
It should be clear how a mixed configuration like the one above should result 
in terms of an "overall" enablePositionIncrements property (true, false, not 
set) if that's needed in the field type implementation (maybe traversing 
objects from the QParser to the SchemaField or in some more convenient way, if 
it exists).
Depending on the choice taken on how to fix the code, if a Solr type using 
TextField has a tokenizer/some filters with enablePositionIncrements set to 
false then there would be different options:
- option 1: it should raise a configuration error
- option 2: log a warning message
- option 3: don't care (like it is now)

> TextField's parseFieldQuery method not using analyzer's enablePosIncr 
> parameter
> ---
>
> Key: SOLR-3350
> URL: https://issues.apache.org/jira/browse/SOLR-3350
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 3.5, 4.0
>Reporter: Tommaso Teofili
>Priority: Minor
>
> parseFieldQuery method of TextField class just set 
> {code}
>   ...
>   boolean enablePositionIncrements = true;
>   ...
> {code}
> while that should be taken from Analyzer's configuration.
> The above condition is evaluated afterwards in two points:
> {code}
>   ...
>   if (enablePositionIncrements) {
> mpq.add((Term[]) multiTerms.toArray(new Term[0]), position);
>   } else {
> mpq.add((Term[]) multiTerms.toArray(new Term[0]));
>   }
>   return mpq;
>   ...
>   ...
>   if (enablePositionIncrements) {
> position += positionIncrement;
> pq.add(new Term(field, term), position);
>   } else {
>  pq.add(new Term(field, term));
>   }
>   ...
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3317) Admin UI: Improve request handler / qt in query form

[Stefan Matheis (steffkes) (Commented) (JIRA)]

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

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

Sorry David i've overlooked this one .. if you can, go for it! ty

> Admin UI: Improve request handler / qt in query form
> 
>
> Key: SOLR-3317
> URL: https://issues.apache.org/jira/browse/SOLR-3317
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: David Smiley
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
>
> The query form in the admin UI could use an improvement regarding how the 
> request handler is chosen; presently all there is is a text input for 'qt'. 
> The first choice to make in the form above the query should really be the 
> request handler since it actually handles the request before any other 
> parameters do anything.  I think it'd be nice if it was filled with "/select" 
> by default to make it very clear what's there, although I realize most of 
> this query form seems to prefer blank values as defaults.  When the form 
> creates the URL to submit to Solr for the search, it needs to do something 
> different depending on wether this value starts with a '/'.  If it does, this 
> goes where "/select" goes in the URL normally (i.e. it's the tail end of the 
> path after the core).  If it doesn't then it goes into the 'qt' URL parameter.
> I did something similar to the old 3x UI in SOLR-3161 that got committed to 
> 3.6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2605) CoreAdminHandler, different Output while 'defaultCoreName' is specified

[Stefan Matheis (steffkes) (Commented) (JIRA)]

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

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

Not sure, where it comes from .. the {{clusterstate.json}} file looks like 
this, using the patch:

{code}{"collection1":{"shard1":{
  "debian2:8983_solr_":{
"shard":"shard1",
"state":"active",
"core":"",
"collection":"collection1",
"node_name":"debian2:8983_solr",
"base_url":"http://debian2:8983/solr"},
  "debian2:8983_solr_collection1":{
"shard":"shard1",
"leader":"true",
"state":"active",
"core":"collection1",
"collection":"collection1",
"node_name":"debian2:8983_solr",
"base_url":"http://debian2:8983/solr"{code}

Started with {{-DzkRun -Dcollection.configName=myconf 
-Dbootstrap_confdir=./solr/conf -Dsolr.environment=dev -Duser.timezone=UTC 
-DhostPort=8983 -Djetty.port=8983}}

> CoreAdminHandler, different Output while 'defaultCoreName' is specified
> ---
>
> Key: SOLR-2605
> URL: https://issues.apache.org/jira/browse/SOLR-2605
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2399-admin-cores-default.xml, 
> SOLR-2399-admin-cores.xml, SOLR-2605.patch, SOLR-2605.patch
>
>
> The attached XML-Files show the little difference between a defined 
> {{defaultCoreName}}-Attribute and a non existing one.
> Actually the new admin ui checks for an core with empty name to set single- / 
> multicore-settings .. it's a quick change to count the number of defined 
> cores instead.
> But, will it be possible, to get the core-name (again)? One of both 
> attributes would be enough, if that makes a difference :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3352) eDismax: pf2 should kick in for a query with 2 terms

[Updated]

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

Jan Høydahl updated SOLR-3352:
--

Attachment: SOLR-3352.patch

The patch. Only change is "<=" into "<".

Also adding test for pf, pf2, pf3 and ps to validate the fix.

Let's fix this now and worry about optimizing potential corner cases with 
redundant clauses as a separate issue.

> eDismax: pf2 should kick in for a query with 2 terms
> 
>
> Key: SOLR-3352
> URL: https://issues.apache.org/jira/browse/SOLR-3352
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 4.0
>
> Attachments: SOLR-3352.patch
>
>
> ...and pf3 for query with 3 terms. Today q=foo bar does not generate a 
> bigram, but q=foo bar baz generates two bigrams.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3339) Cloud-View in Multicore-Mode broken

[Stefan Matheis (steffkes) (Resolved) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-3339.
-

Resolution: Fixed

> Cloud-View in Multicore-Mode broken
> ---
>
> Key: SOLR-3339
> URL: https://issues.apache.org/jira/browse/SOLR-3339
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: SOLR-3339.patch, SOLR-3339.patch
>
>
> [Jamie pointed 
> out|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201204.mbox/%3CCAL3VrCfu64g42D=4uapxc+43ruyauyk8rv-_6eqyyf5em8l...@mail.gmail.com%3E]
>  that the Cloud-View does not work if you're using Solr in Multicore-Mode

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3174) Visualize Cluster State

[Stefan Matheis (steffkes) (Updated) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-3174:


Attachment: SOLR-3174.patch

Updated Patch, the implemented Logic looks like this:

{code}if( live_nodes[node_name] && 'active' === state ) { status = 'active'; }
else if( live_nodes[node_name] )  { status = 'down'; }
else  { status = 'gone'; }{code}

As far as i understand .. that is specific enough to get the right state shown, 
right?

Perhaps we need to tweak the colors in the UI to make it more clear if 
something is active/gone/down and which one is the master? let me know what you 
think

> Visualize Cluster State
> ---
>
> Key: SOLR-3174
> URL: https://issues.apache.org/jira/browse/SOLR-3174
> Project: Solr
>  Issue Type: New Feature
>  Components: web gui
>Reporter: Ryan McKinley
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png, 
> SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch, 
> SOLR-3174.patch
>
>
> It would be great to visualize the cluster state in the new UI. 
> See Mark's wish:
> https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3325) Linking to query page in UI with parameters should execute the query

[Stefan Matheis (steffkes) (Updated) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-3325:


Attachment: SOLR-3325.patch

Form will be automatically submitted, if there is at least one parameter in the 
url

> Linking to query page in UI with parameters should execute the query
> 
>
> Key: SOLR-3325
> URL: https://issues.apache.org/jira/browse/SOLR-3325
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-3325.patch
>
>
> When linking to the query page with parameters, this should execute the query.
> Right now linking to:
> http://localhost:8983/solr/#/singlecore/query?q=id:[*%20TO%20*]
> requires you to then hit the 'Execute Query' button

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3327) Logging UI should indicate which loggers are set vs implicit

[Stefan Matheis (steffkes) (Updated) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-3327:


Attachment: SOLR-3327.patch

First shot, is bold visible enough or do we need some other style of marker?

> Logging UI should indicate which loggers are set vs implicit
> 
>
> Key: SOLR-3327
> URL: https://issues.apache.org/jira/browse/SOLR-3327
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3327.patch
>
>
> The new logging UI looks great!
> http://localhost:8983/solr/#/~logging
> It would be nice to indicate which ones are set explicitly vs implicit -- 
> perhaps making the line bold when set=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3324) Put field name/type in the analysis URL

[Stefan Matheis (steffkes) (Updated) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-3324:


Attachment: SOLR-3324.patch

This patch allows: 
{{/analysis?analysis.fieldvalue=index&analysis.query=query&type_or_name=text_rev}}
 - will set the form-fields to the given values and execute the Analysis

> Put field name/type in the analysis URL 
> 
>
> Key: SOLR-3324
> URL: https://issues.apache.org/jira/browse/SOLR-3324
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-3324.patch
>
>
> It would be nice to be able to link directly to a page that loads the right 
> field in the analysis UI.
> This will also let us link the query-browser page to the analysis page

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3330) Show changes in plugin statistics across multiple requests

[Stefan Matheis (steffkes) (Commented) (JIRA)]

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

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

bq. Right now the UI shows the values from 1, then updates the changes between 
2&3 – the problem is that the values that may have changed between 1&2 are not 
reflected in the UI. (Not a huge deal, but not accurate)

Ah yes, you're right. Hm, will think about that. perhaps there is a quick 
solution for that. Also for the 'new' icon .. yes, the icon set does not have 
an 'update' icon ;o

> Show changes in plugin statistics across multiple requests
> --
>
> Key: SOLR-3330
> URL: https://issues.apache.org/jira/browse/SOLR-3330
> Project: Solr
>  Issue Type: New Feature
>  Components: web gui
>Reporter: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-3330-pluggins-diff.patch, 
> SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, 
> SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch
>
>
> When debugging configuration and performance, I often:
>  1. Look at stats values
>  2. run some queries
>  3. See how the stats values changed
> This is fine, but is often a bit clunky and you have to really know what you 
> are looking for to see any changes.
> It would be great if the 'plugins' page had a button that would make this 
> easier

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3101) Add an operator to edismax for word order (Proximity / NEAR)

[Commented]

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

Jan Høydahl commented on SOLR-3101:
---

That's up to us to define. We could allow a special syntax as for range 
searches for this, e.g. {{ONEAR/*}}.

We'd also need to define what should be the default {{N}}, if people write A 
NEAR B. Perhaps 25? Could be configurable through e.g. {{&q.near=N}}.

Should we perhaps open a LUCENE Jira for the low-level part of this - which 
"blocks" this issue?

> Add an operator to edismax for word order (Proximity / NEAR)
> 
>
> Key: SOLR-3101
> URL: https://issues.apache.org/jira/browse/SOLR-3101
> Project: Solr
>  Issue Type: Sub-task
>  Components: query parsers
>Reporter: Mike
> Fix For: 4.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> A project I'm working on requires *word order* searching. The users are 
> accustomed to Sphinx search, and expect a query like [ A << B ] to return 
> only documents that contain the term A before the term B.
> I believe this can currently be done with the surround parser (SOLR-2703), 
> but we lack an operator for it. It would be great to add it, so that word 
> order searches can be combined by users into sophisticated queries. 
> Note that this should also support a query like [ A << A], which would 
> require that the term be in the document twice (the first instance before the 
> second).
> This issue is part of a meta issue, SOLR-3028, that is requesting two other 
> operators in edismax (quorum search and exact match).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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