[mapguide-internals] Re: Please review RFC 66

[Christine Bao]

Hi Kenneth,

     About your questions:


1)      I'll use GETSITEVERSION instead of GETFEATUREPROVIDERS. You mentioned "if admin functions are disabled in the web tier". Would you please explain more about this?



2)      The interval value should be set a reasonable value to make it work well. For example, the server timeout value is 20 minutes by default, and Fusion pings server every 5 minutes, so the ping can keep browser alive. Basic web layout will ping each 5 minutes also.



3)      The third one is about when to stop pinging server. My solution so far is: if request fail (MgConnectionFailedException) the ping will stop. It's possible that the server is busy and returns this exception, and it will recovery after a while, but I still prefer to stop pinging because: a) The exception happening means server is busy, so browser should stop pinging to release overhead. b) Keep-alive is a nice to have function, the browser still works without pinging. c) Once user refresh the browser, pinging comes back.

Thanks & regards,
Christine


> On Mon, Jun 22, 2009 at 4:55 PM, Kenneth Skovhede, GEOGRAF

> A/S<ks at geograf.dk> wrote:

>> 1)

>> On my setup "GETFEATUREPROVIDERS" returns 13Kb worth of xml.

>> It may not consume CPU resources, but it does consume bandwidth,

>> especially since it is not required, and it happens a fixed intervals,

>> even if the user is inactive.

>>

>> If its too much work to put in a real function, I think Zac's proposal is

>> way better,

>> but I'm not sure it will work if admin functions are disabled in the

>> WebTier.

>>

>> 2)

>> There is a clear 1-1 relation between the server timeout setting and the

>> client ping setting.

>> If you can read the timeout value on viewer startup, that is fine, but I

>> don't think you can.

>>

>> If you require the admin-user to change the time in two places, you can be

>> certain

>> that there will be a pile of support requests.

>> Also, for a non-specialist, it is not immediately obvious that the two

>> should not be the

>> same, eg. setting both to 15 minutes will make the sessions expire at

>> random, due to races

>> and clock drift.

>>

>> 3) I have seen scenarios where a single reqest fails.

>> If you know the duration of the session, it is easy to ignore "connection

>> broken" responses,

>> and only stop pinging when there has been no positive response within a

>> session duration.

>>

>> I think you need to adress issue 1 and 2.

>> Issue 3 is easy and will improve failure resilience, but not required.

>>

>> Regards, Kenneth Skovhede, GEOGRAF A/S

>>