[ 
https://issues.apache.org/jira/browse/LUCENE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13992615#comment-13992615
 ] 

Michael McCandless commented on LUCENE-5644:
--------------------------------------------

{quote}
Not necessarily. You can have different threads batch up different documents 
and pre-sort them before .addDocument. Then you end up w/ pre-sorted segments 
(if you have Thread-affinity). I'm not saying it's such an important usecase to 
support out-of-the-box, more that there is such a usecase, and I think it'd be 
better if we offer some way in Lucene to enable it.
{quote}

OK, I see, you're right.  But this (which segment your thread sends
its docs to) was never really a hard guarantee with IW; it's really an
impl detail.

{quote}
bq. How about I make this default impl un-final?

Either that or factor out a simple API, your call.
{quote}

I'd like to defer this: I'll open a separate issue.  I agree it's
dangerous to have the one impl not be final, so I put final back for
now, and in the follow on issue we can make it un-final and abstract
again, and maybe we can get a (correct) thread-affinity impl back.  I
just think tweaking with the thread assignment is very very expert.

bq. I'd love in general to not sync on "this" but rather have a lock obj or a 
condition but that's just taste I guess...

I'd rather not add another lock here (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
> --------------------------------------------------------------------------
>
>                 Key: LUCENE-5644
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5644
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: core/index
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.8.1, 4.9, 5.0
>
>         Attachments: LUCENE-5644.patch, LUCENE-5644.patch, LUCENE-5644.patch, 
> LUCENE-5644.patch
>
>
> This class remembers which thread used which DWPT, but it never clears
> this "affinity".  It really should clear it on flush, this way if the
> number of threads doing indexing has changed we only use as many DWPTs
> as there are incoming threads.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to