maildroprc Filter

Ich habe schon vor ein paar Tagen versucht einen neuen maildroprc Filter mit ein paar Regeln zu erstellen, weil ich die alte Filterdatei leider gelöscht habe. Der Filter wurde als benutzerdefinierter Filter in einer SysCP-Installation eingebunden. maildrop schien aber immer mit irgendeinem Fehler abzubrechen, sobald er meinen Filter abgearbeitet hat. Der folgende Filter funktionierte dann nach einigem rumprobieren:

if (/^Subject: *\[ADV\]/)
{
  exception {
    MAILDIR = $MAILDIR.Spam/
  }
}

Ich hatte auch schon Varianten mit if (/^Subject: .*\[ADV\]/) oder if (/^Subject: .*\[ADV\]/) { versucht. Irgendwie klappte das aber alles nicht. Ganz verstanden hab ichs nicht. 🙁 Falls jemand ein gutes Howto für maildrop 2.0.2 Filter hat, bitte melden. 🙂

Was ich an Tomcat hasse

Man programmiert mit Netbeans eine JSP/JSF Datenbank-Anwendung und deployed diese auf dem Webserver. Das Resultat ist ernüchternd, es kommt immer wieder diese leidige Exception:

Caused by: org.apache.jasper.JasperException: java.lang.RuntimeException: org.apache.commons.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null'

Den Fehler gibts dann in Google zwar oft, aber keine Problemlösung klappte bei mir. 🙁

Netbeans 5.5 mit Visual Web Pack gefällt mir ansonsten nämlich recht gut. Man kann sich seine Weboberfläche zusammen klicken, die Datenbank-Anbindung läuft auch relativ problemlos und man hat immer noch einen Debugger in der Hinterhand, wenn mal was nicht funktioniert.

WordPress „Beitrag schreiben“ baut sich langsam auf

Ich habe schon länger das Problem, dass sich die Seite „Beitrag schreiben“ in WordPress extrem langsam aufbaut. Auf dem alten Server dauerte das deutlich über 60 Sekunden. Auf dem neuen Server hier nur noch ca. 20 Sekunden. Heute habe ich mir mal Zeit genommen um zu untersuchen warum das so ist. Ich habe mir das Tool mytop installliert und ausgeführt. Beim Aufruf der Seite erschien für ca. 20 Sekunden die folgende SQL-Query:

mysql> SELECT meta_key FROM wp_postmeta GROUP BY meta_key ORDER BY meta_id DESC LIMIT 10;

Als erste Maßnahme habe ich mal den MySQL Query-Cache in der my.cnf hochgeschaltet, da mein Webserver 2 GB RAM hat und davon noch nicht alles genutzt wird:

#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 128M

Das brachte dann den Effekt, dass innerhalb eines relativ kurzen Zeitraums die Abfrage sehr schnell ablief. Nach ein paar Minuten (wenn überhaupt) war der Geschwindigkeitsgewinn aber wieder weg.

Also habe ich mal geschaut, was die SQL-Abfrage überhaupt macht:

mysql> SELECT meta_key FROM wp_postmeta GROUP BY meta_key ORDER BY meta_id DESC LIMIT 10;

+----------------------+
| meta_key             |
+----------------------+
| podPressPostSpecific |
| _wp_page_template    |
| _utw_tags_0          |
| _utw_tags_           |
| related_id           |
| podPressMedia        |
+----------------------+
6 rows in set (25.67 sec)


mysql> SELECT meta_key FROM wp_postmeta GROUP BY meta_key ORDER BY meta_id DESC LIMIT 10;

+----------------------+
| meta_key             |
+----------------------+
| podPressPostSpecific |
| _wp_page_template    |
| _utw_tags_0          |
| _utw_tags_           |
| related_id           |
| podPressMedia        |
+----------------------+
6 rows in set (0.00 sec)

Die Query erzeugt also unter „Ein neues benutzerdefiniertes Feld hinzufügen“ eine Liste mit 10 Werten für den setzbaren Schlüssel. Ein Feature das ich bisher nie benutzt habe. Also habe ich mich auf die Suche nach der Query gemacht. Ich wurde in wp-admin/admin-functions.php in der Funktion meta_form() fündig. Also schnell das folgende auskommentiert und mit 0,8 Sekunden Seiteladezeit (als über 20 Mal schneller :-)) glücklich werden:

/*      $keys = $wpdb->get_col("
                        SELECT meta_key
                        FROM $wpdb->postmeta
                        GROUP BY meta_key
                        ORDER BY meta_id DESC
                        LIMIT 10");*/

IPv6 Migration kommt

Wie heise online berichtet legt sich ICANN für eine rasche Migration zu IPv6 ins Zeug. Es zeichnet sich ab, dass in 2 bis 4 Jahren die IPv4-Adresspools alle vergeben sind. NAT hat dafür gesorgt das der Zwang zur Migration über Jahre immer wieder hinausgeschoben werden konnte. Nun ist es meiner Meinung nach endgültig an der Zeit die IPv6-Migration zu forcieren. Weitere Infos gibts auf meiner IPv6-Infoseite und IPv6 ready?.