48h hours earlier… Naja, so ungefähr zumindest. Wir haben Post bekommen, von der Region Hannover. Da Bea jetzt ja schon einige Zeit in der Wohngruppe ist, würden sie sich mit Regionsvertreter und Amtsärztin gerne ein Bild davon machen und sie am Soundsovielten besuchen und wir sollten falls möglich auch dabei sein. Hmm, grundsätzlich können sie ja kontrollieren was sie wollen, allerdings sehe ich da ein kleines Problem. Entweder haben wir seit 13 Jahren eine Zwillingsschwester übersehen oder meine Frau, Zoe und ich leiden an Halluzinationen. Denn als der Brief kam, sahen wir Bea gerade im Garten spielen.

Da Behörden und Ämter immer Recht haben, muss es wirklich eine Illusion sein, dass wir seit geschlagenen drei Monaten auf die Zusage der Region warten, allerdings handelt es sich ja auch nur um ein beschleunigtes Verfahren. Für eine Rückfrage war der Absender natürlich telefonisch nicht zu erreichen, auch heute nicht. Mal schauen, vielleicht gibts da einen Bea-Klon von dem wir nichts wissen???

Aber zurück in die Gegenwart: Heute morgen wollte ich eigentlich etwas “ausschlafen” und hab den Wecker auf Viertal nach Sieben gestellt, dabei allerdings nicht mit meinem Biorhythmus gerechnet – 20 nach 6 war ich wach. Gut, Arbeit ist genug zu tun. Für 9:00 Uhr hatten sich zwei Nachbarskinder angekündigt um mit Zoe zu spielen, wenn auch etwas unfreiwillig – denn beide Eltern mussten zu einem Termin, aber da heute Schul- und Kindergartenfrei war , konnten alle drei den Vormittag gemeinsam nutzen.

Praktisch dass meine Frau Freitags auch frei hat, so mussten die Kollegen am Telefon nur etwas Kinderlärm im Hintergrund in Kauf nehmen. Gestört hat das anscheinend keinen, zumindest hat sich keiner beschwert.

Irgendwann waren sie dann alle wieder weg und auch meine drei Frauen waren unterwegs als gegen fünf das Telefon klingelte – Bea’s Wohngruppe. Sie haben heute(!) die Zusage der Region Hannover zur Kostenübernahme in der Post, Bea kann also zum 1.5.2012 dort einziehen, wenn da nicht ein kleines Problem wäre: Wir haben den 18.5. (ja, auch 2012), aber über diese temporale 18-Tage-Problem mache ich mir jetzt keine Gedanken mehr. Zu viel nachdenken über temporale Paradoxien kann einen verrückt machen – und ich meine das durchaus im medizinischen Sinne.

Jetzt ist er also da, der Tag den wir mit sehr gemischten Gefühlen seit Februar erwarten. Ein Umzugstermin steht noch nicht genau fest, aber nächste Woche wird es soweit sein, spätestens am Freitag zieht unsere “Große” aus und um. Ein komisches Gefühl.

Am Anfang stand die Entscheidung, die uns nicht leicht gefallen ist, danach war es ein Verwaltungsakt mit Papierkrieg und ewigem Nachfragen. In dieser Zeit habe ich das Ganze mehr oder weniger emotional ausgeblendet, denn es war nur Papier, das hin uns her geschickt wurde, ein paar Formular ausfüllen, viele Kopien machen, drüber schmunzeln das Bea’s Ehemann sein Einkommen offenlegen soll (bei einer 13jährigen! Zumindest soweit ich weiß ist sie noch Single und wird das vermutlich auch lebenslang bleiben wenn sie sich nicht emotional und rational extrem weiterentwickelt) und sich über das ärgern was die Ämter unter einer “schnellen Bearbeitung” verstehen.

Jetzt ist das alles erledigt und ich habe – glaube ich – noch nicht richtig realisiert was das bedeutet, genauer gesagt, was es für nächste Woche bedeutet – und die ist gar nicht mehr so fern. Ganz nebenbei bin ich ziemlich entsetzt über den ganzen Vorgang. Bei Bea war die Dringlichkeit geboten, damit der Platz nicht anderweitig vergeben wird, aber was wäre, wenn sie wegen Misshandlungen umziehen müsste? Man darf sich das gar nicht vorstellen: Wenn sich im Februar ein Kind an eine Vertrauensperson gewendet und diese sofort und richtig reagiert hätte, dann hätte es noch drei Monate zu Hause aushalten müssen? Nein, da darf man gar nicht drüber nachdenken.

Momentan bin ich eigentlich auch etwas froh darüber, denn Bea hatte heute wieder verstärkt Umfälle. Dabei hat sie einen Anfall der sie selbst aus dem Gleichgewicht bringt, die Reflexe reichen noch aus um ein, zwei Schritte zu machen in dem Versuch, das Gleichgewicht wiederzuerlangen, aber meist war es dann mit der Koordination vorbei und sie lag am Boden. Draußen auf dem Rasen ist das kein größeres Problem, aber im Haus kann es schnell zu ernsthaften Verletzungen führen. Vor ein paar Tagen hat es sie auf der Treppe “erwischt”, glücklicherweise waren es nur drei Stufen und sie ist – anscheinend – fast gar nicht schmerzempfindlich. Wenn die Spülmaschine ein- oder ausgeräumt wird, muss sie schon seit längerem mindestens eine Körperlänge Abstand halten, denn wenn sie umkippt und womöglich in den Besteckkorb fällt, sind Kind und Maschine kaputt.

Zurück zum Tag: Seit einer Woche wünschte sich meine Frau Fischstäbchen. Allerdings nicht die in freier Wildbahn gefangenen, die typischerweise in Rudeln konstanter Größe in Pappschachteln leben, sondern selbst gemachte. Das geht einfacher als man denkt: Ein halbwegs festes Fischfilet in passende Streifen oder Stücke schneiden, in Mehl, Ei und gewürzter Panade wälzen und in der Fritteuse ausbacken, dazu passende Beilagen – fertig.

Die erste Portion “Fischschnitzel” waren gerade schon wieder aus ihrem Ölbad befreit und verzehrbereit, da kam aus dem Wohnzimmer der Ruf: “Diazepam!” Also den Fisch – auch die noch im Fett schwimmenden Stücke – Fisch sein gelassen, zum Kühlschrank gesprintet, die vorletzte Alupackung gegriffen und auf dem Weg ins Wohnzimmer geöffnet und zur Anwendung vorbereitet. Dort lag Bea in einem ihrer “schweren” Anfälle und kam diesmal auch nach der Diazepam-Dosis nicht recht raus. Es dauerte gefühlt ein oder zwei Minuten bis die ärztlich verordneten Drogen wirkten und sie wieder halbwegs normal war.

Essen wollte sie jetzt natürlich nicht mehr, sondern nur noch ins Bett und auf der vorletzten Stufe kam dann anscheinen die volle Wirkung durch. Jeder der schon einmal einen kräftigen Rausch hatte, kann sich vielleicht ansatzweise vorstellen wie es ihr in diesem Moment geht, nur mit dem Unterschied dass die Wirkung bei ihr nicht nach und nach mit jedem Glas zunimmt, sondern anscheinend von einer Sekunde auf die andere mit voller Wucht kommt. Egal, Mama stand daneben und war vorbereitet, also ist nichts weiter passiert, außer vielleicht dass sie morgen früh nicht mehr wissen wird, wie sie ins Bett gekommen ist.

Die Fischstäbchen haben wir mit Zoe dann doch noch gegessen… nein, stop, deutsche Grammatik… Wir haben natürlich nicht Zoe als Beilage zu den Fischstäbchen verspeist, sondern meine Frau, Zoe und ich haben Fischstäbchen und Beilagen vernichtet. Erstere sind eigentlich ganz gut geworden obwohl ich vorher skeptisch war.

So, ich mache jetzt Schluss für heute, allerdings nicht ohne nochmal auf das Gewinnspiel hinzuweisen.

Quelle: Besucher, Fische und Drogen

Später spielen die Kids im Garten und Zoe fängt an zu erzählen: “Wenn das Eichhörnchen kommt, dann muss ich ganz schnell sein und es einfangen, dann haben wir auch ein Tier und das wohnt dann bei uns” gibt sie die Marschrichtung vor. Mama’s Erklärungsversuche, das Eichhörnchen ganz traurig sind wenn sie bei Menschen wohnen müssen, lässt sie dabei nicht gelten.

Wir haben Fische, aber die lassen sich leider so schlecht streicheln. Vielleicht sollten wir noch einen Zitteraal anschaffen, der macht sich eindeutig bemerkbar wenn er nicht mehr gestreichelt werden will…

Quelle: Ein Tier für das Kind

Der erste Preis ist ein einmaliger, handgemachter USB-Stick-Teddy / The first price: A handmade unique USB storage teddy:

Als zweiter Preis winkt der erste Band der fünfteiligen Triologie “Per Anhalter durch die Galaxis” von Douglas Adams / The second price is Douglas Adam’s Hitchhiker’s Guide to the Galaxy, the first of the five books.

Dritter Preis ist schließlich das Buch aus dem das PAL-Feld stammt Das Leben, das Universum und der ganze Rest / Third price will be Life, the Universe and Everything, number three of the Hichhiker’s series and the book which introduced the SEP field which made up the name for this blog.

Beide Bücher gibt es wahlweise in Deutsch oder Englisch / Both books are in German or English (whatever you choose).

Mitmachen ist ganz einfach: Schreibe bis zum 3. Juni 2012 einen Kommentar unter diesen Post (bitte angeben ob das Buch ggf. auf Deutsch oder Englisch sein soll). / Wanna win? Just drop a comment below this post before June 3rd, 2012 (don’t forget to write if you’ld prefer a German or English book).

Quelle: Happy Birthday myself!

Being a great tool, Gearman still lacks a complete documentation and the server software is no exception. It’s very easy to set up but there are still some things to consider before starting.

Gearman is no reliable tool. It’s good, stable and fast but there is no guarantee that a job isn’t lost if something goes wrong because everything is held in memory. It’s cable to keep some kind of transaction log into a database (actually it’s no log as you might think, just a copy of the current in-memory state, it’s never read during runtime, just written). It’s up to the developer: Do you want to add this safety possibly paying with speed? If you do, I strongly recommend SQLite instead of a classic SQL database server (which are also supported) because Gearman doesn’t use features where database servers are great: Reading and filtering data and parallel access (well, myISAM isn’t great for parallel access at all but that’s another story). Memcache might be an option but I won’t call it more reliable in case of trouble.

All dispatcher server arguments are shown on the Gearman homepage and I won’t copy or repeat them here because most defaults are pretty good for everyone and also for trying it out, maybe you want to set the listen address and port to custom values.

Gearman has a simple management interface which could be used with any telnet client (like netcat (nc) and – obviously – telnet or use a Perl IPC socket to connect). After connecting to the ip address of the dispatcher and Gearman port, type “status” to get a list of current job names and tab-seperated status counts:

Simple::echo	0	0	2
HTTP::post	2	1	1
HTTP::get	0	0	1

Three job names are supported by this dispatcher. I’m using double-colons to group them into classes but this is just a personal decision, the job names may contain any letter or number and some special chars (like : ).

The first job “Simple::echo” has no jobs queued, no currently running and two workers registered with this dispatcher, one of them will get the next incoming Simple::echo job. My HTTP client worker registered two job names, one for each HTTP request method. Two jobs are currently laying in the dispatcher queue for HTTP::post and one of them is being processed. The first number (jobs in queue) minus the second number (jobs currently running) is the number ob jobs waiting for a free worker.

Type “workers” to get a list of the currently connected workers:

29 192.168.128.161 curbsjiecarbvhiduzmrsxtfphwghq : HTTP::post Simple::echo HTTP::get

The first column is the internal file descriptor number of the dispatcher server and I could hardly think of any use for this information.

The second column is the ip address of this worker. Many workers may run on one server, so the ip isn’t unique but the third value is: It’s the unique worker id for this worker process which is just a random value generated when the worker connects the server. A single colon is used as separation char between the fixed columns and the space-separated list of jobs provided by this worker.

There are few more commands with IMHO have much less use than the ones explained above.

This information is easily accessible and I quickly wrote a simple script to fetch this status information just after deploying Gearman in a production environment. It shows the “status” report from all of our dispatchers in a merged list.

It’s simple, but (currently) one of my most-often-used tools.

Usually each worker connects to all dispatchers and whoever wants to pass a job to it may do so – if it isn’t working for another dispatcher at the moment. The sample above shows 64 workers per dispatcher for issuing HTTP GET requests and 16 workers for HTTP POST requests which are connected to all dispatchers. The difference doesn’t really show up from the numbers above.

It’s highly uncommon that the GET workers don’t connect to all dispatchers and result of the server layout, you should know such things when looking at your own status report.

This is how to setup and manage Gearman. Pretty easy, isn’t it? The next post will show the actual developer side.

Quelle: Setting up Gearman

Meine Frau hatte sich zu Weihnachten Konzertkarten für die Celtic Woman Believe Tour 2012 gewünscht – und bekommen. Das Konzert fand allerdings nicht an Weihnachten statt, sondern gestern Abend.

Unser erster “kinderfreier” Abend in diesem Jahr (hatten wir letztes Jahr überhaupt einen?) und wir haben ihn genossen. Oma wurde als Babysitter eingespannt hatte sich als Babysitter angeboten und passte auf Bea und Zoe auf.

Ohne Navi wären wir am komplett falschen Ende von Hannover gelandet. Wir haben hier die AWD-Arena (Heimat-Stadium von Hannover 96 die sich gerade in der zweiten Saison in Folge in den Europacup gespielt haben – Glückwunsch!), die TUI Arena (eher eine kleinere Halle, auch als Eishockey-Stadium genutzt) und ein paar weitere kleine Veranstaltungshallen. Irgendwie haben meine Frau und ich die TUI-Arena mit der AWD-Hall verwechselt, denn in letzterer fand das Konzert statt. Gemerkt haben wir den Fehler erst, als uns das Navi scheinbar total falsch führen wollte. Nur das uneingeschränkte Vertrauen in die moderne Technik hat uns dann doch noch rechtzeitig zur richtigen Halle geführt.

Der erste große Enttäuschung gab es bereits vor der Show: Ton- und Videoaufnahmen sind bei Konzerten nicht gerne gesehen, klar, die Künstler wollen (vollkommen zurecht) auch CDs verkaufen. Hier wurde allerdings an jeder Ecke durch Plakate, mündlich bei jedem Besucher durch die Kartenkontrolleure am Eingang und per Ansage direkt vor Showbeginn drauf hingewiesen, dass auch keinerlei Fotos erlaubt sind, deswegen ziert diesen Post auch kein tolles Foto der dreistöckigen Bühne.

Das Konzert selbst war toll, wenn auch die Reihenfolge der Lieder etwas unpassend wirkte, denn absolut ruhige Songs und mitreißende Geigeneinlagen oder flotte Rhythmen wechselten sich übergangslos ab. Drei tolle Stimmen, eine große Auswahl an Instrumenten und ideenreiche Showeinlagen gestalteten den Abend kurzweilig.

Unvergessen bleibt der “Zickenkrieg”, bei dem sich zwei der Celtic Woman ohne Worte, nur mit Lautgesang von entgegengesetzten Enden der Bühne scheinbar wortreich streiten bis die dritte dazu kommt und den Streit schlichtet. Eine grandiose Umsetzung und ein Lied, das ohne die Showeinlage dazu seine Wirkung garantiert verliert.

Persönlicher Höhepunkt war dann kurz vor Schluss Green Grow the Rushes, O, bei dem neben dem ganzen Ensemble ein rund 1000stimmiger Chor einsetzte (vielleicht auch nur 600, ich hab nur geschätzt). Mitmach-Einlagen bei Konzerten sind eigentlich nichts besonderes, diese aber schon und das lag auch am Publikum.

Nächstes Jahr wieder? Mal schauen. Wenn, dann auf jeden Fall mit besseren Karten näher an der Bühne (und das obwohl wir diesmal auch schon in der 2. oder 3. Kategorie saßen).

Quelle: Merry Christmas: Celtic Woman in Hannover

New, faster, better, cheaper hardware is published nearly every week (day?) and only the sky is the limit if as long as one could just buy more cpu power and memory to cover increasing source code complexity and request counts. Most web applications will never ever reach the sky (which is the limit), but could also benefit from multitasking. Three examples:

Not for your eyes

Complex web scripts do some work to calculate the next page to be shown to the user but also do many things which don’t change the resulting web page at all, like logging statistics data, sending emails, updating database records where the result isn’t relevant for this page. There is no need to these tasks to be performed while a impatient user is waiting for the result of his click. Remember – web scripts life in fragments of seconds (well, they should).

I’m not strong enough

A web server is always a mixture of high cpu power, enough memory, disks for quick log file access and high bandwidth for fast database and internet connections. Some applications don’t require all of this, like resizing a user-picture, extracting preview pictures for a video file or compressing uploaded data for storage. They need hugh cpu power but few (if any) disk size and speed. Running those jobs on a webserver will not only slow down the request itself but also all other requests due to high cpu load. The job may run at reduced priority giving other jobs more air to breeze but often all other parts of the request (other source code besides the resizing snippet) will take the same time (or less) like the resizing process.

It’s a long way home

Some work requires time. More time than a request should take, but still many websites just let the user wait for 10, 30, 60 or more seconds. Some of them show a “processing will take time, don’t click this button twice” message or a waiting animation. Nice, but the user is still waiting, the request may get canceled and everything is lost. Often the user doesn’t know if anything was done or if the request was successful if anything goes wrong. Why not start to do the work, show a waiting page to the user and ask the webserver for result in regular intervals. Any other website script could do a quick check if some unreported result is waiting and show a notification for the user as soon as the long running job is done.

Classic multitasking

Threads

Perl started to support threads a long, long time ago and I did some threading tests as soon as our distribution provided as threading Perl. Threading is cool but dangerous: Developers must have a deep understanding of what’s going on (they should in every case, but you know… reality isn’t like this). Using a single database connection in two different threads may ruin your whole day.

Threading has two other major drawbacks: You can’t use it in persistent environments like mod_perl or fcgi because the Perl part is only guest within a parent process – which may be using thread itself, maybe even for running multiple Perl web-workers in parallel. The other drawback are the power of Perl: Many modules aren’t thread-safe or noone knows if they’re safe or not.

Thread will usually benefit from multiple cpu cores (while a single process is running on a single core), but can’t use more than one server. A single box with four, eight or sixteen cpu cores is the limit – and 16 cores in one server aren’t cheap at all.

Fork, Spoon and Knife

Spooning and knifing aren’t quire common for developers, but forking is an option: Split a running process into two like single cell microorganisms do, but easily controllable by the developer, the new child won’t disturb the parent and vice-versa, but forking also has some drawbacks: It doubles the required memory (which is clearly something to consider if your typical project modules take 100 MB just after use’ing), all variables are doubled which makes life easier most of the time but could also create unexpected side-effects.

Network and database connections are really critical: The child will  close them (at least on exit) and the parent’s copy will also be closed without any notice to the parent, but the child also must not try to use them as it would mix up the connection state known by the parent.

mod_perl and fcgi environments also don’t work well with fork because everything is copied including the Apache handler process or the fcgi main loop and their parent would end up with two processes sitting in one slot.

Finally, there is no good way for the child to inform the parent of any result, they’re different processes and must use some kind of inter-process communication.

Open-system nohup

Most languages could easily execute other processes and a simple “&” at the end of a command line will send the new process to the background. Prepend “nohup” to finally disconnect STDIN, STDOUT and STDERR (or do it yourself within the child) and forget the child, it won’t share anything with the parent and many of the drawbacks are gone. One-way-signaling is easy if the child is being started using “open” and either input or output are piped back to to the parent.

But starting a new (Perl) process is an expensive thing as the interpreter has to be loaded again and every module used by the new process has to be compiled (again). Passing arguments isn’t easy and the risk for adding injection chances is high (just imagine system “foo.pl $original_filename_of_uploaded_file &”; and a client sending ;rm -rf * as the filename). Finally all childs will run on the webserver even if they might use other cpu cores.

Standing in line

Building a job queue is easy: Add a database table (queue) and push (INSERT) every new job which has to be done into it. A cronjob or even a daemon could process the queue on another server. Adding database triggers (who inform the client once a new row has been added instead of letting the client search for new jobs) isn’t easy but may speed up things and additional work could even allow many workers on many servers to process the same queue in parallel.

But databases aren’t build for this, most don’t perform well on a table which gets thousands of INSERTs, UPDATEs and DELETEs per minute and thing start getting worse if the database is being replicated: Keeping mySQL in sync is nearly impossible (max_seconds_behind and binary log position aren’t accurate) and every new slave has to have enough power to handle all writing operations plus additional resources for read requests.

Pushing a massive amount of developer time and hardware cost might be able to reduce the problems and drop time between job insertion and processing start (as well as the way back once the work is done), but I doubt it would be safe to relay on it while the user is waiting for the reply.

The Diary of Jane

…probably wouldn’t fill up a single webserver, but all others do. LiveJournal isn’t as big as Facebook but created a lot of impressive technologies – including Gearman which is a job dispatcher system.

It consists of three parts: A client, a (Gearman) dispatcher server and as many worker tasks as you like. Every web script, program or anything else able to open a network socket may act as a client. Basically a client is someone who wants to give away a part of his work (the working man in Bon Jovi’s song).

The Gearman dispatcher server simply accepts all the work from the clients, queues up everything, handles priorities and results (if there is a result at all) and keeps track of the progress of the running jobs. It’s a simple and small piece of software not doing anything more than necessary but doing a good job on his part.

The workers may be written in any language (not necessarily the same as the clients), they sit around until the Gearman dispatcher has something to do for them. Once they get a job, they do the work for the working man, pass their results back to the dispatcher – and calm down waiting for the next job.

The Gearman solution also has drawbacks – it involves network communication and passing huge amounts of data requires all involved servers to push it around, but the workers are running completely independent from the clients/web-scripts, they don’t share any network or database connection, filehandle or variables.

Workers may run on any number of servers and cpu-cores without any additional development time and also the dispatchers may run redundant, the worker tasks start once (loading the interpreter), load their modules once and connect the database(s) once – no need to do this again for every new job and no risk of mixing up parent and child.

A small environment may use some worker tasks and a dispatcher task running on the webserver box but would scale to many workers on different servers and two or more dispatchers without any problem. The dispatcher(s) don’t know about workers until they register themselfs – no need to configure IP addresses and ports for the workers on the dispatcher side and the dispatcher silently forgets a worker once it died and optionally assigns it’s last task to another one. Workers may run on cheap hardware with no need to buy 4-cpu-boards or RAID disk arrays.

A really big environment may also provide a diskless boot service for worker servers. Connect a new box to your network, power it on and it will boot from the network, start one or more workers who register at the dispatchers. Once the rush hour is done, worker servers could finish their running jobs and shutdown waiting for a wake-on-lan signal to come back for the next rush. Sorry, just dreaming…

There are still drawbacks: What happens if the (running) worker source changes? You have to care yourself about detecting and loading the new version, can’t pass files from client to worker without a network filesystem or shared drive and the client shouldn’t wait forever if the result should be shown to the user.

To be continued…

A co-worker suggested using some kind of dispatcher solution for solving our scaling problems at work not long ago. I liked the idea and started to read about and work on implementing things and providing a simple framework for taking care of our project-dependent things. Gearman and it’s Perl modules turned out to be much easier to set up and use than expected (even if it’s documentation is not as detailed as I’ld like it to be) and today we’re using it not only within cronjobs or our internal admin websites but also on public sites which earn our money and must be up and running 24/7. We experienced some smaller problems but much less than expected.

I’ll write about setting up Gearman, the clients and workers in another post following shortly.

PS: This posts features 4 songs – did you find all of them?

Quelle: Web-Multitasking: Whos gonna work for the working man?

Von den Lesern die sich dazu geäußert haben habe ich durchgehend positives Feedback bekommen – kein Wunder, mich nerven diese Captchas auch, vor allem bei Blogspot und mit Android.

Viel interessanter ist jedoch die Frage, wie viel Spam ich seitdem von Hand wegklicken musste und ob sogar welcher ohne Bestätigung durchgekommen ist.

Insgesamt bleibt es sehr im Rahmen, vielleicht 3-5 Spam-Kommentare pro Woche waren da und auch die sahen eher “von Hand geschrieben” aus als von Bots.

Somit bleibt das Captcha-Plugin bis auf weiteres deaktiviert, viel Spaß beim kommentieren.

Quelle: Ein Monat ohne Captcha – ein Fazit

A classic CGI script doesn’t care: It exists after one request and everything is reloaded before the next run, but persistent interpreters need to check for changed files and trigger some kind of “recompile” themself. I can’t force developers to trigger a manual restart for some reasons.

I’ll explain how to detect if a recompile is necessary in another blog post, but how to recompile something in Perl? Either load the source file and push it through eval(), use do() or require, but all of them have major drawbacks: If one file is replaced within a running script, file-scope variables might end up in some unexpected state, initialization is done twice or not at all – not really usable in a production environment.

The YAWF framework has a simple, small development webserver which does a best-effort mod_perl simulation. It doesn’t care about changed files or reloading – it’s very likely that at least one source file or template changes between two requests to a developer webserver. Every request is running in a new, forked process using the webservers Perl interpreter but a fresh and clean environment. Good for testing, but not much better than classic CGI scripts in a production environment.

I wrote a basic worker/request handler lately and started to push real traffic on it today. It was using exec $0, @ARGV; to replace itself by a fresh process which could compile everything from scratch on any source change. Everything was fine until other tasks started to get “Too many connection” errors from a mySQL server.

It turned out that those exec calls successfully refreshed everything including some network connections, but not any database connection. I can’t switch to system because those processes are under control of a scheduler, the process finishing at the system call would be treated as “finished” and restarted by the scheduler.

The check for source file changes now runs every 240 + int(rand(60)) seconds and the workers are respawned 10 to 300 seconds after their exit. The scheduler could respawn them up to 1 second after they’re done but if any of the has a huge, resource-eating endless loop, it’s copies might crash the whole server.

Quelle: Don’t use exec and database connections

Nachdem Bea die City BKK erfolgreich in den Ruin getrieben hat, arbeiten wir derzeit an der Barmer – und die hilft nach Kräften mit. Auf Anraten der Schule haben wir für Bea einen so genannten Talker beantragt.

Ihr kennt bestimmt diese Kuscheltiere, denen man etwas vorspricht und auf Tasten- (oder Pfoten-)druck spielen sie die Aufnahme ab. So etwas gibt es auch als medizinisches Gerät, weniger kuschelig sondern nur mit einem kalten Plastikgehäuse und dafür teurer als ein waschechter Steiff-Teddy.

Bei Bea sind eher die kognitiven Fähigkeiten ausschlaggebend für die “Sprachstörung” (ist es noch eine Störung wenn sie gar nicht spricht?) und nicht Stimmbänder oder ähnliches, also sollte es ein Gerät sein, das sie auch bedienen kann. Der Hersteller hatte ihr ein Exemplar freundlicherweise zum Ausprobieren zur Verfügung gestellt, denn er möchte schließlich Umsatz machen und das haben wir dann auch beantragt. Das “Plus”-Modell hat etwa A4-Format, 12 große Tasten und die Möglichkeit, ein bemaltes oder bedrucktes A4-Blatt einzuschieben. Hinter den Plexiglasabdeckungen der Tasten sieht man dann die Symbole/Fotos/Bilder zum gespeicherten Text (wenn man sie auf dem A4-Blatt richtig positioniert hat). 9 Tasten sind normalerweise fest belegt, 3 für den täglichen Gebrauch, zum Beispiel damit Bea ihre Wochenend-Erlebnisse “erzählen” oder die Schule ihre neusten Flausen aufsprechen kann. In der Produktion in China kostet das Gerät vermutlich keine 5 Euro, die Krankenkasse hätte dafür etwa 150 ausgeben müssen.

Allerdings reden wir hier von einer Krankenkasse und diese können es nicht auf sich sitzen lassen, einen fast 20 Milliarden Euro großen Überschuss erwirtschaftet zu haben und so mussten wir zu unserer Verwunderung feststellen, dass nicht etwa das beantragte “Plus”-Modell genehmigt worden war. Nein, statt dessen wurde das Modell “4″ zugeteilt – für läppische 678 Euro! Vermutlich hat es einen tollen Touchscreen oder zumindest drei Dutzend tolle bunte Bildchen – sehr praktisch bei einem Kind, dass mit 9 Bild-Tasten fast schon überfordert ist. Wir lassen uns überraschen etwas anderes bleibt uns sowieso nicht übrig.

Wir hätten ihr das Gerät (egal welches) auch selbst gekauft oder ein älteres Android-Tablet und selbst schnell eine passende App geschrieben, aber ich habe schon Zweifel an der Sinnhaftigkeit. Für Bea wird es vermutlich ein nettes Spielzeug werden dass lustige Töne macht wenn man draufdrückt, sowas hat sie gerne. Die Schule sieht das anders und die Barmer will unbedingt zahlen, also lassen wir sie, immerhin verdiene ich keine 19,5 Milliarden im Jahr. Vielleicht sollte ich mein Gehalt mal nachverhandeln…

Quelle: Wir basteln uns ein Defizit

Leider hat anscheinend keiner das kleine Kreuzworträtsel lösen können, zumindest hat keiner einen entsprechenden Kommentar abgegeben. hier gibt es nochmal zum Vergleichen die Komplettlösung:

Quelle: Auflösung zum Rätsel-R