Please review RFC 66
|
|
| 1 2 |
Christine Bao
|
Hi all,
RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
Kenneth Skovhede, GEOGRAF A/S
|
I would suggest that there is a real function to support "keep alive" pings,
instead of calling a function that has another purpose. Also, the client would have to read out the timeout value, to correctly adjust the ping interval. Perhaps it would be reasonable to have a "GETSESSIONTIMEOUT" function, so the client can call this, and use the returned value to dynamically adjust the ping interval? Also, connection broken exception should be handled with extra logic in the client to repeat the ping with a short interval to counter temporary network problems. Other than that, I like the proposal, and have implemented it with custom code myself. Regards, Kenneth Skovhede, GEOGRAF A/S Christine Bao skrev: > Hi all, > > RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. > > Thanks & regards, > Christine > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
Haris Kurtagic
|
In reply to this post
by Christine Bao
For Keep alive script there will be option to turn it on or off ? I don't like idea of clients making constant auto requests to server. Perhaps for some applications it make sense but I think that should be optional to turn it on (include script). Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Christine Bao Sent: Wednesday, June 17, 2009 5:12 AM To: [hidden email] Subject: [mapguide-internals] Please review RFC 66 Hi all, RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
Chris Claydon
|
I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue.
Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic Sent: Wednesday, June 17, 2009 6:35 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 For Keep alive script there will be option to turn it on or off ? I don't like idea of clients making constant auto requests to server. Perhaps for some applications it make sense but I think that should be optional to turn it on (include script). Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Christine Bao Sent: Wednesday, June 17, 2009 5:12 AM To: [hidden email] Subject: [mapguide-internals] Please review RFC 66 Hi all, RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
Jason Birch
|
What would this user prompt look like?
I think that with the current users if your connection is dropped you need a full browser refresh to re-establish your session and all of the objects associated with it. If that's the case, would the user be told to "press refresh in your browser", or be provided with a button to do the same, or... Jason -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon Sent: Wednesday, June 17, 2009 7:25 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic Sent: Wednesday, June 17, 2009 6:35 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 For Keep alive script there will be option to turn it on or off ? I don't like idea of clients making constant auto requests to server. Perhaps for some applications it make sense but I think that should be optional to turn it on (include script). Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Christine Bao Sent: Wednesday, June 17, 2009 5:12 AM To: [hidden email] Subject: [mapguide-internals] Please review RFC 66 Hi all, RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Chris Claydon
|
I thought I saw some code go into Fusion trunk to allow the user to specify a certain amount of map state when loading a layout, so we might be able to do a little better than a full browser refresh. I was thinking more along the lines of re-creating any session-resident resources and preserving as much state information as is available (and applicable) within the client.
I can't claim to have given this any in-depth analysis, however. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch Sent: Wednesday, June 17, 2009 9:03 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 What would this user prompt look like? I think that with the current users if your connection is dropped you need a full browser refresh to re-establish your session and all of the objects associated with it. If that's the case, would the user be told to "press refresh in your browser", or be provided with a button to do the same, or... Jason -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon Sent: Wednesday, June 17, 2009 7:25 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic Sent: Wednesday, June 17, 2009 6:35 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 For Keep alive script there will be option to turn it on or off ? I don't like idea of clients making constant auto requests to server. Perhaps for some applications it make sense but I think that should be optional to turn it on (include script). Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Christine Bao Sent: Wednesday, June 17, 2009 5:12 AM To: [hidden email] Subject: [mapguide-internals] Please review RFC 66 Hi all, RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Jason Birch
|
A best-effort session recreation would be great. Not sure how this would work with Fusion PHP sessions; don't they try to use the same sessionID as the Mg session?
Note that network problems between the web tier and the server, or inactivity on the client side, are not the only reasons for a client disconnect. If the server goes down, this also happens. With this in mind, it would be useful if there was the ability to have something like "Could not connect to server, click here to reload your session. If this problem persists, please contact the City of Nanaimo Help Desk at 250-555-5555" Jason -----Original Message----- From: Chris Claydon Sent: Wednesday, June 17, 2009 8:14 AM Subject: RE: [mapguide-internals] Please review RFC 66 I thought I saw some code go into Fusion trunk to allow the user to specify a certain amount of map state when loading a layout, so we might be able to do a little better than a full browser refresh. I was thinking more along the lines of re-creating any session-resident resources and preserving as much state information as is available (and applicable) within the client. I can't claim to have given this any in-depth analysis, however. _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Jason Birch
|
Um, preferably user-configurable so that all of the MapGuide implementations aren't calling my help desk :)
Jason -----Original Message----- From: Jason Birch Sent: Wednesday, June 17, 2009 8:31 AM Subject: RE: [mapguide-internals] Please review RFC 66 With this in mind, it would be useful if there was the ability to have something like "Could not connect to server, click here to reload your session. If this problem persists, please contact the City of Nanaimo Help Desk at 250-555-5555" _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
Trevor Wekel-3
|
In reply to this post
by Chris Claydon
Hi everyone,
Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: SAVESESSION --> mgp downloaded to viewer Original server goes offline Exceptions thrown Viewer calls CREATESESSION to get a new session on another server Viewer calls LOADSESSION(newSessionId, downloaded mgp) Viewer sets appropriate center/scale But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. Thanks, Trevor -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon Sent: Wednesday, June 17, 2009 9:14 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 I thought I saw some code go into Fusion trunk to allow the user to specify a certain amount of map state when loading a layout, so we might be able to do a little better than a full browser refresh. I was thinking more along the lines of re-creating any session-resident resources and preserving as much state information as is available (and applicable) within the client. I can't claim to have given this any in-depth analysis, however. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch Sent: Wednesday, June 17, 2009 9:03 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 What would this user prompt look like? I think that with the current users if your connection is dropped you need a full browser refresh to re-establish your session and all of the objects associated with it. If that's the case, would the user be told to "press refresh in your browser", or be provided with a button to do the same, or... Jason -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon Sent: Wednesday, June 17, 2009 7:25 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic Sent: Wednesday, June 17, 2009 6:35 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 For Keep alive script there will be option to turn it on or off ? I don't like idea of clients making constant auto requests to server. Perhaps for some applications it make sense but I think that should be optional to turn it on (include script). Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Christine Bao Sent: Wednesday, June 17, 2009 5:12 AM To: [hidden email] Subject: [mapguide-internals] Please review RFC 66 Hi all, RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Jason Birch
|
I'm not sure that it's necessary to recreate the whole session; when it times out, often it's too late to save. Just enough to recreate the user's current view state (extent, layer state, possibly selection, etc) would be a good best-effort.
Jason -----Original Message----- From: Trevor Wekel Sent: Wednesday, June 17, 2009 10:29 AM Subject: RE: [mapguide-internals] Please review RFC 66 Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: SAVESESSION --> mgp downloaded to viewer Original server goes offline Exceptions thrown Viewer calls CREATESESSION to get a new session on another server Viewer calls LOADSESSION(newSessionId, downloaded mgp) Viewer sets appropriate center/scale But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Christine Bao
|
In reply to this post
by Christine Bao
Hi all,
Thank you for your quick response. Your suggestions are very appreciated! To Trevor & Jason, This task is not about "session recreation". It pings the MapGuide server periodically to avoid session timeout as Fusion does, and we don't support recreate a session from one which is timeout. Actually there was discussion about real "session recreation", but it's scoped out due to time/resource limitation. To Haris, Yes, there is setting to configure how often Ajax viewer will ping server. The default value is 5 minutes, the same as Fusion does. And you can set it to a longer time, or turn it off. To Chris, Thank you for your reminder. Your suggestion is very good. If server fails the browser should stop pinging server again and again. It totally makes sense. Thanks & regards, Christine -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Friday, June 19, 2009 12:00 AM To: [hidden email] Subject: mapguide-internals Digest, Vol 30, Issue 9 Send mapguide-internals mailing list submissions to [hidden email] To subscribe or unsubscribe via the World Wide Web, visit http://lists.osgeo.org/mailman/listinfo/mapguide-internals or, via email, send a message with subject or body 'help' to [hidden email] You can reach the person managing the list at [hidden email] When replying, please edit your Subject line so it is more specific than "Re: Contents of mapguide-internals digest..." Today's Topics: 1. RE: Please review RFC 66 (Trevor Wekel) 2. RE: Please review RFC 66 (Jason Birch) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Jun 2009 10:29:25 -0700 From: Trevor Wekel <[hidden email]> Subject: RE: [mapguide-internals] Please review RFC 66 To: MapGuide Internals Mail List <[hidden email]> Message-ID: <[hidden email]> Content-Type: text/plain; charset="us-ascii" Hi everyone, Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: SAVESESSION --> mgp downloaded to viewer Original server goes offline Exceptions thrown Viewer calls CREATESESSION to get a new session on another server Viewer calls LOADSESSION(newSessionId, downloaded mgp) Viewer sets appropriate center/scale But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. Thanks, Trevor -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon Sent: Wednesday, June 17, 2009 9:14 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 I thought I saw some code go into Fusion trunk to allow the user to specify a certain amount of map state when loading a layout, so we might be able to do a little better than a full browser refresh. I was thinking more along the lines of re-creating any session-resident resources and preserving as much state information as is available (and applicable) within the client. I can't claim to have given this any in-depth analysis, however. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch Sent: Wednesday, June 17, 2009 9:03 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 What would this user prompt look like? I think that with the current users if your connection is dropped you need a full browser refresh to re-establish your session and all of the objects associated with it. If that's the case, would the user be told to "press refresh in your browser", or be provided with a button to do the same, or... Jason -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon Sent: Wednesday, June 17, 2009 7:25 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue. Chris. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic Sent: Wednesday, June 17, 2009 6:35 AM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] Please review RFC 66 For Keep alive script there will be option to turn it on or off ? I don't like idea of clients making constant auto requests to server. Perhaps for some applications it make sense but I think that should be optional to turn it on (include script). Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Christine Bao Sent: Wednesday, June 17, 2009 5:12 AM To: [hidden email] Subject: [mapguide-internals] Please review RFC 66 Hi all, RFC 66 - Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. Would you please review it? Thank you in advance. Thanks & regards, Christine _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals ------------------------------ Message: 2 Date: Wed, 17 Jun 2009 10:58:23 -0700 From: Jason Birch <[hidden email]> Subject: RE: [mapguide-internals] Please review RFC 66 To: MapGuide Internals Mail List <[hidden email]> Message-ID: <26D0CD10F2AC5B4E9C48C3F17D577BEA31963AD0@kendrick> Content-Type: text/plain; charset="us-ascii" I'm not sure that it's necessary to recreate the whole session; when it times out, often it's too late to save. Just enough to recreate the user's current view state (extent, layer state, possibly selection, etc) would be a good best-effort. Jason -----Original Message----- From: Trevor Wekel Sent: Wednesday, June 17, 2009 10:29 AM Subject: RE: [mapguide-internals] Please review RFC 66 Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: SAVESESSION --> mgp downloaded to viewer Original server goes offline Exceptions thrown Viewer calls CREATESESSION to get a new session on another server Viewer calls LOADSESSION(newSessionId, downloaded mgp) Viewer sets appropriate center/scale But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. ------------------------------ _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals End of mapguide-internals Digest, Vol 30, Issue 9 ************************************************* _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
zspitzer
|
will it only be for logged in users?
On Fri, Jun 19, 2009 at 7:44 PM, Christine Bao<[hidden email]> wrote: > Hi all, > > Thank you for your quick response. Your suggestions are very appreciated! > > To Trevor & Jason, > This task is not about "session recreation". It pings the MapGuide server periodically to avoid session timeout as Fusion does, and we don't support recreate a session from one which is timeout. Actually there was discussion about real "session recreation", but it's scoped out due to time/resource limitation. > > To Haris, > Yes, there is setting to configure how often Ajax viewer will ping server. The default value is 5 minutes, the same as Fusion does. And you can set it to a longer time, or turn it off. > > To Chris, > Thank you for your reminder. Your suggestion is very good. If server fails the browser should stop pinging server again and again. It totally makes sense. > > Thanks & regards, > Christine > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] > Sent: Friday, June 19, 2009 12:00 AM > To: [hidden email] > Subject: mapguide-internals Digest, Vol 30, Issue 9 > > Send mapguide-internals mailing list submissions to > [hidden email] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > or, via email, send a message with subject or body 'help' to > [hidden email] > > You can reach the person managing the list at > [hidden email] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mapguide-internals digest..." > > > Today's Topics: > > 1. RE: Please review RFC 66 (Trevor Wekel) > 2. RE: Please review RFC 66 (Jason Birch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Jun 2009 10:29:25 -0700 > From: Trevor Wekel <[hidden email]> > Subject: RE: [mapguide-internals] Please review RFC 66 > To: MapGuide Internals Mail List <[hidden email]> > Message-ID: > <[hidden email]> > > Content-Type: text/plain; charset="us-ascii" > > Hi everyone, > > Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: > > SAVESESSION --> mgp downloaded to viewer > Original server goes offline > Exceptions thrown > Viewer calls CREATESESSION to get a new session on another server > Viewer calls LOADSESSION(newSessionId, downloaded mgp) > Viewer sets appropriate center/scale > > But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. > > Thanks, > Trevor > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon > Sent: Wednesday, June 17, 2009 9:14 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > I thought I saw some code go into Fusion trunk to allow the user to specify a certain amount of map state when loading a layout, so we might be able to do a little better than a full browser refresh. I was thinking more along the lines of re-creating any session-resident resources and preserving as much state information as is available (and applicable) within the client. > > I can't claim to have given this any in-depth analysis, however. > > Chris. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch > Sent: Wednesday, June 17, 2009 9:03 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > What would this user prompt look like? > > I think that with the current users if your connection is dropped you need a full browser refresh to re-establish your session and all of the objects associated with it. If that's the case, would the user be told to "press refresh in your browser", or be provided with a button to do the same, or... > > Jason > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon > Sent: Wednesday, June 17, 2009 7:25 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue. > > Chris. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic > Sent: Wednesday, June 17, 2009 6:35 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > > For Keep alive script there will be option to turn it on or off ? > > I don't like idea of clients making constant auto requests to server. > Perhaps for some applications it make sense but I think that should be > optional to turn it on (include script). > > Haris > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Christine Bao > Sent: Wednesday, June 17, 2009 5:12 AM > To: [hidden email] > Subject: [mapguide-internals] Please review RFC 66 > > Hi all, > > RFC 66 - > Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. > Would you please review it? Thank you in advance. > > Thanks & regards, > Christine > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Jun 2009 10:58:23 -0700 > From: Jason Birch <[hidden email]> > Subject: RE: [mapguide-internals] Please review RFC 66 > To: MapGuide Internals Mail List <[hidden email]> > Message-ID: <26D0CD10F2AC5B4E9C48C3F17D577BEA31963AD0@kendrick> > Content-Type: text/plain; charset="us-ascii" > > I'm not sure that it's necessary to recreate the whole session; when it times out, often it's too late to save. Just enough to recreate the user's current view state (extent, layer state, possibly selection, etc) would be a good best-effort. > > Jason > > -----Original Message----- > From: Trevor Wekel > Sent: Wednesday, June 17, 2009 10:29 AM > Subject: RE: [mapguide-internals] Please review RFC 66 > > Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: > > SAVESESSION --> mgp downloaded to viewer > Original server goes offline > Exceptions thrown > Viewer calls CREATESESSION to get a new session on another server > Viewer calls LOADSESSION(newSessionId, downloaded mgp) > Viewer sets appropriate center/scale > > But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. > > > ------------------------------ > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > > > End of mapguide-internals Digest, Vol 30, Issue 9 > ************************************************* > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Kenneth Skovhede, GEOGRAF A/S
|
In reply to this post
by Christine Bao
I commented on the issue as well.
You are free to ignore it, but in case you somehow missed it, here it is: http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 Regards, Kenneth Skovhede, GEOGRAF A/S Christine Bao skrev: > Hi all, > > Thank you for your quick response. Your suggestions are very appreciated! > > To Trevor & Jason, > This task is not about "session recreation". It pings the MapGuide server periodically to avoid session timeout as Fusion does, and we don't support recreate a session from one which is timeout. Actually there was discussion about real "session recreation", but it's scoped out due to time/resource limitation. > > To Haris, > Yes, there is setting to configure how often Ajax viewer will ping server. The default value is 5 minutes, the same as Fusion does. And you can set it to a longer time, or turn it off. > > To Chris, > Thank you for your reminder. Your suggestion is very good. If server fails the browser should stop pinging server again and again. It totally makes sense. > > Thanks & regards, > Christine > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] > Sent: Friday, June 19, 2009 12:00 AM > To: [hidden email] > Subject: mapguide-internals Digest, Vol 30, Issue 9 > > Send mapguide-internals mailing list submissions to > [hidden email] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > or, via email, send a message with subject or body 'help' to > [hidden email] > > You can reach the person managing the list at > [hidden email] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mapguide-internals digest..." > > > Today's Topics: > > 1. RE: Please review RFC 66 (Trevor Wekel) > 2. RE: Please review RFC 66 (Jason Birch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Jun 2009 10:29:25 -0700 > From: Trevor Wekel <[hidden email]> > Subject: RE: [mapguide-internals] Please review RFC 66 > To: MapGuide Internals Mail List <[hidden email]> > Message-ID: > <[hidden email]> > > Content-Type: text/plain; charset="us-ascii" > > Hi everyone, > > Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: > > SAVESESSION --> mgp downloaded to viewer > Original server goes offline > Exceptions thrown > Viewer calls CREATESESSION to get a new session on another server > Viewer calls LOADSESSION(newSessionId, downloaded mgp) > Viewer sets appropriate center/scale > > But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. > > Thanks, > Trevor > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon > Sent: Wednesday, June 17, 2009 9:14 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > I thought I saw some code go into Fusion trunk to allow the user to specify a certain amount of map state when loading a layout, so we might be able to do a little better than a full browser refresh. I was thinking more along the lines of re-creating any session-resident resources and preserving as much state information as is available (and applicable) within the client. > > I can't claim to have given this any in-depth analysis, however. > > Chris. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch > Sent: Wednesday, June 17, 2009 9:03 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > What would this user prompt look like? > > I think that with the current users if your connection is dropped you need a full browser refresh to re-establish your session and all of the objects associated with it. If that's the case, would the user be told to "press refresh in your browser", or be provided with a button to do the same, or... > > Jason > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon > Sent: Wednesday, June 17, 2009 7:25 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > I agree that this should be configurable. My preference is to switch it on by default. Fusion already pings the server periodically to keep the session alive, and I think it prevents more problems than it causes. However, it needs to be updated so that if the session no longer exists, it stops trying, and prompts the user to re-connect. - with the current setup, the error log can get filled with "Session not found" errors if the server is re-started (and thus the original session is lost). I'm pretty sure there is already a Trac ticket logged against Fusion for this issue. > > Chris. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic > Sent: Wednesday, June 17, 2009 6:35 AM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] Please review RFC 66 > > > For Keep alive script there will be option to turn it on or off ? > > I don't like idea of clients making constant auto requests to server. > Perhaps for some applications it make sense but I think that should be > optional to turn it on (include script). > > Haris > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Christine Bao > Sent: Wednesday, June 17, 2009 5:12 AM > To: [hidden email] > Subject: [mapguide-internals] Please review RFC 66 > > Hi all, > > RFC 66 - > Failover<https://trac.osgeo.org/mapguide/wiki/MapGuideRfc66> is posted. > Would you please review it? Thank you in advance. > > Thanks & regards, > Christine > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Jun 2009 10:58:23 -0700 > From: Jason Birch <[hidden email]> > Subject: RE: [mapguide-internals] Please review RFC 66 > To: MapGuide Internals Mail List <[hidden email]> > Message-ID: <26D0CD10F2AC5B4E9C48C3F17D577BEA31963AD0@kendrick> > Content-Type: text/plain; charset="us-ascii" > > I'm not sure that it's necessary to recreate the whole session; when it times out, often it's too late to save. Just enough to recreate the user's current view state (extent, layer state, possibly selection, etc) would be a good best-effort. > > Jason > > -----Original Message----- > From: Trevor Wekel > Sent: Wednesday, June 17, 2009 10:29 AM > Subject: RE: [mapguide-internals] Please review RFC 66 > > Session recreation is tricky business. You would need to implement two HTTP APIs to make this work. SAVESESSION(sessionId) would download the user's session repository as an mgp. The second API, LOADSESSION(sessionId, mgp) would upload the same mgp into a newly created session repository on another server. The overall flow would be something like this: > > SAVESESSION --> mgp downloaded to viewer > Original server goes offline > Exceptions thrown > Viewer calls CREATESESSION to get a new session on another server > Viewer calls LOADSESSION(newSessionId, downloaded mgp) > Viewer sets appropriate center/scale > > But there is a big catch here. The downloaded mgp will contain old session repository references, eg, "Session:xxyyzz//Temporary.LayerDefinition" for any dynamically generated resources (layers, SDF feature sources, selection, etc). LOADSESSION will have to fixup all of these references during the load process. > > > ------------------------------ > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > > > End of mapguide-internals Digest, Vol 30, Issue 9 > ************************************************* > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Christine Bao
|
In reply to this post
by Christine Bao
Hi Kenneth,
Thank you for your suggestion. Here are my comments: 1. A real function to support "keep alive" pings We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. This function is light-weighted and won't cause much overhead. Using this method is the easiest way to approach it. Your suggestion makes sense, but we'll need to add another API which is only for this purpose, so we decide not to do this. 2. The client read out timeout value to adjust ping interval I'm afraid it's too much complicated. The plan is to ping server at a fixed time interval (of course you can set it in configuration), and the interval won't change during runtime. It works as Fusion does. 3. Connection broken Once the connection broken or timeout because server down, the client will stop ping server. But it will not recovery from a broken/timeout session. Thanks & regards, Christine ------------------------------ Message: 3 Date: Fri, 19 Jun 2009 12:41:14 +0200 From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> Subject: Re: [mapguide-internals] RE: Please review RFC 66 To: MapGuide Internals Mail List <[hidden email]> Message-ID: <[hidden email]> Content-Type: text/plain; charset=ISO-8859-3; format=flowed I commented on the issue as well. You are free to ignore it, but in case you somehow missed it, here it is: http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 Regards, Kenneth Skovhede, GEOGRAF A/S _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
zspitzer
|
how about GETSITEVERSION ? that's what I have used for keepalives in
my own stuff and it returns a much smaller response? z On Mon, Jun 22, 2009 at 4:05 PM, Christine Bao<[hidden email]> wrote: > Hi Kenneth, > > Thank you for your suggestion. Here are my comments: > > > 1. A real function to support "keep alive" pings > > We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. This function is light-weighted and won't cause much overhead. Using this method is the easiest way to approach it. Your suggestion makes sense, but we'll need to add another API which is only for this purpose, so we decide not to do this. > > > > 2. The client read out timeout value to adjust ping interval > > I'm afraid it's too much complicated. The plan is to ping server at a fixed time interval (of course you can set it in configuration), and the interval won't change during runtime. It works as Fusion does. > > > > 3. Connection broken > > Once the connection broken or timeout because server down, the client will stop ping server. But it will not recovery from a broken/timeout session. > > Thanks & regards, > Christine > > > ------------------------------ > > > > Message: 3 > > Date: Fri, 19 Jun 2009 12:41:14 +0200 > > From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> > > Subject: Re: [mapguide-internals] RE: Please review RFC 66 > > To: MapGuide Internals Mail List <[hidden email]> > > Message-ID: <[hidden email]> > > Content-Type: text/plain; charset=ISO-8859-3; format=flowed > > > > I commented on the issue as well. > > > > You are free to ignore it, but in case you somehow missed it, here it is: > > http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 > > > > Regards, Kenneth Skovhede, GEOGRAF A/S > > > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Kenneth Skovhede, GEOGRAF A/S
|
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 Zac Spitzer skrev: > how about GETSITEVERSION ? that's what I have used for keepalives in > my own stuff > and it returns a much smaller response? > > z > > On Mon, Jun 22, 2009 at 4:05 PM, Christine > Bao<[hidden email]> wrote: > >> Hi Kenneth, >> >> Thank you for your suggestion. Here are my comments: >> >> >> 1. A real function to support "keep alive" pings >> >> We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. This function is light-weighted and won't cause much overhead. Using this method is the easiest way to approach it. Your suggestion makes sense, but we'll need to add another API which is only for this purpose, so we decide not to do this. >> >> >> >> 2. The client read out timeout value to adjust ping interval >> >> I'm afraid it's too much complicated. The plan is to ping server at a fixed time interval (of course you can set it in configuration), and the interval won't change during runtime. It works as Fusion does. >> >> >> >> 3. Connection broken >> >> Once the connection broken or timeout because server down, the client will stop ping server. But it will not recovery from a broken/timeout session. >> >> Thanks & regards, >> Christine >> >> >> ------------------------------ >> >> >> >> Message: 3 >> >> Date: Fri, 19 Jun 2009 12:41:14 +0200 >> >> From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> >> >> Subject: Re: [mapguide-internals] RE: Please review RFC 66 >> >> To: MapGuide Internals Mail List <[hidden email]> >> >> Message-ID: <[hidden email]> >> >> Content-Type: text/plain; charset=ISO-8859-3; format=flowed >> >> >> >> I commented on the issue as well. >> >> >> >> You are free to ignore it, but in case you somehow missed it, here it is: >> >> http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 >> >> >> >> Regards, Kenneth Skovhede, GEOGRAF A/S >> >> >> >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> >> > > > > mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
zspitzer
|
Frustratingly, there isn't currently a nice simple way to check if a
session is valid without getting into exception and error log territory Adding something like MgSite.isValidSession(sessionId) which returns a boolean result would be really useful and elimate the need for klunky workarounds. z On Mon, Jun 22, 2009 at 4:55 PM, Kenneth Skovhede, GEOGRAF A/S<[hidden email]> 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 > > > > Zac Spitzer skrev: >> >> how about GETSITEVERSION ? that's what I have used for keepalives in >> my own stuff >> and it returns a much smaller response? >> >> z >> >> On Mon, Jun 22, 2009 at 4:05 PM, Christine >> Bao<[hidden email]> wrote: >> >>> >>> Hi Kenneth, >>> >>> Thank you for your suggestion. Here are my comments: >>> >>> >>> 1. A real function to support "keep alive" pings >>> >>> We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. >>> This function is light-weighted and won't cause much overhead. Using this >>> method is the easiest way to approach it. Your suggestion makes sense, but >>> we'll need to add another API which is only for this purpose, so we decide >>> not to do this. >>> >>> >>> >>> 2. The client read out timeout value to adjust ping interval >>> >>> I'm afraid it's too much complicated. The plan is to ping server at a >>> fixed time interval (of course you can set it in configuration), and the >>> interval won't change during runtime. It works as Fusion does. >>> >>> >>> >>> 3. Connection broken >>> >>> Once the connection broken or timeout because server down, the client >>> will stop ping server. But it will not recovery from a broken/timeout >>> session. >>> >>> Thanks & regards, >>> Christine >>> >>> >>> ------------------------------ >>> >>> >>> >>> Message: 3 >>> >>> Date: Fri, 19 Jun 2009 12:41:14 +0200 >>> >>> From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> >>> >>> Subject: Re: [mapguide-internals] RE: Please review RFC 66 >>> >>> To: MapGuide Internals Mail List <[hidden email]> >>> >>> Message-ID: <[hidden email]> >>> >>> Content-Type: text/plain; charset=ISO-8859-3; format=flowed >>> >>> >>> >>> I commented on the issue as well. >>> >>> >>> >>> You are free to ignore it, but in case you somehow missed it, here it is: >>> >>> http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 >>> >>> >>> >>> Regards, Kenneth Skovhede, GEOGRAF A/S >>> >>> >>> >>> _______________________________________________ >>> mapguide-internals mailing list >>> [hidden email] >>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >>> >>> >> >> >> >> > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Trevor Wekel-3
|
Hi Zac,
I think ResourceExists is implemented in 2.1. I wonder if MgResourceService.ResourceExists would work on the root of the session repository "Session:xxyyzz-abc//"? Alternatively you could check for the existence of the MgMap object "Session:xxyyzz-abc//MyMapName.Map". ResourceExists does return a boolean. Thanks, Trevor ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] Sent: Monday, June 22, 2009 2:10 AM To: MapGuide Internals Mail List Subject: Re: [mapguide-internals] Re: Please review RFC 66 Frustratingly, there isn't currently a nice simple way to check if a session is valid without getting into exception and error log territory Adding something like MgSite.isValidSession(sessionId) which returns a boolean result would be really useful and elimate the need for klunky workarounds. z On Mon, Jun 22, 2009 at 4:55 PM, Kenneth Skovhede, GEOGRAF A/S<[hidden email]> 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 > > > > Zac Spitzer skrev: >> >> how about GETSITEVERSION ? that's what I have used for keepalives in >> my own stuff >> and it returns a much smaller response? >> >> z >> >> On Mon, Jun 22, 2009 at 4:05 PM, Christine >> Bao<[hidden email]> wrote: >> >>> >>> Hi Kenneth, >>> >>> Thank you for your suggestion. Here are my comments: >>> >>> >>> 1. A real function to support "keep alive" pings >>> >>> We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. >>> This function is light-weighted and won't cause much overhead. Using this >>> method is the easiest way to approach it. Your suggestion makes sense, but >>> we'll need to add another API which is only for this purpose, so we decide >>> not to do this. >>> >>> >>> >>> 2. The client read out timeout value to adjust ping interval >>> >>> I'm afraid it's too much complicated. The plan is to ping server at a >>> fixed time interval (of course you can set it in configuration), and the >>> interval won't change during runtime. It works as Fusion does. >>> >>> >>> >>> 3. Connection broken >>> >>> Once the connection broken or timeout because server down, the client >>> will stop ping server. But it will not recovery from a broken/timeout >>> session. >>> >>> Thanks & regards, >>> Christine >>> >>> >>> ------------------------------ >>> >>> >>> >>> Message: 3 >>> >>> Date: Fri, 19 Jun 2009 12:41:14 +0200 >>> >>> From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> >>> >>> Subject: Re: [mapguide-internals] RE: Please review RFC 66 >>> >>> To: MapGuide Internals Mail List <[hidden email]> >>> >>> Message-ID: <[hidden email]> >>> >>> Content-Type: text/plain; charset=ISO-8859-3; format=flowed >>> >>> >>> >>> I commented on the issue as well. >>> >>> >>> >>> You are free to ignore it, but in case you somehow missed it, here it is: >>> >>> http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 >>> >>> >>> >>> Regards, Kenneth Skovhede, GEOGRAF A/S >>> >>> >>> >>> _______________________________________________ >>> mapguide-internals mailing list >>> [hidden email] >>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >>> >>> >> >> >> >> > > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals_______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
zspitzer
|
ahh, of course, thanks Trevor, I'm actually wokring on upgrading an app to 2.1
at the moment, I'll try it z On Mon, Jun 22, 2009 at 6:21 PM, Trevor Wekel<[hidden email]> wrote: > Hi Zac, > > I think ResourceExists is implemented in 2.1. I wonder if MgResourceService.ResourceExists would work on the root of the session repository "Session:xxyyzz-abc//"? Alternatively you could check for the existence of the MgMap object "Session:xxyyzz-abc//MyMapName.Map". > > ResourceExists does return a boolean. > > Thanks, > Trevor > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] > Sent: Monday, June 22, 2009 2:10 AM > To: MapGuide Internals Mail List > Subject: Re: [mapguide-internals] Re: Please review RFC 66 > > Frustratingly, there isn't currently a nice simple way to check if a > session is valid without getting into exception and error log territory > > Adding something like MgSite.isValidSession(sessionId) which returns > a boolean result would be really useful and elimate the need for klunky > workarounds. > > z > > > On Mon, Jun 22, 2009 at 4:55 PM, Kenneth Skovhede, GEOGRAF > A/S<[hidden email]> 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 >> >> >> >> Zac Spitzer skrev: >>> >>> how about GETSITEVERSION ? that's what I have used for keepalives in >>> my own stuff >>> and it returns a much smaller response? >>> >>> z >>> >>> On Mon, Jun 22, 2009 at 4:05 PM, Christine >>> Bao<[hidden email]> wrote: >>> >>>> >>>> Hi Kenneth, >>>> >>>> Thank you for your suggestion. Here are my comments: >>>> >>>> >>>> 1. A real function to support "keep alive" pings >>>> >>>> We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. >>>> This function is light-weighted and won't cause much overhead. Using this >>>> method is the easiest way to approach it. Your suggestion makes sense, but >>>> we'll need to add another API which is only for this purpose, so we decide >>>> not to do this. >>>> >>>> >>>> >>>> 2. The client read out timeout value to adjust ping interval >>>> >>>> I'm afraid it's too much complicated. The plan is to ping server at a >>>> fixed time interval (of course you can set it in configuration), and the >>>> interval won't change during runtime. It works as Fusion does. >>>> >>>> >>>> >>>> 3. Connection broken >>>> >>>> Once the connection broken or timeout because server down, the client >>>> will stop ping server. But it will not recovery from a broken/timeout >>>> session. >>>> >>>> Thanks & regards, >>>> Christine >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> >>>> Message: 3 >>>> >>>> Date: Fri, 19 Jun 2009 12:41:14 +0200 >>>> >>>> From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> >>>> >>>> Subject: Re: [mapguide-internals] RE: Please review RFC 66 >>>> >>>> To: MapGuide Internals Mail List <[hidden email]> >>>> >>>> Message-ID: <[hidden email]> >>>> >>>> Content-Type: text/plain; charset=ISO-8859-3; format=flowed >>>> >>>> >>>> >>>> I commented on the issue as well. >>>> >>>> >>>> >>>> You are free to ignore it, but in case you somehow missed it, here it is: >>>> >>>> http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 >>>> >>>> >>>> >>>> Regards, Kenneth Skovhede, GEOGRAF A/S >>>> >>>> >>>> >>>> _______________________________________________ >>>> mapguide-internals mailing list >>>> [hidden email] >>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >>>> >>>> >>> >>> >>> >>> >> >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals_______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
zspitzer
|
seem to work well
i did a test by creating one session, then creating another and then closing the first and testing is the session:close_session_id exists which returned no/false ( as Administrator) out of interest, in the admin log even tho ResourceExists returned False, it logs as sucess <2009-06-22T18:55:38> 1816 Administrator ResourceExists.1.0.0:1(Session:61b8e4b0-4138-102c-8000-005056c00008_en_7F0000010AFC0AFB0AFA//) Success does Success in these logs indicate the result, or just that the operation completed? z On Mon, Jun 22, 2009 at 6:26 PM, Zac Spitzer<[hidden email]> wrote: > ahh, of course, thanks Trevor, I'm actually wokring on upgrading an app to 2.1 > at the moment, I'll try it > > z > > > On Mon, Jun 22, 2009 at 6:21 PM, Trevor Wekel<[hidden email]> wrote: >> Hi Zac, >> >> I think ResourceExists is implemented in 2.1. I wonder if MgResourceService.ResourceExists would work on the root of the session repository "Session:xxyyzz-abc//"? Alternatively you could check for the existence of the MgMap object "Session:xxyyzz-abc//MyMapName.Map". >> >> ResourceExists does return a boolean. >> >> Thanks, >> Trevor >> >> ________________________________________ >> From: [hidden email] [[hidden email]] On Behalf Of Zac Spitzer [[hidden email]] >> Sent: Monday, June 22, 2009 2:10 AM >> To: MapGuide Internals Mail List >> Subject: Re: [mapguide-internals] Re: Please review RFC 66 >> >> Frustratingly, there isn't currently a nice simple way to check if a >> session is valid without getting into exception and error log territory >> >> Adding something like MgSite.isValidSession(sessionId) which returns >> a boolean result would be really useful and elimate the need for klunky >> workarounds. >> >> z >> >> >> On Mon, Jun 22, 2009 at 4:55 PM, Kenneth Skovhede, GEOGRAF >> A/S<[hidden email]> 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 >>> >>> >>> >>> Zac Spitzer skrev: >>>> >>>> how about GETSITEVERSION ? that's what I have used for keepalives in >>>> my own stuff >>>> and it returns a much smaller response? >>>> >>>> z >>>> >>>> On Mon, Jun 22, 2009 at 4:05 PM, Christine >>>> Bao<[hidden email]> wrote: >>>> >>>>> >>>>> Hi Kenneth, >>>>> >>>>> Thank you for your suggestion. Here are my comments: >>>>> >>>>> >>>>> 1. A real function to support "keep alive" pings >>>>> >>>>> We plan to call "GETFEATUREPROVIDERS" through MapAgent to keep alive. >>>>> This function is light-weighted and won't cause much overhead. Using this >>>>> method is the easiest way to approach it. Your suggestion makes sense, but >>>>> we'll need to add another API which is only for this purpose, so we decide >>>>> not to do this. >>>>> >>>>> >>>>> >>>>> 2. The client read out timeout value to adjust ping interval >>>>> >>>>> I'm afraid it's too much complicated. The plan is to ping server at a >>>>> fixed time interval (of course you can set it in configuration), and the >>>>> interval won't change during runtime. It works as Fusion does. >>>>> >>>>> >>>>> >>>>> 3. Connection broken >>>>> >>>>> Once the connection broken or timeout because server down, the client >>>>> will stop ping server. But it will not recovery from a broken/timeout >>>>> session. >>>>> >>>>> Thanks & regards, >>>>> Christine >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> >>>>> >>>>> Message: 3 >>>>> >>>>> Date: Fri, 19 Jun 2009 12:41:14 +0200 >>>>> >>>>> From: "Kenneth Skovhede, GEOGRAF A/S" <[hidden email]> >>>>> >>>>> Subject: Re: [mapguide-internals] RE: Please review RFC 66 >>>>> >>>>> To: MapGuide Internals Mail List <[hidden email]> >>>>> >>>>> Message-ID: <[hidden email]> >>>>> >>>>> Content-Type: text/plain; charset=ISO-8859-3; format=flowed >>>>> >>>>> >>>>> >>>>> I commented on the issue as well. >>>>> >>>>> >>>>> >>>>> You are free to ignore it, but in case you somehow missed it, here it is: >>>>> >>>>> http://n2.nabble.com/Please-review-RFC-66-tc3090381.html#a3092233 >>>>> >>>>> >>>>> >>>>> Regards, Kenneth Skovhede, GEOGRAF A/S >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mapguide-internals mailing list >>>>> [hidden email] >>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> mapguide-internals mailing list >>> [hidden email] >>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >>> >> >> >> >> -- >> Zac Spitzer - >> http://zacster.blogspot.com >> +61 405 847 168 >> _______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals_______________________________________________ >> mapguide-internals mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/mapguide-internals >> > > > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
