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
[
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
[
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-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
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
> 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
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
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
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
[
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
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.
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
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
[
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
[
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
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
>
>
> ---
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
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
[
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
[
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
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-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
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-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller reassigned LUCENE-1595:
---
Assignee: Mark Miller
> Split DocMaker into ContentSource and DocMaker
> ---
[
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-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-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-1607:
Attachment: intern.patch
> String.intern() faster alternative
> --
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-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
[
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=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-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
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-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
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.
35 matches
Mail list logo
