[jira] [Commented] (QPIDJMS-136) use System.nanoTime() when deriving time to tick the transport with for idle-timeout handling

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/QPIDJMS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982731#comment-14982731 ] 

ASF subversion and git services commented on QPIDJMS-136:
---------------------------------------------------------

Commit 7c22d59e40253fa7915b575db8e33c33510d7a13 in qpid-jms's branch refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=7c22d59 ]

QPIDJMS-136: use System.nanoTime() when deriving time to tick the transport with for idle-timeout handling


> use System.nanoTime() when deriving time to tick the transport with for idle-timeout handling
> ---------------------------------------------------------------------------------------------
>
>                 Key: QPIDJMS-136
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-136
>             Project: Qpid JMS
>          Issue Type: Bug
>          Components: qpid-jms-client
>    Affects Versions: 0.6.0
>            Reporter: Robbie Gemmell
>            Assignee: Robbie Gemmell
>             Fix For: 0.7.0
>
>
> The sending of empty AMQP heartbeating frames to satisfy the remote peers advertised idle-timeout, and closure of the connection if no frames are received from a peer to satisfy our local idle-timeout, are handled by protons Transport#tick() method. This method takes the current time as an argument and determines what (if any) actions should be undertaken now, then returns the next point at which further processing is required. In order to faciliate this the last 'current time' the method was called with is saved between calls. 
> As with QPID-6698, we should update our usage of the proton Transport#tick() method to use a monotonic time, derived from System.nanoTime(), rather than a wall time from System.currentTimeMillis(), so that clock changes between these points dont lead to incorrect behaviour (e.g not sending a required frame, or thinking a frame hasnt been received that should have been).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org