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