[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[
https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253144#comment-14253144
]
Uwe Schindler commented on LUCENE-5951:
---
Hi Mike,
I am OK with that. I would only add one other addition: For all other
operating systems it currently assumes a rotational disk for backwards
compatibility.
Another idea: we should maybe add special convenience setter to set optimal
settings. By that, you don't rely on the auto detection and still can set
automatic settings for both types of drives:
- {{setMaxMergesAndThreads(int maxMergeCount, int maxThreadCount)}} (expert)
- {{setDefaultMergesAndThreads(boolean optimizeForNonRotational)}} (convenience)
Uwe
Detect when index is on SSD and set dynamic defaults
Key: LUCENE-5951
URL: https://issues.apache.org/jira/browse/LUCENE-5951
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch,
LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch
E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on
SSD and 1 if it's on spinning disks.
I think the new NIO2 APIs can let us figure out which device we are mounted
on, and from there maybe we can do os-specific stuff e.g. look at
/sys/block/dev/queue/rotational to see if it's spinning storage or not ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253185#comment-14253185
]
Adrien Grand commented on LUCENE-6124:
--
+1
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253186#comment-14253186
]
Michael McCandless commented on LUCENE-6124:
+1
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5951: --- Attachment: LUCENE-5951.patch New patch, adding Uwe's sentence to the javadocs, and a new setDefaultMaxMergesAndThreads(boolean spins) method. I think it's ready. Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6119) Add AdaptiveRateLimitedDirectoryWrapper
[ https://issues.apache.org/jira/browse/LUCENE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253197#comment-14253197 ] Michael McCandless commented on LUCENE-6119: I ran some tests with this approach and I think it's no good. This creates a tricky feedback system, where both CMS (via hard stalling of incoming threads) and this directory attempt to make change to let merges catch up. When CMS's hard stalls kick in, this lowers the indexing byte/sec rate, which causes this directory to (over simplistically) lower the merge IO throttling, which causes the merges to take longer. I think it's better if all throttling efforts happen in one place, e.g. CMS. I'l think about it ... Add AdaptiveRateLimitedDirectoryWrapper --- Key: LUCENE-6119 URL: https://issues.apache.org/jira/browse/LUCENE-6119 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.0, Trunk Attachments: LUCENE-6119.patch, LUCENE-6119.patch This method returns number of incoming bytes IW has written since it was opened, excluding merging. It tracks flushed segments, new commits (segments_N), incoming files/segments by addIndexes, newly written live docs / doc values updates files. It's an easy statistic for IW to track and should be useful to help applications more intelligently set defaults for IO throttling (RateLimiter). For example, an application that does hardly any indexing but finally triggered a large merge can afford to heavily throttle that large merge so it won't interfere with ongoing searches. But an application that's causing IW to write new bytes at 50 MB/sec must set a correspondingly higher IO throttling otherwise merges will clearly fall behind. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6718) relative coreRootDirectory evaluated against CWD, not Solr Home
[
https://issues.apache.org/jira/browse/SOLR-6718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253202#comment-14253202
]
ASF subversion and git services commented on SOLR-6718:
---
Commit 1646660 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1646660 ]
SOLR-6718: coreRootDirectory should be resolved against SOLR_HOME
relative coreRootDirectory evaluated against CWD, not Solr Home
---
Key: SOLR-6718
URL: https://issues.apache.org/jira/browse/SOLR-6718
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: Hoss Man
Assignee: Alan Woodward
Priority: Blocker
Fix For: 5.0
Attachments: SOLR-6718.patch, SOLR-6718.patch, SOLR-6718.patch
as reported by Andreas Hubold on solr-user...
{noformat}
I'd like to just set it to a subdirectory of solr home (a cores directory to
avoid confusion with configsets and other directories). I tried
str name=coreRootDirectorycores/str
but that's interpreted relative to the current working directory. Other paths
such as sharedLib are interpreted relative to Solr Home and I had expected
this here too.
{noformat}
This is definitely non-intuitive and we should try to fix it in 5.0 since it
will represent a back-compat change for anyone already using a relative path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6718) relative coreRootDirectory evaluated against CWD, not Solr Home
[
https://issues.apache.org/jira/browse/SOLR-6718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253225#comment-14253225
]
ASF subversion and git services commented on SOLR-6718:
---
Commit 1646665 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1646665 ]
SOLR-6718: coreRootDirectory should be resolved against SOLR_HOME
relative coreRootDirectory evaluated against CWD, not Solr Home
---
Key: SOLR-6718
URL: https://issues.apache.org/jira/browse/SOLR-6718
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: Hoss Man
Assignee: Alan Woodward
Priority: Blocker
Fix For: 5.0
Attachments: SOLR-6718.patch, SOLR-6718.patch, SOLR-6718.patch
as reported by Andreas Hubold on solr-user...
{noformat}
I'd like to just set it to a subdirectory of solr home (a cores directory to
avoid confusion with configsets and other directories). I tried
str name=coreRootDirectorycores/str
but that's interpreted relative to the current working directory. Other paths
such as sharedLib are interpreted relative to Solr Home and I had expected
this here too.
{noformat}
This is definitely non-intuitive and we should try to fix it in 5.0 since it
will represent a back-compat change for anyone already using a relative path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6718) relative coreRootDirectory evaluated against CWD, not Solr Home
[
https://issues.apache.org/jira/browse/SOLR-6718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward resolved SOLR-6718.
-
Resolution: Fixed
relative coreRootDirectory evaluated against CWD, not Solr Home
---
Key: SOLR-6718
URL: https://issues.apache.org/jira/browse/SOLR-6718
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: Hoss Man
Assignee: Alan Woodward
Priority: Blocker
Fix For: 5.0
Attachments: SOLR-6718.patch, SOLR-6718.patch, SOLR-6718.patch
as reported by Andreas Hubold on solr-user...
{noformat}
I'd like to just set it to a subdirectory of solr home (a cores directory to
avoid confusion with configsets and other directories). I tried
str name=coreRootDirectorycores/str
but that's interpreted relative to the current working directory. Other paths
such as sharedLib are interpreted relative to Solr Home and I had expected
this here too.
{noformat}
This is definitely non-intuitive and we should try to fix it in 5.0 since it
will represent a back-compat change for anyone already using a relative path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[
https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253278#comment-14253278
]
Uwe Schindler commented on LUCENE-5951:
---
Yeah, looks good. Maybe just add a reference to the new method in the
introduction: To enable default settings for spinning or solid state disks for
other operating systems, use {@link #setDefaultMaxMergesAnThreads(boolean)}.
I am currently investigating detection for windows, but its unlikely that we
can detect SSDs there without native code or spawning processes (no file system
with device data). But I think, for MacOSX there may be a similar solution?
I'll investigate.
Detect when index is on SSD and set dynamic defaults
Key: LUCENE-5951
URL: https://issues.apache.org/jira/browse/LUCENE-5951
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch,
LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch
E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on
SSD and 1 if it's on spinning disks.
I think the new NIO2 APIs can let us figure out which device we are mounted
on, and from there maybe we can do os-specific stuff e.g. look at
/sys/block/dev/queue/rotational to see if it's spinning storage or not ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[
https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253278#comment-14253278
]
Uwe Schindler edited comment on LUCENE-5951 at 12/19/14 11:08 AM:
--
Yeah, looks good. Maybe just add a reference to the new method in the
introduction:
{noformat}To enable default settings for spinning or solid state disks for other
operating systems, use {@link #setDefaultMaxMergesAnThreads(boolean)}.{noformat}
I am currently investigating detection for windows, but its unlikely that we
can detect SSDs there without native code or spawning processes (no file system
with device data). But I think, for MacOSX there may be a similar solution?
I'll investigate.
was (Author: thetaphi):
Yeah, looks good. Maybe just add a reference to the new method in the
introduction: To enable default settings for spinning or solid state disks for
other operating systems, use {@link #setDefaultMaxMergesAnThreads(boolean)}.
I am currently investigating detection for windows, but its unlikely that we
can detect SSDs there without native code or spawning processes (no file system
with device data). But I think, for MacOSX there may be a similar solution?
I'll investigate.
Detect when index is on SSD and set dynamic defaults
Key: LUCENE-5951
URL: https://issues.apache.org/jira/browse/LUCENE-5951
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch,
LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch
E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on
SSD and 1 if it's on spinning disks.
I think the new NIO2 APIs can let us figure out which device we are mounted
on, and from there maybe we can do os-specific stuff e.g. look at
/sys/block/dev/queue/rotational to see if it's spinning storage or not ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6123) BitDocIdSet.Builder.andNot is wrong
[ https://issues.apache.org/jira/browse/LUCENE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6123: - Attachment: LUCENE-6123.patch Here is a patch which corrects the bug and adds a test. I also rewrote the way that BaseBitSetTestCase tests or/and/andNot so that failures are easier to trace when they happen. BitDocIdSet.Builder.andNot is wrong --- Key: LUCENE-6123 URL: https://issues.apache.org/jira/browse/LUCENE-6123 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6123.patch The 2nd part of the body references sparseSet instead of denseSet. We should test it better. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6118) Improve efficiency of the history structure for filter caching
[ https://issues.apache.org/jira/browse/LUCENE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253291#comment-14253291 ] ASF subversion and git services commented on LUCENE-6118: - Commit 1646674 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1646674 ] LUCENE-6118: Improve the efficiency of the history structure for recently-used filters. Improve efficiency of the history structure for filter caching -- Key: LUCENE-6118 URL: https://issues.apache.org/jira/browse/LUCENE-6118 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6118.patch, LUCENE-6118.patch The filter caching uses a ring buffer that tracks frequencies of the hashcodes of the most-recently used filters. However it is based on an ArrayDequeInteger and a HashMapInteger which keep on (un)wrapping ints. Since the data-structure is very simple, we could try to do something better... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6118) Improve efficiency of the history structure for filter caching
[ https://issues.apache.org/jira/browse/LUCENE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253295#comment-14253295 ] ASF subversion and git services commented on LUCENE-6118: - Commit 1646675 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646675 ] LUCENE-6118: Improve the efficiency of the history structure for recently-used filters. Improve efficiency of the history structure for filter caching -- Key: LUCENE-6118 URL: https://issues.apache.org/jira/browse/LUCENE-6118 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6118.patch, LUCENE-6118.patch The filter caching uses a ring buffer that tracks frequencies of the hashcodes of the most-recently used filters. However it is based on an ArrayDequeInteger and a HashMapInteger which keep on (un)wrapping ints. Since the data-structure is very simple, we could try to do something better... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6118) Improve efficiency of the history structure for filter caching
[ https://issues.apache.org/jira/browse/LUCENE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6118. -- Resolution: Fixed Fix Version/s: Trunk 5.0 Thanks Ryan! Improve efficiency of the history structure for filter caching -- Key: LUCENE-6118 URL: https://issues.apache.org/jira/browse/LUCENE-6118 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0, Trunk Attachments: LUCENE-6118.patch, LUCENE-6118.patch The filter caching uses a ring buffer that tracks frequencies of the hashcodes of the most-recently used filters. However it is based on an ArrayDequeInteger and a HashMapInteger which keep on (un)wrapping ints. Since the data-structure is very simple, we could try to do something better... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6801) Load components from blob store
[
https://issues.apache.org/jira/browse/SOLR-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-6801:
-
Attachment: SOLR-6801.patch
with testcases this time. I plan to commit this soon
Load components from blob store
---
Key: SOLR-6801
URL: https://issues.apache.org/jira/browse/SOLR-6801
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
Attachments: SOLR-6801.patch, SOLR-6801.patch
The solrconfig APIs ( SOLR-6607) now allow registering components through
API. SOLR-6787 will support for blob storage.
Jars should be able to be loaded from blobs
example
{code}
curl http://localhost:8983/solr/gettingstarted/config -H Content-Type:
application/json -d '{
create-requesthandler : {name : /mypath ,
class:org.apache.solr.handler.DumpRequestHandler,
lib : mycomponent,
version:2}
}'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253299#comment-14253299 ] Uwe Schindler commented on LUCENE-5951: --- I have here another item on the TODO list: I am currently investigating the new Linux Filesystem BTRFS, which might also bring some cool things for Lucene. Some Linux distribs now starting to make it as a default file system (like OpenSUSE, Ubuntu not yet - but soon). BTRFS is more like ZFS from Slowlaris, so the mount table is no longer giving you all information (no raw devices anymore just some symbolic volume name), because you have now sub-filesystems that you can mount anywhere. Of course, the current code cannot handle that, but we might improve. The same applies to bind mounts, I prefer in some situations. Bind mounts are those where you mount part of one file system at another place (like a symlink, but more hard). Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[
https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253299#comment-14253299
]
Uwe Schindler edited comment on LUCENE-5951 at 12/19/14 11:35 AM:
--
I have here another item on the TODO list: I am currently investigating the new
Linux Filesystem BTRFS, which might also bring some cool things for Lucene.
Some Linux distribs now starting to make it as a default file system (like
OpenSUSE, Ubuntu not yet - but soon). -BTRFS is more like ZFS from Slowlaris,
so the mount table is no longer giving you all information (no raw devices
anymore just some symbolic volume name), because you have now
sub-filesystems that you can mount anywhere. Of course, the current code
cannot handle that, but we might improve.- Correction: this is not a problem,
the device name of the mount is still the raw device. The sub volume is given
as parameter ({{-o subvol=xxx}} to mount/fstab. So the current code should be
able to handle that.
The same applies to bind mounts, I prefer in some situations. Bind mounts are
those where you mount part of one file system at another place (like a symlink,
but more hard).
was (Author: thetaphi):
I have here another item on the TODO list: I am currently investigating the new
Linux Filesystem BTRFS, which might also bring some cool things for Lucene.
Some Linux distribs now starting to make it as a default file system (like
OpenSUSE, Ubuntu not yet - but soon). BTRFS is more like ZFS from Slowlaris, so
the mount table is no longer giving you all information (no raw devices anymore
just some symbolic volume name), because you have now sub-filesystems that
you can mount anywhere. Of course, the current code cannot handle that, but we
might improve.
The same applies to bind mounts, I prefer in some situations. Bind mounts are
those where you mount part of one file system at another place (like a symlink,
but more hard).
Detect when index is on SSD and set dynamic defaults
Key: LUCENE-5951
URL: https://issues.apache.org/jira/browse/LUCENE-5951
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch,
LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch
E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on
SSD and 1 if it's on spinning disks.
I think the new NIO2 APIs can let us figure out which device we are mounted
on, and from there maybe we can do os-specific stuff e.g. look at
/sys/block/dev/queue/rotational to see if it's spinning storage or not ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[
https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253307#comment-14253307
]
Michael McCandless commented on LUCENE-5951:
Actually, I run BTRFS on my current dev box. It is a symlink, but spins() gets
through that:
{noformat}
mike@haswell:/$ df -h .
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/haswell--vg-root 466G 138G 324G 30% /
mike@haswell:/$ ls -l /dev/mapper/haswell--vg-root
lrwxrwxrwx 1 root root 7 Dec 14 17:08 /dev/mapper/haswell--vg-root - ../dm-0
mike@haswell:/$ cat /sys/block/dm-0/queue/rotational
0
{noformat}
To verify spins() is working, I just run:
{noformat}
ant test -Dtestcase=TestConcurrentMergeScheduler
-Dtestmethod=testDynamicDefaults -Dtests.verbose=true
-Dtests.directory=MMapDirectory
{noformat}
and then look for the line where CMS logs the spins result:
{noformat}
[junit4] 1 CMS 1 [Fri Dec 19 16:36:47 UZT 2014; main]:
initMaxMergesAndThreads spins=false maxThreadCount=3 maxMergeCount=5
{noformat}
Detect when index is on SSD and set dynamic defaults
Key: LUCENE-5951
URL: https://issues.apache.org/jira/browse/LUCENE-5951
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch,
LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch
E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on
SSD and 1 if it's on spinning disks.
I think the new NIO2 APIs can let us figure out which device we are mounted
on, and from there maybe we can do os-specific stuff e.g. look at
/sys/block/dev/queue/rotational to see if it's spinning storage or not ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253308#comment-14253308 ] Michael McCandless commented on LUCENE-5951: bq. Maybe just add a reference to the new method in the introduction: I'll add that! Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_20) - Build # 4394 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4394/ Java: 32bit/jdk1.8.0_20 -client -XX:+UseParallelGC (asserts: false) 2 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([8A7F699247E8DDAC]:0) FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([8A7F699247E8DDAC]:0) Build Log: [...truncated 9379 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandlerBackup [junit4] 2 Creating dataDir: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\init-core-data-001 [junit4] 2 1901103 T4960 oas.SolrTestCaseJ4.setUp ###Starting doTestBackup [junit4] 2 1901113 T4960 oejs.Server.doStart jetty-8.1.10.v20130312 [junit4] 2 1901134 T4960 oejs.AbstractConnector.doStart Started SelectChannelConnector@127.0.0.1:? [junit4] 2 1901135 T4960 oass.SolrDispatchFilter.init SolrDispatchFilter.init() [junit4] 2 1901135 T4960 oasc.SolrResourceLoader.locateSolrHome JNDI not configured for solr (NoInitialContextEx) [junit4] 2 1901135 T4960 oasc.SolrResourceLoader.locateSolrHome using system property solr.solr.home: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\solr-instance-001 [junit4] 2 1901135 T4960 oasc.SolrResourceLoader.init new SolrResourceLoader for directory: 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\solr-instance-001\' [junit4] 2 1901157 T4960 oasc.ConfigSolr.fromFile Loading container configuration from C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\solr-instance-001\solr.xml [junit4] 2 1901177 T4960 oasc.CoreContainer.init New CoreContainer 25258135 [junit4] 2 1901177 T4960 oasc.CoreContainer.load Loading cores into CoreContainer [instanceDir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\solr-instance-001\] [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting socketTimeout to: 9 [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting urlScheme to: [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting connTimeout to: 15000 [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting maxConnectionsPerHost to: 20 [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting maxConnections to: 1 [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting corePoolSize to: 0 [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting maximumPoolSize to: 2147483647 [junit4] 2 1901178 T4960 oashc.HttpShardHandlerFactory.getParameter Setting maxThreadIdleTime to: 5 [junit4] 2 1901179 T4960 oashc.HttpShardHandlerFactory.getParameter Setting sizeOfQueue to: -1 [junit4] 2 1901179 T4960 oashc.HttpShardHandlerFactory.getParameter Setting fairnessPolicy to: false [junit4] 2 1901179 T4960 oasu.UpdateShardHandler.init Creating UpdateShardHandler HTTP client with params: socketTimeout=34connTimeout=45000retry=false [junit4] 2 1901179 T4960 oasl.LogWatcher.createWatcher SLF4J impl is org.slf4j.impl.Log4jLoggerFactory [junit4] 2 1901179 T4960 oasl.LogWatcher.newRegisteredLogWatcher Registering Log Listener [Log4j (org.slf4j.impl.Log4jLoggerFactory)] [junit4] 2 1901181 T4960 oasc.CoreContainer.load Host Name: 127.0.0.1 [junit4] 2 1901182 T4972 oasc.SolrResourceLoader.init new SolrResourceLoader for directory: 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\solr-instance-001\collection1\' [junit4] 2 1901207 T4972 oasc.SolrConfig.init Using Lucene MatchVersion: 5.0.0 [junit4] 2 1901213 T4972 oasc.SolrConfig.init Loaded SolrConfig: solrconfig.xml [junit4] 2 1901214 T4972 oass.IndexSchema.readSchema Reading Solr Schema from C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-8A7F699247E8DDAC-001\solr-instance-001\collection1\conf\schema.xml
[jira] [Created] (LUCENE-6126) Group sort by numFound
Prateek Sachan created LUCENE-6126:
--
Summary: Group sort by numFound
Key: LUCENE-6126
URL: https://issues.apache.org/jira/browse/LUCENE-6126
Project: Lucene - Core
Issue Type: New Feature
Reporter: Prateek Sachan
Currently, the doing a group query gives the response in the following manner:
grouped:{
field_name: value:{
matches:5,
doclist:{numFound:3,start:0,docs:[{ ... }]
}}
There should be a way to sort the groups. One way of doing it would be to store
a field in the index and apply sort on that.
But, having a way to sort groups according to numFound would be better than
storing temp fields for this purpose.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6126) Group sort by numFound
[
https://issues.apache.org/jira/browse/LUCENE-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prateek Sachan updated LUCENE-6126:
---
Priority: Minor (was: Major)
Group sort by numFound
--
Key: LUCENE-6126
URL: https://issues.apache.org/jira/browse/LUCENE-6126
Project: Lucene - Core
Issue Type: New Feature
Reporter: Prateek Sachan
Priority: Minor
Currently, the doing a group query gives the response in the following manner:
grouped:{
field_name: value:{
matches:5,
doclist:{numFound:3,start:0,docs:[{ ... }]
}}
There should be a way to sort the groups. One way of doing it would be to
store a field in the index and apply sort on that.
But, having a way to sort groups according to numFound would be better than
storing temp fields for this purpose.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6126) Group sort by numFound
[
https://issues.apache.org/jira/browse/LUCENE-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prateek Sachan updated LUCENE-6126:
---
Priority: Major (was: Minor)
Group sort by numFound
--
Key: LUCENE-6126
URL: https://issues.apache.org/jira/browse/LUCENE-6126
Project: Lucene - Core
Issue Type: New Feature
Reporter: Prateek Sachan
Currently, the doing a group query gives the response in the following manner:
grouped:{
field_name: value:{
matches:5,
doclist:{numFound:3,start:0,docs:[{ ... }]
}}
There should be a way to sort the groups. One way of doing it would be to
store a field in the index and apply sort on that.
But, having a way to sort groups according to numFound would be better than
storing temp fields for this purpose.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253351#comment-14253351 ] Uwe Schindler commented on LUCENE-5951: --- Thanks Mike! I already changed my original message because the raw device still appears in mount output, the virtual subvolume is part of the mount options. So our code works with BTRFS. I was about to startup another virtual machine. I just want to list all the special cases here, so when people open bug reports we already know where there might be problems. And we also know what our customers might ask :-) +1 to commit! Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253467#comment-14253467 ] ASF subversion and git services commented on LUCENE-6121: - Commit 1646737 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1646737 ] LUCENE-6121: CachingTokenFilter.reset() propagates to input if not cached Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6840) Remove legacy solr.xml mode
[
https://issues.apache.org/jira/browse/SOLR-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253475#comment-14253475
]
Alan Woodward commented on SOLR-6840:
-
I'm working on the distributed tests now. Rather than having a core predefined
in solr.xml, I'm creating them via the core admin API in setup, but I've bumped
up against a bit of an API mismatch here. If you want to create cores on an
empty node via SolrJ, you create a SolrServer pointing at the /solr context,
but if you then want to query a specific core you need to create a second
SolrServer that points at that core. In SolrCloud you can set the 'collection'
parameter to get round this, but in standard multicore Solr that doesn't work.
Remove legacy solr.xml mode
---
Key: SOLR-6840
URL: https://issues.apache.org/jira/browse/SOLR-6840
Project: Solr
Issue Type: Task
Reporter: Steve Rowe
Assignee: Erick Erickson
Priority: Blocker
Fix For: 5.0
Attachments: SOLR-6840.patch, SOLR-6840.patch
On the [Solr Cores and solr.xml
page|https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml],
the Solr Reference Guide says:
{quote}
Starting in Solr 4.3, Solr will maintain two distinct formats for
{{solr.xml}}, the _legacy_ and _discovery_ modes. The former is the format we
have become accustomed to in which all of the cores one wishes to define in a
Solr instance are defined in {{solr.xml}} in
{{corescore/...core//cores}} tags. This format will continue to be
supported through the entire 4.x code line.
As of Solr 5.0 this form of solr.xml will no longer be supported. Instead
Solr will support _core discovery_. [...]
The new core discovery mode structure for solr.xml will become mandatory as
of Solr 5.0, see: Format of solr.xml.
{quote}
AFAICT, nothing has been done to remove legacy {{solr.xml}} mode from 5.0 or
trunk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253516#comment-14253516 ] ASF subversion and git services commented on LUCENE-6121: - Commit 1646767 from [~dsmiley] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646767 ] LUCENE-6121: CachingTokenFilter.reset() propagates to input if not cached Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-6121. -- Resolution: Fixed Thanks for your input Rob. FYI I moved the QueryBuilder buffer.reset() to the end of the previous try-catch that wraps with RuntimeException, so it'll not be swallowed. Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1959 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1959/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) No tests ran. Build Log: [...truncated 291 lines...] [javac] Compiling 424 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/core/classes/test [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java:52: error: local variable resetCount is accessed from within inner class; needs to be declared final [javac] resetCount.incrementAndGet(); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:529: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:477: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:61: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/extra-targets.xml:39: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:49: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:793: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:807: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:1875: Compile failed; see the compiler error output for details. Total time: 41 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) Archiving artifacts Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: No test report files were found. Configuration error? at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2677) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ..remote call to MacOSX VBOX(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:970) at hudson.FilePath.act(FilePath.java:959) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at hudson.model.Run.execute(Run.java:1784) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1959 - Still Failing!
This is a sneaky java 7/8 difference: java 8 is able to infer this variable is effectively final, but java 7 isn't... Mike McCandless http://blog.mikemccandless.com On Fri, Dec 19, 2014 at 10:21 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1959/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) No tests ran. Build Log: [...truncated 291 lines...] [javac] Compiling 424 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/core/classes/test [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java:52: error: local variable resetCount is accessed from within inner class; needs to be declared final [javac] resetCount.incrementAndGet(); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:529: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:477: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:61: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/extra-targets.xml:39: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:49: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:793: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:807: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:1875: Compile failed; see the compiler error output for details. Total time: 41 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) Archiving artifacts Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: No test report files were found. Configuration error? at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2677) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ..remote call to MacOSX VBOX(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:970) at hudson.FilePath.act(FilePath.java:959) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at hudson.model.Run.execute(Run.java:1784) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail:
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2003 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2003/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true) 1 tests failed. FAILED: org.apache.solr.TestHighlightDedupGrouping.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:53515 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:53515 at __randomizedtesting.SeedInfo.seed([47C4F958225D4B97:C622774055022BAB]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:578) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:213) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:209) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102) at org.apache.solr.TestHighlightDedupGrouping.addDoc(TestHighlightDedupGrouping.java:127) at org.apache.solr.TestHighlightDedupGrouping.randomizedTest(TestHighlightDedupGrouping.java:101) at org.apache.solr.TestHighlightDedupGrouping.doTest(TestHighlightDedupGrouping.java:47) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
Re: [JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1959 - Still Failing!
I committed a fix. Mike McCandless http://blog.mikemccandless.com On Fri, Dec 19, 2014 at 10:24 AM, Michael McCandless luc...@mikemccandless.com wrote: This is a sneaky java 7/8 difference: java 8 is able to infer this variable is effectively final, but java 7 isn't... Mike McCandless http://blog.mikemccandless.com On Fri, Dec 19, 2014 at 10:21 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1959/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) No tests ran. Build Log: [...truncated 291 lines...] [javac] Compiling 424 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/core/classes/test [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java:52: error: local variable resetCount is accessed from within inner class; needs to be declared final [javac] resetCount.incrementAndGet(); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:529: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:477: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:61: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/extra-targets.xml:39: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:49: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:793: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:807: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:1875: Compile failed; see the compiler error output for details. Total time: 41 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) Archiving artifacts Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: No test report files were found. Configuration error? at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2677) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ..remote call to MacOSX VBOX(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:970) at hudson.FilePath.act(FilePath.java:959) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at hudson.model.Run.execute(Run.java:1784) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Email was triggered
[jira] [Commented] (SOLR-6865) Upgrade HttpClient to 4.4
[ https://issues.apache.org/jira/browse/SOLR-6865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253539#comment-14253539 ] Shawn Heisey commented on SOLR-6865: I misread the HC release announcement. It's a new release of httpcore, not the entire httpcomponents suite. I'll just leave this open and try the upgrade once the full release is made. Upgrade HttpClient to 4.4 - Key: SOLR-6865 URL: https://issues.apache.org/jira/browse/SOLR-6865 Project: Solr Issue Type: Task Affects Versions: 5.0 Reporter: Shawn Heisey Priority: Minor Fix For: 5.0, Trunk HttpClient 4.4 has been released. 5.0 seems like a good time to upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253541#comment-14253541 ] ASF subversion and git services commented on LUCENE-5951: - Commit 1646775 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1646775 ] LUCENE-5951: try to detect if index is on an SSD and default CMS's settings accordingly Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.10-Linux (64bit/jdk1.9.0-ea-b34) - Build # 161 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/161/
Java: 64bit/jdk1.9.0-ea-b34 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts:
true)
1 tests failed.
FAILED: org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT
Error Message:
SOLR-5815? : wrong maxDoc: core=org.apache.solr.core.SolrCore@188340b
searcher=Searcher@57f13cb[collection1]
main{StandardDirectoryReader(segments_8:16 _4(4.10.3):c1 _5(4.10.3):c1)}
expected:3 but was:2
Stack Trace:
java.lang.AssertionError: SOLR-5815? : wrong maxDoc:
core=org.apache.solr.core.SolrCore@188340b
searcher=Searcher@57f13cb[collection1]
main{StandardDirectoryReader(segments_8:16 _4(4.10.3):c1 _5(4.10.3):c1)}
expected:3 but was:2
at
__randomizedtesting.SeedInfo.seed([6C81DC7FF4981DB0:D907BDF84B59AF44]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at
org.apache.solr.core.TestNonNRTOpen.assertNotNRT(TestNonNRTOpen.java:142)
at
org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT(TestNonNRTOpen.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
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:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
[jira] [Reopened] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reopened LUCENE-6121: - Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253551#comment-14253551 ] Robert Muir commented on LUCENE-6121: - I don't like that: you can't follow the logic flow: because reset is in a crazy place. Please, just wrap with runtimeexception. Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-5951. Resolution: Fixed Fix Version/s: Trunk 5.0 Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.0, Trunk Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253553#comment-14253553 ] ASF subversion and git services commented on LUCENE-5951: - Commit 1646778 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646778 ] LUCENE-5951: try to detect if index is on an SSD and default CMS's settings accordingly Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.0, Trunk Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_40-ea-b09) - Build # 11774 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11774/ Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseSerialGC (asserts: false) 1 tests failed. FAILED: org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([12505B38D807BDC6:C51C6FEE65E6208C]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails(TestCachingTokenFilter.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 653 lines...] [junit4] Suite: org.apache.lucene.analysis.TestCachingTokenFilter [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestCachingTokenFilter -Dtests.method=testDoubleResetFails -Dtests.seed=12505B38D807BDC6 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=cs_CZ -Dtests.timezone=America/Yakutat -Dtests.asserts=false -Dtests.file.encoding=US-ASCII
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[
https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253572#comment-14253572
]
David Smiley commented on LUCENE-6121:
--
Sure; that point occurred to me too.
If there is no term attribute (as strange as that may be), then this reset()
call needs to be guarded by {{if (numTokens 0)}} or else a double-reset will
ensue. See it?
Also, I'd like to remove the needless = null|false initializations to variables
where it's not needed due to the compiler figuring out it's not needed (which
IntelliJ helpfully points out).
Fix CachingTokenFilter to propagate reset() the first time
--
Key: LUCENE-6121
URL: https://issues.apache.org/jira/browse/LUCENE-6121
Project: Lucene - Core
Issue Type: Improvement
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.0, Trunk
Attachments:
LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch,
LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch
CachingTokenFilter should have been propagating reset() _but only the first
time_ and thus you would then use CachingTokenFilter in a more normal way –
wrap it and call reset() then increment in a loop, etc., instead of knowing
you need to reset() on what it wraps but not this token filter itself. That's
weird. It's ab-normal for a TokenFilter to never propagate reset, so every
user of CachingTokenFilter to date has worked around this by calling reset()
on the underlying input instead of the final wrapping token filter
(CachingTokenFilter in this case).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_40-ea-b09) - Build # 4500 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4500/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: false) 4 tests failed. FAILED: org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([8A63DD412A8E3D1A:5D2FE997976FA050]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails(TestCachingTokenFilter.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.lucene.util.TestIOUtils.testRotatingPlatters Error Message: C:\dev\zzz1 Stack Trace: java.nio.file.NoSuchFileException: C:\dev\zzz1 at __randomizedtesting.SeedInfo.seed([8A63DD412A8E3D1A:5D5FF0344D9A9A5F]:0) at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) at
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253580#comment-14253580 ] David Smiley commented on LUCENE-6121: -- ... cleaner to just move the numTokens==0 to before the reset, I think Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253581#comment-14253581 ] Robert Muir commented on LUCENE-6121: - Can you just wrap with runtimeexception and try making minimal changes to the code as it was for this issue? This method is e.g. used by all queryparsers and is complex. This is not the place to try to be cute to save a try/catch. It is important that logic and flow make sense, because its already confusing. I am sure there are other issues with the method besides the no-term-att-case, because its complicated. But that means its even more important to be cautious, e.g. approach this in a separate issue and so on. Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1959 - Still Failing!
Ouch; thanks! ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Fri, Dec 19, 2014 at 10:29 AM, Michael McCandless luc...@mikemccandless.com wrote: I committed a fix. Mike McCandless http://blog.mikemccandless.com On Fri, Dec 19, 2014 at 10:24 AM, Michael McCandless luc...@mikemccandless.com wrote: This is a sneaky java 7/8 difference: java 8 is able to infer this variable is effectively final, but java 7 isn't... Mike McCandless http://blog.mikemccandless.com On Fri, Dec 19, 2014 at 10:21 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1959/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) No tests ran. Build Log: [...truncated 291 lines...] [javac] Compiling 424 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/core/classes/test [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java:52: error: local variable resetCount is accessed from within inner class; needs to be declared final [javac] resetCount.incrementAndGet(); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:529: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:477: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:61: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/extra-targets.xml:39: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:49: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:793: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:807: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:1875: Compile failed; see the compiler error output for details. Total time: 41 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) Archiving artifacts Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: No test report files were found. Configuration error? at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:92) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2677) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ..remote call to MacOSX VBOX(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:970) at hudson.FilePath.act(FilePath.java:959) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:89) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[
https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253583#comment-14253583
]
Robert Muir commented on LUCENE-6121:
-
{quote}
... cleaner to just move the numTokens==0 to before the reset, I think
{quote}
Please, I do not want these changes under this issue. The current code was
already committed in a cowboy way.
Trunk tests are failing. branch_5x compile does not fail.
More care is needed here.
Fix CachingTokenFilter to propagate reset() the first time
--
Key: LUCENE-6121
URL: https://issues.apache.org/jira/browse/LUCENE-6121
Project: Lucene - Core
Issue Type: Improvement
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.0, Trunk
Attachments:
LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch,
LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch
CachingTokenFilter should have been propagating reset() _but only the first
time_ and thus you would then use CachingTokenFilter in a more normal way –
wrap it and call reset() then increment in a loop, etc., instead of knowing
you need to reset() on what it wraps but not this token filter itself. That's
weird. It's ab-normal for a TokenFilter to never propagate reset, so every
user of CachingTokenFilter to date has worked around this by calling reset()
on the underlying input instead of the final wrapping token filter
(CachingTokenFilter in this case).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_67) - Build # 4395 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4395/ Java: 32bit/jdk1.7.0_67 -client -XX:+UseParallelGC (asserts: false) 4 tests failed. FAILED: org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([17FDC61F34C2DB4E:C0B1F2C989234604]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails(TestCachingTokenFilter.java:134) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.lucene.util.TestIOUtils.testSSD Error Message: C:\dev\zzz1 Stack Trace: java.nio.file.NoSuchFileException: C:\dev\zzz1 at __randomizedtesting.SeedInfo.seed([17FDC61F34C2DB4E:72EF4E372642BDA9]:0) at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:90) at
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #792: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/792/ 2 tests failed. FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([E3E2A5BBAA3E1545]:0) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([E3E2A5BBAA3E1545]:0) Build Log: [...truncated 53936 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: The following error occurred while executing this line: : Java returned: 1 Total time: 378 minutes 4 seconds Build step 'Invoke Ant' marked build as failure Recording test results 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-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253618#comment-14253618 ] ASF subversion and git services commented on LUCENE-5951: - Commit 1646791 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1646791 ] LUCENE-5951: these test cases can't run on Windows Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.0, Trunk Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5951) Detect when index is on SSD and set dynamic defaults
[ https://issues.apache.org/jira/browse/LUCENE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253620#comment-14253620 ] ASF subversion and git services commented on LUCENE-5951: - Commit 1646792 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646792 ] LUCENE-5951: these test cases can't run on Windows Detect when index is on SSD and set dynamic defaults Key: LUCENE-5951 URL: https://issues.apache.org/jira/browse/LUCENE-5951 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.0, Trunk Attachments: LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch, LUCENE-5951.patch E.g. ConcurrentMergeScheduler should default maxMergeThreads to 3 if it's on SSD and 1 if it's on spinning disks. I think the new NIO2 APIs can let us figure out which device we are mounted on, and from there maybe we can do os-specific stuff e.g. look at /sys/block/dev/queue/rotational to see if it's spinning storage or not ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253625#comment-14253625 ] Michael McCandless commented on LUCENE-6121: Can we rollback this change for now? Sounds like it needs a little more iterating here first... Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_40-ea-b09) - Build # 4500 - Failure!
I committed a fix for the TestIOUtils failures. Mike McCandless http://blog.mikemccandless.com On Fri, Dec 19, 2014 at 10:59 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4500/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: false) 4 tests failed. FAILED: org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([8A63DD412A8E3D1A:5D2FE997976FA050]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.analysis.TestCachingTokenFilter.testDoubleResetFails(TestCachingTokenFilter.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.lucene.util.TestIOUtils.testRotatingPlatters Error Message: C:\dev\zzz1 Stack Trace:
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253640#comment-14253640 ] ASF subversion and git services commented on LUCENE-6121: - Commit 1646793 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1646793 ] LUCENE-6121: Fix a test to assumeTrue assertions enabled. Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6122) explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig
[ https://issues.apache.org/jira/browse/LUCENE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6122: --- Attachment: LUCENE-6122.patch Simple patch... explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig --- Key: LUCENE-6122 URL: https://issues.apache.org/jira/browse/LUCENE-6122 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-6122.patch This is just like not using FSDirectory.open in tests. The same seed should do the same stuff on different machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253643#comment-14253643 ] ASF subversion and git services commented on LUCENE-6121: - Commit 1646794 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1646794 ] LUCENE-6121: QueryBuilder put 2nd reset() to where it was, and add test to ensure no double-reset if there is no term attribute. Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253652#comment-14253652 ] ASF subversion and git services commented on LUCENE-6121: - Commit 1646796 from [~dsmiley] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646796 ] LUCENE-6121: QueryBuilder put 2nd reset() to where it was, and add test to ensure no double-reset if there is no term attribute. Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[
https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253665#comment-14253665
]
David Smiley commented on LUCENE-6121:
--
I appreciate it may have seemed cowboy from where you sit but I ran tests on
trunk 5x, precommit as well. Of course this doesn't guarantee no problems.
1. I should switch my 5x environment shell to switch my java environment to
Java 7, not my default (Java 8). Thanks for the quick fix Mike.
2. The test failure seen on trunk was because the test I added fundamentally
requires MockTokenizer to do its thing, and when assertions aren't enabled
(randomly chosen) then it won't. So I committed this moments ago:
{code}
assumeTrue(We want MockAnalyzer to detect double-reset, TEST_ASSERTS_ENABLED);
{code}
I anticipate both trunk/5x should be stable now.
bq. I am sure there are other issues with the method besides the
no-term-att-case, because its complicated. But that means its even more
important to be cautious, e.g. approach this in a separate issue and so on.
I added a test to TestQueryBuilder that tests the behavior we want when there
is no term attribute, since clearly QueryBuilder was written to support that
yet it wasn't tested.
bq. Please, I do not want these changes under this issue.
I don't agree on insisting on a heavy-weight process for minor code clarity
improvements. It's not worth it to create an issue over such things; so it
sits there the way it is. As it is, we need to commit to multiple branches,
which is a PITA. But fine, you have a right to your opinion.
Fix CachingTokenFilter to propagate reset() the first time
--
Key: LUCENE-6121
URL: https://issues.apache.org/jira/browse/LUCENE-6121
Project: Lucene - Core
Issue Type: Improvement
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.0, Trunk
Attachments:
LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch,
LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch
CachingTokenFilter should have been propagating reset() _but only the first
time_ and thus you would then use CachingTokenFilter in a more normal way –
wrap it and call reset() then increment in a loop, etc., instead of knowing
you need to reset() on what it wraps but not this token filter itself. That's
weird. It's ab-normal for a TokenFilter to never propagate reset, so every
user of CachingTokenFilter to date has worked around this by calling reset()
on the underlying input instead of the final wrapping token filter
(CachingTokenFilter in this case).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
[ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253684#comment-14253684 ] Michael McCandless commented on LUCENE-6121: bq. I should switch my 5x environment shell to switch my java environment to Java 7, not my default (Java 8). Thanks for the quick fix Mike. Actually, even if you use Java 8 on 5.x, it fails compilation (thanks to javac.source=1.7). Still it is of course best to run compilation/tests with java7 on backport ... but it's easy to forget ... Fix CachingTokenFilter to propagate reset() the first time -- Key: LUCENE-6121 URL: https://issues.apache.org/jira/browse/LUCENE-6121 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch, LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch CachingTokenFilter should have been propagating reset() _but only the first time_ and thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset() then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate reset, so every user of CachingTokenFilter to date has worked around this by calling reset() on the underlying input instead of the final wrapping token filter (CachingTokenFilter in this case). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6127) fix mockanalyzer to not use asserts
Robert Muir created LUCENE-6127: --- Summary: fix mockanalyzer to not use asserts Key: LUCENE-6127 URL: https://issues.apache.org/jira/browse/LUCENE-6127 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Currently MockAnalyzer's checks are implemented with assert. But this is just for convenience, we should not rely upon asserts being turned on: this is the whole point of the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6841) Visualize lucene segment info in admin
[ https://issues.apache.org/jira/browse/SOLR-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253723#comment-14253723 ] Hoss Man commented on SOLR-6841: very cool - would definitely welcome that as a patch to integrate directly into the solr admin. I suspect that auto generating the size scale in such a way that the numbers don't look silly is a hard problem -- particularly since it looks like you are trying to use a log scale as well. maybe just label the max (ie: size of biggest segment) on the horizontal axis, along with the vertical log lines, and then label each segment with it's size (or use tool tips) ? Visualize lucene segment info in admin -- Key: SOLR-6841 URL: https://issues.apache.org/jira/browse/SOLR-6841 Project: Solr Issue Type: Improvement Reporter: Alexey Kozhemiakin Fix For: 5.0 Attachments: i7^cimgpsh_orig.png We find it useful to tune merge policy not blindly but looking on segment size and fill ratio. We're working on a patch that adds a tab to admin page with McCandless-style of segment visualization. Draft UI is attached (currenly as part of admin.extra). Please share your ideas if it's ok to put the code in core admin. More details here http://search-lucene.com/m/QTPa44cNJ1 https://plus.google.com/+MichaelMcCandless/posts/MJVueTznYnD http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6127) fix mockanalyzer to not use asserts
[ https://issues.apache.org/jira/browse/LUCENE-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-6127: Attachment: LUCENE-6127.patch Here is a first stab. Tests pass. fix mockanalyzer to not use asserts --- Key: LUCENE-6127 URL: https://issues.apache.org/jira/browse/LUCENE-6127 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6127.patch Currently MockAnalyzer's checks are implemented with assert. But this is just for convenience, we should not rely upon asserts being turned on: this is the whole point of the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6031) TokenSources optimization, avoid sort
[
https://issues.apache.org/jira/browse/LUCENE-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-6031:
-
Attachment:
LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch
This patch further improves slightly by using an AttributeFactory WITH
PackedTokenAttributeImpl, and thus reducing the memory overhead involved in
captureState() since there will be one attribute impl (2 if payloads).
{code}
//This attribute factory uses less memory when captureState() is called.
public static final AttributeFactory ATTRIBUTE_FACTORY =
AttributeFactory.getStaticImplementation(
AttributeFactory.DEFAULT_ATTRIBUTE_FACTORY,
PackedTokenAttributeImpl.class);
{code}
I pass that via the constructor, super(ATTRIBUTE_FACTORY).
I'll commit in a couple days or so.
TokenSources optimization, avoid sort
-
Key: LUCENE-6031
URL: https://issues.apache.org/jira/browse/LUCENE-6031
Project: Lucene - Core
Issue Type: Improvement
Components: modules/highlighter
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.0, Trunk
Attachments: LUCENE-6031.patch, LUCENE-6031.patch,
LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch,
LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch
TokenSources.java, in the highlight module, is a facade that returns a
TokenStream for a field by either un-inverting converting the TermVector
Terms, or by text re-analysis if TermVectors are unavailable or don't have
the right options. TokenSources is used by the default highlighter, which is
the most accurate highlighter we've got. When documents are large (say
hundreds of kilobytes on up), I found that most of the highlighter's activity
was up-front spent un-inverting converting the term vector to a
TokenStream, not on the actual/real highlighting that follows. Much of that
time was on a huge sort of hundreds of thousands of Tokens. Time was also
spent doing lots of String conversion and char copying, and it used a lot of
memory, too.
In this patch, I overhauled TokenStreamFromTermPositionVector.java, and I
removed similar logic in TokenSources that was used in circumstances when
positions weren't available but offsets were. This class can un-invert term
vectors that have positions *and/or* offsets (at least one). It doesn't
sort. It places Tokens _directly_ into an array of tokens directly indexed
by position. When positions aren't available, the startOffset/8 is a
substitute. I've got a more light-weight Token inner class used in place of
the former and deprecated Token that ultimately forms a linked-list when the
process is done. There is no string conversion; character copying is
minimized. The Token array is GC'ed after initialization, it's only needed
during construction.
Misc:
* It implements reset() efficiently so it need not be wrapped in
CachingTokenFilter (I'll supply a patch later on this).
* It only fetches payloads if you ask for them by adding the attribute (the
default highlighter won't add the attribute).
* It exposes the underlying TermVector terms via a getter too, which is
needed by another patch to follow later.
A key assumption is that the position increment gap or first position isn't
gigantic, as that will create wasted space and the linked-list formation
ultimately has to visit all the slots. We also assume that there aren't a
ton of tokens at the same position, since inserting new tokens in sorted
order is O(N^2) where 'N' is the average co-occurring token length.
My performance testing using Lucene's benchmark module on a megabyte document
showed 5x speedup, in conjunction with some other patches to be posted
separately. This patch made the most difference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6031) TokenSources optimization, avoid sort
[ https://issues.apache.org/jira/browse/LUCENE-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253770#comment-14253770 ] Robert Muir commented on LUCENE-6031: - This issue is marked resolved. Can you please open a new issue for other changes? TokenSources optimization, avoid sort - Key: LUCENE-6031 URL: https://issues.apache.org/jira/browse/LUCENE-6031 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6031.patch, LUCENE-6031.patch, LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch, LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch TokenSources.java, in the highlight module, is a facade that returns a TokenStream for a field by either un-inverting converting the TermVector Terms, or by text re-analysis if TermVectors are unavailable or don't have the right options. TokenSources is used by the default highlighter, which is the most accurate highlighter we've got. When documents are large (say hundreds of kilobytes on up), I found that most of the highlighter's activity was up-front spent un-inverting converting the term vector to a TokenStream, not on the actual/real highlighting that follows. Much of that time was on a huge sort of hundreds of thousands of Tokens. Time was also spent doing lots of String conversion and char copying, and it used a lot of memory, too. In this patch, I overhauled TokenStreamFromTermPositionVector.java, and I removed similar logic in TokenSources that was used in circumstances when positions weren't available but offsets were. This class can un-invert term vectors that have positions *and/or* offsets (at least one). It doesn't sort. It places Tokens _directly_ into an array of tokens directly indexed by position. When positions aren't available, the startOffset/8 is a substitute. I've got a more light-weight Token inner class used in place of the former and deprecated Token that ultimately forms a linked-list when the process is done. There is no string conversion; character copying is minimized. The Token array is GC'ed after initialization, it's only needed during construction. Misc: * It implements reset() efficiently so it need not be wrapped in CachingTokenFilter (I'll supply a patch later on this). * It only fetches payloads if you ask for them by adding the attribute (the default highlighter won't add the attribute). * It exposes the underlying TermVector terms via a getter too, which is needed by another patch to follow later. A key assumption is that the position increment gap or first position isn't gigantic, as that will create wasted space and the linked-list formation ultimately has to visit all the slots. We also assume that there aren't a ton of tokens at the same position, since inserting new tokens in sorted order is O(N^2) where 'N' is the average co-occurring token length. My performance testing using Lucene's benchmark module on a megabyte document showed 5x speedup, in conjunction with some other patches to be posted separately. This patch made the most difference. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-6031) TokenSources optimization, avoid sort
[ https://issues.apache.org/jira/browse/LUCENE-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reopened LUCENE-6031: -- Hi Rob. Since it hasn't been released yet, I'll simply re-open. The patch is an incremental improvement; no change in scope. TokenSources optimization, avoid sort - Key: LUCENE-6031 URL: https://issues.apache.org/jira/browse/LUCENE-6031 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: LUCENE-6031.patch, LUCENE-6031.patch, LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch, LUCENE-6031_lazy_init_at_incrementToken,_and_optimize_payloads.patch TokenSources.java, in the highlight module, is a facade that returns a TokenStream for a field by either un-inverting converting the TermVector Terms, or by text re-analysis if TermVectors are unavailable or don't have the right options. TokenSources is used by the default highlighter, which is the most accurate highlighter we've got. When documents are large (say hundreds of kilobytes on up), I found that most of the highlighter's activity was up-front spent un-inverting converting the term vector to a TokenStream, not on the actual/real highlighting that follows. Much of that time was on a huge sort of hundreds of thousands of Tokens. Time was also spent doing lots of String conversion and char copying, and it used a lot of memory, too. In this patch, I overhauled TokenStreamFromTermPositionVector.java, and I removed similar logic in TokenSources that was used in circumstances when positions weren't available but offsets were. This class can un-invert term vectors that have positions *and/or* offsets (at least one). It doesn't sort. It places Tokens _directly_ into an array of tokens directly indexed by position. When positions aren't available, the startOffset/8 is a substitute. I've got a more light-weight Token inner class used in place of the former and deprecated Token that ultimately forms a linked-list when the process is done. There is no string conversion; character copying is minimized. The Token array is GC'ed after initialization, it's only needed during construction. Misc: * It implements reset() efficiently so it need not be wrapped in CachingTokenFilter (I'll supply a patch later on this). * It only fetches payloads if you ask for them by adding the attribute (the default highlighter won't add the attribute). * It exposes the underlying TermVector terms via a getter too, which is needed by another patch to follow later. A key assumption is that the position increment gap or first position isn't gigantic, as that will create wasted space and the linked-list formation ultimately has to visit all the slots. We also assume that there aren't a ton of tokens at the same position, since inserting new tokens in sorted order is O(N^2) where 'N' is the average co-occurring token length. My performance testing using Lucene's benchmark module on a megabyte document showed 5x speedup, in conjunction with some other patches to be posted separately. This patch made the most difference. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6851) oom_solr.sh problems and other issues that make it hard to run Solr as a service on *nix
[
https://issues.apache.org/jira/browse/SOLR-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253784#comment-14253784
]
Timothy Potter commented on SOLR-6851:
--
If you're interested in this type of stuff - please give a review of:
https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production,
which covers features supported by this patch.
oom_solr.sh problems and other issues that make it hard to run Solr as a
service on *nix
Key: SOLR-6851
URL: https://issues.apache.org/jira/browse/SOLR-6851
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Timothy Potter
Fix For: 5.0
Attachments: SOLR-6851.patch
noticed 2 problems with the oom_solr.sh script...
1) the script is only being run with the port of hte solr instance to
terminate, so the log messages aren't getting writen to the correct directory
-- if we change hte script to take a log dir/file as an argument, we can
ensure the logs are written to the correct place
2) on my ubuntu linux machine (where /bin/sh is a symlink to /bin/dash),
the console log is recording a script error when java runs oom_solr.sh...
{noformat}
#
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError=/home/hossman/lucene/5x_dev/solr/bin/oom_solr.sh
8983
# Executing /bin/sh -c /home/hossman/lucene/5x_dev/solr/bin/oom_solr.sh
8983...
/home/hossman/lucene/5x_dev/solr/bin/oom_solr.sh: 20: [: 14305: unexpected
operator
Running OOM killer script for process 14305 for Solr on port 8983
Killed process 14305
{noformat}
steps to reproduce: {{bin/solr -e techproducts -m 10m}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6127) fix mockanalyzer to not use asserts
[ https://issues.apache.org/jira/browse/LUCENE-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253807#comment-14253807 ] Michael McCandless commented on LUCENE-6127: +1 Thank you for fixing TestCachingTokenFilter to be more precise in its check for an exception. fix mockanalyzer to not use asserts --- Key: LUCENE-6127 URL: https://issues.apache.org/jira/browse/LUCENE-6127 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6127.patch Currently MockAnalyzer's checks are implemented with assert. But this is just for convenience, we should not rely upon asserts being turned on: this is the whole point of the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6127) fix mockanalyzer to not use asserts
[ https://issues.apache.org/jira/browse/LUCENE-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253815#comment-14253815 ] David Smiley commented on LUCENE-6127: -- +1 Nice. fix mockanalyzer to not use asserts --- Key: LUCENE-6127 URL: https://issues.apache.org/jira/browse/LUCENE-6127 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6127.patch Currently MockAnalyzer's checks are implemented with assert. But this is just for convenience, we should not rely upon asserts being turned on: this is the whole point of the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6122) explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig
[ https://issues.apache.org/jira/browse/LUCENE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253821#comment-14253821 ] Robert Muir commented on LUCENE-6122: - +1, this will help reproducibility when using CMS explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig --- Key: LUCENE-6122 URL: https://issues.apache.org/jira/browse/LUCENE-6122 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-6122.patch This is just like not using FSDirectory.open in tests. The same seed should do the same stuff on different machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6128) Add stricter ant/build option for developers?
Michael McCandless created LUCENE-6128: -- Summary: Add stricter ant/build option for developers? Key: LUCENE-6128 URL: https://issues.apache.org/jira/browse/LUCENE-6128 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Can we add a build option (-Dpendantic=true) that is more anal? E.g. on backporting a change from trunk (java 8) to 5.x (java 7) I very rarely remember to use java 7 to compile/test. Sure, we set javac.source/target to 1.7, but that's not perfect (e.g. an interface w/ a default method as of java 8). With this option set we could do things like require you are using java 7 on 5.x, fail on warnings, etc. Casual users/developers can then still use java 8 to run tests, etc. (the option would default to off). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6128) Add stricter ant/build option for developers?
[ https://issues.apache.org/jira/browse/LUCENE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253854#comment-14253854 ] Robert Muir commented on LUCENE-6128: - +1, this sounds great. Less jenkins failures. Add stricter ant/build option for developers? - Key: LUCENE-6128 URL: https://issues.apache.org/jira/browse/LUCENE-6128 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Can we add a build option (-Dpendantic=true) that is more anal? E.g. on backporting a change from trunk (java 8) to 5.x (java 7) I very rarely remember to use java 7 to compile/test. Sure, we set javac.source/target to 1.7, but that's not perfect (e.g. an interface w/ a default method as of java 8). With this option set we could do things like require you are using java 7 on 5.x, fail on warnings, etc. Casual users/developers can then still use java 8 to run tests, etc. (the option would default to off). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6122) explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig
[ https://issues.apache.org/jira/browse/LUCENE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253905#comment-14253905 ] ASF subversion and git services commented on LUCENE-6122: - Commit 1646850 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1646850 ] LUCENE-6122: always set CMS settings in LuceneTestCase.newIndexWriterConfig explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig --- Key: LUCENE-6122 URL: https://issues.apache.org/jira/browse/LUCENE-6122 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-6122.patch This is just like not using FSDirectory.open in tests. The same seed should do the same stuff on different machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6128) Add stricter ant/build option for developers?
[ https://issues.apache.org/jira/browse/LUCENE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253917#comment-14253917 ] David Smiley commented on LUCENE-6128: -- +1 I could have used that today ;-P Add stricter ant/build option for developers? - Key: LUCENE-6128 URL: https://issues.apache.org/jira/browse/LUCENE-6128 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Can we add a build option (-Dpendantic=true) that is more anal? E.g. on backporting a change from trunk (java 8) to 5.x (java 7) I very rarely remember to use java 7 to compile/test. Sure, we set javac.source/target to 1.7, but that's not perfect (e.g. an interface w/ a default method as of java 8). With this option set we could do things like require you are using java 7 on 5.x, fail on warnings, etc. Casual users/developers can then still use java 8 to run tests, etc. (the option would default to off). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-4839: Attachment: SOLR-4839.patch I'm attaching this patch as a checkpoint. # Fixed some compile failures in StartSolrJetty and SolrRequestParserTest # Modified jetty.xml and solr-jetty-context.xml to conform to Jetty 9 changes Todo: # Fix the SSL example # The example doesn't work right now because unlike previous versions of jetty, jetty.home is resolved as the location of start.jar which gets resolved to the ivy cache path which messes up our configuration. # Jetty 9 has this concept of modules which can be configured via property files and/or by xml. We could do away with XML configuration if we want. Opinions? Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6122) explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig
[ https://issues.apache.org/jira/browse/LUCENE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253946#comment-14253946 ] ASF subversion and git services commented on LUCENE-6122: - Commit 1646853 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646853 ] LUCENE-6122: always set CMS settings in LuceneTestCase.newIndexWriterConfig explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig --- Key: LUCENE-6122 URL: https://issues.apache.org/jira/browse/LUCENE-6122 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Attachments: LUCENE-6122.patch This is just like not using FSDirectory.open in tests. The same seed should do the same stuff on different machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6122) explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig
[ https://issues.apache.org/jira/browse/LUCENE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6122. Resolution: Fixed Fix Version/s: 5.x Trunk explicitly always set CMS values in LuceneTestCase.newIndexWriterConfig --- Key: LUCENE-6122 URL: https://issues.apache.org/jira/browse/LUCENE-6122 Project: Lucene - Core Issue Type: Test Reporter: Robert Muir Fix For: Trunk, 5.x Attachments: LUCENE-6122.patch This is just like not using FSDirectory.open in tests. The same seed should do the same stuff on different machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253944#comment-14253944 ] Shalin Shekhar Mangar edited comment on SOLR-4839 at 12/19/14 8:19 PM: --- I'm attaching this patch as a checkpoint. # Fixed some compile failures in StartSolrJetty and SolrRequestParserTest # Modified jetty.xml and solr-jetty-context.xml to conform to Jetty 9 changes Todo: # Fix the SSL example # Fix the failing tests # The example doesn't work right now because unlike previous versions of jetty, jetty.home is resolved as the location of start.jar which gets resolved to the ivy cache path which messes up our configuration. # Jetty 9 has this concept of modules which can be configured via property files and/or by xml. We could do away with XML configuration if we want. Opinions? was (Author: shalinmangar): I'm attaching this patch as a checkpoint. # Fixed some compile failures in StartSolrJetty and SolrRequestParserTest # Modified jetty.xml and solr-jetty-context.xml to conform to Jetty 9 changes Todo: # Fix the SSL example # The example doesn't work right now because unlike previous versions of jetty, jetty.home is resolved as the location of start.jar which gets resolved to the ivy cache path which messes up our configuration. # Jetty 9 has this concept of modules which can be configured via property files and/or by xml. We could do away with XML configuration if we want. Opinions? Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253968#comment-14253968
]
ASF subversion and git services commented on LUCENE-6124:
-
Commit 1646854 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1646854 ]
LUCENE-6124: fix broken close() methods in .store/.codec apis
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-6680) DefaultSolrHighlighter can sometimes avoid CachingTokenFilter
[ https://issues.apache.org/jira/browse/SOLR-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reopened SOLR-6680: Re-opening for incremental improvement: The next patch further reduces token caching in DefaultSolrHighlighter, this time by TermOffsetsTokenStream, which is used for multi-valued fields with term vectors to provide an offset based view/window into the token stream. I found the name unclear so I also renamed it to OffsetWindowTokenFilter with a comment to clarify it's used for multi-valued term vectors. I found the variable names unclear so I renamed them too. It used to call captureState restoreState for every token; now it only does it for the first token leading into the next value. It used to use a cloned AttributeSource but I found there to be no point to that, plus it interferes with TokenStreamFromTermVector's ability to detect if payloads are desired. DefaultSolrHighlighter can sometimes avoid CachingTokenFilter - Key: SOLR-6680 URL: https://issues.apache.org/jira/browse/SOLR-6680 Project: Solr Issue Type: Improvement Components: highlighter Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: SOLR-6680.patch, SOLR-6680.patch The DefaultSolrHighlighter (the most accurate one) is a bit over-eager to wrap the token stream in a CachingTokenFilter when hl.usePhraseHighlighter=true. This wastes memory, and it interferes with other optimizations -- LUCENE-6034. Furthermore, the internal TermOffsetsTokenStream (used when TermVectors are used with this) wasn't properly delegating reset(). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6680) DefaultSolrHighlighter can sometimes avoid CachingTokenFilter
[ https://issues.apache.org/jira/browse/SOLR-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-6680: --- Attachment: SOLR-6680_Solr_Highligher,_part_2,_OffsetWindowTokenFilter.patch I'll commit Monday if there's no feedback. DefaultSolrHighlighter can sometimes avoid CachingTokenFilter - Key: SOLR-6680 URL: https://issues.apache.org/jira/browse/SOLR-6680 Project: Solr Issue Type: Improvement Components: highlighter Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: SOLR-6680.patch, SOLR-6680.patch, SOLR-6680_Solr_Highligher,_part_2,_OffsetWindowTokenFilter.patch The DefaultSolrHighlighter (the most accurate one) is a bit over-eager to wrap the token stream in a CachingTokenFilter when hl.usePhraseHighlighter=true. This wastes memory, and it interferes with other optimizations -- LUCENE-6034. Furthermore, the internal TermOffsetsTokenStream (used when TermVectors are used with this) wasn't properly delegating reset(). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-6124.
-
Resolution: Fixed
Fix Version/s: Trunk
5.0
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 5.0, Trunk
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254021#comment-14254021
]
ASF subversion and git services commented on LUCENE-6124:
-
Commit 1646868 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1646868 ]
LUCENE-6124: fix broken close() methods in .store/.codec apis
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 5.0, Trunk
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6867) bin/solr -e foo should use collection/cores api to check if collection/core exists before trying to create it
[
https://issues.apache.org/jira/browse/SOLR-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter reassigned SOLR-6867:
Assignee: Timothy Potter
bin/solr -e foo should use collection/cores api to check if collection/core
exists before trying to create it
-
Key: SOLR-6867
URL: https://issues.apache.org/jira/browse/SOLR-6867
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Timothy Potter
currently if you run an example command and the core/collection being created
already exists you get an error message in the console, ut then the example
keeps working (see below).
I think it would be better if the script used the cores api (or collection
api in the 'cloud' example) to check if the collection already existed, and
if so just output a note about it, something like...
{noformat}
Core API indicates a core named 'techproducts' already exists...
http://localhost:8983/solr/admin/cores?action=statuscore=techproducts
To remove this core, use the following command...
bin/solr ...etc...
And then you can recreate it with...
bin/solr ...etc...
{noformat}
Current behavior...
{noformat}
...
Creating new core 'techproducts' using command:
http://localhost:8983/solr/admin/cores?action=CREATEname=techproductsinstanceDir=techproducts
Exception in thread main org.apache.solr.client.solrj.SolrServerException:
Request to
http://localhost:8983/solr/admin/cores?action=CREATEname=techproductsinstanceDir=techproducts
failed due to: Core with name 'techproducts' already exists.
at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:473)
at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:416)
at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:402)
at
org.apache.solr.util.SolrCLI$CreateCoreTool.runTool(SolrCLI.java:1274)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:185)
Indexing tech product example docs from
/home/hossman/lucene/5x_dev/solr/example/exampledocs
SimplePostTool version 1.5
Posting files to base url http://localhost:8983/solr/techproducts/update
using content-type application/xml..
...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 708 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/708/ 2 tests failed. REGRESSION: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testDistribSearch Error Message: IOException occured when talking to server at: http://127.0.0.1:53787/disj/m/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:53787/disj/m/collection1 at __randomizedtesting.SeedInfo.seed([9B00FFD089472389:1AE671C8FE1843B5]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:580) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:213) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:209) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.cloud.CloudInspectUtil.compareResults(CloudInspectUtil.java:223) at org.apache.solr.cloud.CloudInspectUtil.compareResults(CloudInspectUtil.java:165) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrServer(FullSolrCloudDistribCmdsTest.java:414) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.doTest(FullSolrCloudDistribCmdsTest.java:144) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-4509) Disable HttpClient stale check for performance and fewer spurious connection errors.
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254036#comment-14254036 ] Mark Miller commented on SOLR-4509: --- Okay, this will not affect socket timeout settings. I was seeing something else with the difference in exceptions from SSL slowness it seems. I have something pretty solid now. I still have not figured out why the SolrCloud tests that use the proxy stuff to simulate network partitions don't work yet, but other than that things are coming together nicely I think. Disable HttpClient stale check for performance and fewer spurious connection errors. Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Assignee: Mark Miller Priority: Minor Fix For: 5.0, Trunk Attachments: IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, baremetal-stale-nostale-med-latency.dat, baremetal-stale-nostale-med-latency.svg, baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. ReviewBoard: https://reviews.apache.org/r/28393/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6127) fix mockanalyzer to not use asserts
[ https://issues.apache.org/jira/browse/LUCENE-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254049#comment-14254049 ] ASF subversion and git services commented on LUCENE-6127: - Commit 1646878 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1646878 ] LUCENE-6127: fix mockanalyzer to not use asserts fix mockanalyzer to not use asserts --- Key: LUCENE-6127 URL: https://issues.apache.org/jira/browse/LUCENE-6127 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6127.patch Currently MockAnalyzer's checks are implemented with assert. But this is just for convenience, we should not rely upon asserts being turned on: this is the whole point of the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6869) need beter param sanity checking error reporting in CoreAdmin API (and probably CollectionAdmin API)
Hoss Man created SOLR-6869:
--
Summary: need beter param sanity checking error reporting in
CoreAdmin API (and probably CollectionAdmin API)
Key: SOLR-6869
URL: https://issues.apache.org/jira/browse/SOLR-6869
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Priority: Minor
Today i made the mistake of doing this...
http://localhost:8983/solr/admin/cores?action=RELOADname=techproducts
...that request causes an NPE to be thrown by TreeMap.containsKey -- can you
guess why?
... it's because i have the wrong param name (it should be
{{core=techproducts}} ) and CoreAdminHandler.handleReloadAction doesn't bother
to validate the input it gets (or doesn't get in this case since core param
is completely missing) before passing values on to lower level code.
we should audit all of the CoreAdminHandler API methods (and the
CollectionAdminHandler methods) and make sure they return meaningful error
messages if the mandatory request params are missing -- we can easily write
tests that validate the expected error is thrown when various params are
missing/bogus.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [CI] Lucene Linux Java 8 64 Test Only - Build # 18889 - Failure!
I think this is a double-close() bug in mock windows itself. I am looking into it. On Fri, Dec 19, 2014 at 4:55 PM, bu...@elasticsearch.com wrote: *BUILD FAILURE* Build URL http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/ Project:lucene_trunk_linux_java8_64_test_only Date of build:Fri, 19 Dec 2014 22:53:20 +0100 Build duration:2 min 20 sec *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/core/test/temp/junit4-J0-20141219_225326_756.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20141219_225326_756.events checkout/lucene/build/core/test/temp/junit4-J1-20141219_225326_756.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20141219_225326_756.events checkout/lucene/build/core/test/temp/junit4-J2-20141219_225326_757.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20141219_225326_757.events checkout/lucene/build/core/test/temp/junit4-J3-20141219_225326_757.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20141219_225326_757.events checkout/lucene/build/core/test/temp/junit4-J4-20141219_225326_771.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20141219_225326_771.events checkout/lucene/build/core/test/temp/junit4-J5-20141219_225326_771.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20141219_225326_771.events checkout/lucene/build/core/test/temp/junit4-J6-20141219_225326_772.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20141219_225326_772.events checkout/lucene/build/core/test/temp/junit4-J7-20141219_225326_772.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20141219_225326_772.events *FAILED JUNIT TESTS* Name: org.apache.lucene.index Failed: 1 test(s), Passed: 738 test(s), Skipped: 20 test(s), Total: 759 test(s) *Failed: org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test * *CONSOLE OUTPUT* [...truncated 1580 lines...] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test [junit4] [junit4] [junit4] JVM J0: 0.91 .. 123.56 = 122.65s [junit4] JVM J1: 0.90 .. 124.98 = 124.07s [junit4] JVM J2: 0.89 .. 122.74 = 121.85s [junit4] JVM J3: 0.91 .. 124.70 = 123.79s [junit4] JVM J4: 1.13 .. 126.25 = 125.13s [junit4] JVM J5: 0.99 .. 123.06 = 122.07s [junit4] JVM J6: 1.14 .. 124.78 = 123.64s [junit4] JVM J7: 0.90 .. 122.63 = 121.73s [junit4] Execution time total: 2 minutes 6 seconds [junit4] Tests summary: 408 suites, 3164 tests, 1 error, 63 ignored (53 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/build.xml:49: The following error occurred while executing this line: /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:1349: The following error occurred while executing this line: /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:956: There were test failures: 408 suites, 3164 tests, 1 error, 63 ignored (53 assumptions) Total time: 2 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254111#comment-14254111
]
ASF subversion and git services commented on LUCENE-6124:
-
Commit 1646889 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1646889 ]
LUCENE-6124: fix double-close() bugs in WindowsFS etc
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 5.0, Trunk
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [CI] Lucene Linux Java 8 64 Test Only - Build # 18889 - Failure!
I committed a fix. On Fri, Dec 19, 2014 at 5:09 PM, Robert Muir robert.m...@elasticsearch.com wrote: I think this is a double-close() bug in mock windows itself. I am looking into it. On Fri, Dec 19, 2014 at 4:55 PM, bu...@elasticsearch.com wrote: *BUILD FAILURE* Build URL http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/ Project:lucene_trunk_linux_java8_64_test_only Date of build:Fri, 19 Dec 2014 22:53:20 +0100 Build duration:2 min 20 sec *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/core/test/temp/junit4-J0-20141219_225326_756.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20141219_225326_756.events checkout/lucene/build/core/test/temp/junit4-J1-20141219_225326_756.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20141219_225326_756.events checkout/lucene/build/core/test/temp/junit4-J2-20141219_225326_757.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20141219_225326_757.events checkout/lucene/build/core/test/temp/junit4-J3-20141219_225326_757.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20141219_225326_757.events checkout/lucene/build/core/test/temp/junit4-J4-20141219_225326_771.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20141219_225326_771.events checkout/lucene/build/core/test/temp/junit4-J5-20141219_225326_771.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20141219_225326_771.events checkout/lucene/build/core/test/temp/junit4-J6-20141219_225326_772.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20141219_225326_772.events checkout/lucene/build/core/test/temp/junit4-J7-20141219_225326_772.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/18889/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20141219_225326_772.events *FAILED JUNIT TESTS* Name: org.apache.lucene.index Failed: 1 test(s), Passed: 738 test(s), Skipped: 20 test(s), Total: 759 test(s) *Failed: org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test * *CONSOLE OUTPUT* [...truncated 1580 lines...] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test [junit4] [junit4] [junit4] JVM J0: 0.91 .. 123.56 = 122.65s [junit4] JVM J1: 0.90 .. 124.98 = 124.07s [junit4] JVM J2: 0.89 .. 122.74 = 121.85s [junit4] JVM J3: 0.91 .. 124.70 = 123.79s [junit4] JVM J4: 1.13 .. 126.25 = 125.13s [junit4] JVM J5: 0.99 .. 123.06 = 122.07s [junit4] JVM J6: 1.14 .. 124.78 = 123.64s [junit4] JVM J7: 0.90 .. 122.63 = 121.73s [junit4] Execution time total: 2 minutes 6 seconds [junit4] Tests summary: 408 suites, 3164 tests, 1 error, 63 ignored (53 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/build.xml:49: The following error occurred while executing this line: /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:1349: The following error occurred while executing this line: /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:956: There were test failures: 408 suites, 3164 tests, 1 error, 63 ignored (53 assumptions) Total time: 2 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st
[jira] [Commented] (LUCENE-6127) fix mockanalyzer to not use asserts
[ https://issues.apache.org/jira/browse/LUCENE-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254118#comment-14254118 ] ASF subversion and git services commented on LUCENE-6127: - Commit 1646890 from [~rcmuir] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1646890 ] LUCENE-6127: fix mockanalyzer to not use asserts fix mockanalyzer to not use asserts --- Key: LUCENE-6127 URL: https://issues.apache.org/jira/browse/LUCENE-6127 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6127.patch Currently MockAnalyzer's checks are implemented with assert. But this is just for convenience, we should not rely upon asserts being turned on: this is the whole point of the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2351 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2351/ 4 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: expected:...5C18C4F6A2BA1-001/te[mpDir-003/solrj_test_core_props_shard1_replica1] but was:...5C18C4F6A2BA1-001/te[stPropertyParamsForCreate-001/instanceDir-ksif] Stack Trace: org.junit.ComparisonFailure: expected:...5C18C4F6A2BA1-001/te[mpDir-003/solrj_test_core_props_shard1_replica1] but was:...5C18C4F6A2BA1-001/te[stPropertyParamsForCreate-001/instanceDir-ksif] at __randomizedtesting.SeedInfo.seed([69B5C18C4F6A2BA1:E8534F9438354B9D]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.checkInstanceDirs(CollectionsAPIDistributedZkTest.java:1154) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:901) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:205) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254142#comment-14254142
]
ASF subversion and git services commented on LUCENE-6124:
-
Commit 1646897 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1646897 ]
LUCENE-6124: fix double-close bug in BaseDirectoryWrapper
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 5.0, Trunk
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254144#comment-14254144
]
ASF subversion and git services commented on LUCENE-6124:
-
Commit 1646898 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1646898 ]
LUCENE-6124: fix double-close() bugs in WindowsFS etc
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 5.0, Trunk
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6124) Fix broken close() methods
[
https://issues.apache.org/jira/browse/LUCENE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254145#comment-14254145
]
ASF subversion and git services commented on LUCENE-6124:
-
Commit 1646899 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1646899 ]
LUCENE-6124: fix double-close bug in BaseDirectoryWrapper
Fix broken close() methods
--
Key: LUCENE-6124
URL: https://issues.apache.org/jira/browse/LUCENE-6124
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 5.0, Trunk
Attachments: LUCENE-6124.patch, LUCENE-6124.patch, LUCENE-6124.patch,
LUCENE-6124_asserts.patch, LUCENE-6124_asserts.patch
Closeable.close() says If the stream is already closed then invoking this
method has no effect..
But a lot of our code does not really respect that. If i add an extra
close() call in assertingcodec, it finds all kinds of bugs in codec code, for
example:
{noformat}
[junit4] Tests with failures (first 10 out of 59):
[junit4] -
org.apache.lucene.index.TestCrashCausesCorruptIndex.testCrashCorruptsIndexing
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsOnly
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqs
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testRandom
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4] -
org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat.testDocsAndFreqsAndPositions
[junit4] - org.apache.lucene.index.TestDirectoryReader.testFilesOpenClose
[junit4] -
org.apache.lucene.index.TestIndexWriterDelete.testIndexingThenDeleting
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 18941 - Failure!
Test bug in BaseDirectoryWrapper. If close() is called multiple times, it will try to checkIndex() a closed index. I committed a fix. On Fri, Dec 19, 2014 at 5:18 PM, bu...@elasticsearch.com wrote: *BUILD FAILURE* Build URL http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/ Project:lucene_4x_linux_java8_64_test_only Date of build:Fri, 19 Dec 2014 23:16:01 +0100 Build duration:2 min 16 sec *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/core/test/temp/junit4-J0-20141219_231606_779.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20141219_231606_779.events checkout/lucene/build/core/test/temp/junit4-J1-20141219_231606_779.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20141219_231606_779.events checkout/lucene/build/core/test/temp/junit4-J2-20141219_231606_780.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20141219_231606_780.events checkout/lucene/build/core/test/temp/junit4-J3-20141219_231606_781.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20141219_231606_781.events checkout/lucene/build/core/test/temp/junit4-J4-20141219_231606_784.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20141219_231606_784.events checkout/lucene/build/core/test/temp/junit4-J5-20141219_231606_781.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20141219_231606_781.events checkout/lucene/build/core/test/temp/junit4-J6-20141219_231606_781.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20141219_231606_781.events checkout/lucene/build/core/test/temp/junit4-J7-20141219_231606_784.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18941/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20141219_231606_784.events *FAILED JUNIT TESTS* Name: org.apache.lucene.store Failed: 1 test(s), Passed: 377 test(s), Skipped: 9 test(s), Total: 387 test(s) *Failed: org.apache.lucene.store.TestRateLimitedDirectoryWrapper.testDoubleCloseDirectory * *CONSOLE OUTPUT* [...truncated 1526 lines...] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.store.TestRateLimitedDirectoryWrapper.testDoubleCloseDirectory [junit4] [junit4] [junit4] JVM J0: 0.95 .. 117.58 = 116.64s [junit4] JVM J1: 1.20 .. 119.44 = 118.24s [junit4] JVM J2: 1.03 .. 117.03 = 116.00s [junit4] JVM J3: 0.94 .. 124.07 = 123.13s [junit4] JVM J4: 0.95 .. 117.73 = 116.78s [junit4] JVM J5: 1.23 .. 120.17 = 118.94s [junit4] JVM J6: 1.20 .. 116.95 = 115.75s [junit4] JVM J7: 0.94 .. 117.63 = 116.69s [junit4] Execution time total: 2 minutes 4 seconds [junit4] Tests summary: 408 suites, 3161 tests, 1 error, 63 ignored (53 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_4x_linux_java8_64_test_only/checkout/lucene/build.xml:49: The following error occurred while executing this line: /home/jenkins/workspace/lucene_4x_linux_java8_64_test_only/checkout/lucene/common-build.xml:1363: The following error occurred while executing this line: /home/jenkins/workspace/lucene_4x_linux_java8_64_test_only/checkout/lucene/common-build.xml:970: There were test failures: 408 suites, 3161 tests, 1 error, 63 ignored (53 assumptions) Total time: 2 minutes 11 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st
Re: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 18933 - Failure!
This is the same double-checkindex bug (fixed) On Fri, Dec 19, 2014 at 4:27 PM, bu...@elasticsearch.com wrote: *BUILD FAILURE* Build URL http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/ Project:lucene_4x_linux_java8_64_test_only Date of build:Fri, 19 Dec 2014 22:25:01 +0100 Build duration:2 min 28 sec *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/core/test/temp/junit4-J0-20141219_222508_101.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20141219_222508_101.events checkout/lucene/build/core/test/temp/junit4-J1-20141219_222508_101.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20141219_222508_101.events checkout/lucene/build/core/test/temp/junit4-J2-20141219_222508_103.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20141219_222508_103.events checkout/lucene/build/core/test/temp/junit4-J3-20141219_222508_102.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20141219_222508_102.events checkout/lucene/build/core/test/temp/junit4-J4-20141219_222508_103.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20141219_222508_103.events checkout/lucene/build/core/test/temp/junit4-J5-20141219_222508_103.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20141219_222508_103.events checkout/lucene/build/core/test/temp/junit4-J6-20141219_222508_103.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20141219_222508_103.events checkout/lucene/build/core/test/temp/junit4-J7-20141219_222508_103.events http://build-eu-00.elasticsearch.org/job/lucene_4x_linux_java8_64_test_only/18933/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20141219_222508_103.events *FAILED JUNIT TESTS* Name: org.apache.lucene.store Failed: 1 test(s), Passed: 377 test(s), Skipped: 9 test(s), Total: 387 test(s) *Failed: org.apache.lucene.store.TestDirectory.testDoubleCloseDirectory * *CONSOLE OUTPUT* [...truncated 1523 lines...] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.store.TestDirectory.testDoubleCloseDirectory [junit4] [junit4] [junit4] JVM J0: 1.03 .. 127.15 = 126.12s [junit4] JVM J1: 1.06 .. 128.32 = 127.25s [junit4] JVM J2: 1.03 .. 126.67 = 125.64s [junit4] JVM J3: 1.03 .. 126.68 = 125.65s [junit4] JVM J4: 1.13 .. 126.37 = 125.24s [junit4] JVM J5: 1.02 .. 126.86 = 125.84s [junit4] JVM J6: 1.27 .. 129.54 = 128.27s [junit4] JVM J7: 1.26 .. 133.64 = 132.38s [junit4] Execution time total: 2 minutes 13 seconds [junit4] Tests summary: 408 suites, 3161 tests, 1 error, 62 ignored (52 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_4x_linux_java8_64_test_only/checkout/lucene/build.xml:49: The following error occurred while executing this line: /home/jenkins/workspace/lucene_4x_linux_java8_64_test_only/checkout/lucene/common-build.xml:1363: The following error occurred while executing this line: /home/jenkins/workspace/lucene_4x_linux_java8_64_test_only/checkout/lucene/common-build.xml:970: There were test failures: 408 suites, 3161 tests, 1 error, 62 ignored (52 assumptions) Total time: 2 minutes 21 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st
[jira] [Commented] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254329#comment-14254329 ] Steve Davids commented on SOLR-4839: bq. Jetty 9 has this concept of modules which can be configured via property files and/or by xml. We could do away with XML configuration if we want. I actually like the module concept but I'm not sure how much of that you are going to want to bundle in Solr itself (copying module files). Let me know if you want a hand with any of the TODOs. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6859) Disable REBALANCELEADERS for 5.0
[ https://issues.apache.org/jira/browse/SOLR-6859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254338#comment-14254338 ] ASF subversion and git services commented on SOLR-6859: --- Commit 1646904 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1646904 ] SOLR-6859: Disable REBALANCELEADERS for 5.0 Disable REBALANCELEADERS for 5.0 Key: SOLR-6859 URL: https://issues.apache.org/jira/browse/SOLR-6859 Project: Solr Issue Type: Bug Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Attachments: SOLR-6859.patch This is flat dangerous with it's current implementation and should not get into the wild. The (I hope) proper fix is in SOLR-6691. I want to let that code bake for a while post 5.0 before committing though. So this will just comment the handling of REBALANCELEADERS from the collections API for the time being. Marked as blocker, but I should be able to take care of this ASAP so it shouldn't stand in the way of 5.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6859) Disable REBALANCELEADERS for 5.0
[ https://issues.apache.org/jira/browse/SOLR-6859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-6859: - Attachment: SOLR-6859.patch Comments out the Collecitons API endpoint. Tests for the API throwing an exception. Disable REBALANCELEADERS for 5.0 Key: SOLR-6859 URL: https://issues.apache.org/jira/browse/SOLR-6859 Project: Solr Issue Type: Bug Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Attachments: SOLR-6859.patch This is flat dangerous with it's current implementation and should not get into the wild. The (I hope) proper fix is in SOLR-6691. I want to let that code bake for a while post 5.0 before committing though. So this will just comment the handling of REBALANCELEADERS from the collections API for the time being. Marked as blocker, but I should be able to take care of this ASAP so it shouldn't stand in the way of 5.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254345#comment-14254345 ] Shalin Shekhar Mangar commented on SOLR-4839: - bq. I actually like the module concept but I'm not sure how much of that you are going to want to bundle in Solr itself (copying module files). Thanks Steve. I think we can: # Bundle http, https, ssl and server modules # Have a start.ini which has all the properties of the server (SSL and non-SSL) # Enable only the http related part but have all the SSL related properties there as comments Then I hope to have bin/solr enable/disable modules as necessary so that enabling ssl can be a matter of setting some environment variables and executing bin/solr with a special argument. Right now we use restlet-jee which is not compatible with Jetty9 but restlet-jse 2.3 is compatible. According to [~sar...@syr.edu] there is no special reason to use restlet-jee instead of restlet-jse so we may be able to switch to jse and upgrade the version to make it work. I'll attach another patch as a checkpoint in an hour or so. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
