date:20120412

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

Dawid Weiss commented on LUCENE-3973:
-

There is also this interesting tool: http://babelfish.arc.nasa.gov/trac/jpf

I haven't used it and I don't know if it can handle Lucene size codebase (the
number of execution paths will be astronomic) but if somebody has some time to
play with it, it'd be interesting to hear what it can do.

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

2012-04-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)

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

Dawid Weiss commented on LUCENE-3973:
-

Both are helpful. We use both and I think FindBugs is slightly more useful than
PMD but it's just a subjective opinion not anything I measured.

Also, both can be verbose and a pain in the ass at times when you know the code
is right and they still complain... And they are long to execute so they should
be part of jenkins nightly/ smoke tests I think, not regular builds (and
definitely not ant test...).

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

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

2012-04-12 Thread Commented

[
https://issues.apache.org/jira/browse/SOLR-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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).

-
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

[
https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
23 – the problem is that the values that may have changed between 12 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

-
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

2012-04-12 Thread 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=indexanalysis.query=querytype_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] [Updated] (SOLR-3327) Logging UI should indicate which loggers are set vs implicit

2012-04-12 Thread 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-3325) Linking to query page in UI with parameters should execute the query

2012-04-12 Thread 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-3174) Visualize Cluster State

2012-04-12 Thread 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=13218272page=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-3339) Cloud-View in Multicore-Mode broken

2012-04-12 Thread 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-3352) eDismax: pf2 should kick in for a query with 2 terms

2012-04-12 Thread 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] [Commented] (SOLR-2605) CoreAdminHandler, different Output while 'defaultCoreName' is specified

2012-04-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (SOLR-3317) Admin UI: Improve request handler / qt in query form

2012-04-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.

-
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

2012-04-12 Thread Tommaso Teofili (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (LUCENE-3976) Improve error messages for unsupported Hunspell formats

2012-04-12 Thread 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-2368) Improve extended dismax (edismax) parser

2012-04-12 Thread Commented

[
https://issues.apache.org/jira/browse/SOLR-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 barqf=pf=textps=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.

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

Re: LeaderElectionIntegrationTest failure

2012-04-12 Thread Sami Siren

On Thu, Apr 12, 2012 at 10:01 AM, Dawid Weiss dawid.we...@gmail.com 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] (LUCENE-3972) Improve AllGroupsCollector implementations

2012-04-12 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Assigned] (SOLR-2459) Implement LogLevelSelection as a RequestHandler

2012-04-12 Thread 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] [Updated] (LUCENE-3972) Improve AllGroupsCollector implementations

2012-04-12 Thread 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] [Commented] (SOLR-3312) Allows Solr Admin GUI to display schema and solrconfig files that aren't named schema.xml or solrconfig.xml

2012-04-12 Thread Eric Pugh (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (SOLR-3317) Admin UI: Improve request handler / qt in query form

2012-04-12 Thread 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] [Issue Comment Edited] (LUCENE-3972) Improve AllGroupsCollector implementations

2012-04-12 Thread Dawid Weiss (Issue Comment Edited) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Assigned] (SOLR-3301) Migrate enable/disable Ping from JSP to PingRequestHandler

2012-04-12 Thread 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] [Assigned] (SOLR-3312) Allows Solr Admin GUI to display schema and solrconfig files that aren't named schema.xml or solrconfig.xml

2012-04-12 Thread 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] [Commented] (LUCENE-3972) Improve AllGroupsCollector implementations

2012-04-12 Thread Martijn van Groningen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (SOLR-3312) Allows Solr Admin GUI to display schema and solrconfig files that aren't named schema.xml or solrconfig.xml

2012-04-12 Thread 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] (SOLR-3301) Migrate enable/disable Ping from JSP to PingRequestHandler

2012-04-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (LUCENE-3972) Improve AllGroupsCollector implementations

2012-04-12 Thread Martijn van Groningen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (LUCENE-3972) Improve AllGroupsCollector implementations

[
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.

-
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

2012-04-12 Thread Yonik Seeley (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (SOLR-3353) Commented examples in solrconfig.xml don't account for SolrCloud in URP chains

2012-04-12 Thread 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}
 updateRequestProcessorChain name=langid
   processor 
class=org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory
 str name=langid.fltext,title,subject,description/str
 str name=langid.langFieldlanguage_s/str
 str name=langid.fallbacken/str
   /processor
   processor class=solr.LogUpdateProcessorFactory /
   processor class=solr.RunUpdateProcessorFactory /
 /updateRequestProcessorChain
{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

Test for NoSQL databases?

2012-04-12 Thread 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] [Commented] (LUCENE-3972) Improve AllGroupsCollector implementations


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

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

2012-04-12 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

Re: LeaderElectionIntegrationTest failure

2012-04-12 Thread 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 ssi...@gmail.com wrote:
 On Thu, Apr 12, 2012 at 10:01 AM, Dawid Weiss dawid.we...@gmail.com 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] [Created] (LUCENE-3977) generated/duplicated javadocs are wasteful and bloat the release

2012-04-12 Thread 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] [Assigned] (SOLR-3353) Commented examples in solrconfig.xml don't account for SolrCloud in URP chains

2012-04-12 Thread 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}
  updateRequestProcessorChain name=langid
processor 
 class=org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory
  str name=langid.fltext,title,subject,description/str
  str name=langid.langFieldlanguage_s/str
  str name=langid.fallbacken/str
/processor
processor class=solr.LogUpdateProcessorFactory /
processor class=solr.RunUpdateProcessorFactory /
  /updateRequestProcessorChain
 {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] (SOLR-3353) Commented examples in solrconfig.xml don't account for SolrCloud in URP chains

2012-04-12 Thread Mark Miller (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
  updateRequestProcessorChain name=langid
processor 
 class=org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory
  str name=langid.fltext,title,subject,description/str
  str name=langid.langFieldlanguage_s/str
  str name=langid.fallbacken/str
/processor
processor class=solr.LogUpdateProcessorFactory /
processor class=solr.RunUpdateProcessorFactory /
  /updateRequestProcessorChain
 {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-3977) generated/duplicated javadocs are wasteful and bloat the release

2012-04-12 Thread Martijn van Groningen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (LUCENE-3972) Improve AllGroupsCollector implementations


[ 
https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (SOLR-2459) Implement LogLevelSelection as a RequestHandler

2012-04-12 Thread 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] (SOLR-3174) Visualize Cluster State

2012-04-12 Thread Mark Miller (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=13218272page=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-3327) Logging UI should indicate which loggers are set vs implicit

2012-04-12 Thread 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

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

2012-04-12 Thread 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 rcm...@gmail.com wrote:

 Vote has passed. Thanks everyone.
 
 On Tue, Apr 10, 2012 at 9:50 AM, Yonik Seeley
 yo...@lucidimagination.com 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 rcm...@gmail.com 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] [Resolved] (SOLR-3325) Linking to query page in UI with parameters should execute the query

2012-04-12 Thread 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

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

2012-04-12 Thread Ryan McKinley (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: eDismax pf2 and pf3

2012-04-12 Thread 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

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

2012-04-12 Thread Shawn Heisey (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

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

[
https://issues.apache.org/jira/browse/LUCENE-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

-
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

[
https://issues.apache.org/jira/browse/LUCENE-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

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

2012-04-12 Thread 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 rcm...@gmail.com wrote:
 
 Vote has passed. Thanks everyone.
 
 On Tue, Apr 10, 2012 at 9:50 AM, Yonik Seeley
 yo...@lucidimagination.com 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 rcm...@gmail.com 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

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

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,  build...@apache.org 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: Responding to Requests with Chunks/Streaming

2012-04-12 Thread 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 nicholas.b...@nodelay.com
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
mkhlud...@griddynamics.com 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 boutr...@gmail.com 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-with-Chunks-Streaming-tp3827316p3829909.html
Sent from the Solr - User mailing list archive at Nabble.com.

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

http://www.griddynamics.com
mkhlud...@griddynamics.com

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

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

2012-04-12 Thread 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,  build...@apache.org 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

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

2012-04-12 Thread 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 LinkedListCharacter 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

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 markrmil...@gmail.com 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,  build...@apache.org 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

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

2012-04-12 Thread 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

[ANNOUNCE] Apache Lucene 3.6 released.

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

[ANNOUNCE] Apache Solr 3.6 released

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

[jira] [Resolved] (SOLR-3210) 3.6 POST RELEASE TASK: update site tutorial.html to link to versioned tutorial

2012-04-12 Thread 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

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


[ 
https://issues.apache.org/jira/browse/LUCENE-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (LUCENE-3973) Incorporate PMD / FindBugs

[
https://issues.apache.org/jira/browse/LUCENE-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

-
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

2012-04-12 Thread 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] [Updated] (SOLR-3355) Add shard name to SolrCore statistics

2012-04-12 Thread 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] [Commented] (SOLR-3327) Logging UI should indicate which loggers are set vs implicit

2012-04-12 Thread Commented


[ 
https://issues.apache.org/jira/browse/SOLR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (LUCENE-3977) generated/duplicated javadocs are wasteful and bloat the release


[ 
https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (LUCENE-3978) redo how our download redirect pages work

2012-04-12 Thread 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-3978) redo how our download redirect pages work


[ 
https://issues.apache.org/jira/browse/LUCENE-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (LUCENE-3977) generated/duplicated javadocs are wasteful and bloat the release


[ 
https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-3977) generated/duplicated javadocs are wasteful and bloat the release


[ 
https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (SOLR-3356) Logging UI (and LogLevelHandler) should support Log4j

2012-04-12 Thread 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] [Updated] (SOLR-3356) Logging UI (and LogLevelHandler) should support Log4j

2012-04-12 Thread 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}
str name=frameworkjava.util.logging/str
str name=slfj4org.slf4j.impl.JDK14LoggerFactory/str
{code}

{code:xml}
str name=frameworklog4j/str
str name=slfj4org.slf4j.impl.Log4jLoggerFactory/str
{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

Screencasts on the tutorial page?

2012-04-12 Thread 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] [Commented] (SOLR-3238) Sequel of Admin UI

2012-04-12 Thread dylan (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=xmlrows=10start=0q=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=trueanalysis.query=analysis.fieldname=ageseganalysis.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

[jira] [Assigned] (SOLR-3355) Add shard name to SolrCore statistics

2012-04-12 Thread 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] [Updated] (SOLR-3355) Add shard name to SolrCore statistics

2012-04-12 Thread 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] [Commented] (LUCENE-3979) NGramTokenizer

2012-04-12 Thread David Mason (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Updated] (LUCENE-3979) NGramTokenizer strips whitespace, with no option to keep leading and trailing whitespace

2012-04-12 Thread 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-3978) redo how our download redirect pages work

2012-04-12 Thread Uwe Schindler (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=enanswer=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] [Commented] (SOLR-3327) Logging UI should indicate which loggers are set vs implicit

2012-04-12 Thread Shawn Heisey (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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