[mapguide-internals] Server status/Ping API

[Martin Morrison]

So let the image have an arg for an FDO connection.  If the arg is present, read the FDO, if not use the legend image.

Being able to monitor Mapguide/Apache with SNMP would be the cat's meow...is it doable with the resources we have?


Martin



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Monday, October 26, 2009 4:57 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Server status/Ping API

my experience is the same as Jason, FDO is usually the problem ( hence
my orginal concerns about the pinned connections, but thats a different thread)

can i throw SNMP into the mix here? rather than re-inventing the wheel,
supporting SNMP would allow straight forward integration into
existing monitoring systems...

On Tue, Oct 27, 2009 at 7:17 AM, Jason Birch <jason at jasonbirch.com> wrote:
> In my experience, if a map isn't rendering it's often the FDO (connections)
> layer that's hung.
>
> 2009/10/26 Walt Welton-Lair <walt.welton-lair at autodesk.com>
>
>> How about reducing this to just a legend image?  That will still exercise
>> rendering, but it avoids the overhead of making FDO calls.
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:
>> mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Dave Wilson
>> Sent: Monday, October 26, 2009 12:09 PM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Server status/Ping API
>>
>> If we assume the image is a test image only then I wouldn't be concerned
>> about the map and credentials. We could even supply a default one that is a
>> variation of Sheboygan or something with 1 or 2 layers max. Since the
>> eventual request is server side it could use the server authentication to
>> access and render the map.
>>
>> I'm more concerned about how you get multiple results back from all sites.
>> I'm guessing the request is a multipart post that processes each server one
>> by one in a loop in the webtier or does it process them all, assemble the
>> results (including any failures) and return one result set?
>>
>> Dave
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:
>> mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Bruce Dechant
>> Sent: Monday, October 26, 2009 9:23 AM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Server status/Ping API
>>
>> A ping is supposed to be fast - adding overhead to generate a map image
>> could be slow, but having this optional would get around that. What about
>> security risks of being able to render a map without credentials? Obviously
>> if it is a tiny thumbnail of the map it is not very useful at all - other
>> than to see if the server is there and can render it.
>>
>> Thanks,
>> Bruce
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:
>> mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
>> Sent: Monday, October 26, 2009 8:08 AM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Server status/Ping API
>>
>> No problem on the performance metrics.
>>
>> Martin's suggestion of doing a lightweight render is a good idea.  Perhaps
>> we can make this an optional item with the render only occurring if a map
>> definition resource id is supplied as an input parameter.  We could just
>> render a small image at the map extents.  The various pieces - API version,
>> offline/online, and image could be returned as an xml document with the
>> image returned as a base64 blob.  Something like this perhaps:
>>
>> <Ping>
>>  <Status>Online</Status>
>>  <ApiVersion>2.2</ApiVersion>
>>  <ImageSize>8061</ImageSize>
>>  <Image>[8061 base64 encoded bytes]</Image>
>> </Ping>
>>
>> Thanks,
>> Trevor
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:
>> mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Bruce Dechant
>> Sent: October 26, 2009 7:55 AM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Server status/Ping API
>>
>> The API version would be nice to have.
>>
>> I have to agree that performance metrics without credentials I'm not sure I
>> like.
>>
>> Bruce
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:
>> mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
>> Sent: Sunday, October 25, 2009 11:00 AM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] Server status/Ping API
>>
>> I think it would be cool to return API version (2.1, 2.2, etc) as part
>> of this, but not rev/build.
>>
>> Would be hesitant to return performance metrics through a non-authenticated
>> api.
>>
>> Jason
>>
>> On 2009-10-22, Bruce Dechant <bruce.dechant at autodesk.com> wrote:
>> > Hi All,
>> >
>> > The existing Server Admin service has the following APIs that are not
>> > officially published but are available to use:
>> >
>> > GetSiteVersion() - returns the exact MapGuide server version
>> > GetSiteInfo() - returns MapGuide server information and OS information
>> >
>> > Both of these require authentication credentials because of the
>> information
>> > returned.
>> >
>> > I was wondering about adding a new API that would not require
>> authentication
>> > credentials.
>> >
>> > Example: GetSiteStatus()
>> >
>> > I would like it to return the server status as either "Offline" or
>> "Online"
>> > as some of the information.
>> >
>> > This API could be used as a sort of "ping" if needed.
>> >
>> > What other non sensitive information do you think we could include with
>> this
>> > API?
>> >
>> > Thanks,
>> > Bruce
>> > _______________________________________________
>> > mapguide-internals mailing list
>> > mapguide-internals at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> >
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>



-- 
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals