the issue:
https://github.com/apache/lucenenet/pull/208
Guys, the PR title here references LUCENE-5644 and this trigger's ASF
JIRA-GitHub integration to link the conversation here to comments on that old
issue. Can you please edit the PR title?
> ThreadAffinityDocumentsWrit
he
thread<https://github.com/notifications/unsubscribe-auth/ARBXprqH0s0Tjj1dhQ4f_ryNc6H2vCZEks5sILy9gaJpZM4N4A9a>.
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
>
d on the issue:
https://github.com/apache/lucenenet/pull/208
@vvdb
I would like to add this fix to the next release. Are you planning to
submit another pull request?
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings o
pull request at:
https://github.com/apache/lucenenet/pull/208
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https:
es (such as changing the curly bracket from the same line to
the following line of a function or if statement), but to my knowledge a tool
like that doesn't exist.
> ThreadAffinityDocuments
GitHub<https://github.com/apache/lucenenet/pull/208#issuecomment-308027273>, or
mute the
thread<https://github.com/notifications/unsubscribe-auth/ARBXpku1AqOToF4KGaoBuQG8Pu83axMhks5sDjV4gaJpZM4N4A9a>.
> ThreadA
the moment, how can we be
sure this doesn't introduce any? cc @NightOwl888
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
>
lear();
+ }
--- End diff --
this seems unrelated?
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https:
xing”. Technically, this is something from releases/lucene-solr/4.8.1, but
profiling indicates it makes a huge difference in multithreaded scenarios
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings o
5644:
-
Commit 1593650 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1593650 ]
LUCENE-5644: favor an already initialized ThreadState
> ThreadAffinityDocumentsWriterThreadPool should clear the
. When that
happens, we should try to pick a ThreadState that's already initialized, so
that if no full-flushing (getReader) is happening, we don't tie up RAM
indefinitely in the pending segments.
> ThreadAffinityDocumentsWriterThreadPool should clear the bind
[
https://issues.apache.org/jira/browse/LUCENE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-5644.
Resolution: Fixed
> ThreadAffinityDocumentsWriterThreadPool should clear
5644:
-
Commit 1593230 from [~mikemccand] in branch 'dev/branches/lucene_solr_4_8'
[ https://svn.apache.org/r1593230 ]
LUCENE-5644: switch to simpler LIFO thread to ThreadState allocator during
indexing
> ThreadAffinityDocumentsWriterThreadPool should clear the
5644:
-
Commit 1593651 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1593651 ]
LUCENE-5644: favor an already initialized ThreadState
> ThreadAffinityDocumentsWriterThreadPool should clear the
(this class is already using its
intrinsic lock)? Or at least, let's defer it; maybe we can make a
lock-free queue later...
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
[
https://issues.apache.org/jira/browse/LUCENE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-5644.
Resolution: Fixed
> ThreadAffinityDocumentsWriterThreadPool should clear
case where the
ThreadState isn't initialized, we loop through the other thread states to find
one that is initialized.
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
>
5644:
-
Commit 1593226 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1593226 ]
LUCENE-5644: switch to simpler LIFO thread to ThreadState allocator during
indexing
> ThreadAffinityDocumentsWriterThreadPool should clear the
5644:
-
Commit 1593649 from [~mikemccand] in branch 'dev/branches/lucene_solr_4_8'
[ https://svn.apache.org/r1593649 ]
LUCENE-5644: favor an already initialized ThreadState
> ThreadAffinityDocumentsWriterThreadPool should clear the
{noformat}
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https://issues.apache.org/jira/browse/LUCENE-5644
> Project: Lucene
5644:
-
Commit 1593240 from [~mikemccand] in branch 'dev/branches/lucene_solr_4_8'
[ https://svn.apache.org/r1593240 ]
LUCENE-5644: remove this class
> ThreadAffinityDocumentsWriterThreadPool should clear the
ume things. But, I leave it to you.
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https://issues.apache.org/jira/browse
5644:
-
Commit 1593228 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1593228 ]
LUCENE-5644: switch to simpler LIFO thread to ThreadState allocator during
indexing
> ThreadAffinityDocumentsWriterThreadPool should clear the
ormat}
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https://issues.apache.org/jira/browse/LUCENE-5644
> Project: Lucene - Core
>
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https://issues.apache.org/jira/browse/LUCENE-5644
> Project: Lucene - Core
>
5644:
-
Commit 1592623 from [~mikemccand] in branch 'dev/branches/lucene_solr_4_8'
[ https://svn.apache.org/r1592623 ]
LUCENE-5644: clear IW's thread state bindings on flush
> ThreadAffinityDocumentsWriterThreadPool should clear
5644:
-
Commit 1592621 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1592621 ]
LUCENE-5644: clear IW's thread state bindings on flush
> ThreadAffinityDocumentsWriterThreadPool should clear
5644:
-
Commit 1592620 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1592620 ]
LUCENE-5644: clear IW's thread state bindings on flush
> ThreadAffinityDocumentsWriterThreadPool should clear
27;ll add that & commit shortly.
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https://issues.apache
ate.lock();
if (minThreadState.isInitialized() == false) {
threadBindings.put(requestingThread, minThreadState); // make sure we get the
same state next time
}
return minThreadState;
{code}
> ThreadAffinityDocumentsWriterThreadPool should clear the
not recording a thread
binding when we had an uncontended minThreadState, causing an
unnecessary call to minContentedThreadState for each doc.
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings o
Michael McCandless created LUCENE-5644:
--
Summary: ThreadAffinityDocumentsWriterThreadPool should clear the
bindings on flush
Key: LUCENE-5644
URL: https://issues.apache.org/jira/browse/LUCENE-5644
ise ThreadAffinityDocumentsWriterThreadPool queue handling
> -
>
> Key: LUCENE-3060
> URL: https://issues.apache.org/jira/browse/LUCENE-3060
> Project: Lucene - Core
> Issue Type: Improvement
>
Nick Tarleton created LUCENE-5359:
-
Summary: ThreadAffinityDocumentsWriterThreadPool checks
hasQueuedThreads rather than isLocked
Key: LUCENE-5359
URL: https://issues.apache.org/jira/browse/LUCENE-5359
ise ThreadAffinityDocumentsWriterThreadPool queue handling
> -
>
> Key: LUCENE-3060
> URL: https://issues.apache.org/jira/browse/LUCENE-3060
> Project: Lucene - Core
> Issue Type: Improvement
hey peter,
On Mon, Jan 16, 2012 at 8:45 AM, Peter K wrote:
> Thanks Simon for all the explanations so far :) !
no problem!
>
>>> And what happens if two threads accessing the same ThreadState? The
>>> second will try to lock and fail and then get the minimal contended
>>> state (?) You said there
Thanks Simon for all the explanations so far :) !
>> And what happens if two threads accessing the same ThreadState? The
>> second will try to lock and fail and then get the minimal contended
>> state (?) You said there is no problem when two threads accessing one
>> ThreadState, but won't two thr
On Fri, Jan 13, 2012 at 11:52 AM, Peter K wrote:
> Hi Simon,
>
>> ThreadAffinityDocumentsWriterThreadPool tries to select the least
>> contended DocumentsWriterPerThread for the incoming thread and if
>> possible assigns the same DWPT to the thread if the associated
>&
Hi Simon,
> ThreadAffinityDocumentsWriterThreadPool tries to select the least
> contended DocumentsWriterPerThread for the incoming thread and if
> possible assigns the same DWPT to the thread if the associated
> (previously selected) DWPT is not contended.
ah, ok and contended or
hey peter,
On Thu, Jan 12, 2012 at 4:10 PM, Peter K wrote:
> Hi,
>
> questions regarding ThreadAffinityDocumentsWriterThreadPool:
>
> 1. Would someone explain to me the ThreadAffinityDocumentsWriterThreadPool
> class? E.g. why couldn't I use a ThreadLocal (I'll get e
Hi,
questions regarding ThreadAffinityDocumentsWriterThreadPool:
1. Would someone explain to me the
ThreadAffinityDocumentsWriterThreadPool class? E.g. why couldn't I use a
ThreadLocal (I'll get exceptions)? Also what does the TODO mean?
2. When profiling I see that "threadBindi
Revise ThreadAffinityDocumentsWriterThreadPool queue handling
-
Key: LUCENE-3060
URL: https://issues.apache.org/jira/browse/LUCENE-3060
Project: Lucene - Java
Issue Type
42 matches
Mail list logo
