cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Mazursky (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5690) Fix AsyncOneResponse
Date Fri, 19 Jul 2013 02:32:49 GMT


Mikhail Mazursky commented on CASSANDRA-5690:

No, that is not true.

get() obtains the lock, then do TimeUnit.NANOSECONDS.timedWait() [1] that uses Object.wait()
[2] internally.
>From it's javadocs:
 The current thread must own this object's monitor. The thread releases ownership of this
monitor and waits until either of the following two conditions has occurred:

    Another thread notifies threads waiting on this object's monitor to wake up either through
a call to the notify method or the notifyAll method.
    The timeout period, specified by timeout milliseconds plus nanos nanoseconds arguments,
has elapsed. 

The thread then waits until it can re-obtain ownership of the monitor and resumes execution.


So, any number of threads blocked in get() are not preventing response() from setting the

p.s. Current implementation uses the same pattern but just doing it wrong.

> Fix AsyncOneResponse
> --------------------
>                 Key: CASSANDRA-5690
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Mikhail Mazursky
>            Assignee: Mikhail Mazursky
>            Priority: Minor
>         Attachments: trunk-5690.patch
> Current implementation of AsyncOneResponse suffers from two problems:
> 1. Spurious wakeup will lead to TimeoutException being thrown because awaiting for condition
is not done in loop;
> 2. condition.signal() is used where .signalAll() should be used - this leads to only
one thread blocked on .get() to be unblocked. Other threads will stay blocked forever.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message