This was the test that failed -- it's a false failure from
LUCENE-1573. I'll fix...
[junit] - Standard Output ---
[junit] FAILED; unexpected exception during close
[junit] java.lang.RuntimeException: java.lang.InterruptedException
[junit] at
org.apache.
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700571#action_12700571
]
Michael McCandless commented on LUCENE-831:
---
bq. I was also thinking that some of
Okay, we'd like to have equality-by-reference for field names,
yielding überfast comparisions in all our tight inner loops. But we
dislike default String.intern() for its java<->native transitions and
general lentitude.
There's a perfect solution. Too dumb to come up with it myself, but
fortunately
[
https://issues.apache.org/jira/browse/LUCENE-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700577#action_12700577
]
Michael McCandless commented on LUCENE-1518:
bq. I really hate the hasRandomA
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700583#action_12700583
]
Mark Miller commented on LUCENE-831:
bq. >>I was also thinking that some of these issue
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700585#action_12700585
]
Uwe Schindler commented on LUCENE-831:
--
I am still thinking about the difference betwe
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700586#action_12700586
]
Mark Miller commented on LUCENE-831:
bq. but maybe the new ValueSource could provide bo
String.intern() faster alternative
--
Key: LUCENE-1607
URL: https://issues.apache.org/jira/browse/LUCENE-1607
Project: Lucene - Java
Issue Type: Improvement
Reporter: Earwin Burrfoot
F
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-1607:
Attachment: intern.patch
> String.intern() faster alternative
> --
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700593#action_12700593
]
Mark Miller commented on LUCENE-1607:
-
What was the field count? Is it still a conside
[
https://issues.apache.org/jira/browse/LUCENE-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700595#action_12700595
]
Mark Miller commented on LUCENE-1598:
-
I guess I've just got to make the FieldComparat
[
https://issues.apache.org/jira/browse/LUCENE-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller reassigned LUCENE-1595:
---
Assignee: Mark Miller
> Split DocMaker into ContentSource and DocMaker
> ---
On Thu, Apr 16, 2009 at 10:45:49AM -0400, Michael McCandless wrote:
> tomorrow I leave for a week long vacation
Liar.
Marvin Humphrey
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-
[
https://issues.apache.org/jira/browse/LUCENE-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700596#action_12700596
]
Mark Miller commented on LUCENE-1599:
-
Could you write a quick test case? I just give
The implementation of Interner doesn't look threadsafe to me. At the very
least shouldn't 'pool' be marked volatile, otherwise the result of 'pool
= newPool' is not guaranteed to be visible to other threads?
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.j
ira.plugin.sy
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated LUCENE-1607:
-
Attachment: LUCENE-1607.patch
Here's a completely lockless and memory barrier free intern() cach
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700599#action_12700599
]
Yonik Seeley commented on LUCENE-1607:
--
Earwin, I took a quick look at your implement
This implementation suffers from thread visibility problems too - changes
to the array's values aren't guaranteed to be visible across threads. In
addition to that, there's also a problem with hash collisions invalidating
cache entries which could greatly degrade performance in several common us
Chris Miller wrote:
but the thread visibility problem seems potentially serious.
Why do you think so? The assignments are atomic and if a set is not
visible to a thread yet, it just gets an extra intern, right?
I agree that benchmarks will be key though.
--
- Mark
http://www.lucidimagination
Even on vacation there are random snippets here and there to "catch up" ;)
Mike
On Sun, Apr 19, 2009 at 1:20 PM, Marvin Humphrey wrote:
> On Thu, Apr 16, 2009 at 10:45:49AM -0400, Michael McCandless wrote:
>
>> tomorrow I leave for a week long vacation
>
> Liar.
>
> Marvin Humphrey
>
>
> ---
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700600#action_12700600
]
Mark Miller commented on LUCENE-1607:
-
bq. Earwin, I took a quick look at your impleme
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700601#action_12700601
]
Earwin Burrfoot commented on LUCENE-1607:
-
bq. This default would be more back com
As far as I can see, both these implementations only suffer from threadsafety
problems in that they don't guarantee visibility across threads, ie it's
possible for threads to see stale data. I don't see any prospect of corruption
or race conditions due to out-of-order execution. So the code shou
On Sun, Apr 19, 2009 at 23:16, Chris Miller wrote:
> As far as I can see, both these implementations only suffer from
> threadsafety problems in that they don't guarantee visibility across
> threads, ie it's possible for threads to see stale data.
> So the code should work fine if you can live wi
How about benchmarking with eg a ConcurrentHashMap instead?
Scratch that, I forgot about the 1.3/1.4 dependency...
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h.
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700604#action_12700604
]
Earwin Burrfoot commented on LUCENE-1607:
-
bq. What was the field count? Is it sti
As soon as all possible fields are in the pool, we're essentially
readonly.
The problem is, there's no guarantee we will ever reach this point. For example
suppose you have a server app that spawns a new thread per request. Each
new thread might have to make all the .intern() calls again becau
On Sun, Apr 19, 2009 at 23:42, Chris Miller wrote:
>> As soon as all possible fields are in the pool, we're essentially
>> readonly.
> The problem is, there's no guarantee we will ever reach this point. For
> example suppose you have a server app that spawns a new thread per request.
> Each new th
Sorry I wasn't as clear as I could have been - I realise JEE servers use
a threadpool for handling requests, I was thinking of many other applications
in the real world I'm aware of that don't (be that good design or otherwise...).
I'm not sure I follow you though when you say "it won't even do
> Sorry I wasn't as clear as I could have been - I realise JEE servers use a
> threadpool for handling requests, I was thinking of many other applications
> in the real world I'm aware of that don't (be that good design or
> otherwise...).
You was. I just wanted to point out that in real apps you'r
You was. I just wanted to point out that in real apps you're not going
to see stale data longer than for milliseconds
Agreed, which is why this whole discussion is very theoretical anyway :)
On cache miss, I re-retrieve pool reference after a lock (HashMap is
no longer stale), re-read a string
[
https://issues.apache.org/jira/browse/LUCENE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-1606:
Attachment: automatonmultiqueryfuzzy.patch
this includes an alternative for another slow linear qu
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700618#action_12700618
]
Yonik Seeley commented on LUCENE-1607:
--
The thread safety problem has to do with safe
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700629#action_12700629
]
Derek DeMarco commented on LUCENE-1607:
---
Good point Yonik. Making pool volatile sho
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/802/changes
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
35 matches
Mail list logo
