[jira] [Commented] (IGNITE-7134) Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ 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:

    https://github.com/apache/ignite/pull/3166

    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:

    https://github.com/apache/ignite/pull/3166.patch

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 <ei...@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
(v6.4.14#64029)