[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743061#action_12743061
]
Mark Miller commented on LUCENE-1791:
-
{quote}sweet. i'll review the patch for real to
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743039#action_12743039
]
Hoss Man commented on LUCENE-1791:
--
bq. The filter is applied per sub-reader
Doh! .. rig
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1791:
Attachment: LUCENE-1791.patch
> Enhance QueryUtils and CheckHIts to wrap everything they check in
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743036#action_12743036
]
Mark Miller commented on LUCENE-1791:
-
bq. Sweet! ... Even the random boolean query te
I was out, for the last few days.
Thanks for figuring that out.
Michael McCandless wrote:
Yes :) And I'm glad I managed to remember that we had done that!
Mike
On Mon, Aug 10, 2009 at 6:31 AM, Uwe Schindler wrote:
Yes! We had this problem also with the analyzers contrib missing the stop
w
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743032#action_12743032
]
Hoss Man commented on LUCENE-1791:
--
bq. Okay, I've got all tests passing.
Sweet! ... Eve
[
https://issues.apache.org/jira/browse/LUCENE-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Rutherglen updated LUCENE-1806:
-
Attachment: LUCENE-1806.patch
Adds ability to pass jvmarg(s) to JUnit task doing somethi
[
https://issues.apache.org/jira/browse/LUCENE-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Cowan updated LUCENE-1807:
---
Attachment: LUCENE-1807.patch
Patch to add extra constructor.
> Add convenient constructor to PerFi
Add convenient constructor to PerFieldAnalyzerWrapper for Dependency Injection
--
Key: LUCENE-1807
URL: https://issues.apache.org/jira/browse/LUCENE-1807
Project: Lucene - Jav
Add args to test-macro
--
Key: LUCENE-1806
URL: https://issues.apache.org/jira/browse/LUCENE-1806
Project: Lucene - Java
Issue Type: Improvement
Components: Build
Affects Versions: 2.4.1
Reporter
On Thu, Aug 13, 2009 at 6:03 PM, Shai Erera wrote:
> Also Mike - even if the writer has committed, and then I notify the other
> nodes they should refresh, it's still possible for them to hit this
> exception, right?
I'm hoping you won't hit the exception, as long as the updates are
less frequent
On Thu, Aug 13, 2009 at 6:02 PM, Shai Erera wrote:
> How can the writer delete all previous segments? If I have a reader open,
> doesn't it prevent those files to be deleted? That's why I count on any of
> those files to exist. Perhaps I'm wrong though.
The segments_N file is not held open... it's
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743000#action_12743000
]
Robert Muir commented on LUCENE-1794:
-
{quote}
What if one of those streams will becom
Also Mike - even if the writer has committed, and then I notify the other
nodes they should refresh, it's still possible for them to hit this
exception, right?
On Fri, Aug 14, 2009 at 1:02 AM, Shai Erera wrote:
> How can the writer delete all previous segments? If I have a reader open,
> doesn't
How can the writer delete all previous segments? If I have a reader open,
doesn't it prevent those files to be deleted? That's why I count on any of
those files to exist. Perhaps I'm wrong though.
I think we can come up w/ some notification mechanism, through MQ or
something.
Do you think it's wo
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742994#action_12742994
]
Shai Erera commented on LUCENE-1794:
bq. I only call reset() on streams.result when th
On Thu, Aug 13, 2009 at 5:33 PM, Shai Erera wrote:
> So if afterwards we read until segment_17 and exhaust read-ahead, and we
> determine that there's a problem - we throw the exception. If instead we'll
> try to read backwards, I'm sure one of the segments will be read
> successfully, because tha
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742988#action_12742988
]
Robert Muir commented on LUCENE-1794:
-
Shai thinking about this some more, as long as
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742984#action_12742984
]
Robert Muir commented on LUCENE-1794:
-
Shai, first of all let me address your first co
Well ... I was just thinking that today, because of stale caches, we might
read segments_5 from either segments.gen or directory listing, and attempt
to read and succeed. Then the reader will see the index 'until segment 5'.
So when I analyze the exception I think that:
* The directory listing cou
On Thu, Aug 13, 2009 at 5:02 PM, Shai Erera wrote:
> What about doing a read-backwards as well? I.e., if read ahead fails, try to
> read backwards --> we must be able to read any segment, no?
How would that help?
Ie, IndexWriter only writes "forwards". So if a filesystem cache is
stale, it must
[
https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742977#action_12742977
]
Grant Ingersoll edited comment on LUCENE-1790 at 8/13/09 2:23 PM:
--
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742978#action_12742978
]
Shai Erera commented on LUCENE-1794:
Also Robert, I've looked at the patch and I see t
[
https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1790:
Attachment: LUCENE-1790-position.patch
Pass in position information as well for scoring
>
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742974#action_12742974
]
Shai Erera commented on LUCENE-1794:
Robert, what I meant about pulling SavedStreams u
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1791:
Attachment: LUCENE-1791.patch
every so slight cleaned up
removed a couple unused imports
added a
[
https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742957#action_12742957
]
Grant Ingersoll edited comment on LUCENE-1790 at 8/13/09 2:03 PM:
--
What about doing a read-backwards as well? I.e., if read ahead fails, try to
read backwards --> we must be able to read any segment, no?
Shai
On Thu, Aug 13, 2009 at 9:29 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> This is spooky -- it looks like SMB2 (which was introduced with
On 08/13/2009 01:56 PM, Mark Miller wrote:
Shai Erera wrote:
So far Mike has resolved the issue again, so it sounds like we go w/
it ?
Lazy consensus - so its lookin good so far - but someone could still
derail us I suppose.
I've been a stick-in-the-mud wrt migrating to Java 5 in the past.
[
https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reopened LUCENE-1790:
-
Going to reopen and actually pass along the Term and the position information
into both the
[
https://issues.apache.org/jira/browse/LUCENE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1802.
Resolution: Fixed
> Un-deprecate QueryParser and remove documentation that says it
Tangent: Now that contrib/CHANGES.txt is getting regular updates, I think it
would make sense to generate a Changes.html corresponding to its contents, in
the same way that the core CHANGES.txt is transformed.
Looks like this Sandbox/Contrib page would be a good place to host it.
Steve
> -
Almost there.
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310110&fixfor=12312682
Looks like we will be ready by next week?
Anyone think thats too optimistic?
--
- Mark
http://www.lucidimagination.c
I like the idea of having syntax extensions,
and proposed something similar for "ComplexPhraseQueryParser" JIRA issue.
But we should create a new jira issue for this using the new queryparser,
this is a new feature an is not backward compatible with the current
lucene syntax.
For the syntax I
On 8/13/09 7:29 AM, Yonik Seeley wrote:
I'm liking the new attribute based analysis (in conjunction with
reusability), but I'm running into some questions...
Is it valid for tokenizers or token filters add new attributes after
their constructor (after they have processed some tokens)?
At
Looks like this page is a bit out of date:
http://lucene.apache.org/java/2_4_1/lucene-sandbox/index.html
been a while since its been the sandbox too ...
--
- Mark
http://www.lucidimagination.com
-
To unsubscribe, e-mail: j
[
https://issues.apache.org/jira/browse/LUCENE-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1789.
Resolution: Fixed
> getDocValues should provide a MultiReader DocValues abstractio
This is spooky -- it looks like SMB2 (which was introduced with Windows
Vista & Windows Server 2008) now does "aggressive" client-side
caching, such that the cache can be wrong about the current state of
the directory.
At least it sort of sounds like Microsoft considers it a real issue:
> Yes, th
[
https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742915#action_12742915
]
Jason Rutherglen commented on LUCENE-1720:
--
I've been using TimeLimitingCollector
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1791:
Attachment: LUCENE-1791.patch
> Enhance QueryUtils and CheckHIts to wrap everything they check in
Shai Erera wrote:
So far Mike has resolved the issue again, so it sounds like we go w/ it ?
Lazy consensus - so its lookin good so far - but someone could still
derail us I suppose.
--
- Mark
http://www.lucidimagination.com
[
https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742902#action_12742902
]
Shai Erera commented on LUCENE-1720:
We still haven't coded in the items on the commen
So far Mike has resolved the issue again, so it sounds like we go w/ it ?
Going forward, what about contribs that are on Java 1.6?
Personally I don't think it's wrong that benchmark will be on Java 1.5 or
even 1.6. Even that Lucene is 1.4, I believe many run it w/ 1.5 or 1.6, so
testing Lucene w/
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742900#action_12742900
]
Mark Miller commented on LUCENE-1791:
-
Okay, I've got all tests passing.
I rigged up
Shai Erera wrote:
On my next Benchmark issue will I be free to use 1.5 stuff? (kidding)
If we go with this than yes ;)
And if you had argued before that you wanted to test a 1.5 module with
Benchmark, I would have voted right behind you as well. Generics wasn't
enough to sway me :)
--
-
Like I said - you won't hear me complaining. On my next Benchmark issue will
I be free to use 1.5 stuff? (kidding)
Though... that was different, because that code hadn't been created yet
I actually did write the code, but didn't post the patch - so I guess it
doesn't count :).
I'm fine w/ it, I
[
https://issues.apache.org/jira/browse/LUCENE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1773.
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.9
Sett
Heh :)
Though... that was different, because that code hadn't been created
yet (I think) and so you were asking whether you could use 1.5. The
added work & cost of sticking with 1.4 was basically zero.
Whereas in this case we have new and useful functionality (the new
"fast vector highlighter")
Thats fair -
My inclination for anything in Contrib off the top is to keep it at 1.4
if its already at 1.4 - especially concerning language constructs and
what not.
However, this task is already in, it's nice to have, and thats enough to
sway me here.
The point that really gets me is that
Umm ... not that I'll complain, but look here:
https://issues.apache.org/jira/browse/LUCENE-1595?focusedCommentId=12711586&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12711586
And read the comments from both of you below :).
I s wanted to use generics in Ben
I could go for that as well :)
Mike
On Thu, Aug 13, 2009 at 12:02 PM, Mark Miller wrote:
> I'd almost just say Benchmark is 1.5 now. We try to keep contrib things that
> are 1.4 at 1.4, but why bend over backwards here to pull that task out?
> Technically there is no back compat promise here.
>
>
And further - it makes sense that Benchmark would work with contrib
modules and contrib allows 1.5 ...
Mark Miller wrote:
I'd almost just say Benchmark is 1.5 now. We try to keep contrib
things that are 1.4 at 1.4, but why bend over backwards here to pull
that task out? Technically there is no
Thanks Mike. I wouldn't mind doing it myself, but since you already reopened
... ;)
On Thu, Aug 13, 2009 at 6:56 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Sigh. I guess we have to pull that task for 2.9.
>
> I'll reopen the original issue (LUCENE-1773), note this, and mark it
I'd almost just say Benchmark is 1.5 now. We try to keep contrib things
that are 1.4 at 1.4, but why bend over backwards here to pull that task
out? Technically there is no back compat promise here.
The number of people relying on 1.4 for Benchmark has got to be ...
Michael McCandless wrote:
[
https://issues.apache.org/jira/browse/LUCENE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reopened LUCENE-1773:
Unfortunately, contrib/benchmark is 1.4 only, but the fast vector highlighter
is 1.5.
[
https://issues.apache.org/jira/browse/LUCENE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1773:
---
Fix Version/s: (was: 2.9)
3.0
> Add benchmark task for FastVe
Sigh. I guess we have to pull that task for 2.9.
I'll reopen the original issue (LUCENE-1773), note this, and mark it
as fix for 3.0.
Mike
On Thu, Aug 13, 2009 at 11:24 AM, Shai Erera wrote:
> Me too ... and you were suggesting to hold off w/ 3.0 and having 2.5 and
> then 2.9 ... :).
>
> What d
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742868#action_12742868
]
Mark Miller commented on LUCENE-1791:
-
I guess the out of bounds exception is still th
Me too ... and you were suggesting to hold off w/ 3.0 and having 2.5 and
then 2.9 ... :).
What do you think I should do w/ that task in the meantime?
Shai
On Thu, Aug 13, 2009 at 6:21 PM, Grant Ingersoll wrote:
> I _so_ can't wait to have this one off of our back for a while. Of course,
> then
I _so_ can't wait to have this one off of our back for a while. Of
course, then we'll have 1.6 creep... ;-)
On Aug 13, 2009, at 9:15 AM, Shai Erera wrote:
I up SVN and noticed some compilation errors in my eclipse in
SearchTravRetVectorHighlightTask. I added FastVectorHighlighter to
my b
On Aug 13, 2009, at 10:29 AM, Yonik Seeley wrote:
I'm liking the new attribute based analysis (in conjunction with
reusability), but I'm running into some questions...
Is it valid for tokenizers or token filters add new attributes after
their constructor (after they have processed some tokens)
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1805.
Resolution: Fixed
Thanks Shai!
> CloseableThreadLocal should allow null Objects
>
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742836#action_12742836
]
Michael McCandless commented on LUCENE-1805:
bq. Don't you want to move the te
I'm liking the new attribute based analysis (in conjunction with
reusability), but I'm running into some questions...
Is it valid for tokenizers or token filters add new attributes after
their constructor (after they have processed some tokens)?
Should restoreState() be able to add attributes (it
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742835#action_12742835
]
Shai Erera commented on LUCENE-1805:
I was just commenting that I should remove the mi
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1805:
---
Attachment: LUCENE-1805.patch
Attached small tweaks to the test (removed the mislead
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742831#action_12742831
]
Shai Erera commented on LUCENE-1805:
Oops, you're right. I overlooked it. So maybe the
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742830#action_12742830
]
Michael McCandless commented on LUCENE-1805:
bq. If you call ctl.get() w/o se
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1805:
--
Assignee: Michael McCandless
> CloseableThreadLocal should allow null Objects
ok patch is already submitted
On Thu, Aug 13, 2009 at 4:53 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> I think just fix it for 2.9? I don't think we're planning on a 2.4.2
> release at this point...
>
> Mike
>
> On Thu, Aug 13, 2009 at 8:53 AM, Shai Erera wrote:
> > Sure! shall
I think just fix it for 2.9? I don't think we're planning on a 2.4.2
release at this point...
Mike
On Thu, Aug 13, 2009 at 8:53 AM, Shai Erera wrote:
> Sure! shall I fix it on 2.4.1 as well? If so, how soon can we tag a 2.4.2?
> If not before 2.9, then it doesn't matter, at least to me, if it wi
[
https://issues.apache.org/jira/browse/LUCENE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-1805:
---
Attachment: LUCENE-1805.patch
Remove assert v != null and added a test case.
Funny, but it's as if
I up SVN and noticed some compilation errors in my eclipse in
SearchTravRetVectorHighlightTask. I added FastVectorHighlighter to my build
path, but it failed again because the latter is Java 1.5 compliant, and I
set the compiler level to 1.4 (to comply w/ core and benchmark level).
Maybe this task
CloseableThreadLocal should allow null Objects
--
Key: LUCENE-1805
URL: https://issues.apache.org/jira/browse/LUCENE-1805
Project: Lucene - Java
Issue Type: Bug
Components: contrib/analyz
Sure! shall I fix it on 2.4.1 as well? If so, how soon can we tag a 2.4.2?
If not before 2.9, then it doesn't matter, at least to me, if it will be
fixed on trunk only.
On Thu, Aug 13, 2009 at 3:20 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Let's just allow null? Can you open a
Hi
Has anyone experienced any problems w/ Lucene indexes on a shared SMB2
network drive?
We've hit a scenario where it seems the FS cache refuses to check for
existence of files on the shared network drive. Specifically, we hit the
following exception:
java.io.FileNotFoundException: Z:\index\seg
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742813#action_12742813
]
Mark Miller commented on LUCENE-1791:
-
Have you started working on the ItemizedFilter
Let's just allow null? Can you open an issue?
Mike
On Thu, Aug 13, 2009 at 6:18 AM, Shai Erera wrote:
> Hi
>
> I have an Analyzer which is given a Config object and when tokenStream or
> reusableTokenStream is called, it generates a TokenStream based on the
> Config settings. I also have a setCo
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-1794:
Attachment: LUCENE-1794.patch
with ShingleAnalyzerWrapper and tests, plan to do QueryAutoStopWord
Hi
I have an Analyzer which is given a Config object and when tokenStream or
reusableTokenStream is called, it generates a TokenStream based on the
Config settings. I also have a setConfig method on that Analyzer. setConfig
calls setPreviousTokenStream(null) so that next time reusableTokenStream i
[
https://issues.apache.org/jira/browse/LUCENE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742781#action_12742781
]
Erik Hatcher commented on LUCENE-1800:
--
Does anyone use PrecedenceQueryParser? It w
[
https://issues.apache.org/jira/browse/LUCENE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-1800:
Attachment: LUCENE-1800_analyzingQP.patch
not sure this belongs here, can do under some issue if y
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742758#action_12742758
]
Simon Willnauer commented on LUCENE-1791:
-
I just looked at the patch - one little
[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-1791:
-
Attachment: LUCENE-1791.patch
one other thing i experimented with earlier today was making the "wrapped"
84 matches
Mail list logo
