Hey again,
I was thinking that,
it would make more sense to learn about the time duration since the
last
read event.
No problem:
System.currentTimeMillis() - getLastReadTime() = elapsed time since
last read
I have to do date calculations in my code to know if the
heartbeat arrived in the stipulated time period.
No, no date calculcations. Just a simple long-calculation:
----
if (System.currentTimeMillis() - getLastReadTime() >
myHeartBeatTimeout) {
// do whatever is required to handle heartbeat timeout
}
----
br,
Alex
-------- Original Message --------
Subject: Re: What does getLastReadTime return ?
Date: Mon, 18 Jun 2012 13:44:25 +0530
From: ನಾಗೇಶ್ ಸುಬ್ರಹ್ಮಣ್ಯ (Nagesh S) <[email protected]>
To: [email protected]
Reply-To: [email protected]
Hello Alex,
I did guess it was a Unix timestamp. But, all along, I was thinking
that,
it would make more sense to learn about the time duration since the
last
read event. Hence, my notion of 'wrong' time reported by the
getLastReadTime().
So, now that it is established that, the time being reported is a Unix
timestamp, I have to do date calculations in my code to know if the
heartbeat arrived in the stipulated time period.
Thank you, Alex, Emmanuel, for your help !
N>
On Mon, Jun 18, 2012 at 1:14 PM, Alexander Christian <[email protected]>
wrote:
Hello N. ...
if a method is named "getLastReadTIME" and returns a long value, it's
- at
least for me - obvious, that this methods returns a unix timestamp
rather
than the elapsed milliseconds between last read-action and "now".
At the latest it must be visible to you that it's a unix timestamp
when
you watch your own screenshot (see linked jira issue below). The
value is
1340004322642 ... Maybe try that:
System.out.println(new Date(1340004322642l));
I get: "Mon Jun 18 09:25:22 CEST 2012"
So finally, it seems to be the timestamp when the last read has
happened.
Maybe read this:
http://en.wikipedia.org/wiki/**Unix_timestamp<http://en.wikipedia.org/wiki/Unix_timestamp>
br,
Alex
On Mon, 18 Jun 2012 12:57:26 +0530, ನಾಗೇಶ್ ಸುಬ್ರಹ್ಮಣ್ಯ wrote:
Hi,
As I understand, here is the flow :
1. acceptor.bind(portNumber) binds the server.
2. Client sends a message and is handled by an extension of
IoHandlerAdapter.
3. Client sends a heartbeat.
At 2 above, isn't the 'timer' started ? So that, at 3, when I do
getLastReadTime() I get the number of milliseconds elapsed between 2
and
3.
Of course, there will be a finite time difference between 1 and 2.
I thought of posting the question here after the Debug perspective
showed
a
weird value for the number of milliseconds as reported by
getLastReadTime(). ;-)
JIRA -
https://issues.apache.org/**jira/browse/DIRMINA-895<https://issues.apache.org/jira/browse/DIRMINA-895>
N.
On Mon, Jun 18, 2012 at 12:33 PM, Emmanuel Lécharny
<[email protected]>wrote:
Le 6/18/12 7:57 AM, ನಾಗೇಶ್ ಸುಬ್ರಹ್ಮಣ್ಯ (Nagesh S) a écrit :
Hi,
So the thing is that there is no read if the client just connect
and
does
not send anything before the heartbeat.
But, the connect is happening once the client has sent a connect
message
(containing, for example, id and password). This message is
handled in a
handler. Isn't this connect counted as a read after the session is
created
(i.e. the server is bound as acceptor.bind(portNumber)) ?
acceptor.bind() does nothing but creating a session. The
lastReadTime
counter is only modified when a message is received. There is no
message
sent by the user when the session is beng created.
Maybe we should initialize it to the time of the session creation
?
You mean, initially, getCreationTime() and getlastReadTime()
report
the
same. But, as the session progresses, getlastReadTime() is reset
accordingly ?
Yes.
You can probably woraround your problem by checking that the
counter is 0
when you first check the heartbeat, then wit for one more
heartbeat.
Also note that I'm just checking the code, it would be easier to
check
while debugging it to be sure I'm not missing something.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
