[mapguide-internals] Re: Please review RFC 66

Kenneth Skovhede, GEOGRAF A/S ks at geograf.dk
Tue Jun 23 05:02:11 EDT 2009


1)
In the file "webconfig.ini" you can set:
DisableAuthoring = 1

Which will disable a lot of features in the MapGuide server.
It is recommended to do so in the Autodesk MapGuide Security Whitepaper 
(page 3, middle).
http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7798553

I just tested this, and the GetSiteVersion method is disabled,
when DisableAuthoring is enabled.
FYI, GetFeatureProviders is also disabled.

This means that the keepalive feature will not work on a secure site.
This leads back to my original comment: Make a seperate method for this.

2)
How does the client (fusion, basic layout) read the timeout value?
The "20" minutes is set in the serverconfig.ini, and many people may 
have changed that value.
If the session timeout is changed to say 5 min, in order to handle heavy 
load better,
the keepalive system will not work as expected.

3) Ok, MgConnectionFailedException is a good place to stop pinging. I 
was thinking more of a "no response" type error when I wrote it.

Regards, Kenneth Skovhede, GEOGRAF A/S



Christine Bao skrev:
> 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
>>>       
>
>   
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>   


More information about the mapguide-internals mailing list