ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-7134) Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()
Date Thu, 07 Dec 2017 10:12:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281618#comment-16281618

ASF GitHub Bot commented on IGNITE-7134:

GitHub user akuramshingg opened a pull request:


    IGNITE-7134 Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk().


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/gridgain/apache-ignite ignite-7134

Alternatively you can review and apply these changes as the patch at:


To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #3166
commit 982f91a695442a4f2a63f7dc96761f7cc87a25cf
Author: Alexandr Kuramshin <ein.nsk.ru@gmail.com>
Date:   2017-12-07T10:10:02Z

    IGNITE-7134 Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk().


> Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()
> --------------------------------------------------------------------------
>                 Key: IGNITE-7134
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7134
>             Project: Ignite
>          Issue Type: Bug
>          Components: general
>    Affects Versions: 2.3
>            Reporter: Alexandr Kuramshin
>            Assignee: Alexandr Kuramshin
>            Priority: Critical
>             Fix For: 2.4
> {noformat}
> org.apache.ignite.spi.IgniteSpiOperationTimeoutHelper#nextTimeoutChunk
> long curTs = U.currentTimeMillis();
> timeout = timeout - (curTs - lastOperStartTs);
> {noformat}
> Timeout will not be decreased at all if delay between successive calls to nextTimeoutChunk()
is smaller than U.currentTimeMillis() discretization. Such behaviour could be easily achieved
when getting an error right after the nextTimeoutChunk() invocation and do the retry.
> Only rare calls (the first right before U.currentTimeMillis() and the second right after
that) may decrease timeout, so actual IgniteSpiOperationTimeoutHelper timeout could be much
bigger than the failureDetectionTimeout.
> My opinion to not split failureDetectionTimeout between network operations, but initialize
first operation timestamp at first call to nextTimeoutChunk(), and then calculate the timeout
as a difference between the current timestamp and the first operation timestamp.

This message was sent by Atlassian JIRA

View raw message