[opencms-dev] Repeated (daily) crashes of OpenCms 7.0.5

[Jonathan Woods]

It might still be worth double-checking that backups aren't the cause.  I've
seen exactly the same problem - content delivery fine, Workplace not - and
it went away when we took a different approach to back-ups.
 
Jon


  _____  

From: opencms-dev-bounces at opencms.org
[mailto:opencms-dev-bounces at opencms.org] On Behalf Of Christian Steinert
Sent: 19 February 2009 22:33
To: The OpenCms mailing list
Subject: Re: [opencms-dev] Repeated (daily) crashes of OpenCms 7.0.5


oh well - reading helps. Since you wrote that the backups are not done
around the time when things crash, then backups can probably not be the
cause for this. 
Concerning the 404 handler: this handler is not only used for delivering 404
error pages - it also seems to be (and more importantly) used for static
export. So if you have any static export active (including static export on
demand, where the file system is used as sort of an additional cache), then
the exported pager are generated like this (description is for export on
demand):
- Publishing something clears out all files in the export folder
- request URLs for exportable resources are rewritten to point to the export
folder
- when somebody requests a URL that was not yet exported, then the 404
handler kicks in. It will check, whether the same resource that is missing
in the export location does exist in opencms. If so, the resource is
generated, delivered and written to the export folder
- when another request is done for the export location, opencms has already
written the file there, so it can be served from the export folder by tomcat
directly, without the 404 handler of opencms being invoked again to
re-generate the resource.

This seems to be the mechanism as far as I understand. 
So, if static export is active, then the 404 handler will ultimately be
triggered to cause the resources to be exported. This does not explain
though, why the crashes happen "only" once a day. Unless the crashes are
happening not too long after having published something or clearing the
export folder for some other reason.

Best Regards
Christian






  

- There's some evidence that the threads are waiting for something to happen
with MySQL.  We observe this behavior:  our sites remain up and running, but
no one can log into the Workplace.  The stacktrace in opencms.log is shown
below (much clipped to save space.)  Our IT people say there is nothing
unusual in the MySQL logs that correspond to these exceptions.

    



Maybe it's something entirely different, but you should take a look at when
and how your backups are done. Usually, when mysql is backed then usually,
the DB is locked for writes during that time to get a consistent state
copied into the backup.



A recommended way for doing backups with MySQL is, to do constant
replication to a second db server instance and then take that replica
offline for backups. When bringing the replica up again, it will
automatically catch up again quickly.  In this way you get a consistent
backup of your DB without blocking the main app.



Regards

Christian

_______________________________________________________________________

Jetzt 1 Monat kostenlos! WEB.DE FreeDSL - Telefonanschluss + DSL

für nur 17,95 EURO/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a





_______________________________________________

This mail is sent to you from the opencms-dev mailing list

To change your list options, or to unsubscribe from the list, please visit

http://lists.opencms.org/mailman/listinfo/opencms-dev



  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20090220/44164af1/attachment.htm>