<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-15"

 http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

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. <br>

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):<br>

- Publishing something clears out all files in the export folder<br>

- request URLs for exportable resources are rewritten to point to the

export folder<br>

- 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<br>

- 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.<br>

<br>

This seems to be the mechanism as far as I understand. <br>

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.<br>

<br>

Best Regards<br>

Christian<br>

<br>

<br>

<blockquote cite="mid:1519473157@web.de" type="cite">

  <pre wrap="">

  </pre>

  <blockquote type="cite">

    <pre wrap="">- 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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

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.!* <a class="moz-txt-link-freetext" href="http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a">http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a</a>

_______________________________________________

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

<a class="moz-txt-link-freetext" href="http://lists.opencms.org/mailman/listinfo/opencms-dev">http://lists.opencms.org/mailman/listinfo/opencms-dev</a>

  </pre>

</blockquote>

<br>

</body>

</html>