date:20110714

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

Michael McCandless updated LUCENE-3309:
---

Attachment: LUCENE-3309.patch

Thanks Chris -- great feedback! I agree with all your suggestions...

New patch:

* Removed oal.documen2.FieldSelector*

* Renamed moved to standalone StoredFieldVisitor.java

* Made the default/sugar visitor first class, as
DocumentStoredFieldVisitor.java, also allowing it to optionally
accept SetString fieldsToLoad.

* Fix javadoc errors I think I caused, but we [separately] have
pre-existing javadoc errors that need fixing (Nikola: can you
address these? Thanks!).

Sorry, my changes have some svn mvs, and my last patch was from svn
diff. New patch should be fully applyable... (to field type
branch).

Add narrow API for loading stored fields, to replace FieldSelector
--

Key: LUCENE-3309
URL: https://issues.apache.org/jira/browse/LUCENE-3309
Project: Lucene - Java
Issue Type: Improvement
Components: core/index
Reporter: Michael McCandless
Fix For: Field Type branch

Attachments: LUCENE-3309.patch, LUCENE-3309.patch, LUCENE-3309.patch

I think we should invert the FieldSelector API, with a push API
whereby FieldsReader invokes this API once per field in the document
being visited.
Implementations of the API can then do arbitrary things like save away
the field's size, load the field, clone the IndexInput for later lazy
loading, etc.
This very thin API would be a mirror image of the very thin index time
API we now have (IndexableField) and, importantly, it would have no
dependence on our user space Document/Field/FieldType impl, so apps
are free to do something totally custom.
After we have this, we should build the sugar API that rebuilds a
Document instance (ie IR.document(int docID)) on top of this new thin
API. This'll also be a good test that the API is sufficient.
Relevant discussions from IRC this morning at
http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-07-13#l76

--
This message is automatically generated by JIRA.
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-3309) Add narrow API for loading stored fields, to replace FieldSelector

2011-07-14 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-3309:


Super, +1 to committing.

 Add narrow API for loading stored fields, to replace FieldSelector
 --

 Key: LUCENE-3309
 URL: https://issues.apache.org/jira/browse/LUCENE-3309
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Reporter: Michael McCandless
 Fix For: Field Type branch

 Attachments: LUCENE-3309.patch, LUCENE-3309.patch, LUCENE-3309.patch


 I think we should invert the FieldSelector API, with a push API
 whereby FieldsReader invokes this API once per field in the document
 being visited.
 Implementations of the API can then do arbitrary things like save away
 the field's size, load the field, clone the IndexInput for later lazy
 loading, etc.
 This very thin API would be a mirror image of the very thin index time
 API we now have (IndexableField) and, importantly, it would have no
 dependence on our user space Document/Field/FieldType impl, so apps
 are free to do something totally custom.
 After we have this, we should build the sugar API that rebuilds a
 Document instance (ie IR.document(int docID)) on top of this new thin
 API.  This'll also be a good test that the API is sufficient.
 Relevant discussions from IRC this morning at
 http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-07-13#l76

--
This message is automatically generated by JIRA.
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-2186) DataImportHandler multi-threaded option throws exception


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

Shalin Shekhar Mangar reassigned SOLR-2186:
---

Assignee: Shalin Shekhar Mangar  (was: Grant Ingersoll)

 DataImportHandler multi-threaded option throws exception
 

 Key: SOLR-2186
 URL: https://issues.apache.org/jira/browse/SOLR-2186
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Reporter: Lance Norskog
Assignee: Shalin Shekhar Mangar
 Attachments: SOLR-2186.patch, SOLR-2186.patch, Solr-2186.patch, 
 TestDocBuilderThreaded.java, TestTikaEntityProcessor.patch, TikaResolver.patch


 The multi-threaded option for the DataImportHandler throws an exception and 
 the entire operation fails. This is true even if only 1 thread is configured 
 via *threads='1'*

--
This message is automatically generated by JIRA.
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-3312) Break out StorableField from IndexableField

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

Simon Willnauer commented on LUCENE-3312:
-

once we are on this here we should think about breaking out storing fields from
the indexing chain. I think this could easily be a separated process such that
stored fields are not written by the indexing chain but once all fields are
indexed. This would make the indexing chain somewhat cleaner I think.

Break out StorableField from IndexableField
---

Key: LUCENE-3312
URL: https://issues.apache.org/jira/browse/LUCENE-3312
Project: Lucene - Java
Issue Type: Improvement
Components: core/index
Reporter: Michael McCandless
Fix For: Field Type branch

In the field type branch we have strongly decoupled
Document/Field/FieldType impl from the indexer, by having only a
narrow API (IndexableField) passed to IndexWriter. This frees apps up
use their own documents instead of the user-space impls we provide
in oal.document.
Similarly, with LUCENE-3309, we've done the same thing on the
doc/field retrieval side (from IndexReader), with the
StoredFieldsVisitor.
But, maybe we should break out StorableField from IndexableField,
such that when you index a doc you provide two Iterables -- one for the
IndexableFields and one for the StorableFields. Either can be null.
One downside is possible perf hit for fields that are both indexed
stored (ie, we visit them twice, lookup their name in a hash twice,
etc.). But the upside is a cleaner separation of concerns in API

--
This message is automatically generated by JIRA.
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-2186) DataImportHandler multi-threaded option throws exception


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

Shalin Shekhar Mangar updated SOLR-2186:


Attachment: SOLR-2186.patch

A patch which fixes the NPE with multi-threaded mode.

The problem was that the resolver is supposed to be looked up just-in-time for 
the current entity but ThreadedContext delegated the getResolvedEntityAttribute 
method to super class which did not have one. The fix was to override 
getResolvedEntityAttribute correctly.

I added the TestTikaEntityProcessor patch by Frank in the patch.

This does not solve the problem with the evaluators - I'll add a patch in 
SOLR-2463 to fix it.

 DataImportHandler multi-threaded option throws exception
 

 Key: SOLR-2186
 URL: https://issues.apache.org/jira/browse/SOLR-2186
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Reporter: Lance Norskog
Assignee: Shalin Shekhar Mangar
 Attachments: SOLR-2186.patch, SOLR-2186.patch, SOLR-2186.patch, 
 Solr-2186.patch, TestDocBuilderThreaded.java, TestTikaEntityProcessor.patch, 
 TikaResolver.patch


 The multi-threaded option for the DataImportHandler throws an exception and 
 the entire operation fails. This is true even if only 1 thread is configured 
 via *threads='1'*

--
This message is automatically generated by JIRA.
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-3309) Add narrow API for loading stored fields, to replace FieldSelector


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

Simon Willnauer commented on LUCENE-3309:
-

ah man I am to late :)

I only looked at the StoredFieldVisitor briefly, what I always missed is a 
String... fieldsToLoad ctor for convenience which simply passes an array that 
is used to create a set. in several environments this would be helpful for 
example when you get the fields to load from a request or something like that.

I also don't understand why the set is null in the default ctors, can't we use 
the empty set here. If we want to prevent the method call if no fields should 
be loaded there should be a LoadNoFieldsVisitor I think, no?


 Add narrow API for loading stored fields, to replace FieldSelector
 --

 Key: LUCENE-3309
 URL: https://issues.apache.org/jira/browse/LUCENE-3309
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Reporter: Michael McCandless
 Fix For: Field Type branch

 Attachments: LUCENE-3309.patch, LUCENE-3309.patch, LUCENE-3309.patch


 I think we should invert the FieldSelector API, with a push API
 whereby FieldsReader invokes this API once per field in the document
 being visited.
 Implementations of the API can then do arbitrary things like save away
 the field's size, load the field, clone the IndexInput for later lazy
 loading, etc.
 This very thin API would be a mirror image of the very thin index time
 API we now have (IndexableField) and, importantly, it would have no
 dependence on our user space Document/Field/FieldType impl, so apps
 are free to do something totally custom.
 After we have this, we should build the sugar API that rebuilds a
 Document instance (ie IR.document(int docID)) on top of this new thin
 API.  This'll also be a good test that the API is sufficient.
 Relevant discussions from IRC this morning at
 http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-07-13#l76

--
This message is automatically generated by JIRA.
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-3309) Add narrow API for loading stored fields, to replace FieldSelector

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

Michael McCandless commented on LUCENE-3309:

bq. ah man I am to late

No you're not! It's just software ;) The iterations go on and on and on...

bq. I only looked at the StoredFieldVisitor briefly, what I always missed is a
String... fieldsToLoad ctor for convenience which simply passes an array that
is used to create a set

You mean DocumentStoredFieldVisitor, right? Ie the default/sugar visitor that
makes a Document. I agree we should add a sugar ctor taking String... I'll do
that.

bq. I also don't understand why the set is null in the default ctors, can't we
use the empty set here.

Hmm but the default ctor means all fields are accepted (empty set would mean
none).

bq. If we want to prevent the method call if no fields should be loaded there
should be a LoadNoFieldsVisitor I think, no?

Wait, shouldn't the app just not call IR.document() if it wants no fields?

Add narrow API for loading stored fields, to replace FieldSelector
--

Key: LUCENE-3309
URL: https://issues.apache.org/jira/browse/LUCENE-3309
Project: Lucene - Java
Issue Type: Improvement
Components: core/index
Reporter: Michael McCandless
Fix For: Field Type branch

Attachments: LUCENE-3309.patch, LUCENE-3309.patch, LUCENE-3309.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS-MAVEN] Lucene-Solr-Maven-3.x #181: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-3.x/181/

No tests ran.

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



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

[jira] [Updated] (SOLR-2535) REGRESSION: in Solr 3.x and trunk the admin/file handler fails to show directory listings

2011-07-14 Thread Erick Erickson (JIRA)


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

Erick Erickson updated SOLR-2535:
-

Attachment: SOLR-2535-post-SOLR-2452.patch

Patch to reflect relocated code.

 REGRESSION: in Solr 3.x and trunk the admin/file handler fails to show 
 directory listings
 -

 Key: SOLR-2535
 URL: https://issues.apache.org/jira/browse/SOLR-2535
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 3.1, 3.2, 4.0
 Environment: java 1.6, jetty
Reporter: Peter Wolanin
Assignee: Erick Erickson
 Fix For: 3.4, 4.0

 Attachments: SOLR-2535-post-SOLR-2452.patch, SOLR-2535.patch, 
 SOLR-2535_fix_admin_file_handler_for_directory_listings.patch


 In Solr 1.4.1, going to the path solr/admin/file I see an XML-formatted 
 listing of the conf directory, like:
 {noformat}
 response
 lst name=responseHeaderint name=status0/intint 
 name=QTime1/int/lst
 lst name=files
   lst name=elevate.xmllong name=size1274/longdate 
 name=modified2011-03-06T20:42:54Z/date/lst
   ...
 /lst
 /response
 {noformat}
 I can list the xslt sub-dir using solr/admin/files?file=/xslt
 In Solr 3.1.0, both of these fail with a 500 error:
 {noformat}
 HTTP ERROR 500
 Problem accessing /solr/admin/file/. Reason:
 did not find a CONTENT object
 java.io.IOException: did not find a CONTENT object
 {noformat}
 Looking at the code in class ShowFileRequestHandler, it seem like 3.1.0 
 should still handle directory listings if not file name is given, or if the 
 file is a directory, so I am filing this as a bug.

--
This message is automatically generated by JIRA.
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-3313) fix nightly build timeouts

fix nightly build timeouts
--

 Key: LUCENE-3313
 URL: https://issues.apache.org/jira/browse/LUCENE-3313
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir


The nightly builds are timing out, here are the problems
# we need to get a notification of build failure when this happens, because if 
they just silently die they dont report anything to the dev list, masking real 
test failures (like this one 
https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/)
# we need to fix the tests with NIGHTLY so that this generally succeeds

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure

TestNumericRangeQuery test failure
--

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir


https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/

ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
-Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
-Dtests.nightly=true

--
This message is automatically generated by JIRA.
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: FindBugs PMD ?

2011-07-14 Thread Smiley, David W.

I did more digging and realized I completely forgot that these concurrency
annotations are available with CLASS retention as the findbugs jsr305 jar.
Here's an example of one of the sources:
http://www.jarvana.com/jarvana/view/com/google/code/findbugs/jsr305/1.3.9/jsr305-1.3.9.jar!/javax/annotation/concurrent/GuardedBy.java?format=ok
Since it is CLASS retention, the jar isn't a runtime dependency, and there is
no transitive compile issue with Java 5 (see the HttpClient URL below for that
bug). FYI, this jsr305 jar is using a creative-commons attribution license.

Chris, I read your thoughts on custom PMD rules. I think that's a fantastic
idea. I'm not sure if these rules should be PMD rules or FindBugs rules, but
we can cross that bridge when we come to it. AFAIK, FindBugs is way more
popular so I would favor that.

~ David

On Jul 8, 2011, at 3:17 PM, Smiley, David W. wrote:

The annotations defined by FindBugs are marked with CLASS retention, which
means there shouldn't be a runtime dependency.

However the JCIP (Java Concurrency In Practice, a book) annotations, such as
@ThreadSafe, are unfortunately marked with RUNTIME retention. Information
I've found leads me to believe that in Java 6, there is no runtime or compile
time dependency for 3rd party libraries using Lucene/Solr if there are
annotations there, but Java 5 has problems with it:
https://issues.apache.org/jira/browse/HTTPCLIENT-866Just now I messaged
the maintainer of the ASL licensed cleanroom port of the findbugs annotations
to see if he'll do the same for the JCIP ones.

~ David

On Jul 8, 2011, at 1:16 PM, Uwe Schindler wrote:

Just a stupid question:
Once you add those annotations, wouldn't the JAR file not require then this
annotations.jar? Or are all of them not available to runtime?

Uwe

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

-Original Message-
From: Smiley, David W. [mailto:dsmi...@mitre.org]
Sent: Friday, July 08, 2011 4:30 PM
To: dev@lucene.apache.org
Subject: Re: FindBugs PMD ?

Rob, there is an ASL 2.0 licensed implementation here:
https://github.com/stephenc/findbugs-annotations

~ David

On Jul 8, 2011, at 10:12 AM, Robert Muir wrote:

On Fri, Jul 8, 2011 at 10:08 AM, Smiley, David W. dsmi...@mitre.org
wrote:
Developers,
Any thoughts on using FindBugs PMD to catch more bugs in
Lucene/Solr? Jenkins could be configured to run FindBugs PMD analysis
nightly. It would have helped find this:

(LUCENE-3294) Some code still compares string equality
instead using equals

I am aware there are a high degree of false-positives but there are
ways
of dealing with them, such as with @SuppressWarnings(PMD) and with
//NOPMD and for Findbugs, there is
@edu.umd.cs.findbugs.annotations.SuppressWarnings() and there's a
fairly detailed configuration file for FindBugs to really control it and
to make
exceptions. I'd also really like to see use of FindBugs concurrency
annotations @GuardedBy, @Immutable, @NotThreadSafe, @ThreadSafe.

I think its a good idea for nightly, but I am strongly against linking
to an LGPL library for these annotations.
I would prefer PMD instead, because of the license.

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

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

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

[JENKINS-MAVEN] Lucene-Solr-Maven-3.x #182: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-3.x/182/

No tests ran.

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



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

[jira] [Commented] (LUCENE-3309) Add narrow API for loading stored fields, to replace FieldSelector


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

Simon Willnauer commented on LUCENE-3309:
-

bq. Wait, shouldn't the app just not call IR.document() if it wants no fields?
nevermind I was confused about the null set.

simon

 Add narrow API for loading stored fields, to replace FieldSelector
 --

 Key: LUCENE-3309
 URL: https://issues.apache.org/jira/browse/LUCENE-3309
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Reporter: Michael McCandless
 Fix For: Field Type branch

 Attachments: LUCENE-3309.patch, LUCENE-3309.patch, LUCENE-3309.patch


 I think we should invert the FieldSelector API, with a push API
 whereby FieldsReader invokes this API once per field in the document
 being visited.
 Implementations of the API can then do arbitrary things like save away
 the field's size, load the field, clone the IndexInput for later lazy
 loading, etc.
 This very thin API would be a mirror image of the very thin index time
 API we now have (IndexableField) and, importantly, it would have no
 dependence on our user space Document/Field/FieldType impl, so apps
 are free to do something totally custom.
 After we have this, we should build the sugar API that rebuilds a
 Document instance (ie IR.document(int docID)) on top of this new thin
 API.  This'll also be a good test that the API is sufficient.
 Relevant discussions from IRC this morning at
 http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-07-13#l76

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure


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

Robert Muir updated LUCENE-3314:


Affects Version/s: 4.0

Setting affects=4.0, I'm beasting the test on 3.x and 4.0 to try to find seeds 
that fail faster.

 TestNumericRangeQuery test failure
 --

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir

 https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/
 ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
 -Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
 -Dtests.nightly=true

--
This message is automatically generated by JIRA.
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-2452) rewrite solr build system

2011-07-14 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-2452:


On trunk in solr, ant example after touching a single source file was 31 
seconds before this patch and is now 51.  Anyone have any ideas where we lost?  
(the original description did cite speed as one reason for a rewrite ;-)

 rewrite solr build system
 -

 Key: SOLR-2452
 URL: https://issues.apache.org/jira/browse/SOLR-2452
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
Assignee: Steven Rowe
 Fix For: 3.4, 4.0

 Attachments: SOLR-2452-post-reshuffling.patch, 
 SOLR-2452-post-reshuffling.patch, SOLR-2452-post-reshuffling.patch, 
 SOLR-2452.diffSource.py.patch.zip, SOLR-2452.dir.reshuffle.branch_3x.sh, 
 SOLR-2452.dir.reshuffle.sh, SOLR-2452.dir.reshuffle.sh, 
 SOLR-2452.post.dir.reshuffle.branch_3x.patch


 As discussed some in SOLR-2002 (but that issue is long and hard to follow), I 
 think we should rewrite the solr build system.
 Its slow, cumbersome, and messy, and makes it hard for us to improve things.

--
This message is automatically generated by JIRA.
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-2651) The new SolrCore#reload method does not create a ZkSolrResourceLoader in ZooKeeper mode


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

Mark Miller updated SOLR-2651:
--

Attachment: SOLR-2651.patch

I've added a test and fixed a test issue where the zkclient was trying to 
reconnect to the wrong zkserver port due to asking the OS for a port.

I'll commit in a bit.

 The new SolrCore#reload method does not create a ZkSolrResourceLoader in 
 ZooKeeper mode
 ---

 Key: SOLR-2651
 URL: https://issues.apache.org/jira/browse/SOLR-2651
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2651.patch, SOLR-2651.patch


 this is a trunk bug
 reload is hard wired to simply make a SolrResourceLoader - this means that in 
 ZooKeeper mode, changes to config are not picked up on a reload - instead you 
 would get any local configs.

--
This message is automatically generated by JIRA.
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-3041) Support Query Visting / Walking


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

Simon Willnauer commented on LUCENE-3041:
-

bq. Yes I definitely am going to revisit this. I'm still unsure how best to 
incorporate this into IndexSearcher so that it can work per-segment. But we can 
commit the functionality and then deal with the integration separately.

actually this already works per segment in a way it should. If you look at 
rewriting this is done based on the IS anyway for a query so we only rewrite 
once. If you are inside a MTQ and you want to do the rewrite caching or other 
things you can do this based on the IS. The question is if we should really 
commit this without any specific usecase or other code using it :/

are you going to address earwins issue still?



 Support Query Visting / Walking
 ---

 Key: LUCENE-3041
 URL: https://issues.apache.org/jira/browse/LUCENE-3041
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/search
Affects Versions: 4.0
Reporter: Chris Male
Assignee: Simon Willnauer
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-3041.patch, LUCENE-3041.patch, LUCENE-3041.patch, 
 LUCENE-3041.patch, LUCENE-3041.patch


 Out of the discussion in LUCENE-2868, it could be useful to add a generic 
 Query Visitor / Walker that could be used for more advanced rewriting, 
 optimizations or anything that requires state to be stored as each Query is 
 visited.
 We could keep the interface very simple:
 {code}
 public interface QueryVisitor {
   Query visit(Query query);
 }
 {code}
 and then use a reflection based visitor like Earwin suggested, which would 
 allow implementators to provide visit methods for just Querys that they are 
 interested in.

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure


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

Uwe Schindler commented on LUCENE-3314:
---

The bug is a feature of the test:
The test iterates the enum until it returns null. After it returned null (end 
of enum), it calls again next() and asserts it still returns null. And that is 
where it fails, it looks like a new bug in MultiTermsEnum.

 TestNumericRangeQuery test failure
 --

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir

 https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/
 ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
 -Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
 -Dtests.nightly=true

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure

2011-07-14 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on LUCENE-3314:
--

The javadoc of next says:
{code}
 Returns the resulting term, or null if the end was hit (which means the enum 
is unpositioned).
{code}

It doesn't say anything about the result of next() if the previous call 
resulted in null, and the unpositioned verbiage would suggest a more 
undefined state to me.  If calling next() after null is returned is supported, 
we should doc it (but this might add extra overhead/state to some 
implementations?)

 TestNumericRangeQuery test failure
 --

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir

 https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/
 ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
 -Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
 -Dtests.nightly=true

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure


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

Uwe Schindler commented on LUCENE-3314:
---

+1

 TestNumericRangeQuery test failure
 --

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir

 https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/
 ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
 -Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
 -Dtests.nightly=true

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure


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

Robert Muir commented on LUCENE-3314:
-

also, i think if its too slow to do a real check for this, we can always try to 
add a check that only works if assertions are enabled... this is still 
something.

 TestNumericRangeQuery test failure
 --

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir

 https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/
 ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
 -Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
 -Dtests.nightly=true

--
This message is automatically generated by JIRA.
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-2186) DataImportHandler multi-threaded option throws exception

2011-07-14 Thread Frank Wesemann (JIRA)


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

Frank Wesemann commented on SOLR-2186:
--

Thanks for taking this issue Shalin.
You might close SOLR-2544 along with this

 DataImportHandler multi-threaded option throws exception
 

 Key: SOLR-2186
 URL: https://issues.apache.org/jira/browse/SOLR-2186
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Reporter: Lance Norskog
Assignee: Shalin Shekhar Mangar
 Attachments: SOLR-2186.patch, SOLR-2186.patch, SOLR-2186.patch, 
 Solr-2186.patch, TestDocBuilderThreaded.java, TestTikaEntityProcessor.patch, 
 TikaResolver.patch


 The multi-threaded option for the DataImportHandler throws an exception and 
 the entire operation fails. This is true even if only 1 thread is configured 
 via *threads='1'*

--
This message is automatically generated by JIRA.
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-2308) Separately specify a field's type

2011-07-14 Thread Nikola Tankovic (JIRA)

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

Nikola Tankovic edited comment on LUCENE-2308 at 7/14/11 4:20 PM:
--

14th patch fixes lucene javadoc errors.

was (Author: ntankovic):
14th patch fixex lucene javadoc errors.

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Labels: gsoc2011, lucene-gsoc-11, mentor
Fix For: 4.0

Attachments: LUCENE-2308-10.patch, LUCENE-2308-11.patch,
LUCENE-2308-12.patch, LUCENE-2308-13.patch, LUCENE-2308-14.patch,
LUCENE-2308-2.patch, LUCENE-2308-3.patch, LUCENE-2308-4.patch,
LUCENE-2308-5.patch, LUCENE-2308-6.patch, LUCENE-2308-7.patch,
LUCENE-2308-8.patch, LUCENE-2308-9.patch, LUCENE-2308-ltc.patch,
LUCENE-2308.patch, LUCENE-2308.patch

This came up from dicussions on IRC. I'm summarizing here...
Today when you make a Field to add to a document you can set things
index or not, stored or not, analyzed or not, details like omitTfAP,
omitNorms, index term vectors (separately controlling
offsets/positions), etc.
I think we should factor these out into a new class (FieldType?).
Then you could re-use this FieldType instance across multiple fields.
The Field instance would still hold the actual value.
We could then do per-field analyzers by adding a setAnalyzer on the
FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise
for per-field codecs (with flex), where we now have
PerFieldCodecWrapper).
This would NOT be a schema! It's just refactoring what we already
specify today. EG it's not serialized into the index.
This has been discussed before, and I know Michael Busch opened a more
ambitious (I think?) issue. I think this is a good first baby step. We could
consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe hold
off on that for starters...

--
This message is automatically generated by JIRA.
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-2308) Separately specify a field's type

2011-07-14 Thread Nikola Tankovic (JIRA)

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

Nikola Tankovic updated LUCENE-2308:

Attachment: LUCENE-2308-14.patch

14th patch fixex lucene javadoc errors.

Separately specify a field's type
-

--
This message is automatically generated by JIRA.
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-2613) DIH Cache backed w/bdb-je

2011-07-14 Thread James Dyer (JIRA)


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

James Dyer updated SOLR-2613:
-

Attachment: SOLR-2613.patch

This is an update to stay in-sync with recent changes in Trunk.

 DIH Cache backed w/bdb-je
 -

 Key: SOLR-2613
 URL: https://issues.apache.org/jira/browse/SOLR-2613
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 4.0
Reporter: James Dyer
Priority: Minor
 Attachments: SOLR-2613.patch, SOLR-2613.patch, SOLR-2613.patch


 This is spun out of SOLR-2382, which provides a framework for multiple 
 cacheing implementations with DIH.  This cache implementation is fast  
 flexible, supporting persistence and delta updates.  However, it depends on 
 Berkley Database Java Edition so in order to evaluate this and use it you 
 must download bdb-je from Oracle and accept the license requirements.

--
This message is automatically generated by JIRA.
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-2382) DIH Cache Improvements

2011-07-14 Thread James Dyer (JIRA)

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

James Dyer updated SOLR-2382:
-

Attachment: SOLR-2382-dihwriter.patch

This is the DIHCacheWriter and DIHCacheProcessor portion taken from the
June 24 version of the entire patch. This patch depends both on the
properties patch and the solrwriter patch.

DIHWriter is a drop-in replacement for SolrWriter, allowing a DIH run to write
its output to a DIHCache rather than to Solr. Users can specify which
CacheImpl to use. If the Cache supports persistence, delta updates can be
performed on cached data.

DIHCacheProcessor is an EntityProcessor that takes a DIHCache as its input.

Unit tests are included. However, most tests skip because SortedMapBackedCache
does not support persistence. To get the tests to run, (for now), we need to
also apply SOLR-2613 (BerkleyBackedCache).

DIH Cache Improvements
--

Key: SOLR-2382
URL: https://issues.apache.org/jira/browse/SOLR-2382
Project: Solr
Issue Type: New Feature
Components: contrib - DataImportHandler
Reporter: James Dyer
Priority: Minor
Attachments: SOLR-2382-dihwriter.patch, SOLR-2382-entities.patch,
SOLR-2382-properties.patch, SOLR-2382-properties.patch,
SOLR-2382-solrwriter.patch, SOLR-2382-solrwriter.patch, SOLR-2382.patch,
SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch,
SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch

Functionality:
1. Provide a pluggable caching framework for DIH so that users can choose a
cache implementation that best suits their data and application.

2. Provide a means to temporarily cache a child Entity's data without
needing to create a special cached implementation of the Entity Processor
(such as CachedSqlEntityProcessor).

3. Provide a means to write the final (root entity) DIH output to a cache
rather than to Solr. Then provide a way for a subsequent DIH call to use the
cache as an Entity input. Also provide the ability to do delta updates on
such persistent caches.

4. Provide the ability to partition data across multiple caches that can
then be fed back into DIH and indexed either to varying Solr Shards, or to
the same Core in parallel.
Use Cases:
1. We needed a flexible scalable way to temporarily cache child-entity
data prior to joining to parent entities.
- Using SqlEntityProcessor with Child Entities can cause an n+1 select
problem.
- CachedSqlEntityProcessor only supports an in-memory HashMap as a Caching
mechanism and does not scale.
- There is no way to cache non-SQL inputs (ex: flat files, xml, etc).

2. We needed the ability to gather data from long-running entities by a
process that runs separate from our main indexing process.

3. We wanted the ability to do a delta import of only the entities that
changed.
- Lucene/Solr requires entire documents to be re-indexed, even if only a
few fields changed.
- Our data comes from 50+ complex sql queries and/or flat files.
- We do not want to incur overhead re-gathering all of this data if only 1
entity's data changed.
- Persistent DIH caches solve this problem.

4. We want the ability to index several documents in parallel (using 1.4.1,
which did not have the threads parameter).

5. In the future, we may need to use Shards, creating a need to easily
partition our source data into Shards.
Implementation Details:
1. De-couple EntityProcessorBase from caching.
- Created a new interface, DIHCache two implementations:
- SortedMapBackedCache - An in-memory cache, used as default with
CachedSqlEntityProcessor (now deprecated).
- BerkleyBackedCache - A disk-backed cache, dependent on bdb-je, tested
with je-4.1.6.jar
- NOTE: the existing Lucene Contrib db project uses je-3.3.93.jar.
I believe this may be incompatible due to Generic Usage.
- NOTE: I did not modify the ant script to automatically get this jar,
so to use or evaluate this patch, download bdb-je from
http://www.oracle.com/technetwork/database/berkeleydb/downloads/index.html

2. Allow Entity Processors to take a cacheImpl parameter to cause the
entity data to be cached (see EntityProcessorBase DIHCacheProperties).

3. Partially De-couple SolrWriter from DocBuilder
- Created a new interface DIHWriter, two implementations:
- SolrWriter (refactored)
- DIHCacheWriter (allows DIH to write ultimately to a Cache).

4. Create a new Entity Processor, DIHCacheProcessor, which reads a
persistent Cache as DIH Entity Input.

5. Support a partition parameter with both DIHCacheWriter and
DIHCacheProcessor to allow for easy partitioning of source entity data.

6. Change the semantics of entity.destroy()
- Previously, it was being called on

[jira] [Resolved] (SOLR-2535) REGRESSION: in Solr 3.x and trunk the admin/file handler fails to show directory listings

2011-07-14 Thread Erick Erickson (JIRA)


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

Erick Erickson resolved SOLR-2535.
--

Resolution: Fixed

trunk rev:  1146685
branch 3x rev:  1146806

Thanks David and Peter!

 REGRESSION: in Solr 3.x and trunk the admin/file handler fails to show 
 directory listings
 -

 Key: SOLR-2535
 URL: https://issues.apache.org/jira/browse/SOLR-2535
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 3.1, 3.2, 4.0
 Environment: java 1.6, jetty
Reporter: Peter Wolanin
Assignee: Erick Erickson
 Fix For: 3.4, 4.0

 Attachments: SOLR-2535-post-SOLR-2452.patch, SOLR-2535.patch, 
 SOLR-2535_fix_admin_file_handler_for_directory_listings.patch


 In Solr 1.4.1, going to the path solr/admin/file I see an XML-formatted 
 listing of the conf directory, like:
 {noformat}
 response
 lst name=responseHeaderint name=status0/intint 
 name=QTime1/int/lst
 lst name=files
   lst name=elevate.xmllong name=size1274/longdate 
 name=modified2011-03-06T20:42:54Z/date/lst
   ...
 /lst
 /response
 {noformat}
 I can list the xslt sub-dir using solr/admin/files?file=/xslt
 In Solr 3.1.0, both of these fail with a 500 error:
 {noformat}
 HTTP ERROR 500
 Problem accessing /solr/admin/file/. Reason:
 did not find a CONTENT object
 java.io.IOException: did not find a CONTENT object
 {noformat}
 Looking at the code in class ShowFileRequestHandler, it seem like 3.1.0 
 should still handle directory listings if not file name is given, or if the 
 file is a directory, so I am filing this as a bug.

--
This message is automatically generated by JIRA.
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-2326) Replication command indexversion fails to return index version

2011-07-14 Thread Jeremy Custenborder (JIRA)


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

Jeremy Custenborder commented on SOLR-2326:
---

I'm running into the same issue. My slave server has no update handlers. 
Calling /solr/core/replication?command=indexversion on the master always 
returned 0.  I was looking at the code for the handler and found an interesting 
comment on line 125. It's currently configured to replicate after commit.

{quote}
This happens when replication is not configured to happen after startup and no 
commit/optimize
has happened yet.
{quote}

This got me thinking so I issued the following command against the master
{quote}
curl 'http://127.0.0.1:8080/solr/core/update' -H Content-Type: text/xml 
--data-binary 'optimize/'
{quote}

The next call to /solr/core/replication?command=indexversion returned a valid 
version and replication to the slave started.

This makes me believe the problem is in this code block. 
{code}
   if (command.equals(CMD_INDEX_VERSION)) {
  IndexCommit commitPoint = indexCommitPoint;  // make a copy so it won't 
change
  if (commitPoint != null  replicationEnabled.get()) {
//
// There is a race condition here.  The commit point may be changed / 
deleted by the time
// we get around to reserving it.  This is a very small window though, 
and should not result
// in a catastrophic failure, but will result in the client getting an 
empty file list for
// the CMD_GET_FILE_LIST command.
//
core.getDeletionPolicy().setReserveDuration(commitPoint.getVersion(), 
reserveCommitDuration);
rsp.add(CMD_INDEX_VERSION, commitPoint.getVersion());
rsp.add(GENERATION, commitPoint.getGeneration());
  } else {
// This happens when replication is not configured to happen after 
startup and no commit/optimize
// has happened yet.
rsp.add(CMD_INDEX_VERSION, 0L);
rsp.add(GENERATION, 0L);
  }
}
{code}


It looks like there is a race condition resulting in indexCommitPoint being 
null. Look at the method postCommit() in getEventListener() method.

{code}
public void postCommit() {
IndexCommit currentCommitPoint = 
core.getDeletionPolicy().getLatestCommit();

if (getCommit) {
  // IndexCommit oldCommitPoint = indexCommitPoint;
  indexCommitPoint = currentCommitPoint;

  // We don't need to save commit points for replication, the 
SolrDeletionPolicy
  // always saves the last commit point (and the last optimized commit 
point, if needed)
  /***
  if (indexCommitPoint != null) {

core.getDeletionPolicy().saveCommitPoint(indexCommitPoint.getVersion());
  }
  if(oldCommitPoint != null){

core.getDeletionPolicy().releaseCommitPoint(oldCommitPoint.getVersion());
  }
  ***/
}
if (snapshoot) {
  try {
SnapShooter snapShooter = new SnapShooter(core, null);
snapShooter.createSnapAsync(currentCommitPoint, 
ReplicationHandler.this);
  } catch (Exception e) {
LOG.error(Exception while snapshooting, e);
  }
}
  }
{code}

Since indexCommitPoint is null until being loaded this causes a value of 0 to 
always be returned. 

If you call optimize like I did does your index start replicating? In my 
situation each core that returned 0/0 started replicating after I called 
optimize. 


 Replication command indexversion fails to return index version
 --

 Key: SOLR-2326
 URL: https://issues.apache.org/jira/browse/SOLR-2326
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
 Environment: Branch 3x latest
Reporter: Eric Pugh
Assignee: Mark Miller
 Fix For: 3.4, 4.0


 To test this, I took the /example/multicore/core0 solrconfig and added a 
 simple replication handler:
   requestHandler name=/replication class=solr.ReplicationHandler 
   lst name=master
 str name=replicateAftercommit/str
 str name=replicateAfterstartup/str
 str name=confFilesschema.xml/str
   /lst
   /requestHandler
 When I query the handler for details I get back the indexVersion that I 
 expect: 
 http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true
 But when I ask for just the indexVersion I get back a 0, which prevent the 
 slaves from pulling updates: 
 http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe,

[jira] [Issue Comment Edited] (SOLR-2326) Replication command indexversion fails to return index version

2011-07-14 Thread Jeremy Custenborder (JIRA)


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

Jeremy Custenborder edited comment on SOLR-2326 at 7/14/11 5:15 PM:


I'm running into the same issue. My slave server has no update handlers. 
Calling /solr/core/replication?command=indexversion on the master always 
returned 0.  I was looking at the code for the handler and found an interesting 
comment on line 125. It's currently configured to replicate after commit.

{quote}
This happens when replication is not configured to happen after startup and no 
commit/optimize
has happened yet.
{quote}

This got me thinking so I issued the following command against the master
{quote}
curl 'http://127.0.0.1:8080/solr/core/update' -H Content-Type: text/xml 
--data-binary 'optimize/'
{quote}

The next call to /solr/core/replication?command=indexversion returned a valid 
version and replication to the slave started.

This makes me believe the problem is in this code block. 
{code}
   if (command.equals(CMD_INDEX_VERSION)) {
  IndexCommit commitPoint = indexCommitPoint;  // make a copy so it won't 
change
  if (commitPoint != null  replicationEnabled.get()) {
//
// There is a race condition here.  The commit point may be changed / 
deleted by the time
// we get around to reserving it.  This is a very small window though, 
and should not result
// in a catastrophic failure, but will result in the client getting an 
empty file list for
// the CMD_GET_FILE_LIST command.
//
core.getDeletionPolicy().setReserveDuration(commitPoint.getVersion(), 
reserveCommitDuration);
rsp.add(CMD_INDEX_VERSION, commitPoint.getVersion());
rsp.add(GENERATION, commitPoint.getGeneration());
  } else {
// This happens when replication is not configured to happen after 
startup and no commit/optimize
// has happened yet.
rsp.add(CMD_INDEX_VERSION, 0L);
rsp.add(GENERATION, 0L);
  }
}
{code}


It looks like there is a race condition resulting in indexCommitPoint being 
null. Look at the method postCommit() in getEventListener() method.

{code}
public void postCommit() {
IndexCommit currentCommitPoint = 
core.getDeletionPolicy().getLatestCommit();

if (getCommit) {
  // IndexCommit oldCommitPoint = indexCommitPoint;
  indexCommitPoint = currentCommitPoint;

  // We don't need to save commit points for replication, the 
SolrDeletionPolicy
  // always saves the last commit point (and the last optimized commit 
point, if needed)
  /***
  if (indexCommitPoint != null) {

core.getDeletionPolicy().saveCommitPoint(indexCommitPoint.getVersion());
  }
  if(oldCommitPoint != null){

core.getDeletionPolicy().releaseCommitPoint(oldCommitPoint.getVersion());
  }
  ***/
}
if (snapshoot) {
  try {
SnapShooter snapShooter = new SnapShooter(core, null);
snapShooter.createSnapAsync(currentCommitPoint, 
ReplicationHandler.this);
  } catch (Exception e) {
LOG.error(Exception while snapshooting, e);
  }
}
  }
{code}

This is the first time I see indexCommitPoint being set. Since indexCommitPoint 
is null until being loaded this causes a value of 0 to always be returned. 

If you call optimize like I did does your index start replicating? In my 
situation each core that returned 0/0 started replicating after I called 
optimize. 


  was (Author: jcustenborder):
I'm running into the same issue. My slave server has no update handlers. 
Calling /solr/core/replication?command=indexversion on the master always 
returned 0.  I was looking at the code for the handler and found an interesting 
comment on line 125. It's currently configured to replicate after commit.

{quote}
This happens when replication is not configured to happen after startup and no 
commit/optimize
has happened yet.
{quote}

This got me thinking so I issued the following command against the master
{quote}
curl 'http://127.0.0.1:8080/solr/core/update' -H Content-Type: text/xml 
--data-binary 'optimize/'
{quote}

The next call to /solr/core/replication?command=indexversion returned a valid 
version and replication to the slave started.

This makes me believe the problem is in this code block. 
{code}
   if (command.equals(CMD_INDEX_VERSION)) {
  IndexCommit commitPoint = indexCommitPoint;  // make a copy so it won't 
change
  if (commitPoint != null  replicationEnabled.get()) {
//
// There is a race condition here.  The commit point may be changed / 
deleted by the time
// we get around to reserving it.  This is a very small window though, 
and should not result
// in a catastrophic failure, but

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 9560 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9560/

No tests ran.

Build Log (for compile errors):
[...truncated 3754 lines...]
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:41:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(size, 100);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:42:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(initialSize, 10);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:43:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(autowarmCount, 25);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:47:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.SolrCache
[javac] newCache.put(oldKey, oldVal);
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:54:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac]   sc.put(i + 1,  + (i + 1));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:56:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(25, sc.get(25));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:57:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(110));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:63:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(1));  // first item put in should be 
the first out
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:71:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] scNew.put(103, 103);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:72:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(90, scNew.get(90));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:73:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, scNew.get(50));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:118:
 warning: [unchecked] unchecked call to 
ConcurrentLRUCache(int,int,int,int,boolean,boolean,org.apache.solr.common.util.ConcurrentLRUCache.EvictionListenerK,V)
 as a member of the raw type org.apache.solr.common.util.ConcurrentLRUCache
[javac] ConcurrentLRUCache cache = new 
ConcurrentLRUCache(upperWaterMark, lowerWaterMark, 
(upperWaterMark+lowerWaterMark)/2, upperWaterMark, false, false, null);
[javac]^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:122:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.common.util.ConcurrentLRUCache
[javac]   cache.put(r.nextInt(maxKey),TheValue);
[javac]^
[javac]

Re: FindBugs PMD ?

2011-07-14 Thread Chris Hostetter


: Chris, I read your thoughts on custom PMD rules.  I think that's a 
: fantastic idea.  I'm not sure if these rules should be PMD rules or 
: FindBugs rules, but we can cross that bridge when we come to it.  
: AFAIK, FindBugs is way more popular so I would favor that.

I didn't mean to come off as saying we should use PMD instead of 
FindBugs, just sharing some comments about one of the non-obvious 
advantages of PMD.

it's really an apples vs milk comparison, they both have nutritional 
value, but in completely different food groups: PMD analyzes the source 
code (so it can catch potential bugs from syntax gotchas and enforce rules 
regarding project conventions) while FindBugs analyzes the bytecode (so it 
can catch lower level problems, like locks not being released in exception 
code paths)


-Hoss

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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 9561 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9561/

No tests ran.

Build Log (for compile errors):
[...truncated 3751 lines...]
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:41:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(size, 100);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:42:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(initialSize, 10);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:43:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(autowarmCount, 25);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:47:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.SolrCache
[javac] newCache.put(oldKey, oldVal);
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:54:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac]   sc.put(i + 1,  + (i + 1));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:56:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(25, sc.get(25));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:57:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(110));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:63:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(1));  // first item put in should be 
the first out
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:71:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] scNew.put(103, 103);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:72:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(90, scNew.get(90));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:73:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, scNew.get(50));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:118:
 warning: [unchecked] unchecked call to 
ConcurrentLRUCache(int,int,int,int,boolean,boolean,org.apache.solr.common.util.ConcurrentLRUCache.EvictionListenerK,V)
 as a member of the raw type org.apache.solr.common.util.ConcurrentLRUCache
[javac] ConcurrentLRUCache cache = new 
ConcurrentLRUCache(upperWaterMark, lowerWaterMark, 
(upperWaterMark+lowerWaterMark)/2, upperWaterMark, false, false, null);
[javac]^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:122:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.common.util.ConcurrentLRUCache
[javac]   cache.put(r.nextInt(maxKey),TheValue);
[javac]^
[javac]

[jira] [Created] (LUCENE-3315) Omit termFreq but keep Positions

2011-07-14 Thread Jibo John (JIRA)

Omit termFreq but keep Positions


 Key: LUCENE-3315
 URL: https://issues.apache.org/jira/browse/LUCENE-3315
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Affects Versions: 3.1
Reporter: Jibo John


It would be useful to have an option to discard term frequency information but 
still keep the positions. Currently, setOmitTermFreqAndPositions discards both. 
The recent commit LUCENE-2048 adds the flexibility to discard only the 
positions. With the new option to discard frequency, position-dependent queries 
can continue to work, and whoever can afford to ignore the scoring based on tf 
can save a lot on the index size.

--
This message is automatically generated by JIRA.
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-2652) Speed up the Solr build

Speed up the Solr build
---

 Key: SOLR-2652
 URL: https://issues.apache.org/jira/browse/SOLR-2652
 Project: Solr
  Issue Type: Improvement
  Components: Build
Affects Versions: 3.4, 4.0
Reporter: Steven Rowe
Priority: Minor


The Solr build after SOLR-2452 is slower than it was, as Yonik [mentioned on 
SOLR-2452|https://issues.apache.org/jira/browse/SOLR-2452?focusedCommentId=13065295#comment-13065295].

Uwe [mentioned on #lucene-dev 
IRC|http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-07-10#l36] 
that switching tests to not build jar files would speed things up -- this is 
how it's done in the Lucene build.

Also, maybe in conjunction with this, expanding use of the Ant properties 
{{\*.compiled}} and {{\*.uptodate}} may help.  (I already did some of this to 
speed things up before committing SOLR-2452.)


--
This message is automatically generated by JIRA.
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-2452) rewrite solr build system


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

Steven Rowe commented on SOLR-2452:
---

bq. On trunk in solr, ant example after touching a single source file was 31 
seconds before this patch and is now 51. Anyone have any ideas where we lost? 
(the original description did cite speed as one reason for a rewrite ;)

I've opened an issue to speed up the build.


 rewrite solr build system
 -

 Key: SOLR-2452
 URL: https://issues.apache.org/jira/browse/SOLR-2452
 Project: Solr
  Issue Type: Task
  Components: Build
Reporter: Robert Muir
Assignee: Steven Rowe
 Fix For: 3.4, 4.0

 Attachments: SOLR-2452-post-reshuffling.patch, 
 SOLR-2452-post-reshuffling.patch, SOLR-2452-post-reshuffling.patch, 
 SOLR-2452.diffSource.py.patch.zip, SOLR-2452.dir.reshuffle.branch_3x.sh, 
 SOLR-2452.dir.reshuffle.sh, SOLR-2452.dir.reshuffle.sh, 
 SOLR-2452.post.dir.reshuffle.branch_3x.patch


 As discussed some in SOLR-2002 (but that issue is long and hard to follow), I 
 think we should rewrite the solr build system.
 Its slow, cumbersome, and messy, and makes it hard for us to improve things.

--
This message is automatically generated by JIRA.
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-1768) NumericRange support for new query parser


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

Uwe Schindler updated LUCENE-1768:
--

Attachment: TestNumericQueryParser-fix.patch

Hi Vinicius,

I tested your patch (after converting it to new trunk directory/package layout 
(thanks Chris Male :-)

It still fails quite often for some locales (at least in Java 6). The problem 
is that some locales produce date formats that are not immune to case changes. 
As QueryParser seems to lowercase the range bounds, some dates cannot be parsed.

This throwed with your patch a NPE, because you implemented NumberDateFormat 
wrong: public Number parse(String source, ParsePosition parsePosition) is 
allowed to return null (it must if a parse error occurs). The same applies to 
date formats, but if you call getTime() on a null Date it throws NPE. So the 
attached patch also fixes the NumberDateFormat to handle null correctly.

I also changed the test initialization a bit to produce sane dates from the 
beginning.

I then added a toLowerCase(LOCALE) to the sanity checker

Now the static initializer fails for:
{noformat}
ant test -Dtestcase=TestNumericQueryParser 
-Dtestmethod=testInclusiveNumericRange 
-Dtests.seed=5825000776503943381:-1057095952794658416
{noformat}

As a lowercased date cannot be parsed, this fails with ParseException. The 
locale is es, so the spanisch translation of GMT is case sensitive:

This parses:
{noformat}
domingo 19 de agosto de 1973 11H31' GAMT AD 34 -0900 1973
{noformat}

This not:
{noformat}
domingo 19 de agosto de 1973 11h31' gamt ad 34 -0900 1973
{noformat}

 NumericRange support for new query parser
 -

 Key: LUCENE-1768
 URL: https://issues.apache.org/jira/browse/LUCENE-1768
 Project: Lucene - Java
  Issue Type: New Feature
  Components: core/queryparser
Affects Versions: 2.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
  Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
 Fix For: 4.0

 Attachments: TestNumericQueryParser-fix.patch, 
 TestNumericQueryParser-fix.patch, week-7.patch, week1.patch, week2.patch, 
 week3.patch, week4.patch, week5-6.patch


 It would be good to specify some type of schema for the query parser in 
 future, to automatically create NumericRangeQuery for different numeric 
 types? It would then be possible to index a numeric value 
 (double,float,long,int) using NumericField and then the query parser knows, 
 which type of field this is and so it correctly creates a NumericRangeQuery 
 for strings like [1.567..*] or (1.787..19.5].
 There is currently no way to extract if a field is numeric from the index, so 
 the user will have to configure the FieldConfig objects in the ConfigHandler. 
 But if this is done, it will not be that difficult to implement the rest.
 The only difference between the current handling of RangeQuery is then the 
 instantiation of the correct Query type and conversion of the entered numeric 
 values (simple Number.valueOf(...) cast of the user entered numbers). 
 Evenerything else is identical, NumericRangeQuery also supports the MTQ 
 rewrite modes (as it is a MTQ).
 Another thing is a change in Date semantics. There are some strange flags in 
 the current parser that tells it how to handle dates.

--
This message is automatically generated by JIRA.
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] (SOLR-2452) rewrite solr build system

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

Steven Rowe edited comment on SOLR-2452 at 7/14/11 6:08 PM:

bq. On trunk in solr, ant example after touching a single source file was 31
seconds before this patch and is now 51. Anyone have any ideas where we lost?
(the original description did cite speed as one reason for a rewrite ;)

I've opened an issue to speed up the build: SOLR-2652

was (Author: steve_rowe):
bq. On trunk in solr, ant example after touching a single source file was
31 seconds before this patch and is now 51. Anyone have any ideas where we
lost? (the original description did cite speed as one reason for a rewrite ;)

I've opened an issue to speed up the build.

rewrite solr build system
-

Key: SOLR-2452
URL: https://issues.apache.org/jira/browse/SOLR-2452
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Steven Rowe
Fix For: 3.4, 4.0

Attachments: SOLR-2452-post-reshuffling.patch,
SOLR-2452-post-reshuffling.patch, SOLR-2452-post-reshuffling.patch,
SOLR-2452.diffSource.py.patch.zip, SOLR-2452.dir.reshuffle.branch_3x.sh,
SOLR-2452.dir.reshuffle.sh, SOLR-2452.dir.reshuffle.sh,
SOLR-2452.post.dir.reshuffle.branch_3x.patch

As discussed some in SOLR-2002 (but that issue is long and hard to follow), I
think we should rewrite the solr build system.
Its slow, cumbersome, and messy, and makes it hard for us to improve things.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 9562 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9562/

No tests ran.

Build Log (for compile errors):
[...truncated 3751 lines...]
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:41:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(size, 100);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:42:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(initialSize, 10);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:43:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(autowarmCount, 25);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:47:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.SolrCache
[javac] newCache.put(oldKey, oldVal);
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:54:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac]   sc.put(i + 1,  + (i + 1));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:56:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(25, sc.get(25));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:57:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(110));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:63:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(1));  // first item put in should be 
the first out
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:71:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] scNew.put(103, 103);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:72:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(90, scNew.get(90));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:73:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, scNew.get(50));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:118:
 warning: [unchecked] unchecked call to 
ConcurrentLRUCache(int,int,int,int,boolean,boolean,org.apache.solr.common.util.ConcurrentLRUCache.EvictionListenerK,V)
 as a member of the raw type org.apache.solr.common.util.ConcurrentLRUCache
[javac] ConcurrentLRUCache cache = new 
ConcurrentLRUCache(upperWaterMark, lowerWaterMark, 
(upperWaterMark+lowerWaterMark)/2, upperWaterMark, false, false, null);
[javac]^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:122:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.common.util.ConcurrentLRUCache
[javac]   cache.put(r.nextInt(maxKey),TheValue);
[javac]^
[javac]

[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser

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

Uwe Schindler commented on LUCENE-1768:
---

I would suggest to not lowercase range bounds for numbers/dates in the
QueryParser. This makes only sense for terms, but numbers should not change
case. I think we can remove the toLowerCase() in the query builder.

NumericRange support for new query parser
-

Key: LUCENE-1768
URL: https://issues.apache.org/jira/browse/LUCENE-1768
Project: Lucene - Java
Issue Type: New Feature
Components: core/queryparser
Affects Versions: 2.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 4.0

Attachments: TestNumericQueryParser-fix.patch,
TestNumericQueryParser-fix.patch, week-7.patch, week1.patch, week2.patch,
week3.patch, week4.patch, week5-6.patch

It would be good to specify some type of schema for the query parser in
future, to automatically create NumericRangeQuery for different numeric
types? It would then be possible to index a numeric value
(double,float,long,int) using NumericField and then the query parser knows,
which type of field this is and so it correctly creates a NumericRangeQuery
for strings like [1.567..*] or (1.787..19.5].
There is currently no way to extract if a field is numeric from the index, so
the user will have to configure the FieldConfig objects in the ConfigHandler.
But if this is done, it will not be that difficult to implement the rest.
The only difference between the current handling of RangeQuery is then the
instantiation of the correct Query type and conversion of the entered numeric
values (simple Number.valueOf(...) cast of the user entered numbers).
Evenerything else is identical, NumericRangeQuery also supports the MTQ
rewrite modes (as it is a MTQ).
Another thing is a change in Date semantics. There are some strange flags in
the current parser that tells it how to handle dates.

--
This message is automatically generated by JIRA.
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-2653) SolrJettyTestBase has the wrong package

SolrJettyTestBase has the wrong package
---

 Key: SOLR-2653
 URL: https://issues.apache.org/jira/browse/SOLR-2653
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Critical


Backport of SOLR-2452 to branch_3x didn't change the package name of 
{{SolrJettyTestBase}}, so the package name {{org.apache.solr.client.solrj}} and 
the directory in which it now resides {{org/apache/solr/}} are now different.

The package name should be changed to {{org.apache.solr}} (this is already done 
in trunk), and this will cause changes to package import statements where the 
class is used.

--
This message is automatically generated by JIRA.
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-2535) REGRESSION: in Solr 3.x and trunk the admin/file handler fails to show directory listings


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

Steven Rowe commented on SOLR-2535:
---

Jenkins is reporting that branch_3x {{solr/src/test}} compilation is failing 
after this issue was committed.

I've opened SOLR-2653 to address the problem.

 REGRESSION: in Solr 3.x and trunk the admin/file handler fails to show 
 directory listings
 -

 Key: SOLR-2535
 URL: https://issues.apache.org/jira/browse/SOLR-2535
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 3.1, 3.2, 4.0
 Environment: java 1.6, jetty
Reporter: Peter Wolanin
Assignee: Erick Erickson
 Fix For: 3.4, 4.0

 Attachments: SOLR-2535-post-SOLR-2452.patch, SOLR-2535.patch, 
 SOLR-2535_fix_admin_file_handler_for_directory_listings.patch


 In Solr 1.4.1, going to the path solr/admin/file I see an XML-formatted 
 listing of the conf directory, like:
 {noformat}
 response
 lst name=responseHeaderint name=status0/intint 
 name=QTime1/int/lst
 lst name=files
   lst name=elevate.xmllong name=size1274/longdate 
 name=modified2011-03-06T20:42:54Z/date/lst
   ...
 /lst
 /response
 {noformat}
 I can list the xslt sub-dir using solr/admin/files?file=/xslt
 In Solr 3.1.0, both of these fail with a 500 error:
 {noformat}
 HTTP ERROR 500
 Problem accessing /solr/admin/file/. Reason:
 did not find a CONTENT object
 java.io.IOException: did not find a CONTENT object
 {noformat}
 Looking at the code in class ShowFileRequestHandler, it seem like 3.1.0 
 should still handle directory listings if not file name is given, or if the 
 file is a directory, so I am filing this as a bug.

--
This message is automatically generated by JIRA.
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-2653) SolrJettyTestBase has the wrong package


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

Steven Rowe updated SOLR-2653:
--

Description: 
Backport of SOLR-2452 to branch_3x didn't change the package name of 
{{SolrJettyTestBase}}, so the package name {{org.apache.solr.client.solrj}} and 
the directory in which it now resides {{org/apache/solr/}} are different.

The package name should be changed to {{org.apache.solr}} (this is already done 
in trunk), and this will cause changes to package import statements where the 
class is used.

  was:
Backport of SOLR-2452 to branch_3x didn't change the package name of 
{{SolrJettyTestBase}}, so the package name {{org.apache.solr.client.solrj}} and 
the directory in which it now resides {{org/apache/solr/}} are now different.

The package name should be changed to {{org.apache.solr}} (this is already done 
in trunk), and this will cause changes to package import statements where the 
class is used.


 SolrJettyTestBase has the wrong package
 ---

 Key: SOLR-2653
 URL: https://issues.apache.org/jira/browse/SOLR-2653
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Critical

 Backport of SOLR-2452 to branch_3x didn't change the package name of 
 {{SolrJettyTestBase}}, so the package name {{org.apache.solr.client.solrj}} 
 and the directory in which it now resides {{org/apache/solr/}} are different.
 The package name should be changed to {{org.apache.solr}} (this is already 
 done in trunk), and this will cause changes to package import statements 
 where the class is used.

--
This message is automatically generated by JIRA.
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-2638) A CoreContainer Plugin interface to create Container level Services


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

Mark Miller commented on SOLR-2638:
---

Anything to share yet Noble? I'd be happy to join on this one.

 A CoreContainer Plugin interface to create Container level Services
 ---

 Key: SOLR-2638
 URL: https://issues.apache.org/jira/browse/SOLR-2638
 Project: Solr
  Issue Type: New Feature
  Components: multicore
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-2638.patch


 It can help register services such as Zookeeper .
 interface
 {code:java}
 public abstract class ContainerPlugin {
   /**Called before initializing any core.
* @param container
* @param attrs
*/
   public abstract void init(CoreContainer container, MapString,String 
 attrs);
   /**Callback after all cores are initialized
*/
   public void postInit(){}
   /**Callback after each core is created, but before registration
* @param core
*/
   public void onCoreCreate(SolrCore core){}
   /**Callback for server shutdown
*/
   public void shutdown(){}
 }
 {code}
 It may be specified in solr.xml as
 {code:xml}
 solr
   plugin name=zk class=solr.ZookeeperService param1=val1 param2=val2 
 zkClientTimeout=8000/
   cores adminPath=/admin/cores defaultCoreName=collection1 
 host=127.0.0.1 hostPort=${hostPort:8983} hostContext=solr 
 core name=collection1 shard=${shard:} 
 collection=${collection:collection1} config=${solrconfig:solrconfig.xml} 
 instanceDir=./
   /cores
 /solr
 {code}

--
This message is automatically generated by JIRA.
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-2653) SolrJettyTestBase has the wrong package


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

Steven Rowe updated SOLR-2653:
--

Attachment: SOLR-2653.patch

Patch fixing the problem.

Committing shortly.

 SolrJettyTestBase has the wrong package
 ---

 Key: SOLR-2653
 URL: https://issues.apache.org/jira/browse/SOLR-2653
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Critical
 Attachments: SOLR-2653.patch


 Backport of SOLR-2452 to branch_3x didn't change the package name of 
 {{SolrJettyTestBase}}, so the package name {{org.apache.solr.client.solrj}} 
 and the directory in which it now resides {{org/apache/solr/}} are different.
 The package name should be changed to {{org.apache.solr}} (this is already 
 done in trunk), and this will cause changes to package import statements 
 where the class is used.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 9563 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9563/

No tests ran.

Build Log (for compile errors):
[...truncated 3751 lines...]
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:41:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(size, 100);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:42:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(initialSize, 10);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:43:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
java.util.Map
[javac] l.put(autowarmCount, 25);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:47:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.SolrCache
[javac] newCache.put(oldKey, oldVal);
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:54:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac]   sc.put(i + 1,  + (i + 1));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:56:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(25, sc.get(25));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:57:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(110));
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:63:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, sc.get(1));  // first item put in should be 
the first out
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:71:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] scNew.put(103, 103);
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:72:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(90, scNew.get(90));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:73:
 warning: [unchecked] unchecked call to get(K) as a member of the raw type 
org.apache.solr.search.FastLRUCache
[javac] assertEquals(null, scNew.get(50));
[javac] ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:118:
 warning: [unchecked] unchecked call to 
ConcurrentLRUCache(int,int,int,int,boolean,boolean,org.apache.solr.common.util.ConcurrentLRUCache.EvictionListenerK,V)
 as a member of the raw type org.apache.solr.common.util.ConcurrentLRUCache
[javac] ConcurrentLRUCache cache = new 
ConcurrentLRUCache(upperWaterMark, lowerWaterMark, 
(upperWaterMark+lowerWaterMark)/2, upperWaterMark, false, false, null);
[javac]^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test/org/apache/solr/search/TestFastLRUCache.java:122:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
org.apache.solr.common.util.ConcurrentLRUCache
[javac]   cache.put(r.nextInt(maxKey),TheValue);
[javac]^
[javac]

[jira] [Resolved] (SOLR-2653) SolrJettyTestBase has the wrong package


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

Steven Rowe resolved SOLR-2653.
---

   Resolution: Fixed
Fix Version/s: 3.4

Committed to branch_3x in r1146838.

 SolrJettyTestBase has the wrong package
 ---

 Key: SOLR-2653
 URL: https://issues.apache.org/jira/browse/SOLR-2653
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Critical
 Fix For: 3.4

 Attachments: SOLR-2653.patch


 Backport of SOLR-2452 to branch_3x didn't change the package name of 
 {{SolrJettyTestBase}}, so the package name {{org.apache.solr.client.solrj}} 
 and the directory in which it now resides {{org/apache/solr/}} are different.
 The package name should be changed to {{org.apache.solr}} (this is already 
 done in trunk), and this will cause changes to package import statements 
 where the class is used.

--
This message is automatically generated by JIRA.
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-3220) Implement various ranking models as Similarities

2011-07-14 Thread David Mark Nemeskey (JIRA)


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

David Mark Nemeskey updated LUCENE-3220:


Attachment: LUCENE-3220.patch

Made the score() and explain() methods in Similarity components final.

 Implement various ranking models as Similarities
 

 Key: LUCENE-3220
 URL: https://issues.apache.org/jira/browse/LUCENE-3220
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: core/search
Affects Versions: flexscoring branch
Reporter: David Mark Nemeskey
Assignee: David Mark Nemeskey
  Labels: gsoc
 Attachments: LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch, 
 LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch, 
 LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch, 
 LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch, LUCENE-3220.patch

   Original Estimate: 336h
  Remaining Estimate: 336h

 With [LUCENE-3174|https://issues.apache.org/jira/browse/LUCENE-3174] done, we 
 can finally work on implementing the standard ranking models. Currently DFR, 
 BM25 and LM are on the menu.
 Done:
  * {{EasyStats}}: contains all statistics that might be relevant for a 
 ranking algorithm
  * {{EasySimilarity}}: the ancestor of all the other similarities. Hides the 
 DocScorers and as much implementation detail as possible
  * _BM25_: the current mock implementation might be OK
  * _LM_
  * _DFR_
  * The so-called _Information-Based Models_

--
This message is automatically generated by JIRA.
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-3307) don't require an analyzer, if all fields are NOT_ANALYZED


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

Robert Muir commented on LUCENE-3307:
-

Shai you want to take this? I am working on something else at the moment!

 don't require an analyzer, if all fields are NOT_ANALYZED
 -

 Key: LUCENE-3307
 URL: https://issues.apache.org/jira/browse/LUCENE-3307
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Robert Muir
 Attachments: LUCENE-3307.patch


 This seems wierd, if you analyze only NOT_ANALYZED fields, you must have an 
 analyzer (null will not work)
 because documentsinverter wants it for things like offsetGap

--
This message is automatically generated by JIRA.
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] (LUCENE-3307) don't require an analyzer, if all fields are NOT_ANALYZED

2011-07-14 Thread Shai Erera (JIRA)


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

Shai Erera reassigned LUCENE-3307:
--

Assignee: Shai Erera

 don't require an analyzer, if all fields are NOT_ANALYZED
 -

 Key: LUCENE-3307
 URL: https://issues.apache.org/jira/browse/LUCENE-3307
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Robert Muir
Assignee: Shai Erera
 Attachments: LUCENE-3307.patch


 This seems wierd, if you analyze only NOT_ANALYZED fields, you must have an 
 analyzer (null will not work)
 because documentsinverter wants it for things like offsetGap

--
This message is automatically generated by JIRA.
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-2544) ThreadedContext throws NPE on getResolvedEntityAttribute()


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

Shalin Shekhar Mangar resolved SOLR-2544.
-

Resolution: Duplicate

Duplicate of SOLR-2186

 ThreadedContext throws NPE on getResolvedEntityAttribute()
 --

 Key: SOLR-2544
 URL: https://issues.apache.org/jira/browse/SOLR-2544
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.1
 Environment: all
Reporter: Frank Wesemann
 Attachments: SOLR-2544.patch, ThreadedContextTest.java


 ThreadedContext.getResolvedEntityAttribute() throws a NPE as it calls
 super.getResolvedEntityAttribute() which in turn calls its private member 
 resolver, which is not set on a ThreadedContext.
 ContextImpl.getResolvedEntityAttribute() should call 
 getVariableResover().replaceTokens(entity.allFields.get(name )).
 a testcase for this particular issue may be:
 assertEquals( context.getResolvedEntityAttribute(attrName), 
 context.getVariableResolver().replaceTokens(entity.allFields.get(name ))

--
This message is automatically generated by JIRA.
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-3315) Omit termFreq but keep Positions


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

Michael McCandless commented on LUCENE-3315:


I don't think this is realistically possible: in order to record the positions 
we need to know the tf for that term/doc because that tells us how many 
positions there are.

 Omit termFreq but keep Positions
 

 Key: LUCENE-3315
 URL: https://issues.apache.org/jira/browse/LUCENE-3315
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Affects Versions: 3.1
Reporter: Jibo John

 It would be useful to have an option to discard term frequency information 
 but still keep the positions. Currently, setOmitTermFreqAndPositions discards 
 both. The recent commit LUCENE-2048 adds the flexibility to discard only the 
 positions. With the new option to discard frequency, position-dependent 
 queries can continue to work, and whoever can afford to ignore the scoring 
 based on tf can save a lot on the index size.

--
This message is automatically generated by JIRA.
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-3315) Omit termFreq but keep Positions


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

Robert Muir commented on LUCENE-3315:
-

simpletext used to not record its freq but instead count its positions and 
return that for freq :)

 Omit termFreq but keep Positions
 

 Key: LUCENE-3315
 URL: https://issues.apache.org/jira/browse/LUCENE-3315
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Affects Versions: 3.1
Reporter: Jibo John

 It would be useful to have an option to discard term frequency information 
 but still keep the positions. Currently, setOmitTermFreqAndPositions discards 
 both. The recent commit LUCENE-2048 adds the flexibility to discard only the 
 positions. With the new option to discard frequency, position-dependent 
 queries can continue to work, and whoever can afford to ignore the scoring 
 based on tf can save a lot on the index size.

--
This message is automatically generated by JIRA.
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-3314) TestNumericRangeQuery test failure


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

Michael McCandless commented on LUCENE-3314:


+1

Assertion fail, throwing ISE, are just best effort.  If you call next again 
after you got null already then it's not defined...

 TestNumericRangeQuery test failure
 --

 Key: LUCENE-3314
 URL: https://issues.apache.org/jira/browse/LUCENE-3314
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir

 https://builds.apache.org/view/G-L/view/Lucene/job/Lucene-trunk/1624/testReport/org.apache.lucene.search/TestNumericRangeQuery32/testEnum/
 ant test -Dtestcase=TestNumericRangeQuery32 -Dtestmethod=testEnum 
 -Dtests.seed=-3603272894684698645:-1998239306864854687 -Dtests.multiplier=3 
 -Dtests.nightly=true

--
This message is automatically generated by JIRA.
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-2104) DIH special command $deleteDocById dosn't skip the document and doesn't increment the deleted statistics


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

Shalin Shekhar Mangar resolved SOLR-2104.
-

Resolution: Won't Fix

I've added a note to this effect in the wiki page. This is all we can do. Hence 
marking this issue as Won't fix.

 DIH special command $deleteDocById dosn't skip the document and doesn't 
 increment the deleted statistics
 

 Key: SOLR-2104
 URL: https://issues.apache.org/jira/browse/SOLR-2104
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.4, 1.4.1
Reporter: Ephraim Ofir
Assignee: Shalin Shekhar Mangar
Priority: Minor

 1. Not sure it's a bug, but looks like a bug to me - if the query returns any 
 values other than $deleteDocById for the row you want deleted, it deletes the 
 row but also re-adds it with the rest of the data, so in effect the row isn't 
 deleted.  In order to work around this issue, you have to either make sure no 
 data other than $deleteDocById=id exists in rows to be deleted or add 
 $skipDoc='true'
 (which I think is a little counter-intuitive, but was the better choice in my 
 case).  My query looks something like:
 SELECT u.id,
u.name,
...
IF(u.delete_flag  0, u.id, NULL) AS $deleteDocById,
IF(u.delete_flag  0, 'true', NULL) AS $skipDoc FROM users_tb u
 2. $deleteDocById doesn't update the statistics of deleted documents.
 This has 2 downsides, the obvious one is that you don't know if/how many 
 documents were deleted, the not-so-obvious one is that if your import 
 contains only deleted items, it won't be committed automatically by DIH and 
 you'll have to commit it manually.

--
This message is automatically generated by JIRA.
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-1768) NumericRange support for new query parser


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

Uwe Schindler updated LUCENE-1768:
--

Attachment: TestNumericQueryParser-fix.patch

Attached you find the same patch, but with the numeric nodes not lowercased. 
The fix was easy: As the NumericQueryNodeProcessor transforms all text nodes to 
numeric nodes, we can simply move the LowerCaseExpandedTerms processor after 
those transformations, so the nodes are no longer touched.

The attached patch simply moves the 
LowercaseExpandedTermsQueryNodeProcessorfilter after the 
NumericRangeQueryNodeProcessor.

Tests now pass, Vinicius  Adriano, what do you think?

 NumericRange support for new query parser
 -

 Key: LUCENE-1768
 URL: https://issues.apache.org/jira/browse/LUCENE-1768
 Project: Lucene - Java
  Issue Type: New Feature
  Components: core/queryparser
Affects Versions: 2.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
  Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
 Fix For: 4.0

 Attachments: TestNumericQueryParser-fix.patch, 
 TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, 
 week-7.patch, week1.patch, week2.patch, week3.patch, week4.patch, 
 week5-6.patch


 It would be good to specify some type of schema for the query parser in 
 future, to automatically create NumericRangeQuery for different numeric 
 types? It would then be possible to index a numeric value 
 (double,float,long,int) using NumericField and then the query parser knows, 
 which type of field this is and so it correctly creates a NumericRangeQuery 
 for strings like [1.567..*] or (1.787..19.5].
 There is currently no way to extract if a field is numeric from the index, so 
 the user will have to configure the FieldConfig objects in the ConfigHandler. 
 But if this is done, it will not be that difficult to implement the rest.
 The only difference between the current handling of RangeQuery is then the 
 instantiation of the correct Query type and conversion of the entered numeric 
 values (simple Number.valueOf(...) cast of the user entered numbers). 
 Evenerything else is identical, NumericRangeQuery also supports the MTQ 
 rewrite modes (as it is a MTQ).
 Another thing is a change in Date semantics. There are some strange flags in 
 the current parser that tells it how to handle dates.

--
This message is automatically generated by JIRA.
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-2651) The new SolrCore#reload method does not create a ZkSolrResourceLoader in ZooKeeper mode


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

Mark Miller updated SOLR-2651:
--

Attachment: (was: SOLR-2651.patch)

 The new SolrCore#reload method does not create a ZkSolrResourceLoader in 
 ZooKeeper mode
 ---

 Key: SOLR-2651
 URL: https://issues.apache.org/jira/browse/SOLR-2651
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2651.patch, SOLR-2651.patch, SOLR-2651.patch


 this is a trunk bug
 reload is hard wired to simply make a SolrResourceLoader - this means that in 
 ZooKeeper mode, changes to config are not picked up on a reload - instead you 
 would get any local configs.

--
This message is automatically generated by JIRA.
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-2651) The new SolrCore#reload method does not create a ZkSolrResourceLoader in ZooKeeper mode


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

Mark Miller updated SOLR-2651:
--

Attachment: SOLR-2651.patch

whoops - that was the same patch as before - here is the new one.

 The new SolrCore#reload method does not create a ZkSolrResourceLoader in 
 ZooKeeper mode
 ---

 Key: SOLR-2651
 URL: https://issues.apache.org/jira/browse/SOLR-2651
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2651.patch, SOLR-2651.patch, SOLR-2651.patch


 this is a trunk bug
 reload is hard wired to simply make a SolrResourceLoader - this means that in 
 ZooKeeper mode, changes to config are not picked up on a reload - instead you 
 would get any local configs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[JENKINS-MAVEN] Lucene-Solr-Maven-3.x #183: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-3.x/183/

No tests ran.

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



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

[jira] [Resolved] (SOLR-2651) The new SolrCore#reload method does not create a ZkSolrResourceLoader in ZooKeeper mode


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

Mark Miller resolved SOLR-2651.
---

Resolution: Fixed

committed r1146905

 The new SolrCore#reload method does not create a ZkSolrResourceLoader in 
 ZooKeeper mode
 ---

 Key: SOLR-2651
 URL: https://issues.apache.org/jira/browse/SOLR-2651
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2651.patch, SOLR-2651.patch, SOLR-2651.patch


 this is a trunk bug
 reload is hard wired to simply make a SolrResourceLoader - this means that in 
 ZooKeeper mode, changes to config are not picked up on a reload - instead you 
 would get any local configs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[JENKINS-MAVEN] Lucene-Solr-Maven-3.x #184: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-3.x/184/

1 tests failed.
FAILED:  org.apache.solr.core.TestJmxIntegration.testJmxOnCoreReload

Error Message:
Can't find resource 'solrconfig.xml' in classpath or 'solr/solr/conf/', 
cwd=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/solr/build/solr-maven/classes/test

Stack Trace:
java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath 
or 'solr/solr/conf/', 
cwd=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/solr/build/solr-maven/classes/test
at 
org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:268)
at 
org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:234)
at org.apache.solr.core.Config.init(Config.java:141)
at org.apache.solr.core.SolrConfig.init(SolrConfig.java:131)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:435)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:525)
at 
org.apache.solr.core.TestJmxIntegration.testJmxOnCoreReload(TestJmxIntegration.java:128)
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:44)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1299)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1217)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)




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



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

[jira] [Created] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated

lockType/ not used consistently in all places Directory objects are 
instantiated
--

 Key: SOLR-2654
 URL: https://issues.apache.org/jira/browse/SOLR-2654
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Critical
 Fix For: 3.4


nipunb noted on the mailing list then when configuring solr to use an alternate 
lockType/ (ie: simple) the stats for the SolrIndexSearcher list 
NativeFSLockFactory being used by the Directory.

The problem seems to be that SolrIndexConfig is not consulted when constructing 
Directory objects used for IndexReader (it's only used by SolrIndexWriter)

I don't _think_ this is a problem in most cases since the IndexReaders should 
all be readOnly in the core solr code) but plugins could attempt to use them in 
other ways.  In general it seems like a really bad bug waiting to happen.

--
This message is automatically generated by JIRA.
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-2654) lockType/ not used consistently in all places Directory objects are instantiated


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

Hoss Man commented on SOLR-2654:


Original report...

{noformat}
From: nipunb 
To: solr-user
Date: Thu, 14 Jul 2011 00:50:21 -0700 (PDT)
Subject: Lockfactory indicated by ../solr/admin/cores different from the 
setting in solrconfig.xml

hey
We have set locktype to simple in solrconfig.xml using:
lockTypesimple/lockType. However on the page
localhost:8983/solr/admin/cores shows:
str name=directory
org.apache.lucene.store.MMapDirectory:org.apache.lucene.store.MMapDirectory/solr-cores/core0/data/index
lockFactory=*org.apache.lucene.store.NativeFSLockFactory*@3415ddf5
/str
I can see a write.lock file in the index directory. But shouldn't the page
solr/admin/cores also be showing the the lockFactory to be
org.apache.lucene.store.SimpleFSLockFactory.SimpleFSLockFactory
{noformat}

 lockType/ not used consistently in all places Directory objects are 
 instantiated
 --

 Key: SOLR-2654
 URL: https://issues.apache.org/jira/browse/SOLR-2654
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Critical
 Fix For: 3.4


 nipunb noted on the mailing list then when configuring solr to use an 
 alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list 
 NativeFSLockFactory being used by the Directory.
 The problem seems to be that SolrIndexConfig is not consulted when 
 constructing Directory objects used for IndexReader (it's only used by 
 SolrIndexWriter)
 I don't _think_ this is a problem in most cases since the IndexReaders should 
 all be readOnly in the core solr code) but plugins could attempt to use them 
 in other ways.  In general it seems like a really bad bug waiting to happen.

--
This message is automatically generated by JIRA.
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-2654) lockType/ not used consistently in all places Directory objects are instantiated


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

Hoss Man commented on SOLR-2654:


In general i wonder if there isn't a largely problem here: shouldn't the 
IndexReader and SolrIndexWriter usually be using the exact same _instance_ of a 
Directory object -- not just two instances generated by the same 
DirectoryFactory?)

(I'm not sure given the various work being done with reopen and what not)

 lockType/ not used consistently in all places Directory objects are 
 instantiated
 --

 Key: SOLR-2654
 URL: https://issues.apache.org/jira/browse/SOLR-2654
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Critical
 Fix For: 3.4


 nipunb noted on the mailing list then when configuring solr to use an 
 alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list 
 NativeFSLockFactory being used by the Directory.
 The problem seems to be that SolrIndexConfig is not consulted when 
 constructing Directory objects used for IndexReader (it's only used by 
 SolrIndexWriter)
 I don't _think_ this is a problem in most cases since the IndexReaders should 
 all be readOnly in the core solr code) but plugins could attempt to use them 
 in other ways.  In general it seems like a really bad bug waiting to happen.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

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


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

Hoss Man commented on SOLR-1972:


Shawn: i was a little concerned based on the issue summary that this would slow 
down the performance of the handlers, but skimming the patch i see that unless 
it's explicitly configured in the init params, only a single responseTimes != 
null check is added to each request, and even when it is enabled, all the hard 
work is defered until the stats are actually requested -- so as long as we 
document that recording (and retrieving) these stats may slow down the 
performance of hte handler, i don't see a big problem there.  (my personal 
prefrence is to generate these stats from log parsing because then it can be 
done completely out of band -- but i certainly won't object to making it easier 
for people to get directly from solr)

my only other suggestion is that  you refactor the stats code into some static 
methods (or a helper class) so we can have some test cases that verify the 
accuracy against fixed data ... i'm not a match guy, so it's not entirely 
obvious to me just looking at it that it will always produce the correct 
results (particularly with the max age and array re-ordering and what not) so 
unit tests would help demonstrate tht it does what it's suppose to in various 
edge cases.

 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.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.
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-1768) NumericRange support for new query parser

2011-07-14 Thread Vinicius Barros (JIRA)


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

Vinicius Barros commented on LUCENE-1768:
-

Hi Uwe,

Thanks for fixing the junit, I think changing the order of those processors is 
OK, mainly if Numeric processors do no require lowercasing.

 NumericRange support for new query parser
 -

 Key: LUCENE-1768
 URL: https://issues.apache.org/jira/browse/LUCENE-1768
 Project: Lucene - Java
  Issue Type: New Feature
  Components: core/queryparser
Affects Versions: 2.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
  Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
 Fix For: 4.0

 Attachments: TestNumericQueryParser-fix.patch, 
 TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, 
 week-7.patch, week1.patch, week2.patch, week3.patch, week4.patch, 
 week5-6.patch


 It would be good to specify some type of schema for the query parser in 
 future, to automatically create NumericRangeQuery for different numeric 
 types? It would then be possible to index a numeric value 
 (double,float,long,int) using NumericField and then the query parser knows, 
 which type of field this is and so it correctly creates a NumericRangeQuery 
 for strings like [1.567..*] or (1.787..19.5].
 There is currently no way to extract if a field is numeric from the index, so 
 the user will have to configure the FieldConfig objects in the ConfigHandler. 
 But if this is done, it will not be that difficult to implement the rest.
 The only difference between the current handling of RangeQuery is then the 
 instantiation of the correct Query type and conversion of the entered numeric 
 values (simple Number.valueOf(...) cast of the user entered numbers). 
 Evenerything else is identical, NumericRangeQuery also supports the MTQ 
 rewrite modes (as it is a MTQ).
 Another thing is a change in Date semantics. There are some strange flags in 
 the current parser that tells it how to handle dates.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (LUCENE-502) TermScorer caches values unnecessarily

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

Robert Muir resolved LUCENE-502.

Resolution: Fixed
Fix Version/s: 4.0

In trunk, there is no longer a score cache in TermScorer because this is just
an optimization for the TF/IDF scoring formula.

Instead this optimization is in TFIDFSimilarity, if you want or don't want
similar pre-computations in your scoring you can adjust this by plugging in
your own Similarity.

TermScorer caches values unnecessarily
--

Key: LUCENE-502
URL: https://issues.apache.org/jira/browse/LUCENE-502
Project: Lucene - Java
Issue Type: Improvement
Components: core/search
Affects Versions: 1.9
Reporter: Steven Tamm
Priority: Minor
Fix For: 4.0

Attachments: LUCENE-502.patch, TermScorer.patch

TermScorer aggressively caches the doc and freq of 32 documents at a time for
each term scored. When querying for a lot of terms, this causes a lot of
garbage to be created that's unnecessary. The SegmentTermDocs from which it
retrieves its information doesn't have any optimizations for bulk loading,
and it's unnecessary.
In addition, it has a SCORE_CACHE, that's of limited benefit. It's caching
the result of a sqrt that should be placed in DefaultSimilarity, and if
you're only scoring a few documents that contain those terms, there's no need
to precalculate the SQRT, especially on modern VMs.
Enclosed is a patch that replaces TermScorer with a version that does not
cache the docs or feqs. In the case of a lot of queries, that saves 196
bytes/term, the unnecessary disk IO, and extra SQRTs which adds up.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-3105) String.intern() calls slow down IndexWriter.close() and IndexReader.open() for index with large number of unique field names


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

Robert Muir resolved LUCENE-3105.
-

Resolution: Duplicate

fixed as of lucene-2548

 String.intern() calls slow down IndexWriter.close() and IndexReader.open() 
 for index with large number of unique field names
 

 Key: LUCENE-3105
 URL: https://issues.apache.org/jira/browse/LUCENE-3105
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.1
Reporter: Mark Kristensson
 Attachments: LUCENE-3105.patch


 We have one index with several hundred thousand unqiue field names (we're 
 optimistic that Lucene 4.0 is flexible enough to allow us to change our index 
 design...) and found that opening an index writer and closing an index reader 
 results in horribly slow performance on that one index. I have isolated the 
 problem down to the calls to String.intern() that are used to allow for quick 
 string comparisons of field names throughout Lucene. These String.intern() 
 calls are unnecessary and can be replaced with a hashmap lookup. In fact, 
 StringHelper.java has its own hashmap implementation that it uses in 
 conjunction with String.intern(). Rather than using a one-off hashmap, I've 
 elected to use a ConcurrentHashMap in this patch.

--
This message is automatically generated by JIRA.
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-26) potential optimization of BufferedTokenStream?