[jira] [Resolved] (LUCENE-4188) Storing Shapes shouldn't be Strategy dependent

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-4188.
--

   Resolution: Fixed
Fix Version/s: 4.0

I inlined/removed SpatialStrategy.createStoredField() and added documentation 
to the SpatialStrategy class header & to createFields() regarding storing a 
field value.

Committed.

I'll address the rename of createFields() to createIndexableFields() in 
LUCENE-4192

> Storing Shapes shouldn't be Strategy dependent
> --
>
> Key: LUCENE-4188
> URL: https://issues.apache.org/jira/browse/LUCENE-4188
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Chris Male
>Assignee: David Smiley
> Fix For: 4.0
>
> Attachments: LUCENE-4188_remove_field_storage_from_createField.patch
>
>
> The logic for storing Shape representations seems to be different for each 
> Strategy.  The PrefixTreeStrategy impls store the Shape in WKT, which is nice 
> if you're using WKT but not much help if you're not.  BBoxStrategy doesn't 
> actually store the Shape itself, but a representation of the bounding box.  
> TwoDoubles seems to follow the PrefixTreeStrategy approach, which is 
> surprising since it only indexes Points and they could be stored without 
> using WKT.
> I think we need to consider what storing a Shape means.  If we want to store 
> the Shape itself, then that logic should be standardised and done outside of 
> the Strategys since it is not really related to them.  If we want to store 
> the terms being used by the Strategys to make Shapes queryable, then we need 
> to change the logic in the Strategys to actually do this.

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



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

[JENKINS] Lucene-Solr-4.x-Windows-Java7-64 - Build # 266 - Failure!

[Policeman Jenkins Server]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows-Java7-64/266/

No tests ran.

Build Log:
[...truncated 4 lines...]
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
java.lang.NullPointerException
at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83)
at 
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122)
at 
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:692)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:639)
at hudson.model.Run.execute(Run.java:1513)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Email was triggered for: Failure
Sending email for trigger: Failure




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

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

Committed trunk revision 1359953, 4.x revision 1359954, 3.6 revision 1359956.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209-enforce-cleanup.patch, LUCENE-4209.patch, 
> LUCENE-4209.patch, LUCENE-4209_more.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I f

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4209:
-

+1

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209-enforce-cleanup.patch, LUCENE-4209.patch, 
> LUCENE-4209.patch, LUCENE-4209_more.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why are they not cl

[jira] [Updated] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4209:
--

Attachment: LUCENE-4209-enforce-cleanup.patch

Patch that enforces cleanup of all temporarily generated files on success or 
failure, also partially written output files are deleted on error.

We should do the same for the other places like BytesRefSorter.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209-enforce-cleanup.patch, LUCENE-4209.patch, 
> LUCENE-4209.patch, LUCENE-4209_more.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390part

[jira] [Commented] (SOLR-3591) Startup error not reflected in Solr web view

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-3591:


bq. Perhaps we can use part of SOLR-3358 to capture FATAL exceptions and 
somehow expose them regardless of the core?

i don't have any objections to that, what i've seen of SOLR-3358 looks great so 
far, and it would be nice if it was accesible even w/o having any SolrCores -- 
but i think we need a more specific targeted solution for reporting core 
initialization problems...

* we can't uniquely identify which core caused which log messages
* we can't control what log messages might come out of a plugin from a core
* we can't identify which log message was the "straw that broke the camels 
back" and actually caused the core init to fail.
* we can't definitively know if a log message is "still important" as more log 
messages come in (from other cores)
* we can't know if a specific log messages related to core initialization is 
"still a problem" or if that specific core has already been fix and re-created

...but we can, in CoreContainer, catch and record the specific exceptions 
related to each core name, and track them relative that core name, and let 
CoreAdminHandler have thta data when it's asked to report status.

so if a plugin in coreA logged 99 "fatal" log messages, but coreA still started 
fine; while coreB didn't log anything but the constructor threw an exception X 
we can make CoreAdminHAndler reliably (and confidently) say "here's your status 
for coreA, and FYI: coreB failed to initialize because of X" w/o making the 
user wade through 100 other log messages that are unrelated.  And even if the 
user doesn't look at the core status for hours and hours after trying to 
startup (or after some cron tried to programaticly create coreB), and there 
have been thousands of other "errors" logged by other cores, CoreAdminHandler 
can still say "this error X is the reason you don't have a coreB right now".

see what i mean?


> Startup error not reflected in Solr web view
> 
>
> Key: SOLR-3591
> URL: https://issues.apache.org/jira/browse/SOLR-3591
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Erik Hatcher
>Assignee: Stefan Matheis (steffkes)
>Priority: Blocker
> Fix For: 4.0
>
> Attachments: screenshot-1.jpg
>
>
> When Solr has a fatal startup error, it used to be reflected in general 
> responses from Solr.  With the new UI, it's relegated to only the logs.

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



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

[jira] [Updated] (SOLR-3614) XML parsing in XPathEntityProcessor doesn't respect ENTITY declarations?

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-3614:
---

Attachment: SOLR-3614.patch

trivial test patch demonstrating the error.

> XML parsing in XPathEntityProcessor doesn't respect ENTITY declarations?
> 
>
> Key: SOLR-3614
> URL: https://issues.apache.org/jira/browse/SOLR-3614
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-3614.patch
>
>
> As reported by Michael Belenki on solr-user, pointing XPathEntityProcessor at 
> XML files that use DTD "ENTITY" declarations causes XML parse errors of the 
> form...
> {noformat}
> org.apache.solr.handler.dataimport.DataImportHandlerException: Parsing failed 
> for xml, url:testdata.xml rows processed:0
> ...
> Caused by: java.lang.RuntimeException: com.ctc.wstx.exc.WstxParsingException: 
> Undeclared general entity "uuml"
> ...
> {noformat}
> ...even when the entity is specifically declared.

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



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

[jira] [Created] (SOLR-3614) XML parsing in XPathEntityProcessor doesn't respect ENTITY declarations?

[Hoss Man (JIRA)]

Hoss Man created SOLR-3614:
--

 Summary: XML parsing in XPathEntityProcessor doesn't respect 
ENTITY declarations?
 Key: SOLR-3614
 URL: https://issues.apache.org/jira/browse/SOLR-3614
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


As reported by Michael Belenki on solr-user, pointing XPathEntityProcessor at 
XML files that use DTD "ENTITY" declarations causes XML parse errors of the 
form...

{noformat}
org.apache.solr.handler.dataimport.DataImportHandlerException: Parsing failed 
for xml, url:testdata.xml rows processed:0
...
Caused by: java.lang.RuntimeException: com.ctc.wstx.exc.WstxParsingException: 
Undeclared general entity "uuml"
...
{noformat}

...even when the entity is specifically declared.

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



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

[jira] [Updated] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4209:


Attachment: LUCENE-4209_more.patch

here's the patch: what a horrendous thing to track down.

It only happened on Uwe's computer because he has /tmp on a separate volume. So 
the rename fails, and it does this copy() thing, but doesn't delete the old 
file.


> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch, 
> LUCENE-4209_more.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup

[jira] [Comment Edited] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-4209 at 7/10/12 11:05 PM:
-

The Solr FST test also creates (in Linux, too) 2 of those files and never 
deletes them:

-rw-r--r-- 1 jenkins  nogroup19 Jul 10 21:07 
sort3792768274336297309partition
-rw-r--r-- 1 jenkins  nogroup  21300609 Jul 10 21:07 
sort8319180334296886006intermediate

  was (Author: thetaphi):
The Solr FST test also creates (in Linux, too) 3 of those files and never 
deletes them:

-rw-r--r-- 1 jenkins  nogroup19 Jul 10 21:07 
sort3792768274336297309partition
-rw-r--r-- 1 jenkins  nogroup  21300609 Jul 10 21:07 
sort8319180334296886006intermediate
-rw-r--r-- 1 jenkins  nogroup360655 Jul  8 10:12 
winstone7754695006369921857jar
  
> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314parti

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

Problem found with Robert:
It's not Solr, its again Sort.java.

This time this happens:
On the Jenkins machine /tmp is a separate filesystem (tmpfs), so the code uses 
the fallback, if file.renbameTo() does not work and copies the file. But 
forgets to delete the orginal.

Robert has patch.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> 

[jira] [Commented] (SOLR-3591) Startup error not reflected in Solr web view

[Ryan McKinley (JIRA)]

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

Ryan McKinley commented on SOLR-3591:
-

Perhaps we can use part of SOLR-3358 to capture FATAL exceptions and somehow 
expose them regardless of the core?

Then the UI behavior could essentially show the logging when /solr/admin/ 
does not exist?



> Startup error not reflected in Solr web view
> 
>
> Key: SOLR-3591
> URL: https://issues.apache.org/jira/browse/SOLR-3591
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Erik Hatcher
>Assignee: Stefan Matheis (steffkes)
>Priority: Blocker
> Fix For: 4.0
>
> Attachments: screenshot-1.jpg
>
>
> When Solr has a fatal startup error, it used to be reflected in general 
> responses from Solr.  With the new UI, it's relegated to only the logs.

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



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

[jira] [Commented] (SOLR-3591) Startup error not reflected in Solr web view

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-3591:


It sounds like there are two related problems that compound int oa really bad 
experience...



*1) the web ui isn't cleaning dealing with the situation where there are "no 
cores" returned by the CoreAdminHandler.*

this is a legitimate situation, that doesn't neccessarily indicate an error.  

if there are no cores, then the ui shouldn't blindly try to load 
"/solr/null/admin/system?wt=json" and then complain that the admin handler 
can't be found -- the logic should be something like:

* can we talk to CoreAdminHandler at all? if not give a specific error
* if CoreAdminHandler says there are no cores, give a message to that effect 
** offer the info/commands that are stil available (ie: "Core Admin" 
functionality)
** perhaps suggesting that if they expected to cores to already exist, they 
should check logs 9allthough this may not be needed depending on how far we get 
with "#2" below)
* if cores are available, then try to use /corename/admin to get the other info 
to populate the UI, and if we can't find it *then* mention that they need to 
add config
** i would also suggest using the "defaultcore" if non-null instead of just 
whatever core happens to be listed first (but that's a good fallback if there 
is no default core)



*2) no external reporting of errors in initializing cores*

once upon a time, Solr had an "abortOnConfigurationError" option per core, that 
never really worked well, and would try to partially initialize a core even if 
some things failed.  In conjunction with that (broken) setting, was a static 
list of Exceptions that had been thrown during SolrCore construction, which the 
SolrRequestDispatcher would try to use to generate an error messages if there 
was a problem.

All of that code has been ripped out of trunk for a long while, largely because 
it didn't work, and it _REALLY_ didn't work well with multicore, but as erik 
points out the one thing that it _did_ help with was in making it obvious when 
there were config problems on startup.

I think we should at least partially revive the idea of keeping track of the 
list of "severe" errors, but there are a lot of things we can do differnetly 
now:

* instead of being static, it can be managed by the CoreContainer
* it can specificly be exceptions caught by CoreContainer while initializing 
SolrCores.
* we can maintain it as a map of (String)coreName -> 
Pair<(Date)timstamp,(Exception)error> so it's clear what exception came from 
initializing which solr core
** by using a name mapping, we can delete entires if/when a SolrCore is 
re-loaded to fix the error.
* we can return this map in CoreAdminHandler so the UI can display a big 
flashing warning about cores that failed to initialize (both on startup, or if 
some remote command tried to create a core programaticly)



i suggest we spin off a new Jira for #1 since that is somewhat independent (we 
need to change the "no cores" behavior of the UI no matter what else we do) and 
use sub-tasks of this issue to track improvements to 
CoreContainer/CoreAdminHandler/UI to display errors related to SolrCore 
initialization.

sound good?

> Startup error not reflected in Solr web view
> 
>
> Key: SOLR-3591
> URL: https://issues.apache.org/jira/browse/SOLR-3591
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Erik Hatcher
>Assignee: Stefan Matheis (steffkes)
>Priority: Blocker
> Fix For: 4.0
>
> Attachments: screenshot-1.jpg
>
>
> When Solr has a fatal startup error, it used to be reflected in general 
> responses from Solr.  With the new UI, it's relegated to only the logs.

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



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

[jira] [Commented] (SOLR-3613) Namespace Solr's JAVA OPTIONS

[JIRA]

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

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

The ones I've found so far are the new SolrCloud opts: {{zkRun, 
bootstrap_confdir, collection.configName, numShards, zkHost}}

> Namespace Solr's JAVA OPTIONS
> -
>
> Key: SOLR-3613
> URL: https://issues.apache.org/jira/browse/SOLR-3613
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.0-ALPHA
>Reporter: Jan Høydahl
> Fix For: 4.0
>
>
> Solr being a web-app, should play nicely in a setting where users deploy it 
> on a shared appServer.
> To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid 
> name clashes and for clarity when reading your appserver startup script. We 
> currently do that with most: {{solr.solr.home, solr.data.dir, 
> solr.abortOnConfigurationError, solr.directoryFactory, 
> solr.clustering.enabled, solr.velocity.enabled etc}}, but for some opts we 
> fail to do so.
> Before release of 4.0 we should make sure to clean this up.

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



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

[jira] [Created] (SOLR-3613) Namespace Solr's JAVA OPTIONS

[JIRA]

Jan Høydahl created SOLR-3613:
-

 Summary: Namespace Solr's JAVA OPTIONS
 Key: SOLR-3613
 URL: https://issues.apache.org/jira/browse/SOLR-3613
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.0-ALPHA
Reporter: Jan Høydahl
 Fix For: 4.0


Solr being a web-app, should play nicely in a setting where users deploy it on 
a shared appServer.

To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid 
name clashes and for clarity when reading your appserver startup script. We 
currently do that with most: {{solr.solr.home, solr.data.dir, 
solr.abortOnConfigurationError, solr.directoryFactory, solr.clustering.enabled, 
solr.velocity.enabled etc}}, but for some opts we fail to do so.

Before release of 4.0 we should make sure to clean this up.

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



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

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

The Solr FST test also creates (in Linux, too) 3 of those files and never 
deletes them:

-rw-r--r-- 1 jenkins  nogroup19 Jul 10 21:07 
sort3792768274336297309partition
-rw-r--r-- 1 jenkins  nogroup  21300609 Jul 10 21:07 
sort8319180334296886006intermediate
-rw-r--r-- 1 jenkins  nogroup360655 Jul  8 10:12 
winstone7754695006369921857jar

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermedia

[jira] [Commented] (SOLR-3598) Provide option to allow aliased field to be included in query for EDisMax QParser

[JIRA]

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

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

Couldn't you achieve the same through different field naming in your schema?

Fields = firstname, lastname, fullname

Alias: f.name.qf=firstname,lastname,fullname

> Provide option to allow aliased field to be included in query for EDisMax 
> QParser
> -
>
> Key: SOLR-3598
> URL: https://issues.apache.org/jira/browse/SOLR-3598
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 3.6, 4.0, 4.0-ALPHA
>Reporter: Jamie Johnson
>Priority: Minor
> Attachments: alias.patch
>
>
> I currently have a situation where I'd like the original field included in 
> the query, for instance I have several fields with differing granularity, 
> name, firstname and lastname.  Some of my sources differentiate between these 
> so I can fill out firstname and lastname, while others don't and I need to 
> just place this information in the name field.  When querying I'd like to be 
> able to say name:Jamie and have it translated to name:Jamie first_name:Jamie 
> last_name:Jamie.  In order to do this it creates an alias cycle and the 
> EDisMax Query parser throws an exception about it.  Ideally there would be an 
> option to include the original field as part of the query to support this use 
> case.

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



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

[jira] [Updated] (SOLR-3595) Currency types do not support range queries when multiValued

[JIRA]

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

Jan Høydahl updated SOLR-3595:
--

Fix Version/s: 5.0
   4.0
   Labels: CurrencyField  (was: )

+1
Disallowing multivalue sounds like the right approach, then if anyone figures 
out how to support it in the future it can be done then, not now.

> Currency types do not support range queries when multiValued
> 
>
> Key: SOLR-3595
> URL: https://issues.apache.org/jira/browse/SOLR-3595
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.0-ALPHA
>Reporter: Erick Erickson
>Priority: Minor
>  Labels: CurrencyField
> Fix For: 4.0, 5.0
>
>
> You can define the currency type as multiValued. However, if you do (and have 
> more than one value), range queries, at least, do not work. See the thread 
> titled "Filtering a query by range returning unexpected results".
> I'm not at all sure that currency type _should_ support multivalued. For 
> instance, how would one handle storing multiple values for a currency type in 
> different currencies (e.g. USD and EUR)? I don't know enough about the 
> internals to understand if it's possible, this JIRA is the result of a 
> question on the users list.
> If we decide that currency should _not_ support multiValued, it seems a check 
> at startup is in order on the "fail early, fail loudly" principle.

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



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

[JENKINS] Lucene-Solr-trunk-Linux-Java8-64 - Build # 12 - Still Failing!

[Policeman Jenkins Server]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java8-64/12/

1 tests failed.
REGRESSION:  
org.apache.solr.handler.component.SpellCheckComponentTest.testPerDictionary

Error Message:
mismatch: '0'!='2' @ spellcheck/suggestions/bar/startOffset

Stack Trace:
java.lang.RuntimeException: mismatch: '0'!='2' @ 
spellcheck/suggestions/bar/startOffset
at 
__randomizedtesting.SeedInfo.seed([DF6942825CC072F7:1867B62A54AC67BF]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:573)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:521)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.testPerDictionary(SpellCheckComponentTest.java:102)
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:474)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)




Build Log:
[...truncated 10962 lines...]
[junit4:junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
[junit4:junit4]> (@BeforeClass output)
[j

[jira] [Commented] (LUCENE-4207) speed up our slowest tests

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4207:
-

Can you check the execution stats from your system, Christian? We'll see how 
odd your system is:
{code}
ant clean
for i in `seq 1 20`; do 
  ant -Dtests.cachefile=/somewhere/outside/workspace/testtimes.log test
done
{code}

The "testtimes.log" will contain execution time for all suites, you could 
compare these to the cached one (lucene/tools/junit4/cached-timehints.txt) in 
the checkout. Absolute values will differ but the ordering and relative scale 
should remain pretty much the same. I think?



> speed up our slowest tests
> --
>
> Key: LUCENE-4207
> URL: https://issues.apache.org/jira/browse/LUCENE-4207
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Was surprised to hear from Christian that lucene/solr tests take him 40 
> minutes on a modern mac.
> This is too much. Lets look at the slowest tests and make them reasonable.

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



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

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4209:
-

I committed this on trunk/branch_4x/branch_3_6

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why are they not cleaned up and why d

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4209:
-

Oh crap.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why are they not cleaned up and why do we need those files? Would 
> a RamD

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4209:
-

there were three cases:
1. not calling Sorter.close() in FSTCompletionLookup
2. not closing things in tests.
3. trying to delete things *before* closing an open reader on them in 
SoftedTermFreqIteratorWrapper: windows problem only, it will not allow that.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4209:
-

Why were those temporary files not cleaned up? A bug?

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why are they not cleaned up an

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4209:
-

I agree the Directory abstraction would be nice here.

Then we can verify everything (including windows correctness and no leaks) with 
MockDirectoryWrapper.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "R

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

This one fixes on windows, too.

We should commit this now to make my machines happy and open another issue to 
make this horrible random file placement configureable like in your original 
Sorter (taking Directory instead of File.createTempFile()). We must put this 
method on the forbidden 
list!
 damn!!

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21

[jira] [Updated] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4209:


Attachment: LUCENE-4209.patch

try this one: I think i know the problem on Windows.

See my changes to SortedTermFreqIteratorWrapper.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch, LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why

[jira] [Updated] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4209:
--

Affects Version/s: 3.6
Fix Version/s: 3.6.1

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 3.6.1, 5.0
>
> Attachments: LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why are they not cleaned up and why do we need those files? Would 
> a RamDirectory not be enough for this?
> Th

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

On Windows, those files stayed there after running tests in suggest:

10.07.2012  20:40 0 
SortedTermFreqIteratorWrapper1308605874198741902.sorted
10.07.2012  20:40   351.131 
SortedTermFreqIteratorWrapper2027363697367869268.sorted
10.07.2012  20:40   449.985 
SortedTermFreqIteratorWrapper5542079452540558393.sorted
10.07.2012  20:39   241 
SortedTermFreqIteratorWrapper690999681538401442.sorted
10.07.2012  20:4013.505 
WFSTTermFreqIteratorWrapper6984334111477611000.sorted
10.07.2012  20:4047 
WFSTTermFreqIteratorWrapper7332590534826479332.sorted

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup  

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

I have also seen (on Windows), shit like: 
WFSTTermFreqIteratorWrapper8451761996211413579.sorted

I will try now after cleaning up.

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it mus

[jira] [Resolved] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-4206.
---

   Resolution: Fixed
Fix Version/s: 5.0

Committed trunk revision: 1359827
Committed 4.x revision: 1359828

> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4206.patch, LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Updated] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4209:


Attachment: LUCENE-4209.patch

can you try this one on windows?

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4209.patch
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Why are they not cleaned up and why do we need those files? Would 
> a RamDirectory not be enough for th

[jira] [Commented] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4209:
---

In my opinion, the placing of files should be configureable for user, it should 
*not* create File.createTempFile() [Robert: Put it on the forbidden list, 
please...]

> BytesRefSorter leaves files in /tmp and never cleans them up
> 
>
> Key: LUCENE-4209
> URL: https://issues.apache.org/jira/browse/LUCENE-4209
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/FSTs
>Affects Versions: 4.0-ALPHA
>Reporter: Uwe Schindler
>Priority: Critical
> Fix For: 4.0, 5.0
>
>
> When reviewing my Jenkins installation, I found out that /tmp is filled by 
> Jenkins with the following files (in Linux and Windows).
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
>

[jira] [Updated] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4209:
--

Description: 
When reviewing my Jenkins installation, I found out that /tmp is filled by 
Jenkins with the following files (in Linux and Windows).

-rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
RefSorter-1839005885812820606.sorted
-rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
RefSorter-2799526995307200478.sorted
-rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
RefSorter-2841491891429925756.sorted
-rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
RefSorter-3302954184439492426.sorted
-rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
RefSorter-3738422482066276549.sorted
-rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
RefSorter-4235756851148318773.sorted
-rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
RefSorter-4530019493984469514.sorted
-rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
RefSorter-5245195867837976219.sorted
-rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
RefSorter-5977302780601133089.sorted
-rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
RefSorter-6336186633027300753.sorted
-rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
RefSorter-6447286760971372233.sorted
-rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
RefSorter-6532780916605441895.sorted
-rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
RefSorter-7247901917320979657.sorted
-rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
RefSorter-7796370222379929612.sorted
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
sort1277839437346448611partition
-rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
sort1362726822297484023intermediate
-rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
sort1435680293746542872intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
sort1498884601796138622partition
-rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
sort1634015425760928615intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
sort1954741677243403383partition
-rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
sort2203784121687916561intermediate
-rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
sort24154414907891444intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
sort2816986454022083882partition
-rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
sort285022281545547041intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
sort295507558144077223partition
-rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
sort3013772538520090513intermediate
-rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
sort3297463807520676013intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
sort3364874175018276528partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
sort3846182021346233750partition
-rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
sort4397860673342757974intermediate
-rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
sort4474792189525490476intermediate
-rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
sort4518448528614283778intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
sort4756172476965226743partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
sort5416699953867843402partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
sort5558474409634346477partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
sort6281513108922200314partition
-rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
sort6639309492804635005intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
sort665458777941142partition
-rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
sort6973021800616034113intermediate
-rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
sort7260811068342958052intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
sort852078170643422390partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
sort8857722113319559286partition

The pattern "RefSorter-" I found in Lucene's source code, so it must come
from tests. Why are they not cleaned up and why do we need those files? Would a 
RamDirectory not be enough for this?

This is serious, as the files are never cleaned up, they stay alive when the 
test passes, so its not caused by the always failing Solr Suggester tests.

There are also other filenames with .sorted and similar at end.

The slave was taken automatically offline after its RAM-based /tmp (2 GB) was 
filling in <24h). On the Windows Box c:\Users\JenkinsSlave\AppData\Temp 
contained already 60,000 files like this (still deleting them), taking 12 GB of 
disk space. I will review Apache Jenkins, too -> also cleaned up lots of files.

  was:
When reviewing my Jenkins installation, I found out that /tmp is filled by 
Jenkins with the following files (in Linux and Windows).

-rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
RefSorter-18390058858

[JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 542 - Failure!

[Policeman Jenkins Server]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/542/

All tests passed

Build Log:
[...truncated 20397 lines...]
Looks like the node went offline during the build. Check the slave log for the 
details.FATAL: /var/lib/jenkins/slave-null.log (No such file or directory)
java.io.FileNotFoundException: /var/lib/jenkins/slave-null.log (No such file or 
directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.(RandomAccessFile.java:216)
at 
org.kohsuke.stapler.framework.io.LargeText$FileSession.(LargeText.java:351)
at org.kohsuke.stapler.framework.io.LargeText$1.open(LargeText.java:75)
at 
org.kohsuke.stapler.framework.io.LargeText.writeLogTo(LargeText.java:164)
at 
hudson.console.AnnotatedLargeText.writeHtmlTo(AnnotatedLargeText.java:158)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:512)
at hudson.model.Run.execute(Run.java:1488)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)




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

[jira] [Created] (LUCENE-4209) BytesRefSorter leaves files in /tmp and never cleans them up

[Uwe Schindler (JIRA)]

Uwe Schindler created LUCENE-4209:
-

 Summary: BytesRefSorter leaves files in /tmp and never cleans them 
up
 Key: LUCENE-4209
 URL: https://issues.apache.org/jira/browse/LUCENE-4209
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/FSTs
Affects Versions: 4.0-ALPHA
Reporter: Uwe Schindler
Priority: Critical
 Fix For: 4.0, 5.0


When reviewing my Jenkins installation, I found out that /tmp is filled by 
Jenkins with the following files (in Linux and Windows).

-rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
RefSorter-1839005885812820606.sorted
-rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
RefSorter-2799526995307200478.sorted
-rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
RefSorter-2841491891429925756.sorted
-rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
RefSorter-3302954184439492426.sorted
-rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
RefSorter-3738422482066276549.sorted
-rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
RefSorter-4235756851148318773.sorted
-rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
RefSorter-4530019493984469514.sorted
-rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
RefSorter-5245195867837976219.sorted
-rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
RefSorter-5977302780601133089.sorted
-rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
RefSorter-6336186633027300753.sorted
-rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
RefSorter-6447286760971372233.sorted
-rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
RefSorter-6532780916605441895.sorted
-rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
RefSorter-7247901917320979657.sorted
-rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
RefSorter-7796370222379929612.sorted
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
sort1277839437346448611partition
-rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
sort1362726822297484023intermediate
-rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
sort1435680293746542872intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
sort1498884601796138622partition
-rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
sort1634015425760928615intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
sort1954741677243403383partition
-rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
sort2203784121687916561intermediate
-rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
sort24154414907891444intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
sort2816986454022083882partition
-rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
sort285022281545547041intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
sort295507558144077223partition
-rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
sort3013772538520090513intermediate
-rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
sort3297463807520676013intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
sort3364874175018276528partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
sort3846182021346233750partition
-rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
sort4397860673342757974intermediate
-rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
sort4474792189525490476intermediate
-rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
sort4518448528614283778intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
sort4756172476965226743partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
sort5416699953867843402partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
sort5558474409634346477partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
sort6281513108922200314partition
-rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
sort6639309492804635005intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
sort665458777941142partition
-rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
sort6973021800616034113intermediate
-rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
sort7260811068342958052intermediate
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
sort852078170643422390partition
-rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
sort8857722113319559286partition

The pattern "RefSorter-" I found in Lucene's source code, so it must come
from tests. Interstingly, all files are from July 5, so not appearing on
every run. Why are they not cleaned up and why do we need those files? Would
a RamDirectory not be enough for this?

This is serious, as the files are never cleaned up, they stay alive when the 
test passes, so its not caused by the always failing Solr Suggester tests.

There are also other filenames with .sorted and similar at end.

The slave was taken automatically offline after its RAM-based /tmp (2 GB) was 
filling in <24h). On the Windows Box c:\Users\JenkinsSlave\AppData\Temp 
contained already 60,000 files lik

RE: RefSorter files in /tmp?

[Uwe Schindler]

I checked again: On the windows node C:\Users\JenkinsSlave\AppData\Temp
contained 65000 files with 12 Gigabytes! And I reviewed, they are never
cleaned up, every test run creates new ones!

I'll open issue.

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


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Tuesday, July 10, 2012 8:03 PM
> To: dev@lucene.apache.org
> Subject: RE: RefSorter files in /tmp?
> 
> Hi,
> 
> This is now a serious problem! On the Linux/Windows Jenkins server this
filled
> the 2 GB temp tmpfs in less than 24hrs without cleaning up. We must at
least in
> the test that uses this sorter stuff clean up the temp files.
> Also RefSporter must mark those tempf files as "delete on JVM exit".
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Sunday, July 08, 2012 11:08 AM
> > To: dev@lucene.apache.org
> > Subject: RefSorter files in /tmp?
> >
> > When reviewing my Jenkins installation (because slave was taken
> > offline, which was config bug), I found out that /tmp is filled by
> > Jenkins with the following files:
> >
> > -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> > RefSorter-1839005885812820606.sorted
> > -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> > RefSorter-2799526995307200478.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> > RefSorter-2841491891429925756.sorted
> > -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> > RefSorter-3302954184439492426.sorted
> > -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> > RefSorter-3738422482066276549.sorted
> > -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> > RefSorter-4235756851148318773.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> > RefSorter-4530019493984469514.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> > RefSorter-5245195867837976219.sorted
> > -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> > RefSorter-5977302780601133089.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> > RefSorter-6336186633027300753.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> > RefSorter-6447286760971372233.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> > RefSorter-6532780916605441895.sorted
> > -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> > RefSorter-7247901917320979657.sorted
> > -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> > RefSorter-7796370222379929612.sorted
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> > sort1277839437346448611partition
> > -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> > sort1362726822297484023intermediate
> > -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> > sort1435680293746542872intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> > sort1498884601796138622partition
> > -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> > sort1634015425760928615intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> > sort1954741677243403383partition
> > -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> > sort2203784121687916561intermediate
> > -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> > sort24154414907891444intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> > sort2816986454022083882partition
> > -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> > sort285022281545547041intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> > sort295507558144077223partition
> > -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> > sort3013772538520090513intermediate
> > -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> > sort3297463807520676013intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> > sort3364874175018276528partition
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> > sort3846182021346233750partition
> > -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> > sort4397860673342757974intermediate
> > -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> > sort4474792189525490476intermediate
> > -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> > sort4518448528614283778intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> > sort4756172476965226743partition
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> > sort5416699953867843402partition
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> > sort5558474409634346477partition
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> > sort6281513108922200314partition
> > -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> > sort6639309492804635005intermediate
> > -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> > sort665458777941142partition
> > -rw-r--r-- 1 jenkins  n

RE: RefSorter files in /tmp?

[Uwe Schindler]

Hi,

This is now a serious problem! On the Linux/Windows Jenkins server this
filled the 2 GB temp tmpfs in less than 24hrs without cleaning up. We must
at least in the test that uses this sorter stuff clean up the temp files.
Also RefSporter must mark those tempf files as "delete on JVM exit".

Uwe

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

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, July 08, 2012 11:08 AM
> To: dev@lucene.apache.org
> Subject: RefSorter files in /tmp?
> 
> When reviewing my Jenkins installation (because slave was taken offline,
> which was config bug), I found out that /tmp is filled by Jenkins with the
> following files:
> 
> -rw-r--r-- 1 jenkins  nogroup 12433 Jul  5 21:14
> RefSorter-1839005885812820606.sorted
> -rw-r--r-- 1 jenkins  nogroup 13574 Jul  5 19:26
> RefSorter-2799526995307200478.sorted
> -rw-r--r-- 1 jenkins  nogroup 12600 Jul  5 17:14
> RefSorter-2841491891429925756.sorted
> -rw-r--r-- 1 jenkins  nogroup 11697 Jul  5 19:57
> RefSorter-3302954184439492426.sorted
> -rw-r--r-- 1 jenkins  nogroup 13496 Jul  5 16:30
> RefSorter-3738422482066276549.sorted
> -rw-r--r-- 1 jenkins  nogroup 13781 Jul  5 15:36
> RefSorter-4235756851148318773.sorted
> -rw-r--r-- 1 jenkins  nogroup 12719 Jul  5 18:54
> RefSorter-4530019493984469514.sorted
> -rw-r--r-- 1 jenkins  nogroup 12696 Jul  5 16:04
> RefSorter-5245195867837976219.sorted
> -rw-r--r-- 1 jenkins  nogroup 13879 Jul  5 18:27
> RefSorter-5977302780601133089.sorted
> -rw-r--r-- 1 jenkins  nogroup 12712 Jul  5 21:39
> RefSorter-6336186633027300753.sorted
> -rw-r--r-- 1 jenkins  nogroup 12820 Jul  5 20:30
> RefSorter-6447286760971372233.sorted
> -rw-r--r-- 1 jenkins  nogroup 12105 Jul  5 17:48
> RefSorter-6532780916605441895.sorted
> -rw-r--r-- 1 jenkins  nogroup 13505 Jul  5 20:53
> RefSorter-7247901917320979657.sorted
> -rw-r--r-- 1 jenkins  nogroup 12688 Jul  5 22:10
> RefSorter-7796370222379929612.sorted
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:54
> sort1277839437346448611partition
> -rw-r--r-- 1 jenkins  nogroup  21299752 Jul  5 15:35
> sort1362726822297484023intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300496 Jul  5 17:48
> sort1435680293746542872intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:30
> sort1498884601796138622partition
> -rw-r--r-- 1 jenkins  nogroup  21300869 Jul  5 20:30
> sort1634015425760928615intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:30
> sort1954741677243403383partition
> -rw-r--r-- 1 jenkins  nogroup  21300802 Jul  5 20:53
> sort2203784121687916561intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300493 Jul  5 22:10
> sort24154414907891444intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 22:10
> sort2816986454022083882partition
> -rw-r--r-- 1 jenkins  nogroup  21300111 Jul  5 18:27
> sort285022281545547041intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 18:28
> sort295507558144077223partition
> -rw-r--r-- 1 jenkins  nogroup  21300569 Jul  5 16:30
> sort3013772538520090513intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300574 Jul  5 17:14
> sort3297463807520676013intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:14
> sort3364874175018276528partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:14
> sort3846182021346233750partition
> -rw-r--r-- 1 jenkins  nogroup  21300204 Jul  5 19:26
> sort4397860673342757974intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300050 Jul  5 16:04
> sort4474792189525490476intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300825 Jul  5 18:54
> sort4518448528614283778intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 21:39
> sort4756172476965226743partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 20:53
> sort5416699953867843402partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:26
> sort5558474409634346477partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 17:48
> sort6281513108922200314partition
> -rw-r--r-- 1 jenkins  nogroup  21300155 Jul  5 21:39
> sort6639309492804635005intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 19:57
> sort665458777941142partition
> -rw-r--r-- 1 jenkins  nogroup  21301369 Jul  5 19:57
> sort6973021800616034113intermediate
> -rw-r--r-- 1 jenkins  nogroup  21300341 Jul  5 21:14
> sort7260811068342958052intermediate
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 16:04
> sort852078170643422390partition
> -rw-r--r-- 1 jenkins  nogroup19 Jul  5 15:35
> sort8857722113319559286partition
> 
> The pattern "RefSorter-" I found in Lucene's source code, so it must come
> from tests. Interstingly, all files are from July 5, so not appearing on
> every run. Why are they not cleaned up and why do we need those files?
Would
> a RamDirectory not be enough for this?
> 
> On the Jenkins machine, /tmp is a maximum size 2 GB tmpfs (like on
Solaris),
> so it

Re: Multi-targeting and .Net (WAS Outstanding issues for 3.0.3)

[Christopher Currens]

Thanks Rob.  This was my almost exact solution to this problem, except mine
just modifies the project file and saves a copy named *.35.csproj/sln.  It
got a little more complicated, because I can't support Contrib.Spatial in
.NET 3.5 without some hefty changes I didn't want to do, so there's
(unfortunately) very specific, not really re-usable code, to detect that.
 We also have to add a conditional symbol to each project.  It all works
good enough (read no errors) and generates .NET 3.5 solutions and project
files that can be opened in Visual Studio or built via MSBuild.  I guess my
larger concern is how it can affect the workflow, and since you have some
experience maybe you can answer some of my questions.

What is your workflow with building for all these different frameworks?
 More specifically, do you code for a certain framework and then just run
the tool and hope that the rest compile (this would probably be *my*
"genius" way of doing it)?  There are certainly nice features in .NET 4.0
(Tasks, etc..) that I would prefer to use, so it would make sense to first
write for that target, build the 3.5 projects and try and add conditionals
for that.


Thanks,
Christopher

On Mon, Jul 9, 2012 at 10:21 PM, Rob Vesse  wrote:

> Hey Chris
>
> For multi-targeted stuff with .Net I've built some stuff that uses a small
> executable and NAnt to generate project files which can then be compiled
> with MSBuild.
>
> This technique is used extensively for dotNetRDF where we target up to 6
> different framework profiles for some of our libraries.  Essentially it
> takes a source project, a project template to populate and a resulting
> project name you want to generate.  It also needs a relative path to
> indicate where the source project lives in relation to the target project.
>
> When it runs it goes through the source project file and for every
> Compile/EmbeddedResource item which is directly in that project (I.e. not
> included via a Link) it adds a Link to that item to the target project
> file.
>
> The target project file is literally a stub project file (generated in
> Visual Studio with the target framework set appropriately and it's own
> AssemblyInfo.cs), see
> http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Libraries/core.
> clientprofile/dotNetRDF.ClientProfile.csproj.template?revision=2252&view=ma
> rkup for an example template.
>
> See
> http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Build/ExportCor
> eContentsToTemplate/ for the actual tool
>
> For the NAnt scripts with example usages see
> http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Build/nant/dotn
> etrdf.build?revision=2252&view=markup - Look at the projectgen goals for
> invocation examples and the compile targets for invoking MSBuild on the
> end results.
>
> It may be somewhat clunky but it does work, I'm sure it can be adapted to
> your needs if you're interested - it's all open source
>
> Rob
>
> On 7/9/12 5:51 PM, "Christopher Currens"  wrote:
>
> >I've got it working, compiling and all test passing...The only caveat is
> >that I'm not sure the best way to multi-target.  It doesn't really work on
> >a project level, so you'd have to create two separate projects, one for
> >.NET 4 and the other for 3.5.  To aid me, I wrote a small tool that
> >creates
> >copies of all of the 4.0 projects and solutions to work against the 3.5
> >framework.  Anyone have experience with multi-targeting like this?
> >
> >
> >Thanks,
> >Christopher
> >
> >On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser
> >wrote:
> >
> >>
> >> Have at it.
> >>
> >> 
> >> > Date: Mon, 9 Jul 2012 11:20:06 -0700
> >> > Subject: Re: Outstanding issues for 3.0.3
> >> > From: currens.ch...@gmail.com
> >> > To: lucene-net-...@lucene.apache.org
> >> >
> >> > If it's alright with you, I'll work on it a little bit in that branch,
> >> and
> >> > see what kind of progress I can make, since I have some time right
> >>now.
> >> >
> >> > On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser
> >> >> >wrote:
> >> >
> >> > >
> >> > > I made some progress on 480 - checked into the 3.5 branch, there is
> >> more
> >> > > work to be done we could potentially move it to 3.0.3, but I put it
> >> into
> >> > > 3.5 because I felt that we were closer to having this released, and
> >> adding
> >> > > those changes would add a fair amount of change so close to the
> >> release. I
> >> > > can add it back to the schedule, though I'm mostly just doing
> >> > > administrative work for the next two weeks though - I have a few
> >> things I
> >> > > have to take care of
> >> > >
> >> > > 
> >> > > > Date: Mon, 9 Jul 2012 10:21:42 -0700
> >> > > > Subject: Re: Outstanding issues for 3.0.3
> >> > > > From: currens.ch...@gmail.com
> >> > > > To: lucene-net-...@lucene.apache.org
> >> > > >
> >> > > > The tests should all be fine now. We had a contributer, Luc
> >> Vanlerberghe,
> >> > > > who did a LOT o

[JENKINS] Lucene-Solr-4.x-Linux-Java7-64 - Build # 368 - Failure!

[Policeman Jenkins Server]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java7-64/368/

3 tests failed.
REGRESSION:  
org.apache.lucene.search.suggest.fst.TestSort.testIntermediateMerges

Error Message:
No space left on device

Stack Trace:
java.io.IOException: No space left on device
at 
__randomizedtesting.SeedInfo.seed([5C9D1C84BC63DE13:481D3E6541987742]:0)
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:318)
at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
at java.io.DataOutputStream.write(DataOutputStream.java:107)
at 
org.apache.lucene.search.suggest.fst.Sort$ByteSequencesWriter.write(Sort.java:416)
at 
org.apache.lucene.search.suggest.fst.Sort$ByteSequencesWriter.write(Sort.java:404)
at 
org.apache.lucene.search.suggest.fst.Sort.mergePartitions(Sort.java:337)
at org.apache.lucene.search.suggest.fst.Sort.sort(Sort.java:208)
at 
org.apache.lucene.search.suggest.fst.TestSort.checkSort(TestSort.java:118)
at 
org.apache.lucene.search.suggest.fst.TestSort.testIntermediateMerges(TestSort.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java

[jira] [Commented] (LUCENE-4207) speed up our slowest tests

[Christian Moen (JIRA)]

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

Christian Moen commented on LUCENE-4207:


Thanks, Robert.

It might just be that my system is odd. :)  It would be great to hear what 
others get on their Mac systems.  Mine is a 2010 MacBook Pro with a Core i7 
CPU, 8GB RAM and an 512GB SSD (a rather full one) running Mac OS X Lion.



> speed up our slowest tests
> --
>
> Key: LUCENE-4207
> URL: https://issues.apache.org/jira/browse/LUCENE-4207
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Was surprised to hear from Christian that lucene/solr tests take him 40 
> minutes on a modern mac.
> This is too much. Lets look at the slowest tests and make them reasonable.

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



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

[jira] [Created] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

[David Smiley (JIRA)]

David Smiley created LUCENE-4208:


 Summary: Spatial distance relevancy should use score of 1/distance
 Key: LUCENE-4208
 URL: https://issues.apache.org/jira/browse/LUCENE-4208
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/spatial
Reporter: David Smiley
 Fix For: 4.0


The SpatialStrategy.makeQuery() at the moment uses the distance as the score 
(although some strategies -- TwoDoubles if I recall might not do anything which 
would be a bug).  The distance is a poor value to use as the score because the 
score should be related to relevancy, and the distance itself is inversely 
related to that.  A score of 1/distance would be nice.  Another alternative is 
earthCircumference/2 - distance, although I like 1/distance better.  Maybe use 
a different constant than 1.

Credit: this is Chris Male's idea.

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



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

[jira] [Commented] (LUCENE-4207) speed up our slowest tests

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4207:
-

The list here isn't perfect: I just grepped for [junit4:tophints] and then 
removed anything under 10 seconds.

{noformat}
[junit4:tophints]  92.15s | org.apache.lucene.search.TestNumericRangeQuery64
[junit4:tophints]  50.26s | org.apache.lucene.index.TestIndexWriterWithThreads
[junit4:tophints]  32.30s | org.apache.lucene.util.packed.TestPackedInts
[junit4:tophints]  28.61s | org.apache.lucene.search.TestSloppyPhraseQuery
[junit4:tophints]  26.21s | org.apache.lucene.index.TestIndexWriterExceptions
[junit4:tophints]  32.57s | 
org.apache.lucene.analysis.pattern.TestPatternReplaceCharFilter
[junit4:tophints]  30.73s | org.apache.lucene.analysis.core.TestDuelingAnalyzers
[junit4:tophints]  28.26s | 
org.apache.lucene.analysis.miscellaneous.TestRemoveDuplicatesTokenFilter
[junit4:tophints]  25.49s | org.apache.lucene.analysis.shingle.ShingleFilterTest
[junit4:tophints]  24.60s | org.apache.lucene.analysis.core.TestRandomChains
[junit4:tophints]  21.23s | 
org.apache.lucene.analysis.icu.segmentation.TestICUTokenizer
[junit4:tophints]  15.09s | 
org.apache.lucene.analysis.icu.TestICUTransformFilter
[junit4:tophints]  67.73s | org.apache.lucene.analysis.ja.TestJapaneseTokenizer
[junit4:tophints]  40.69s | org.apache.lucene.analysis.ja.TestJapaneseAnalyzer
[junit4:tophints]  39.52s | org.apache.lucene.analysis.ja.TestExtendedMode
[junit4:tophints]  14.24s | 
org.apache.lucene.analysis.ja.TestJapaneseReadingFormFilter
[junit4:tophints]  24.79s | 
org.apache.lucene.analysis.phonetic.TestPhoneticFilter
[junit4:tophints]  11.21s | 
org.apache.lucene.analysis.phonetic.DoubleMetaphoneFilterTest
[junit4:tophints]  12.97s | 
org.apache.lucene.analysis.cn.smart.TestSmartChineseAnalyzer
[junit4:tophints]  16.69s | org.apache.lucene.analysis.uima.UIMABaseAnalyzerTest
[junit4:tophints]  32.07s | 
org.apache.lucene.benchmark.byTask.TestPerfTasksLogic
[junit4:tophints]  12.21s | org.apache.lucene.benchmark.quality.TestQualityRun
[junit4:tophints]  69.64s | org.apache.lucene.facet.search.SamplingWrapperTest
[junit4:tophints]  60.16s | 
org.apache.lucene.facet.search.AdaptiveAccumulatorTest
[junit4:tophints]  52.27s | 
org.apache.lucene.facet.search.sampling.SamplingAccumulatorTest
[junit4:tophints]  27.02s | 
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyWriter
[junit4:tophints]  24.23s | 
org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy
[junit4:tophints]  46.18s | org.apache.lucene.search.grouping.TestGrouping
[junit4:tophints]  28.63s | 
org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest
[junit4:tophints]  26.83s | 
org.apache.lucene.search.grouping.DistinctValuesCollectorTest
[junit4:tophints]  16.19s | 
org.apache.lucene.search.grouping.GroupFacetCollectorTest
[junit4:tophints]  46.99s | org.apache.lucene.search.join.TestJoinUtil
[junit4:tophints]  17.31s | org.apache.lucene.search.join.TestBlockJoin
[junit4:tophints]  13.66s | org.apache.lucene.index.memory.MemoryIndexTest
[junit4:tophints]  19.02s | 
org.apache.lucene.index.TestBalancedSegmentMergePolicy
[junit4:tophints]  13.64s | org.apache.lucene.queries.ChainedFilterTest
[junit4:tophints]  11.21s | org.apache.lucene.queries.TestCustomScoreQuery
[junit4:tophints]  10.08s | org.apache.lucene.queryparser.xml.TestParser
[junit4:tophints]  11.21s | 
org.apache.lucene.sandbox.queries.TestSlowCollationMethods
[junit4:tophints]  21.29s | 
org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy
[junit4:tophints]  20.57s | org.apache.lucene.spatial.bbox.TestBBoxStrategy
[junit4:tophints]  20.44s | 
org.apache.lucene.spatial.vector.TestTwoDoublesStrategy
[junit4:tophints]  33.48s | org.apache.lucene.search.suggest.fst.TestSort
[junit4:tophints]  16.57s | org.apache.lucene.search.spell.TestSpellChecker
[junit4:tophints]  11.49s | 
org.apache.lucene.search.suggest.fst.FSTCompletionTest
[junit4:tophints] 138.08s | org.apache.solr.TestRandomFaceting
[junit4:tophints] 126.99s | org.apache.solr.cloud.BasicDistributedZkTest
[junit4:tophints]  87.73s | org.apache.solr.cloud.OverseerTest
[junit4:tophints]  86.10s | org.apache.solr.cloud.FullSolrCloudTest
[junit4:tophints]  78.40s | org.apache.solr.search.TestStressRecovery
[junit4:tophints]  48.66s | org.apache.solr.client.solrj.TestLBHttpSolrServer
[junit4:tophints]  17.39s | 
org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
[junit4:tophints]  17.15s | 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest
[junit4:tophints]  15.30s | 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit4:tophints]  13.11s | org.apache.solr.client.solrj.TestBatchUpdate
[junit4:tophints]  19.05s | 
org.apache.solr.handler.clustering.DistributedClusteringComponentTest
[junit4:tophints]  12.08s | 
org.apache.solr.handler

[jira] [Created] (LUCENE-4207) speed up our slowest tests

[Robert Muir (JIRA)]

Robert Muir created LUCENE-4207:
---

 Summary: speed up our slowest tests
 Key: LUCENE-4207
 URL: https://issues.apache.org/jira/browse/LUCENE-4207
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir


Was surprised to hear from Christian that lucene/solr tests take him 40 minutes 
on a modern mac.

This is too much. Lets look at the slowest tests and make them reasonable.

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



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

[jira] [Commented] (LUCENE-4203) Add IndexWriter.tryDeleteDocument, to delete by document id when possible

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4203:
---

Hi Mike,

the user does not see any impl class (we should actually hide SegmentReader 
again), user only sees AtomicReader. NRT should subclass (the internal) 
SegmentReader and after that the code can simply check the incoming Reader if 
it is NRTReader. If not it say "I cannot delete documents by id with non-NRT 
IndexWriter". Nothing more, plain simple. Please do not make anything of these 
crazy internal classes public!

Uwe

> Add IndexWriter.tryDeleteDocument, to delete by document id when possible
> -
>
> Key: LUCENE-4203
> URL: https://issues.apache.org/jira/browse/LUCENE-4203
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Michael McCandless
> Attachments: LUCENE-4203.patch
>
>
> Spinoff from LUCENE-4069.
> In that use case, where the app needs to first lookup a document, then
> call updateDocument, it's wasteful today because the relatively costly
> lookup (by a primary key field, eg "id") is done twice.
> But, since you already resolved the PK to docID on the first lookup,
> it would be nice to then delete by that docID and then you can call
> addDocument instead.
> So I worked out a rough start at this, by adding
> IndexWriter.tryDeleteDocument.  It'd be a very expert API: it takes a
> SegmentInfo (referencing the segment that contains the docID), and as
> long as that segment hasn't yet been merged away, it will mark the
> document for deletion and return true (success).  If it has been
> merged away it returns false and the app must then delete-by-term.  It
> only works if the writer is in NRT mode (ie you've opened an NRT
> reader).
> In LUCENE-4069 using tryDeleteDocument gave a ~20% net speedup.
> I think tryDeleteDocument would also be useful when Solr "updates" a
> document by loading all stored fields, changing them, and calling
> updateDocument.

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



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

[jira] [Commented] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4206:
-

I have no idea how to review (its all black magic to me). I'm just glad Uwe 
didn't give up!

> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4206.patch, LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Updated] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4206:
--

Attachment: LUCENE-4206.patch

Small de-spaghettization of the readClass method (inlined).

I think it's ready to commit for robert, so he cann add his other checks.

> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4206.patch, LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Commented] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3460:
---

Added a makepath cmd as well - chime in if you have any useful ideas we should 
add. I'm going to commit this first iteration shortly.

Part of this change allows you to setup collection to config links before solr 
even starts up in cloud mode - if on startup, a collection node with a given 
config already set is seen, it is simply used as is.

This should provide the flexibility of one of the more complicated cases that 
came up on the mailing list a couple months back.

> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Comment Edited] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-3460 at 7/10/12 4:11 PM:


I've added example/cloud-scripts

In that is zkcli.bat and zkcli.sh - both of which allow you to pass cmd line 
params.

{noformat}
usage: ZkCLI
 -c,--collectionfor linkconfig: name of the collection
 -cmd   cmd to run: bootstrap, upconfig, downconfig, 
linkconfig,
 makepath, clear
 -d,--confdir   for upconfig: a directory of configuration files
 -h,--help   bring up this help page
 -n,--confname  for upconfig, linkconfig: name of the config set
 -r,--runzk run zk internally by passing the solr run port -
 only for clusters on one machine (tests, dev)
 -s,--solrhome  for bootstrap, runzk: solrhome location
 -z,--zkhostZooKeeper host address
{noformat}

  was (Author: markrmil...@gmail.com):
I've added example/cloud-scripts

In that is zkcli.bat and zkcli.sh - both of which allow you to pass cmd line 
params.

{noformat}
usage: ZkCLI
 -c,--collectionfor linkconfig: name of the collection
 -cmd   cmd to run: bootstrap, upconfig, downconfig, 
linkconfig,
 clear
 -d,--confdir   for upconfig: a directory of configuration files
 -h,--help   bring up this help page
 -n,--confname  for upconfig, linkconfig: name of the config set
 -r,--runzk run zk internally by passing the solr run port -
 only for clusters on one machine (tests, dev)
 -s,--solrhome  for bootstrap, runzk: solrhome location
 -z,--zkhostZooKeeper host address
{noformat}
  
> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Comment Edited] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-3460 at 7/10/12 4:06 PM:


I've added example/cloud-scripts

In that is zkcli.bat and zkcli.sh - both of which allow you to pass cmd line 
params.

{noformat}
usage: ZkCLI
 -c,--collectionfor linkconfig: name of the collection
 -cmd   cmd to run: bootstrap, upconfig, downconfig, 
linkconfig,
 clear
 -d,--confdir   for upconfig: a directory of configuration files
 -h,--help   bring up this help page
 -n,--confname  for upconfig, linkconfig: name of the config set
 -r,--runzk run zk internally by passing the solr run port -
 only for clusters on one machine (tests, dev)
 -s,--solrhome  for bootstrap, runzk: solrhome location
 -z,--zkhostZooKeeper host address
{noformat}

  was (Author: markrmil...@gmail.com):
I've added example/cloud-scripts

In that is zkcli.bat and zkcli.sh - both of which allow you to pass cmd line 
params.

{noformat}
usage: ZkCLI
 -c,--collectionfor linkconfig: name of the collection
 -cmd   cmd to run: bootstrap, upconfig, linkconfig,
 clear
 -d,--confdir   for upconfig: a directory of configuration files
 -h,--help   bring up this help page
 -n,--confname  for upconfig, linkconfig: name of the config set
 -r,--runzk run zk internally by passing the solr run port -
 only for clusters on one machine (tests, dev)
 -s,--solrhome  for bootstrap, runzk: solrhome location
 -z,--zkhostZooKeeper host address
{noformat}
  
> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Commented] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3460:
---

I've added example/cloud-scripts

In that is zkcli.bat and zkcli.sh - both of which allow you to pass cmd line 
params.

{noformat}
usage: ZkCLI
 -c,--collectionfor linkconfig: name of the collection
 -cmd   cmd to run: bootstrap, upconfig, linkconfig,
 clear
 -d,--confdir   for upconfig: a directory of configuration files
 -h,--help   bring up this help page
 -n,--confname  for upconfig, linkconfig: name of the config set
 -r,--runzk run zk internally by passing the solr run port -
 only for clusters on one machine (tests, dev)
 -s,--solrhome  for bootstrap, runzk: solrhome location
 -z,--zkhostZooKeeper host address
{noformat}

> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Commented] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3460:
---

I'm ready to commit soon. I just added the download config to dir option. Don't 
have a reverse for the full solr.xml bootstrap, but then can come later as a 
new feature when I get the time.

I'll commit SOLR-3609 with this.

> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Commented] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4206:
---

And your copypaste of the code is not referring to the actual recursion code, 
this one only collects all methods/fields - and that *must* visit all methods, 
otherwise it would not work - it is a unchanged replacement for the ineffective 
code of the original "ClassNode extends ClassVisitor" of ASM 4.0. Maybe you 
shoud apply the patch first :-)

> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Commented] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4206:
---

We must do this on top-level, otherwise it's different to what I did before? 
When it then dives to superclasses/interfaces, it assumes that the original 
compiler already did the check.

> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Updated] (SOLR-3608) Spellcecker: String index out of range: -1

[James Dyer (JIRA)]

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

James Dyer updated SOLR-3608:
-

 Priority: Minor  (was: Blocker)
Affects Version/s: 4.0

Changing to "minor" as this is just a manifestation with a longstanding 
limitation of the "collate" functionality.  But we should improve it, so 
leaving the issue open and adding 4.0 as an "affected" version.

> Spellcecker: String index out of range: -1
> --
>
> Key: SOLR-3608
> URL: https://issues.apache.org/jira/browse/SOLR-3608
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.6, 4.0
> Environment: Ubuntu 11.10 x64
> java version "1.7.0_05"
> Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
>Reporter: dalius
>Priority: Minor
>
> Spell check component throws StringIndexOutOfBoundsException on multiterm 
> search.
> Stack trace: 
> {code}
> SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: 
> -1
>   at 
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:789)
>   at java.lang.StringBuilder.replace(StringBuilder.java:266)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:128)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:156)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> ...
> {code}
> I have dug some debug info at org.apache.solr.spelling.SpellCheckCollator:69
> {code}
>   String collationQueryStr = getCollation(originalQuery, 
> possibility.getCorrections());
> {code}
> originalQuery is "casa saja"
> possibility is "rank=0 casa>cal (-1) saja>sala (-1) casa 
> saja>casa de (-1)"
> The replace function fails on 3rd correction "casa saja>casa de (-1)". I hope 
> this makes any sense.

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



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

[jira] [Commented] (SOLR-3608) Spellcecker: String index out of range: -1

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-3608:
--

I'm not sure what your QueryConverter is supposed to do as I'm not at all 
familiar with how you need to set up the spellchecker to use it for autosuggest 
(as it appears you're doing).  You should probably re-post a summary of all 
this one the solr-user mailing list to get more help.  (you might also want to 
see this overview:  
http://stackoverflow.com/questions/10547438/solr-returns-only-one-collation-for-suggester-component)

My understanding is that the "collate" functionality was only designed to work 
with "normal" query converters.  So if you throw shingled phrases at it from a 
custom query converter all bets are off.  I also think when people use shingles 
like this it is because they are trying to work around the limitations of 
"collate", and not use it at all.  But many of these limitations have been 
removed, particularly with the addition of "maxCollationTries".  But see 
SOLR-3240, which aims in improving the performance of "maxCollationTries" so 
that it would be more useful in an autosuggest situation.

I think for the purposes of this JIRA issue, we need to make the spell check 
collator more resilient when users throw funny things at it, like in this case. 
 At the least it shouldn't throw an exception.  Maybe it could log a warning in 
some cases and others be more capable and actually produce a good collation.  
In the "casa saja" case, it could just throw out the 3rd replacement and go on 
with life.

> Spellcecker: String index out of range: -1
> --
>
> Key: SOLR-3608
> URL: https://issues.apache.org/jira/browse/SOLR-3608
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.6
> Environment: Ubuntu 11.10 x64
> java version "1.7.0_05"
> Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
>Reporter: dalius
>Priority: Blocker
>
> Spell check component throws StringIndexOutOfBoundsException on multiterm 
> search.
> Stack trace: 
> {code}
> SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: 
> -1
>   at 
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:789)
>   at java.lang.StringBuilder.replace(StringBuilder.java:266)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:128)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:156)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> ...
> {code}
> I have dug some debug info at org.apache.solr.spelling.SpellCheckCollator:69
> {code}
>   String collationQueryStr = getCollation(originalQuery, 
> possibility.getCorrections());
> {code}
> originalQuery is "casa saja"
> possibility is "rank=0 casa>cal (-1) saja>sala (-1) casa 
> saja>casa de (-1)"
> The replace function fails on 3rd correction "casa saja>casa de (-1)". I hope 
> this makes any sense.

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



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

[jira] [Commented] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4206:
-

{code}
+public MethodVisitor visitMethod(int access, String name, String desc, 
String signature, String[] exceptions) {
+  final Method m = new Method(name, desc);
{code}

Umm... you just stack all methods without considering their access flags?


> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Updated] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4206:
--

Attachment: LUCENE-4206.patch

Rewrite of the algorithm to also check superclasses and interfaces. The 
overhead approx doubles the time needed before, but is more thorough.

> Allow check-forbidden-apis to also investigate calls to subclasses of 
> forbidden APIs
> 
>
> Key: LUCENE-4206
> URL: https://issues.apache.org/jira/browse/LUCENE-4206
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4206.patch
>
>
> Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
> of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
> investigation of system classes from classloader on demand.

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



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

[jira] [Updated] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-3460:
--

Attachment: SOLR-3460.patch

> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Commented] (SOLR-3460) Improve cmd line config bootstrap tool.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3460:
---

Here is a patch of my current work. A few tweaks to go. Also need to implement 
the zk -> filesystem reverse feature still. Close though - and some tests.

Includes SOLR-3609 (the new scripts count on it).
Also includes SOLR-3612.

> Improve cmd line config bootstrap tool.
> ---
>
> Key: SOLR-3460
> URL: https://issues.apache.org/jira/browse/SOLR-3460
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-3460.patch, SOLR-3460.patch
>
>
> Improve cmd line tool for bootstrapping config sets. Rather than take a 
> config set name and directory, make it work like -Dboostrap_conf=true and 
> read solr.xml to find config sets. Config sets will be named after the 
> collection and auto linked to the identically named collection.

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



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

[jira] [Resolved] (SOLR-2616) Include jdk14 logging configuration file

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-2616.
---

Resolution: Fixed

> Include jdk14 logging configuration file
> 
>
> Key: SOLR-2616
> URL: https://issues.apache.org/jira/browse/SOLR-2616
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-2616.patch, SOLR-2616_jdk14logging_setup.patch
>
>
> The /example/ Jetty Solr configuration should include a basic logging 
> configuration file.  Looking at this wiki page: 
> http://wiki.apache.org/solr/LoggingInDefaultJettySetup  I am creating this 
> patch. 

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



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

[jira] [Resolved] (SOLR-2616) Include jdk14 logging configuration file

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-2616.
---

   Resolution: Cannot Reproduce
Fix Version/s: 5.0

Committed - lets make further improvements in new issues.

> Include jdk14 logging configuration file
> 
>
> Key: SOLR-2616
> URL: https://issues.apache.org/jira/browse/SOLR-2616
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-2616.patch, SOLR-2616_jdk14logging_setup.patch
>
>
> The /example/ Jetty Solr configuration should include a basic logging 
> configuration file.  Looking at this wiki page: 
> http://wiki.apache.org/solr/LoggingInDefaultJettySetup  I am creating this 
> patch. 

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



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

[jira] [Reopened] (SOLR-2616) Include jdk14 logging configuration file

[Mark Miller (JIRA)]

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

Mark Miller reopened SOLR-2616:
---


> Include jdk14 logging configuration file
> 
>
> Key: SOLR-2616
> URL: https://issues.apache.org/jira/browse/SOLR-2616
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-2616.patch, SOLR-2616_jdk14logging_setup.patch
>
>
> The /example/ Jetty Solr configuration should include a basic logging 
> configuration file.  Looking at this wiki page: 
> http://wiki.apache.org/solr/LoggingInDefaultJettySetup  I am creating this 
> patch. 

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



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

[jira] [Resolved] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen resolved LUCENE-4201.


Resolution: Fixed

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[jira] [Commented] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen commented on LUCENE-4201:


Committed revision 1359645 on {{branch_4x}}

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 539 - Failure!

[Policeman Jenkins Server]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/539/

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest.testDistributed

Error Message:
Server at http://localhost:55281/example/core0 returned non ok status:500, 
message:Server Error

Stack Trace:
org.apache.solr.common.SolrException: Server at 
http://localhost:55281/example/core0 returned non ok status:500, message:Server 
Error
at 
__randomizedtesting.SeedInfo.seed([4B78A024F9DC07F9:244A17CC88645996]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:376)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:182)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
at 
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest.testDistributed(MultiCoreExampleJettyTest.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtestin

[jira] [Commented] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen commented on LUCENE-4201:


Added {{svn:eol-style native}} to {{trunk}} with revision 1359632.

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[jira] [Updated] (LUCENE-3877) Lucene should not call System.out.println

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-3877:


Attachment: LUCENE-3877.patch

Here's a patch implementing this check with LUCENE-4202. It excludes any test 
code, but I didnt add any exceptions for legitimate command-line tools.

Current list looks like:
{noformat}
check-system-out:
[forbidden-apis] Reading inline API signatures...
[forbidden-apis] Reading API signatures: 
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/system-out.txt
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.HyphenationTree 
(HyphenationTree.java:467)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.PatternParser 
(PatternParser.java:408)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.PatternParser 
(PatternParser.java:412)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.PatternParser 
(PatternParser.java:416)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.TernaryTree 
(TernaryTree.java:637)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.TernaryTree 
(TernaryTree.java:638)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.TernaryTree 
(TernaryTree.java:640)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.TernaryTree 
(TernaryTree.java:658)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.TernaryTree 
(TernaryTree.java:659)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in 
org.apache.lucene.analysis.compound.hyphenation.TernaryTree 
(TernaryTree.java:660)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:292)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:302)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:312)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:326)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:336)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:346)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:356)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:366)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:376)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:386)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:395)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:404)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.KStemmer (KStemmer.java:413)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.PorterStemmer 
(PorterStemmer.java:529)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.PorterStemmer 
(PorterStemmer.java:534)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.en.PorterStemmer 
(PorterStemmer.java:542)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.hunspell.HunspellStemmer 
(HunspellStemmer.java:314)
[forbidden-apis] Forbidden field access: java.lang.System#out
[forbidden-apis]   in org.apache.lucene.analysis.hunspell.HunspellStemmer 
(HunspellStemmer.java:320)
[forbidden-apis] Forbidden field a

[jira] [Commented] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen commented on LUCENE-4201:


Committed revision 1359613 on {{trunk}}

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[jira] [Commented] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen commented on LUCENE-4201:


Thanks, Robert.  Attached final patch with CHANGES.txt details.

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[jira] [Updated] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen updated LUCENE-4201:
---

Attachment: LUCENE-4201.patch

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[jira] [Assigned] (LUCENE-4201) Add Japanese character filter to normalize iteration marks

[Christian Moen (JIRA)]

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

Christian Moen reassigned LUCENE-4201:
--

Assignee: Christian Moen

> Add Japanese character filter to normalize iteration marks
> --
>
> Key: LUCENE-4201
> URL: https://issues.apache.org/jira/browse/LUCENE-4201
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.0, 5.0
>Reporter: Christian Moen
>Assignee: Christian Moen
> Attachments: LUCENE-4201.patch, LUCENE-4201.patch, LUCENE-4201.patch, 
> LUCENE-4201.patch, LUCENE-4201.patch
>
>
> For some applications it might be useful to normalize kanji and kana 
> iteration marks such as 々, ゞ, ゝ, ヽ and ヾ to make sure they are treated 
> uniformly.

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



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

[jira] [Commented] (LUCENE-4202) allow check-forbidden-apis to look for fields too

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4202:
-

{quote}
Fixed (hopefully) the problem with ANT's .lib/ folder. The task now only uses 
system classloader and its own one, while the own one is used in preference 
(which violates spec); but is much better for our checks (which do not rely on 
JVM class loading semantics).
{quote}

{quote}
I think this is ready to commit, Robert can you check with Apache RAT installed?
{quote}

I checked: it works!

> allow check-forbidden-apis to look for fields too
> -
>
> Key: LUCENE-4202
> URL: https://issues.apache.org/jira/browse/LUCENE-4202
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4202.patch, LUCENE-4202.patch
>
>
> Currently this supports classes and methods, but there are some deprecated 
> fields in the java API, it would be nice to check for those, too.

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



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

[jira] [Resolved] (LUCENE-4202) allow check-forbidden-apis to look for fields too

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-4202.
---

Resolution: Fixed

Committed trunk revision: 1359590
Backported 3.x revision: 1359592

> allow check-forbidden-apis to look for fields too
> -
>
> Key: LUCENE-4202
> URL: https://issues.apache.org/jira/browse/LUCENE-4202
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4202.patch, LUCENE-4202.patch
>
>
> Currently this supports classes and methods, but there are some deprecated 
> fields in the java API, it would be nice to check for those, too.

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



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

[jira] [Commented] (LUCENE-4202) allow check-forbidden-apis to look for fields too

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4202:
---

For the inheritance problem I opened LUCENE-4206 (I think I have a suitable 
solution). But this issue must be committed first, which I will do now.

> allow check-forbidden-apis to look for fields too
> -
>
> Key: LUCENE-4202
> URL: https://issues.apache.org/jira/browse/LUCENE-4202
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4202.patch, LUCENE-4202.patch
>
>
> Currently this supports classes and methods, but there are some deprecated 
> fields in the java API, it would be nice to check for those, too.

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



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

[jira] [Created] (LUCENE-4206) Allow check-forbidden-apis to also investigate calls to subclasses of forbidden APIs

[Uwe Schindler (JIRA)]

Uwe Schindler created LUCENE-4206:
-

 Summary: Allow check-forbidden-apis to also investigate calls to 
subclasses of forbidden APIs
 Key: LUCENE-4206
 URL: https://issues.apache.org/jira/browse/LUCENE-4206
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/build
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.0


Followup for LUCENE-4202: I think I found a solution, that only adds overhead 
of parsing all classes in FileSet 2 times (instead of one time) and dynamic 
investigation of system classes from classloader on demand.

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



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

[jira] [Updated] (LUCENE-4202) allow check-forbidden-apis to look for fields too

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4202:
--

Fix Version/s: 4.0

> allow check-forbidden-apis to look for fields too
> -
>
> Key: LUCENE-4202
> URL: https://issues.apache.org/jira/browse/LUCENE-4202
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-4202.patch, LUCENE-4202.patch
>
>
> Currently this supports classes and methods, but there are some deprecated 
> fields in the java API, it would be nice to check for those, too.

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



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

[jira] [Comment Edited] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-4204 at 7/10/12 10:11 AM:
-

This is not a problem of Lucene itsself, as the Android ApkBuilder component is 
buggy and excludes META-INF completely from the resulting APK (although Android 
supports SPI and other parts of Java 6).

There are several workaround possible, but none of them is fixed in the 
official Anbdroid SDK, you have to use a customized Maven plugin 
[https://github.com/pa314159/maven-android-plugin] or patch ApkBuilder.java to 
not exclude META-INF 
[http://androidxref.com/source/xref/sdk/sdkmanager/libs/sdklib/src/com/android/sdklib/build/ApkBuilder.java]:

{noformat}
 public static boolean checkFolderForPackaging(String folderName) {
   return folderName.equalsIgnoreCase("CVS") == false &&
  folderName.equalsIgnoreCase(".svn") == false &&
  folderName.equalsIgnoreCase("SCCS") == false &&
- folderName.equalsIgnoreCase("META-INF") == false &&
  folderName.startsWith("_") == false;
 }
{noformat}

  was (Author: thetaphi):
This is not a problem, as the Android ApkBuilder component is buggy and 
excludes META-INF completely from the resulting APK (although Android supports 
SPI and other parts of Java 6).

There are several workaround possible, but none of them is fixed in the 
official Anbdroid SDK, you have to use a customized Maven plugin 
[https://github.com/pa314159/maven-android-plugin] or patch ApkBuilder.java to 
not exclude META-INF 
[http://androidxref.com/source/xref/sdk/sdkmanager/libs/sdklib/src/com/android/sdklib/build/ApkBuilder.java]:

{noformat}
 public static boolean checkFolderForPackaging(String folderName) {
   return folderName.equalsIgnoreCase("CVS") == false &&
  folderName.equalsIgnoreCase(".svn") == false &&
  folderName.equalsIgnoreCase("SCCS") == false &&
- folderName.equalsIgnoreCase("META-INF") == false &&
  folderName.startsWith("_") == false;
 }
{noformat}
  
> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Assignee: Uwe Schindler
>Priority: Minor
>  Labels: error, newbie
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Resolved] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-4204.
---

   Resolution: Not A Problem
Fix Version/s: (was: 3.6)
 Assignee: Uwe Schindler

This is not a problem, as the Android ApkBuilder component is buggy and 
excludes META-INF completely from the resulting APK (although Android supports 
SPI and other parts of Java 6).

There are several workaround possible, but none of them is fixed in the 
official Anbdroid SDK, you have to use a customized Maven plugin 
[https://github.com/pa314159/maven-android-plugin] or patch ApkBuilder.java to 
not exclude META-INF 
[http://androidxref.com/source/xref/sdk/sdkmanager/libs/sdklib/src/com/android/sdklib/build/ApkBuilder.java]:

{noformat}
 public static boolean checkFolderForPackaging(String folderName) {
   return folderName.equalsIgnoreCase("CVS") == false &&
  folderName.equalsIgnoreCase(".svn") == false &&
  folderName.equalsIgnoreCase("SCCS") == false &&
- folderName.equalsIgnoreCase("META-INF") == false &&
  folderName.startsWith("_") == false;
 }
{noformat}

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Assignee: Uwe Schindler
>Priority: Minor
>  Labels: error, newbie
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4204:
---

See also: http://code.google.com/p/maven-android-plugin/issues/detail?id=97

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4204:
---

The above link shows the reason:

{quote}
The META-INF folder is deliberately excluded from the APK by ApkBuilder; the 
only comment in ApkBuilder.java is "we need to exclude some other folder (like 
/META-INF)" but there is no other explanation.
{quote}

So you have to maybe add the missing resources directly to your APK using the 
ZIP/JAR ant task after ApkBuilder is finished.

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Comment Edited] (SOLR-3608) Spellcecker: String index out of range: -1

[dalius (JIRA)]

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

dalius edited comment on SOLR-3608 at 7/10/12 9:46 AM:
---

My bad. I told that there are no query converter, but actually there is one...
{code}
public class MultiTermQueryConverter extends SpellingQueryConverter {
private static Joiner space = Joiner.on(' ');

@Override
public Collection convert(String original) {
if (original == null) { // this can happen with q.alt = and no query
return Collections.emptyList();
}
Collection convert = super.convert(original);
if(convert.size() > 1){
String joined = space.join(convert);
int min = 100, max = 0;
for(Token t : convert){
   min = Math.min(min, t.startOffset());
   max = Math.max(max, t.endOffset());
}
convert.add(new Token(joined, min, max));
}
return convert;
}
}
{code}

{code}
  

  suggest
  org.apache.solr.spelling.suggest.Suggester
  org.apache.solr.spelling.suggest.tst.TSTLookup
  
  suggest  
  0.1
  true
  false


  
{code}

It adds additional token that is a join of all tokens separating with space. 
Shouldn't it just ignore the token that can not be replaced instead?

Sorry for that.

  was (Author: dalius_semantico):
My bad. I told that there are no query converter, but actually there is 
one...
{code}
public class MultiTermQueryConverter extends SpellingQueryConverter {
private static Joiner space = Joiner.on(' ');

@Override
public Collection convert(String original) {
if (original == null) { // this can happen with q.alt = and no query
return Collections.emptyList();
}
Collection convert = super.convert(original);
if(convert.size() > 1){
String joined = space.join(convert);
int min = 100, max = 0;
for(Token t : convert){
   min = Math.min(min, t.startOffset());
   max = Math.max(max, t.endOffset());
}
convert.add(new Token(joined, min, max));
}
return convert;
}
}
{code}

{code}
  

  suggest
  org.apache.solr.spelling.suggest.Suggester
  org.apache.solr.spelling.suggest.tst.TSTLookup
  
  suggest  
  0.1
  true
  false


  
{code}

it adds additional token that is a join of all tokens separating with space. 
Shouldn't it just ignore the token that can not be replaces instead?

Sorry for that.
  
> Spellcecker: String index out of range: -1
> --
>
> Key: SOLR-3608
> URL: https://issues.apache.org/jira/browse/SOLR-3608
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.6
> Environment: Ubuntu 11.10 x64
> java version "1.7.0_05"
> Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
>Reporter: dalius
>Priority: Blocker
>
> Spell check component throws StringIndexOutOfBoundsException on multiterm 
> search.
> Stack trace: 
> {code}
> SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: 
> -1
>   at 
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:789)
>   at java.lang.StringBuilder.replace(StringBuilder.java:266)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:128)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:156)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> ...
> {code}
> I have dug some debug info at org.apache.solr.spelling.SpellCheckCollator:69
> {code}
>   String collationQueryStr = getCollation(originalQuery, 
> possibility.getCorrections());
> {code}
> originalQuery is "casa saja"
> possibility is "rank=0 casa>cal (-1) saja>sala (-1) casa 
> saja>casa de (-1)"
> The replace function fails on 3rd correction "casa saja>casa de (-1)". I hope 
> this makes any sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/sec

[jira] [Commented] (SOLR-3608) Spellcecker: String index out of range: -1

[dalius (JIRA)]

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

dalius commented on SOLR-3608:
--

My bad. I told that there are no query converter, but actually there is one...
{code}
public class MultiTermQueryConverter extends SpellingQueryConverter {
private static Joiner space = Joiner.on(' ');

@Override
public Collection convert(String original) {
if (original == null) { // this can happen with q.alt = and no query
return Collections.emptyList();
}
Collection convert = super.convert(original);
if(convert.size() > 1){
String joined = space.join(convert);
int min = 100, max = 0;
for(Token t : convert){
   min = Math.min(min, t.startOffset());
   max = Math.max(max, t.endOffset());
}
convert.add(new Token(joined, min, max));
}
return convert;
}
}
{code}

{code}
  

  suggest
  org.apache.solr.spelling.suggest.Suggester
  org.apache.solr.spelling.suggest.tst.TSTLookup
  
  suggest  
  0.1
  true
  false


  
{code}

it adds additional token that is a join of all tokens separating with space. 
Shouldn't it just ignore the token that can not be replaces instead?

Sorry for that.

> Spellcecker: String index out of range: -1
> --
>
> Key: SOLR-3608
> URL: https://issues.apache.org/jira/browse/SOLR-3608
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.6
> Environment: Ubuntu 11.10 x64
> java version "1.7.0_05"
> Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
>Reporter: dalius
>Priority: Blocker
>
> Spell check component throws StringIndexOutOfBoundsException on multiterm 
> search.
> Stack trace: 
> {code}
> SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: 
> -1
>   at 
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:789)
>   at java.lang.StringBuilder.replace(StringBuilder.java:266)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:128)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:156)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> ...
> {code}
> I have dug some debug info at org.apache.solr.spelling.SpellCheckCollator:69
> {code}
>   String collationQueryStr = getCollation(originalQuery, 
> possibility.getCorrections());
> {code}
> originalQuery is "casa saja"
> possibility is "rank=0 casa>cal (-1) saja>sala (-1) casa 
> saja>casa de (-1)"
> The replace function fails on 3rd correction "casa saja>casa de (-1)". I hope 
> this makes any sense.

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



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

[jira] [Comment Edited] (LUCENE-4204) Error with Codec on android

[ROULLAND Bruno (JIRA)]

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

ROULLAND Bruno edited comment on LUCENE-4204 at 7/10/12 9:37 AM:
-

I have used official jar but i think android classloader don't expose resource 
files inside.

Edit: yes, it could be the reason, i will also try with a more recent version 
of android

  was (Author: moritan):
I have used official jar but i think android classloader don't expose 
resource files inside.


  
> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4204) Error with Codec on android

[ROULLAND Bruno (JIRA)]

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

ROULLAND Bruno commented on LUCENE-4204:


I have used official jar but i think android classloader don't expose resource 
files inside.



> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4204:
---

Maybe thats your problem: 
[http://stackoverflow.com/questions/5760607/using-serviceloader-on-android]

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4204:
---

Did you try to use the official lucene-core.jar? If you build the code from 
source using Android build tools, you have to make sure that your ANT/Eclipse 
project correctly adds the resource folders (also used by Analyzers and a lot 
of other stuff). Lucene heavily depends on resource files placed inside the 
classpath/JAR files (like stopword files, and SPI META-INF files), so they must 
also appear in your DEX files somehow.

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4204) Error with Codec on android

[ROULLAND Bruno (JIRA)]

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

ROULLAND Bruno commented on LUCENE-4204:


Sorry for the wrong priority.

I will try to compile src in  the android project and give the result.
Thanks for the help. 
 

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Updated] (LUCENE-4204) Error with Codec on android

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4204:
--

Priority: Minor  (was: Blocker)

Android is not a supported platform so lowering priority.

> Error with Codec on android
> ---
>
> Key: LUCENE-4204
> URL: https://issues.apache.org/jira/browse/LUCENE-4204
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.0
> Environment: Android 
>Reporter: ROULLAND Bruno
>Priority: Minor
>  Labels: error, newbie
> Fix For: 3.6
>
>
> Hello, with the latest version of Lucene 4.0, I have an error :
> "Codec with name ‘Lucene40′ does not exist.
> You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> []"
> Classpath is OK, but the method for initialise Codec don't work. 
> This error does not append with Lucene 3.6.

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



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

[jira] [Commented] (LUCENE-4202) allow check-forbidden-apis to look for fields too

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4202:
---

bq. Separately we could open an issue to deal with this virtual problem? It 
just means our checker isn't as thorough as it is, but none of our 
checkers/tests are perfect.

Yes it is not as thorough for things like Throwable.printStackTrace(), but for 
the JVM's deprecated list, we should still catch almost all, as the deprecated 
list in the JVM is complete (it also should list subclasses - if method is 
overridded).

For the original checks we did at beginning (encoding, locale,... problems), 
this was also thorough enough, as we listed all calls that may be used. If a 
custom subclass in Lucene code would subclass this system class and modify a 
"forbidden method", the "super" call would trigger the violation report.

I think this is ready to commit, Robert can you check with Apache RAT installed?

> allow check-forbidden-apis to look for fields too
> -
>
> Key: LUCENE-4202
> URL: https://issues.apache.org/jira/browse/LUCENE-4202
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Uwe Schindler
> Attachments: LUCENE-4202.patch, LUCENE-4202.patch
>
>
> Currently this supports classes and methods, but there are some deprecated 
> fields in the java API, it would be nice to check for those, too.

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



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

[jira] [Commented] (SOLR-3585) processing updates in multiple threads

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-3585:


bq. I think it would be nicer if this ...

David, please let me know what issues with current design you see?

>From my perspective UpdateRequestProcessorFactory's way advantage is 
>pluggability, you can cofigure one or several of them, and then you are able 
>to choose whether to use it or not, even in runtime e.g. cient can send small 
>updates into regular chain, and choose parallel chain for huge bulks, or 
>failover during spike periods etc. 

ContentStreamHandlerBase.handleRequestBody() is had to be single threaded. Even 
it creates several processor chains (which are single threaded "prototypes"), 
it's hard to separate content stream onto substreams per several processing 
threads. Even it's possible how to make sure that this distribution is done 
evenly? 

> processing updates in multiple threads
> --
>
> Key: SOLR-3585
> URL: https://issues.apache.org/jira/browse/SOLR-3585
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.0
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-3585.patch, SOLR-3585.patch, multithreadupd.patch, 
> report.tar.gz
>
>
> Hello,
> I'd like to contribute update processor which forks many threads which 
> concurrently process the stream of commands. It may be beneficial for users 
> who streams many docs through single request. 

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



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

[jira] [Commented] (LUCENE-4069) Segment-level Bloom filters for a 2 x speed up on rare term searches

[Mark Harwood (JIRA)]

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

Mark Harwood commented on LUCENE-4069:
--

bq. So now we are close to 1M lookups/sec for a single thread!

Cool!

bq. I wonder if somehow we can do a better job picking the right sized bit 
vector up front? 
bq. You basically need to know up front how many unique terms will be in the 
given field for this segment right?

Yes - the job of anticipating the number of unique keys probably has 2 
different contexts:
1) Net new segments e.g. guessing up front how many docs/keys a user is likely 
to generate in a new segment before the flush settings kick in.
2) Merged segments e.g. guessing how many unique keys survive a merge operation

Estimating key volumes in context 1 is probably hard without some additional 
hints from the end user. Arguably the BloomFilterFactory.getSetForField() 
method already represents where this setting can be controlled.
In context 2 where potentially large merges occur we could look at adding an 
extra method to BloomFilterFactory to handle this different context e.g. 
something like
   FuzzySet getSetForMergeOpOnField(FieldInfo fi, OneMerge mergeContext)
Based on the size of the segments being merged and volumes of deletes a more 
appropriate size of Bloom bitset could be allocated based on a worst-case 
estimate.
Not sure how we get the OneMerge instance fed through the call stack - could 
that be held somewhere on a ThreadLocal as generally useful context?





> Segment-level Bloom filters for a 2 x speed up on rare term searches
> 
>
> Key: LUCENE-4069
> URL: https://issues.apache.org/jira/browse/LUCENE-4069
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 3.6, 4.0
>Reporter: Mark Harwood
>Priority: Minor
> Fix For: 4.0, 3.6.1
>
> Attachments: BloomFilterPostingsBranch4x.patch, 
> LUCENE-4069-tryDeleteDocument.patch, LUCENE-4203.patch, 
> MHBloomFilterOn3.6Branch.patch, PKLookupUpdatePerfTest.java, 
> PKLookupUpdatePerfTest.java, PKLookupUpdatePerfTest.java, 
> PKLookupUpdatePerfTest.java, PrimaryKeyPerfTest40.java
>
>
> An addition to each segment which stores a Bloom filter for selected fields 
> in order to give fast-fail to term searches, helping avoid wasted disk access.
> Best suited for low-frequency fields e.g. primary keys on big indexes with 
> many segments but also speeds up general searching in my tests.
> Overview slideshow here: 
> http://www.slideshare.net/MarkHarwood/lucene-bloomfilteredsegments
> Benchmarks based on Wikipedia content here: http://goo.gl/X7QqU
> Patch based on 3.6 codebase attached.
> There are no 3.6 API changes currently - to play just add a field with "_blm" 
> on the end of the name to invoke special indexing/querying capability. 
> Clearly a new Field or schema declaration(!) would need adding to APIs to 
> configure the service properly.
> Also, a patch for Lucene4.0 codebase introducing a new PostingsFormat

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



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

[jira] [Updated] (LUCENE-4202) allow check-forbidden-apis to look for fields too

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-4202:
--

Attachment: LUCENE-4202.patch

New patch with:
- Spaghetti code removal in signature parser
- Fixed (hopefully) the problem with ANT's .lib/ folder. The task now only uses 
system classloader and its own one, while the own one is used in preference 
(which violates spec); but is much better for our checks (which do not rely on 
JVM class loading semantics).
- Better error reporting
- Print log message for each loaded signature file
- Cleaned up Solr classpath to only inspect lib/ folder when loading signatures.

> allow check-forbidden-apis to look for fields too
> -
>
> Key: LUCENE-4202
> URL: https://issues.apache.org/jira/browse/LUCENE-4202
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Uwe Schindler
> Attachments: LUCENE-4202.patch, LUCENE-4202.patch
>
>
> Currently this supports classes and methods, but there are some deprecated 
> fields in the java API, it would be nice to check for those, too.

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



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

[JENKINS] Lucene-Solr-trunk-Windows-Java7-64 - Build # 499 - Failure!

[Policeman Jenkins Server]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/499/

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

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

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=74 closes=73
at __randomizedtesting.SeedInfo.seed([4F3C223F3B4EE30E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:217)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:82)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:754)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)




Build Log:
[...truncated 10680 lines...]
[junit4:junit4] Suite: org.apache.solr.handler.TestReplicationHandler
[junit4:junit4]> (@BeforeClass output)
[junit4:junit4]   2> 5 T794 oejs.Server.doStart jetty-8.1.2.v20120308
[junit4:junit4]   2> 9 T794 oejs.AbstractConnector.doStart Started 
SocketConnector@0.0.0.0:60286
[junit4:junit4]   2> 10 T794 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
[junit4:junit4]   2> 10 T794 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
.\org.apache.solr.handler.TestReplicationHandler$SolrInstance-1341903492549\master
[junit4:junit4]   2> 10 T794 oasc.SolrResourceLoader. new 
SolrResourceLoader for deduced Solr Home: 
'.\org.apache.solr.handler.TestReplicationHandler$SolrInstance-1341903492549\master\'
[junit4:junit4]   2> 15 T794 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init()
[junit4:junit4]   2> 15 T794 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
[junit4:junit4]   2> 16 T794 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
.\org.apache.solr.handler.TestReplicationHandler$SolrInstance-1341903492549\master
[junit4:junit4]   2> 16 T794 oasc.CoreContainer$Initializer.initialize looking 
for solr.xml: 
C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\solr\build\solr-core\test\J0\.\org.apache.solr.handler.TestReplicationHandler$SolrInstance-1341903492549\master\solr.xml
[junit4:junit4]   2> 16 T794 oasc.CoreContainer. New CoreContainer 
465429407
[junit4:junit4]   2> 16 T794 oasc.CoreContainer$Initializer.initialize no 
solr.xml file found - using default
[junit4:junit4]   2> 17 T794 oasc.CoreContainer.load Loading CoreContainer 
using Solr Home: 
'.\org.apache.solr.handler.TestReplicationHandler$SolrInstance-1341903492549\master\'
[junit4:junit4]   2> 17 T794 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'.\org.apache.solr.handler.TestReplicationHandler$SolrInstance-1341903492549\master\'
[junit4:junit4]   2> 27 T794 oasc.CoreContainer.load Registering Log Listener
[junit4:junit4]   2> 41 T794 oashc.HttpShardHandlerFactory.getParameter Setting 
socketTimeout to