Andrey, feel free to file a ticket and remove the parameter =)
--Yakov
Yakov, it would be good to get rid of the parameter at all. Strictly
speaking, such tiny things are not bugs, but can lead to bugs, and I'm
curious about the way of improving the situation.
> Andrey, it seems unregisterWaiter() method is supposed to be called only
> with current thread as
>It's not public API, just implementation detail.
>GridFutureAdapter::unregisterWaiter is not thread state in general. It
>won't work properly if the argument is not current thread. And also I
>couldn't prove clearly it wouldn't drop some unrelated Node in concurrent
>operation.
Andrey, it seems
On Thu, Aug 24, 2017 at 10:09 AM, Yakov Zhdanov wrote:
> > I think as a first step, the deadlock detection should kick off after a
> > certain timeout, even if the transaction timeout was not set.
>
> > What do you think?
>
> Dmitry, I thought that was what I suggested, no?
> I think as a first step, the deadlock detection should kick off after a
> certain timeout, even if the transaction timeout was not set.
> What do you think?
Dmitry, I thought that was what I suggested, no? =)
--Yakov
Yakov,
I think as a first step, the deadlock detection should kick off after a
certain timeout, even if the transaction timeout was not set.
What do you think?
D.
On Wed, Aug 23, 2017 at 9:44 AM, Yakov Zhdanov wrote:
> Hello, guys!
>
> Currently Ignite clusters are very
It's not public API, just implementation detail.
GridFutureAdapter::unregisterWaiter is not thread state in general. It
won't work properly if the argument is not current thread. And also I
couldn't prove clearly it wouldn't drop some unrelated Node in concurrent
operation.
2017-08-23 22:45
Andrey, do you have an example of such method in Ignite public or private
API?
If it is not Ignite API please provide an example.
--
Yakov Zhdanov
Hi folks,
Strictly speaking, it's not about improving deadlock/starvation detection
mechanisms, but how do we handle fragile concurrent code that (potentially)
leads to this kind of issues? For example, what if the method is assumed to
be thread-safe, but its safety depends on arguments supplied?