On Fri, Jan 13, 2012 at 11:52 AM, Peter K <peat...@yahoo.de> 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 >> (previously selected) DWPT is not contended. > > ah, ok and contended or not is done via queue length ... > > Some further questions if you allow :)
sure - as may as you like :) > > The naming of the collection 'perThreads' in > DocumentsWriterPerThreadPool does not make sense to me. Why not > 'availableThreads'? yeah I think we should just name it "threadStates" > > 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 threads accessing one > DocumentsWriterPerThread make problems (e.g. when using the singleton > object docState) ? DocumentsWriterPerThread should never be accessed by multiple threads at the same time. This is why we lock the ThreadState. The maxNumThreadStates defines the max. concurrency level IW supports. if more threads than threadstates enter the pool extra threads are queued. the problem with the min contented is that this number could change while you iterate, ie. you see a state with 0 queued thread and select it but while you try to lock it somebody else already locked it so it might not be the min contented anymore. > >> >> The TODO is there since there could be a selection which is not ideal >> if two threads are racing but it won't cause any exceptions etc. > > Would this problem also occur if more threads than maxThreadStates try > to feed lucene? see above - I don't think its a big issue but it would be nice to get rid of that limitation. > > >> Is that the test you send the other day to >> the user list like 900k docs in 29 sec or something like that? > > yes, still on that thing. > sorry, its certainly the way you described. I was and I am just curious > ... digging day by day a bit deeper into lucene :) sure! :) simon > > Peter. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
