We not only want to reuse the core, we also want to reuse indexes. If the index
is built in beforeClass you can run all tests against it. If you need another
index, write another test class :-) This speeded up the tests in Lucene and
Solr a lot. We now build indexes, that are global in the befor
: > Hmmm... except they were totally independent before.
:
: Conversion to the new style is not automatic - older style tests
: (those that extend TestCase) run as they always did.
Hmmm ... i'm sorry, my mistake, i spot checked a bunch of tests and
thought that everything which had previously s
On Wed, Apr 28, 2010 at 8:16 PM, Chris Hostetter
wrote:
> : That's extra time, and some test methods may rely on a persistent
> : index across multiple test methods. The move to Junit4 was not back
> : compatible - test methods are not independent.
>
> Hmmm... except they were totally independent
[
https://issues.apache.org/jira/browse/SOLR-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862051#action_12862051
]
Hoss Man commented on SOLR-1896:
Proposed semantics:
DateRangeQParser (aka: drange) with th
"fdx size mismatch" overflow causes RuntimeException
Key: LUCENE-2420
URL: https://issues.apache.org/jira/browse/LUCENE-2420
Project: Lucene - Java
Issue Type: Bug
Components: In
Add a Date Range QParser that makes it trivial to express date range filters
resulting from date faceting
-
Key: SOLR-1896
URL: https://issues.apache.org/jira/
[
https://issues.apache.org/jira/browse/SOLR-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-397:
--
Attachment: SOLR-397.patch
Spurred on by recent email threads about this, i sat down and got the
previously ment
: Rather than rewriting the original query, add a filter query (fq param on the
: HTTP interface). I think in the API you'll be using rb.getFilters() and
: adding a filter to List returned.
that's what would probably make the most sense -- especially from a
filter caching standpoint.
: Running
Hi Peter,
I'm more than happy to hear your customer's requirements, so no problem there.
It does seem to me that they are a bit different than what I've seen. I think
there is plenty of room for different flavors of solution, so please by all
means go ahead and propose your take on it!
Karl
Turns out that FilteredQuery is what is causing the issue in this case. I
removed FilteredQuery, and instead constructed the search using Query objects
instead of Filter objects, and everything is happy now.
Karl
From: Wright Karl (Nokia-S/Cambridge)
Se
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated SOLR-1895:
--
Attachment: LCFSecurityFilter.java
Updated version, using getFilters() and setFilters(), which seems res
: That's extra time, and some test methods may rely on a persistent
: index across multiple test methods. The move to Junit4 was not back
: compatible - test methods are not independent.
Hmmm... except they were totally independent before.
I'm actually amazed that our tests pass at all -- if ev
Hi Karl,
I wasn't trying to to put pay to your design proposal, really the opposite -
to highlight requirements that have found to be necessary for
customers/users, and to hopefully get the best functionality for the
product. If you feel I've put you out on any of the issues raised, then I
apologi
On Wed, Apr 28, 2010 at 7:59 PM, Chris Hostetter
wrote:
> I'm still left wondering why (if we're going to reuse teh SolrCore over
> and over) we don't have a common method in the test base class thta clears
> out the index after each test.
That's extra time, and some test methods may rely on a pe
: Yes, on purpose.
: I've actually restructured how this tests works a lot more in
: https://issues.apache.org/jira/browse/SOLR-1875 - let me commit that
: before proceeding with what you are trying to add.
:
: I actually index all of the documents only once, but in a random order
: and with rand
On Wed, Apr 28, 2010 at 6:57 PM, Chris Hostetter
wrote:
> As best i can figure the current setup isn't cleaning out the index between
> each of the running test methods
Yes, on purpose.
I've actually restructured how this tests works a lot more in
https://issues.apache.org/jira/browse/SOLR-1875 -
I tried the getFilters() approach. It turned out I also needed to create a
list and do setFilters() if getFilters() returns null, but that was easily
remedied. When this is done, it once again works fine if the component is
added "last". But if it is added "first", we now get a stack trace fr
That's certainly an option, and I had thought of it already, but the downside
is that you won't be able to search for documents that *aren't* indexed via LCF
under that model. Which is why I wanted to try to make the other approach fly.
FWIW, I was also told by a colleague that, because this is
: 1) am i understanding "beforeClass" correctly?
: 2) if so, then how is the current setup suppose to ensure that testAAA
: doesn't leave garbase arround that screws up testBBB ?
After skimming the JUnit annotation docs and experimenting, it looks like
the SolrCore is definitely getting reus
I was out of hte loop when the changes where made the all of hte Solr test
to make then more "JUnit4-ish" but now i'm trying to add some new test
methods and finding that my new tests, even when they succeed, are causing
ohter tests to fail -- even if i make no changes to the underlying code.
The best way to match documents that have no values for a specific
field, is to have a special term in that (or another) field, that you
add to the index when, well, a document has no values for that field.
Let's call this term - NULL. You then directly match on it with a
TermFilter/Query.
With you
Adding to the getFilters() list seems reasonable - although, to be fair, my
code does seem to work as intended when the component is added "last". I'll do
some experimentation and see what model things work most consistently with.
TermRangeQuery doesn't seem to map readily to the functionality
[
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861968#action_12861968
]
Uri Boness commented on SOLR-1163:
--
bq. So, how hard would it be to get this in Ant instead
Spellchecker method misnamed "accuraty"
---
Key: LUCENENET-360
URL: https://issues.apache.org/jira/browse/LUCENENET-360
Project: Lucene.Net
Issue Type: Bug
Reporter: Ben West
Priori
Spellchecker accuracy gets overwritten
--
Key: LUCENENET-359
URL: https://issues.apache.org/jira/browse/LUCENENET-359
Project: Lucene.Net
Issue Type: Bug
Reporter: Ben West
Priority
[
https://issues.apache.org/jira/browse/LUCENE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-2419.
-
Resolution: Fixed
Committed revision 939111.
> Improve parallel tests
> --
[
https://issues.apache.org/jira/browse/LUCENE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861960#action_12861960
]
Robert Muir commented on LUCENE-2419:
-
I plan to commit soon.
While there might be s
Rather than rewriting the original query, add a filter query (fq param
on the HTTP interface). I think in the API you'll be using
rb.getFilters() and adding a filter to List returned.
Running your component last won't work (will it?), as it needs to be
run before the "query" component to t
Turns out that, for the standard requestHandler, running this SearchComponent
first causes its rewritten query to be lost. Running last fixed the problem.
(I'd *love* to know why that would be necessary.)
But I'd still like comment as to whether the WildcardFilter construct is
expected to be
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated SOLR-1895:
--
Attachment: LCFSecurityFilter.java
Original grant of source code for LCFSecurityFilter.
> LCF SearchCom
LCF SearchComponent plugin for enforcing LCF security at search time
Key: SOLR-1895
URL: https://issues.apache.org/jira/browse/SOLR-1895
Project: Solr
Issue Type: New Featu
[
https://issues.apache.org/jira/browse/SOLR-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lance Norskog updated SOLR-1894:
Description:
The SolrItas sample app does not support multicore - it hard-codes the Solr URL
to the
[
https://issues.apache.org/jira/browse/MAHOUT-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen updated MAHOUT-387:
-
Priority: Minor (was: Major)
Nevermind I'll add UncenteredCosineSimilarity, can't hurt
> Cosine item si
[
https://issues.apache.org/jira/browse/MAHOUT-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen resolved MAHOUT-387.
--
Fix Version/s: 0.4
(was: 0.3)
Resolution: Fixed
> Cosine item similarity
[
https://issues.apache.org/jira/browse/MAHOUT-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen reopened MAHOUT-387:
--
> Cosine item similarity implementation
> -
>
> Key: MA
[
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861923#action_12861923
]
Grant Ingersoll commented on SOLR-1163:
---
So, how hard would it be to get this in Ant i
[
https://issues.apache.org/jira/browse/SOLR-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861919#action_12861919
]
Yonik Seeley commented on SOLR-1875:
I plan on committing this soon.
The public API is v
Also, other useful resources:
https://cwiki.apache.org/confluence/display/MAHOUT/HowToContribute and
https://cwiki.apache.org/confluence/display/MAHOUT/index#index-Committer%27sResources
-Grant
On Apr 28, 2010, at 3:41 PM, Grant Ingersoll wrote:
> One thing I'd encourage everyone to start on
One thing I'd encourage everyone to start on sooner rather than later is a
placeholder doc on the https://cwiki.apache.org/MAHOUT/algorithms.html page
that captures some of your background material as well as some links to your
JIRA issues.
Also, while it's not required, you might consider fili
[
https://issues.apache.org/jira/browse/LUCENE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2419:
Attachment: LUCENE-2419.patch
attached is a patch, all tests pass.
Additionally i fixed the probl
Improve parallel tests
--
Key: LUCENE-2419
URL: https://issues.apache.org/jira/browse/LUCENE-2419
Project: Lucene - Java
Issue Type: Improvement
Components: Build
Affects Versions: 3.1
Reporter:
Hi Solr-knowledgeable folks,
The LCF Solr SearchComponent plugin I'm developing doesn't quite work. The
query I'm trying to do is:
-(allow_token_document:*) and -(deny_token_document:*) and
The result I'm seeing is that everything in the user's search matches, unlike
what I see in the admin
Actually scratch that patch I sent over. I see the trick now that
makes the existing approach quite good. I think I can make a version
that preserves that trick and still streamlines the processing. I will
benchmark and report back if successful.
On Wed, Apr 28, 2010 at 3:20 PM, Sean Owen wrote:
On Apr 28, 2010, at 1:53 PM, Grant Ingersoll wrote:
>
>
> Begin forwarded message:
>
>> From: Sally Khudairi
>> Date: April 28, 2010 1:48:57 PM EDT
>> To: annou...@apachecon.com
>> Subject: Call for Participation: Technical Talks -- ApacheCon North America
>> 2010
>> Reply-To: s...@apache.or
Begin forwarded message:
> From: Sally Khudairi
> Date: April 28, 2010 1:48:57 PM EDT
> To: annou...@apachecon.com
> Subject: Call for Participation: Technical Talks -- ApacheCon North America
> 2010
> Reply-To: s...@apache.org
>
> ApacheCon North America 2010
> 1-5 November 2010 -- Westin Pe
I use 1.6.0_18.
Maybe seeding w/ System.nanoTime() will help, but don't you think
NativeFSLock should be more robust anyway? Even for the regular lock
file this can happen if at the same time delete() is attempted the
file is held by another process ...
Shai
On Wednesday, April 28, 2010, Michael
OK...
But this must mean that "new Random()" selects a bad (easily
conflicts) seed? Which JRE are you using?
Maybe it's just using System.currentTimeMills()? This is what the
javadocs state for JDK 1.4, but for JDK 1.5 it says it tries to pick
something unique :)
Maybe we should seed w/ System
Mike - I think I'm pretty sure that's what happened. The reason is
that even w/ the reported failure, the lock dir is empty when the
tests finish and the lock file isn't there. I believe that if the
collision was not the case, then I should have seen the test lock file
in there?
So overall these c
[
https://issues.apache.org/jira/browse/MAHOUT-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861850#action_12861850
]
Drew Farris commented on MAHOUT-388:
This seems pretty straightforward considering Coll
[
https://issues.apache.org/jira/browse/MAHOUT-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861850#action_12861850
]
Drew Farris edited comment on MAHOUT-388 at 4/28/10 1:23 PM:
-
T
Thanks John, I'll take a look at and see if we can help in terms of the ant
build stuff necessary to get this going - see my other email for the
administrative stuff (and some ant stuff) on moving this forward as well.
Thanks!
Cheers,
Chris
On 4/27/10 2:35 PM, "John Caron" wrote:
Hi Chris:
Hi John,
On 4/27/10 4:00 PM, "John Caron" wrote:
[...]
>> I can can volonter for updating the pom.xml files for future 4.x
>> versions of the NetCDF library, but we would probably need someone
>> else with credential for uploading to the central repo.
>>
>> Regards,
>>
>> Martin
Nice!
Mike
On Wed, Apr 28, 2010 at 12:54 PM, Robert Muir wrote:
> As far as the build system goes, I implemented the two ideas mentioned
> earlier in this message (not creating a new Formatter for each test, and not
> spawning 26 jvms for each batch)
>
> Jira is down, but if you want to help tes
As far as the build system goes, I implemented the two ideas mentioned
earlier in this message (not creating a new Formatter for each test, and not
spawning 26 jvms for each batch)
Jira is down, but if you want to help test you can try a patch here:
http://pastebin.com/iqwb73H2 (click Raw/Download
I think this are good changes to NativeFSLockFactory.
But: the chances that N JVMs launched at once would conflict on the
randomly generated lock file name should be miniscule... though it
does depend on how good new Random() is at seeding itself. Do we
really think this explains your exceptions
I'd like to summarize the IRC discussion Mark and I had:
The lock file's existence in the directory should not fail obtain() from
retrieving obtaining a lock. That's the whole difference between Simple and
Native. So we should make a best-effort to delete it. If the delete fails on
release(), then
[
https://issues.apache.org/jira/browse/LUCENE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-2417.
Resolution: Fixed
Committed revision 938989.
> Fix IndexCommit hashCode() and equals() to be cons
On 4/26/2010 7:57 PM, Mattmann, Chris A (388J) wrote:
FYI, [1] from here refers to:
[1] http://issues.apache.org/jira/browse/TIKA-153
On 4/26/10 6:46 PM, "Mattmann, Chris A (388J)"
wrote:
(copying tika-...@lucene.apache.org so that we can get some dev
help in Tika-land)
Hi Joh
I don't follow. The simple lock impl must delete the file, but the
native impl should not have to. The file has nothing to do with the lock
- its just the medium to ask for and release the lock. If it already
exists, you don't have to create it - you can just use it to try and get
a native lock
Hello, a possibly related thing: I ran some tests and a new Formatter is
created for each Test Suite.
This is pretty wasteful since we make a lot of lock factories and such, so
one thing to explore is using a singleton here so we arent making thousands
of test locks.
Additionally Shai pointed me
But this method is called also for the regular lock file - if release()
won't delete the file, then the next l.obtain() will return false.
Shai
On Wed, Apr 28, 2010 at 5:31 PM, Mark Miller wrote:
> It shouldn't need too though - the native lock file is simply a dummy file
> to apply the lock to
It shouldn't need too though - the native lock file is simply a dummy
file to apply the lock too - shouldn't matter if it already exists or
not (though it seems to in the current code).
On 4/28/10 10:22 AM, Shai Erera wrote:
If you won't delete the file, the next obtain will fail?
On Wed, Apr
If you won't delete the file, the next obtain will fail?
On Wed, Apr 28, 2010 at 5:12 PM, Mark Miller wrote:
> I wonder if not being able to delete the file should throw a release failed
> exception at all. You have actually released the native lock - you where
> just not able to clean up - but
Sorry, typo, that's what I meant. yes the difference isn't *that* large!
It may be worse in practice since you have a few users with very many prefs.
It may also be beneficial to simply have one fewer phase and throw
around less data. I will also try to benchmark since really that's the
only way to
I wonder if not being able to delete the file should throw a release
failed exception at all. You have actually released the native lock -
you where just not able to clean up - but that seems more like a warning
situation than a failure.
--
- Mark
http://www.lucidimagination.com
On 4/28/10
[
https://issues.apache.org/jira/browse/LUCENE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2417:
---
Attachment: LUCENE-2417.patch
Fixes hashCode() to use getVersion and adds TestIndexCommit. All tests
+1, I've found it confusing and I like MediaType better!
On 4/28/10 6:05 AM, "ju...@apache.org" wrote:
Author: jukka
Date: Wed Apr 28 13:05:14 2010
New Revision: 938976
URL: http://svn.apache.org/viewvc?rev=938976&view=rev
Log:
TIKA-89: Rename MimeType and MimeTypes
Make MimeType use MediaTyp
Hi Sean,
"Say I have P prefs, U users and I items.
Assume P/I prefs per item. The bottleneck of this stage is outputting
I2 vectors of size P/I, or about P*I output.
What you're doing now bottlenecks in the last bit where you output for
each user some data for every pair of items. That's coarsely
I've hit it again and here's the full stacktrace (at least what's printed):
[junit] Exception in thread "main" java.lang.RuntimeException: Failed to
acquire random test lock; please verify filesystem for lock directory
'C:\DOCUME~1\shaie\LOCALS~1\Temp\lucene_junit_lock' supports locking
[j
[
https://issues.apache.org/jira/browse/SOLR-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861802#action_12861802
]
Erik Hatcher commented on SOLR-1894:
Let's take security out of this issue though, Lance
[
https://issues.apache.org/jira/browse/SOLR-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861800#action_12861800
]
Eric Pugh commented on SOLR-1894:
-
I made full paths by adding in the core name which is in
Fix IndexCommit hashCode() and equals() to be consistent
Key: LUCENE-2417
URL: https://issues.apache.org/jira/browse/LUCENE-2417
Project: Lucene - Java
Issue Type: Bug
Compon
ok, since both of you say Dir + version, I'll go with your proposal :).
I can make all its methods abstract - have a hard time believing IndexCommit
is extended outside Lucene. Also, if someone extended it and didn't override
one of these methods, UOE would have hit him already?
Shai
On Wed, Apr
ok so you mean make sure both hashCode and equals work on Dir + version?
I think segFileName is better too, at least it makes it more clear. But I
assumed version is used for a reason in equals() and there's a specific jdoc
about it ...
But if Dir + segFileName is safe (seems like it), I think we
Good catch! We should make both hashCode & equals consistent.
I think Dir + version is best?
In theory Dir + segFileName should be equally good, since segFileName
<-> version is one-to-one/onto, but I think conceptually version is
the better "identifier" of change.
We really should make getVers
On 4/28/10 8:21 AM, Shai Erera wrote:
Hi
According to Java's hashCode jdoc, if two objects answer true to
o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir
+ segmentFileName in hashCode() and Dir + version in equals(). More so,
the jdoc of equals specifies that two IC equa
[
https://issues.apache.org/jira/browse/TIKA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861786#action_12861786
]
Jukka Zitting commented on TIKA-298:
I implemented a simple version of this in revision 9
Hi
According to Java's hashCode jdoc, if two objects answer true to
o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir +
segmentFileName in hashCode() and Dir + version in equals(). More so, the
jdoc of equals specifies that two IC equals if their Dirs are equals and the
have
78 matches
Mail list logo
