Hi, could anyone give me a code review on that?
JK
----- Original Message -----
From: "Jiri Kremser" <jkremser(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Thursday, September 13, 2012 2:21:54 PM
Subject: Fwd: client's time for obtaining the data?
forwarding...
----- Forwarded Message -----
From: "Charles Crouch" <ccrouch(a)redhat.com>
To: "mike thompson" <mithomps(a)redhat.com>
Cc: jboss-on-team(a)redhat.com, "Jiri Kremser" <jkremser(a)redhat.com>
Sent: Wednesday, September 12, 2012 11:04:23 PM
Subject: Re: client's time for obtaining the data?
Lets keep the tech discussions on rhq-devel
Cheers
Charles
----- Original Message -----
Good catch. Sounds like we need a current time service on the server
side that should be used instead of System.currentTimeMillis() on
the client.
-- Mike
On Sep 12, 2012, at 9:12 AM, Jiri Kremser <jkremser(a)redhat.com>
wrote:
> Hi,
> while I was working on
>
https://bugzilla.redhat.com/show_bug.cgi?id=848494 I found out
> there are many places in our coregui client side, where
> System.currentTimeMillis() is used. The problem with this is that
> a user (browser) accessing the UI from different timezone or from
> a computer with bad time setting generates the wrong "now" and
> pass it to the various server side methods. Here I've found the
> possible risks:
>
> AbstractMeasurementRangeEditor:
> MeasurementDataGWTService
> * findDataForResource (used by ResourceMetricGraphView,
> GraphListView (causing 848494))
> * findDataForCompatibleGroup (used by GroupMetricsPortlet,
> ResourceGroupMetricGraphView (848494 probably as well))
> * findCallTimeDataForResource (not used at all)
>
> MeasurementChartsGWTService
> * getMetricDisplaySummariesForCompatibleGroup (used by
> GroupMeasurementTableDataSource, here the times are taken from
> user prefs or from MeasurementUtility.calculateTimeFrame, where
> System.currentTimeMillis() can be used on the client side)
> * getMetricDisplaySummariesForAutoGroup (not used at all (=>
> candidate for removal))
> * getMetricDisplaySummariesForResource (used by
> MeasurementTableDataSource, the same holds as for
> getMetricDisplaySummariesForCompatibleGroup)
>
> In fact, the concept of (long begin, long end) is present on the
> server-side in many methods, so it is kind of natural to preserve
> these method signatures to the client-side, but we should keep
> this fact/risk in mind. That time returned from
> System.currentTimeMillis() called on the client-side could be
> pretty arbitrary. Easy workaround could be instead of GWTService
> methods with params getMeData(long from, long to) to use
> getMeDataOldAtMost(int number, unit unit) or something like that
> and the System.currentTimeMillis() call on the server-side.
>
> What do you think about it?
>
> JK
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel