[mapguide-internals] Some questions about mapguide sessions

[Gabriele Monfardini]

Hi Trevor,

thank you for your patience and the quick reply.

> Setting the interval very high may result in an unresponsive MapGuide Server.
> The cleanup occurs on a separate thread.  The thread will lock portions of or all
> of the session repository during the cleanup process.  In very high concurrency
> testing (new sessions every second or faster), I have seen the MapGuide Server
> "lock out" for up to a minute while hundreds or thousands of stale sessions
> are deleted.  Setting the timeout at 24 hours could add up to thousands of
> sessions being deleted in a single block.  The cleanup per session is fairly fast
> but trying to do thousands of them at once definitely causes problems.

Ok. My question arises from the fact that sometimes I'm seeing in the
log file "Session is invalid" messages exactly at the times in which
session cleanup is supposed to happen (every 20 minutes). When I say
exactly I mean up to the second and every 20 minutes for two hours or
more. A little bit strange if this message is supposed to be logged
only in response to user requests.

> I believe you are also using Linux.  Since the session cleanup occurs on a separate thread,
> the std::string thread safety issue may be coming into play.
> I thought I had most of it corrected in the RC1 build.  Did it help at all?
It helps, I've experiencing less crashes. However it is not uncommon
for me to have still 10 or more crashes in 5 hours.
And if sometimes it works for one or two hours with many users, after
the first crash many more will follow, maybe after very few minutes.
So session timeout is not the problem, since sessions never timeout.
Sessions become invalid after crashes.
There should be some problem left when server come up again and there
is plenty of users making requests with invalid sessions or loading
again maps (thus a huge flood of setResource that I remember from one
of your mails may be cause of problems).
The performance and the use of physical resources are always been
good, so there should be some nasty bug somewhere.

At least one time I and one of my colleague have found
MgSessionResourceContents.dbxml in a corrupted state (db_verify
fails), and in this case also berkeley db command line utility
segfaults trying to recover. I suspect that in this case also dbxml
API used by Mapguide may crash.
So I delete MgSessionResourceContents.dbxml and
MgSessionResourceData.db before starting again Mapguide after a crash,
and let Mapguide create an empty session repository.

Some times we've found problems in the internal index of Library dbxml
after adding or deleting resources and having a server crash (during
the operation or a checkpoint?)
One deleted item was left in the index so it seems to be present when
browsing the library but obviously it is not possible to delete it
from Maestro or Autodesk Studio. The problem was solved forcing a
reindex of the container...

We're also seeing a lot of ACE assert failing that keep crashing
apache childs. Fortunately most of the time Apache complains it and
keep doing its work.

When is expected to have Mapguide using dbxml and ACE in current
stable version? Maybe are them to be blamed and not Mapguide.

I'm using FDOOGRProvider with OGR recompiled with support to PostGIS
(and with thread safety). I'm aware that this appears to be a very
uncommon use of Mapguide, so probably it is receiving less love.

I should probably try new PostgreSQL provider.
Ticket http://trac.osgeo.org/mapguide/ticket/1382 is now closed.
It appears that Centos binaries for RC1 yet suffers from the problem
(they have been built far before 07 October 2010, when you closed the
ticket).
I think I should replace FDO installation with latest FDO-3.5.0.
Since we're talking of binaries without exact build number it would
not be bad to state exactly on internal list when a new FDO is
released that corrects some bug and is assured to be binary compatible
with last Mapguide version. I've tried always to use stock Mapguide in
order for it to be more stable.

A last question, which is the simplest method to recover Mapguide
server minor build number, eg. 2.2.0.4898? The API method reports only
version 2.2.0 without specifying the minor number that is crucial to
understand if it is the RC1 version or the beta

I have to admit that I've spent a lot of time fighting against those
Mapguide crashes and I'm running a bit out of ideas.

Regards,

Gabriele