Seeming bug in ConcurrentUpdateSolrServer

2013-05-29 Thread Benson Margulies
The comment here is clearly wrong, since there is no division by two. I think that the code is wrong, because this results in not starting runners when it should start runners. Am I misanalyzing? if (runners.isEmpty() || (queue.remainingCapacity() queue.size() // queue // is //

Re: Seeming bug in ConcurrentUpdateSolrServer

2013-05-29 Thread Shalin Shekhar Mangar
On Wed, May 29, 2013 at 11:29 PM, Benson Margulies bimargul...@gmail.comwrote: The comment here is clearly wrong, since there is no division by two. I think that the code is wrong, because this results in not starting runners when it should start runners. Am I misanalyzing? if

Re: Seeming bug in ConcurrentUpdateSolrServer

2013-05-29 Thread Benson Margulies
Ah. So now I have to find some other explanation of why it never creates more than one thread, even when I make a very deep queue and specify 6 threads. On Wed, May 29, 2013 at 2:25 PM, Shalin Shekhar Mangar shalinman...@gmail.com wrote: On Wed, May 29, 2013 at 11:29 PM, Benson Margulies

Re: Seeming bug in ConcurrentUpdateSolrServer

2013-05-29 Thread Benson Margulies
I now understand the algorithm, but I don't understand why is the way it is. Consider one of these objects configure with a handful of threads and a pretty big queue. When the first request comes in, the object creates one runner. It then won't create a second runner until the Q reaches