I think it's because we use a WeakReferenceT that inherits from
WeakReference, which in turn, requires has this security attribute:
SecurityPermissionAttribute(SecurityAction.InheritanceDemand, Flags =
SecurityPermissionFlag.UnmanagedCode)]. I'm going to test on a
machine with a medium trust CAS
Hi,
It got worse. Building a custom AttributeFactory can only handle a few
cases, I needed to subclass _every_ TokenStream/TokenFilter to override
all attribute-handling methods (AddAttribute, GetAttribute, etc), and
all analyzers to use these streams, to use a dictionary with strong
It'd be nice to understand where this issue is coming from as it wasn't in
2.9.4 rather than jumping to a quick fix imo. I'll dig a bit myself
~P
Date: Tue, 14 Aug 2012 17:32:29 +0200
From: si...@devhost.se
To: lucene-net-dev@lucene.apache.org
Subject: Re: Lucene.Net 3.0.3 and medium trust
Christopher Currens created LUCENENET-500:
-
Summary: Lucene fails to run in medium trust ASP.NET Application
Key: LUCENENET-500
URL: https://issues.apache.org/jira/browse/LUCENENET-500
[
https://issues.apache.org/jira/browse/LUCENENET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens resolved LUCENENET-500.
---
Resolution: Fixed
Issue was in the WeakKeyT class in WeakDictionary.cs.
Inheriting from WeakReference was the problem. I'm just going to
remove the wrapper entirely, it doesn't give us any real benefit. The
code has already been pushed.
Thanks,
Christopher
On Tue, Aug 14, 2012 at 8:46 AM, Prescott Nasser geobmx...@hotmail.com wrote:
It'd be nice to understand
We should probably try and have unit tests that will spin up medium
trust app domains and run some basic tests in them, so we don't
accidentally ship with something big like this. That is what I
initially tried to do to reproduce this bug on my end, but the code
that I would which should have
Yeah, very likely this bit... didn't look too deep.
Dawid
On Tue, Aug 14, 2012 at 7:54 AM, Robert Muir rcm...@gmail.com wrote:
Because the test is for a uima analyzer, and UIMA mucks around with this?
[
https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433942#comment-13433942
]
Shai Erera commented on LUCENE-4304:
Patch looks good. One minor comment --
[
https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433949#comment-13433949
]
Uwe Schindler commented on LUCENE-4304:
---
+1 to commit. Can we also add a
On Mon, 2012-08-13 at 17:36 +0200, Stefan Trcek wrote:
* There must be 2 caches in the system: The performance degrades
significantly beyond 1000 and again beyond 20 documents
in the index.
With 1000 records, everything is in level 2 cache and a lot in level 1,
which makes it blazingly
Now using lucene-4.0.0-alpha
As the index size increased the indexes do not fit into IO cache.
So I dropped the biggest index for searching.
$ java misc.LuceneKeyValuePerformance write
WRITING
#entries seconds entries/s
1000 0,40 2520
2000 0,29 6863
Results for lucene-4.0.0-alpha:
* Write performance decreased by a factor of about 2.
* Index size increased by a factor 1.3
* Search speed increased by a factor 1.6 (1m requests, 10m entries)
or even more
* The ultra high performance for small indexes decreased.
But this doesn't matter.
I think this benchmark is not really benchmarking writes at all, but
instead the time it takes to wait for merges to complete.
don't indexwriter.close() in your benchmark like this.
On Tue, Aug 14, 2012 at 6:44 AM, Stefan Trcek wzzelfz...@abas.de wrote:
Results for lucene-4.0.0-alpha:
* Write
[
https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434053#comment-13434053
]
Robert Muir commented on LUCENE-4304:
-
I think MIGRATE.txt is overkill here. This was
14 August 2012, Apache Lucene‚ 4.0-beta available
The Lucene PMC is pleased to announce the release of Apache Lucene 4.0-beta
Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that
14 August 2012, Apache Solr™ 4.0-beta available
The Lucene PMC is pleased to announce the release of Apache Solr 4.0-beta.
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting,
[
https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434061#comment-13434061
]
Robert Muir commented on LUCENE-4306:
-
I dont think renaming it accomplishes
[
https://issues.apache.org/jira/browse/SOLR-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434079#comment-13434079
]
Markus Jelsma commented on SOLR-2789:
-
This issue is not resolved but it's documented
[
https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434082#comment-13434082
]
Uwe Schindler commented on LUCENE-4306:
---
OK, I changed the cocommit to a TODO and
[
https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-4304.
-
Resolution: Fixed
Fix Version/s: 4.0
5.0
Remove
[
https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434092#comment-13434092
]
Uwe Schindler commented on LUCENE-4306:
---
Committed trunk revision: 1372866
Am Tue, 14 Aug 2012 06:46:22 -0400 schrieb Robert Muir:
I think this benchmark is not really benchmarking writes at all, but
instead the time it takes to wait for merges to complete.
don't indexwriter.close() in your benchmark like this.
Ok, but how to? As I understand the api I need at
On Tue, Aug 14, 2012 at 8:58 AM, Stefan Trcek wzzelfz...@abas.de wrote:
Am Tue, 14 Aug 2012 06:46:22 -0400 schrieb Robert Muir:
I think this benchmark is not really benchmarking writes at all, but
instead the time it takes to wait for merges to complete.
don't indexwriter.close() in your
[
https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-4306.
---
Resolution: Fixed
Committed branch_4x revision: 1372871
Make
[
https://issues.apache.org/jira/browse/LUCENE-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434125#comment-13434125
]
Marc Sturlese commented on LUCENE-3668:
---
I've tried this with solr-4-beta and
[
https://issues.apache.org/jira/browse/SOLR-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated SOLR-2747:
--
Attachment: SOLR-2747.patch
the start to a patch: but I only did the build piece here just as an
[
https://issues.apache.org/jira/browse/SOLR-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434133#comment-13434133
]
Robert Muir commented on SOLR-2747:
---
The script in general seems to almost work already.
[
https://issues.apache.org/jira/browse/SOLR-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe reassigned SOLR-2747:
-
Assignee: Steven Rowe
Include formatted Changes.html for release
Hmm I've also hit test failures w/ J9 64 bit that look likely to be a JVM bug:
ant test -Dtestcase=TestJapaneseTokenizer
-Dtests.method=testRandomHugeStringsMockGraphAfter
-Dtests.seed=B8EC1E1E5DE1E925 -Dtests.slow=true -Dtests.locale=tr
-Dtests.timezone=Pacific/Chatham
[
https://issues.apache.org/jira/browse/LUCENE-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434179#comment-13434179
]
Michael McCandless commented on LUCENE-4307:
+1
rename
[
https://issues.apache.org/jira/browse/LUCENE-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434180#comment-13434180
]
Uwe Schindler commented on LUCENE-4307:
---
+1
rename
I've had some failures related to threads too... it'd be really nice
if there was a public issue tracking system for J9 -- it's valuable
for the product after all (and those free testers...).
Dawid
On Tue, Aug 14, 2012 at 5:08 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Hmm I've
It must be something we've missed, as we want to target medium trust
locations in the future. I can't think of anything off the top of my
head that would require medium trust, though, let alone unmanaged
code. I'll dive into this.
Thanks,
Christopher
On Mon, Aug 13, 2012 at 10:01 PM, Simon
[
https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434230#comment-13434230
]
Hoss Man commented on SOLR-3690:
bq. It would be good to think about: ideally in the future
Another possibility that would increase customizability via exposing
information we currently throw away, proposed by Mike McCandless on
LUCENE-3940[1] (though controversially[2]): in addition to tokenizing
alpha/numeric char sequences, StandardTokenizer could also tokenize everything
else.
[
https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434233#comment-13434233
]
Robert Muir commented on SOLR-3690:
---
that sounds good. then we get consistency.
Hi,
I tried to reproduce this, it seems impossible to me. Without some helpful IBM
support we cannot fix this.
I tried everything in the guide (http://goo.gl/1jr5E, setting count to 0 or 1
to compile ASAP for both JIT and AOT), but the test does not fail at all with
given seed. I checked,
one thing i tried when playing around (which might help) is to try to
reproduce 'entire test run' with the master junit seed (the one
printed after Junit says hello)
if you have the same SVN revision number and use this same seed and
same # tests.jvms it will allocate all tests to the same slaves
Additionally, I disabled IBM J9 test runs (all word sizes and JDK versions) for
now.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Tuesday, August 14,
[
https://issues.apache.org/jira/browse/SOLR-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434253#comment-13434253
]
Jack Krupansky commented on SOLR-3441:
--
It would be nice if this could be committed.
[
https://issues.apache.org/jira/browse/SOLR-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-3441:
---
Fix Version/s: 4.0
adjusting this for 4.0 visibility
Make ElisionFilterFactory
I had forgotten about this but I agree it could also be used to handle
challenging tokenizations.
In general I think our Tokenizers should throw away as little
information as possible (at least have options to do so). Subsequent
TokenFilters can always remove things ...
I agree there's a risk
: But it really depends on how you want your whole analysis process to
: work. e.g. in the above example if you want to treat foo-bar as
: really equivalent to foobar, or you want to treat U.S.A as equivalent
Unless i'm missreading the Word Boundary doc, the point of these types of
tailorings
On Tue, Aug 14, 2012 at 1:19 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
0D ( － ) FULLWIDTH HYPHEN-MINUS
...so seemingly, according to the word boundary docs, there should be an
option to treat those individual characters as MidLetter characters w/o
requiring the user to change them to
Am Tue, 14 Aug 2012 09:05:47 -0400 schrieb Robert Muir:
But If you just want to make changes visible to searches, you can open
your reader from IndexWriter (see the NRT ctor) and call openIfChanged
to refresh the view when you need.
Ahhh - I know this, but we currently stay with separate
Very cool! Much more sophisticated than ours ... eg it's not instantaneous.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Aug 14, 2012 at 12:21 PM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
Guava (Apache licensed) has a RateLimiter [1] class with additional options
I just happen to notice that (*:*) is not parsed properly by edismax in
4.0-beta. It appears to require spaces before and after the *:*, otherwise it
treats the colon as part of a wildcard term (see the escaping below). I haven’t
tried other releases yet.
Some variations I tried:
str
I've got some code that extends Solr and I use the Solr test framework for my
tests. I upgraded from Solr 4 alpha to Solr 4 beta today, and it appears I am
forced to put my test solr home directory in solr/collection1 rather than just
plain solr/ (relative to my test classpath). I looked
I'm trying to debug other issues, but I can't seem to get past the new
thread leak checks that cause the test case to fail.
Is there a way to disable these checks?
-Yonik
http://lucidworks.com
-
To unsubscribe, e-mail:
If you do ignore even one suite and it leaves threads behind then:
1) it defeats the purpose of having those checks (and I really think
having background threads that do something after a suite completes is
a Bad Thing (tm)).
2) it would hurt my feelings, really. I've put a lot of time and
On Tue, Aug 14, 2012 at 3:36 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
If you do ignore even one suite and it leaves threads behind then:
I'm only trying to run/loop a single test to reproduce a different problem.
1) it defeats the purpose of having those checks (and I really think
Hi all,
I have a patch for SOLR-1093. It isnt a complete solution but
close. The sub queries are run serially as Lance
Norskoghttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=lancenorskog
mention's in his comment on 23/Dec/09. It has been very useful for us and
would like
I'm only trying to run/loop a single test to reproduce a different problem.
That's weird... I mean -- thread leaks are checked after a full suite
completes so a loop inside a test shouldn't matter (?). Anyway, you
can also try with -Dtests.iters unless you're really running gazillion
iterations
[
https://issues.apache.org/jira/browse/SOLR-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434466#comment-13434466
]
Michael Dodsworth commented on SOLR-3725:
-
Excellent. Thanks, Robert.
On Tue, Aug 14, 2012 at 4:08 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
I'm only trying to run/loop a single test to reproduce a different problem.
That's weird... I mean -- thread leaks are checked after a full suite
completes so a loop inside a test shouldn't matter (?). Anyway,
Yeah, I had a shell script looping ant test because of past issues
with tests.iters, but I haven't tried it lately...
I think I commented on one of the issues related to OOMs -- you don't
read my messages :) The recent update to the runner brings two of the
features we once spoke about:
1) if
[
https://issues.apache.org/jira/browse/LUCENE-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-4307.
-
Resolution: Fixed
Fix Version/s: 4.0
5.0
rename
The Solr query syntax wiki says that “Pure negative queries (all clauses
prohibited) are allowed”, but this is only true at the top level – a pure
negative query within parentheses gets evaluated in the same Boolean Query
rather nested as a new BooleanQuery with a MUST for *:*.
See:
[
https://issues.apache.org/jira/browse/SOLR-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Bowyer resolved SOLR-3572.
---
Resolution: Fixed
Fix Version/s: 4.0
Catching up with these things
committed to trunk:
Jack Krupansky created SOLR-3729:
Summary: ExtendedDismaxQParser (edismax) doesn't parse (*:*)
properly
Key: SOLR-3729
URL: https://issues.apache.org/jira/browse/SOLR-3729
Project: Solr
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Krupansky updated SOLR-3729:
-
Description:
I just happen to notice that (\*:\*) is not parsed properly by the edismax
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Krupansky updated SOLR-3729:
-
Description:
I just happen to notice that (\*:\*) is not parsed properly by the edismax
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Krupansky updated SOLR-3729:
-
Description:
I just happen to notice that (\*:\*) is not parsed properly by the edismax
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Krupansky updated SOLR-3729:
-
Description:
I just happen to notice that (\*:\*) is not parsed properly by the edismax
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Krupansky updated SOLR-3729:
-
Description:
I just happen to notice that (\*:\*) is not parsed properly by the edismax
[
https://issues.apache.org/jira/browse/SOLR-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Garski updated SOLR-2592:
-
Attachment: SOLR-2592_r1373086.patch
I've updated my patch which applies cleanly to r1373086.
[
https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3690:
---
Attachment: SOLR-3690.patch
Ok, patch ready for review.
a few things to note:
1) adding the logic to
[
https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434704#comment-13434704
]
Robert Muir commented on SOLR-3690:
---
I can explain the screwed up unnecessary javadocs
[
https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434708#comment-13434708
]
Robert Muir commented on SOLR-3690:
---
OK I was looking to 'show' the example on the
[
https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3690:
---
Attachment: SOLR-3690.broken.jdoc.links.to.solrcore.patch
SOLR-3690.patch
bq. so this
Mark Miller created SOLR-3730:
-
Summary: Rollback is not implemented quite right and can cause
corner case fails in SolrCloud tests.
Key: SOLR-3730
URL: https://issues.apache.org/jira/browse/SOLR-3730
[
https://issues.apache.org/jira/browse/SOLR-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-3730:
--
Priority: Minor (was: Major)
Rollback is not implemented quite right and can cause corner case
[
https://issues.apache.org/jira/browse/SOLR-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434791#comment-13434791
]
Mark Miller commented on SOLR-3730:
---
To clarify, the havoc was generally test havoc -
[
https://issues.apache.org/jira/browse/SOLR-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434803#comment-13434803
]
Mark Miller commented on SOLR-3730:
---
So somehow this screwed up ref counting (which had
75 matches
Mail list logo
