RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize
Roger.Riggs at Oracle.com
Fri Aug 5 15:56:54 UTC 2016
I agree that the 80% reflects the previous coding and is ok.
I don't have enough background on this code to know whether the 80% is
now spurious and confusing and could be removed.
On 8/5/2016 11:46 AM, Seán Coffey wrote:
> Sorry - cc'ed the wrong Pavel earlier. Corrected.
> I thought the consumer/producer model was best served by delegating to
> the BlockingQueue. Is there a need to synchronize as a result ?
> The 80% logic is only implemented in the rare case where the
> com.sun.jndi.ldap.search.replyQueueSize ldap context property is set.
> It seems to be legacy behaviour from the old code where the reader
> thread was paused at 80% capacity. Setting the BlockingQueue to the
> same '80%' size should have the same net effect.
> On 05/08/16 15:50, Roger Riggs wrote:
>> Hi Sean,
>> Looks like a cleaner solution to synchronize writer and readers.
>> I don't quite understand the 80% capacity value. It is related to
>> the obsolete highWatermark
>> but that does not seem relevant with the update.
>> If the caller is going to specify a replyQueueCapacity then why
>> should it be downgraded to 80%?
>> On 8/5/2016 10:05 AM, Seán Coffey wrote:
>>> Hoping to get a review on this issue that's been sitting on my plate
>>> for a long while. Pavel drew up the bulk of the edits for this one
>>> The fix basically delegates polling and timeout management to the
>>> BlockingQueue.poll(timeout.. ) method. As a result it makes
>>> Connection readReply logic much easier to handle.
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8139965.9/webrev/
>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8139965
More information about the core-libs-dev