Sry, I didn't know that. Hopefully, nobody will notice.
----- Original Message -----
From: "John Mazzitelli" <mazz(a)redhat.com>
To: "ON Team" <jboss-on-team(a)redhat.com>
Sent: Thursday, September 13, 2012 2:28:05 PM
Subject: Fwd: client's time for obtaining the data?
Let's hope the whole of the RHQ community (and spammers?) don't realize we've
now published the address to our internal mailing list:
Cc: jboss-on-team(a)redhat.com
Does anyone know if outside people can email internal RedHat mailing lists or does our
mail server block that? If its blocked, it may not be an issue. If not, prepare to be
spammed :)
----- Forwarded Message -----
From: "Jiri Kremser" <jkremser(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Thursday, September 13, 2012 8:21:54 AM
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