Stand With Ukraine. Stop Putin. Stop War.

Hello! Welcome to my humble web presence. I'm Mark Hamstra, 32 years young, wearer of many hats at modmore, resident of Leeuwarden, the Netherlands. Most of my time is spent building and maintaining awesome extras and tools at modmore, but I also love gaming, cooking, and my dogs. More about me.

This site is where I share thoughts, cool projects and other oddities related to MODX, xPDO and ExtJS. I also write about MODX regularly over at MODX.today. Sometimes I post three blogs in a week, sometimes there's nothing new here in a year. Read a random article.


For SiteDash I built a worker queue, based on MySQL, to handle processing tasks asynchronously. There's a central database and separate worker servers inside the same private network that poll for new tasks to execute. These worker servers run PHP, using xPDO 3, to perform the tasks the application server has scheduled.

One problem that would occasionally pop up is that the worker servers would lose connection with the database. The database is on a different server in the network, so that could come from rebooting the database server, a deploy or backup causing high load, network glitch, or just.. gremlins.

Obviously, the worker servers need to talk to the database to be useful, so I started looking at a way to 1) detect the connection was dropped and 2) automatically reconnect if that happens. It turns out to be fairly straightforward (once you know how!).

First, I implemented a check to see if the connection is alive. It does that by checking if a prepared statement (query) could be prepared.

<?php
while (true) {
    $q = 'query that is irrelevant here';
    $stmt = $xpdo->query($q);
    if ($stmt) {
        $stmt->execute();
    }
    else {
        reconnect();
    }
    // Execute task, if any
    sleep(1);
}

function reconnect() {
    global $xpdo;
    $xpdo->connection->pdo = null;
    return $xpdo->connect(null, array(xPDO::OPT_CONN_MUTABLE => true));
}

The workers run in an infinite loop, one loop per second, so this check happens every second. When the statement can't be prepared it's treated as a dropped connection, and we call the reconnect method to restore the connection.

The reconnect happens by unsetting the PDO instance on the xPDOConnection instance. Without that, xPDO thinks it still has a connection, and will continue to fail. Because we don't unset the xPDOConnection instance, we can just call $xpdo->connect() without providing the database connection details again.

With this check in place, the loop can still get stuck in a useless state if there's a reason it can't reconnect. That can have some unintended side effects and makes it harder to detect a problem that needs manual interference, so I also implemented another check.

Every 10 loops, another query is sent to the database with a specific expected response; a simple SELECT <string>. The idea is the same as the check above, see if the statement can't be prepared or doesn't return the expected result, and if so, do something.

Here's what that roughly looks like:

<?php
$wid = 'Worker1';
$loops = 0;
while (true) {
    $loops++;
    
    $q = 'query that is irrelevant here';
    $stmt = $xpdo->query($q);
    if ($stmt) {
        $stmt->execute();
    }
    else {
        reconnect();
    }
    // Execute task, if any
    sleep(1);
    
    // Every 10 loops, check if the connection is alive
    if (($loops % 10) === 0) {
        $alive = $xpdo->query('SELECT ' . $xpdo->quote($wid));
        if (!$alive || $wid !== $alive->fetchColumn()) {
            break;
        }
    }
}

function reconnect() {
    global $xpdo;
    $xpdo->connection->pdo = null;
    return $xpdo->connect(null, array(xPDO::OPT_CONN_MUTABLE => true));
}

In this case, we're not calling the reconnect() method. Instead, we're breaking out of the loop. This way the PHP process can end gracefully, instead of pretending to be churning along properly. When the process ends, supervisord is used to automatically restart it. When a new process is unable of connecting, the logs and monitoring get a lot louder than when a worker silently keeps running, so this system is working nicely.

Now, this obviously isn't the entire worker code for SiteDash. Over time it has grown into 300 lines (not counting the tasks themselves) of worker logging, automatic restarting when a deployment happened, analytics, ability to gracefully kill a process, and dealing with unexpected scenarios like a database connection getting dropped.

Overall this system has managed to keep the processes running quite nicely. There were some issues where certain tasks would cause a worker to get stuck, which have now been resolved, and currently the biggest limiting factor for the worker uptime is deployments. The workers need to restart after a deployment to make sure there is no old code in memory, and I have been fairly busy with adding features to SiteDash (like remote MODX upgrades last week!).

It's also been fun and interesting to try to get a good insight into these background processes and tweaking the monitoring to notify about unexpected events, without triggering too many false negatives. A challenge I'd like to work on in the future is automatically scaling the number of workers if the queue goes over a certain threshold, but for now I can manually launch a couple of extra processes quite quickly if things take too long.

Some fun numbers:

  • Overall, since launching workers as indefinitely running processes, the average worker process was alive for 12,5 hours
  • Since fixing the last known glitch where a process could get stuck executing certain tasks, on October 29th, the average worker stayed online for 2 days, 12 hours and 52 minutes.
  • The longest running workers started on November 1st and stayed up for 12 days, 5 hours and 40 minutes before being restarted due to a deployment.

I'm writing this post on the brand new MODX 2.7, released earlier this week. Among new features like a trash manager, form customisation for create and update in the same set, purging old packages and lots more, there's one more change you're likely to start experiencing soon: deprecated features.

Shortly after updating to 2.7, your MODX error log will start showing new messages saying various things are deprecated. Some examples of what you might encounter include:

  • modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace <namespace> to the routing based system.
  • Flat file processor support is deprecated since version 2.7.0.
  • Flat file processor support, used for action mgr/resources/getlist with path path/to/action.php, is deprecated since version 2.7.0.
  • modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
  • Old modTemplateVar getRender inputmethod

While those logs typically go into the MODX error log, it's also possible to see them when installing packages (especially the modAction and modRestClient messages).

What does it mean?

Basically, a feature is used which is on the shortlist to be removed from MODX in a future release. In many cases, that future release may be MODX 3.0, but that's not necessarily set in stone for everything.

The primary goal is to inform you, as someone responsible for a site, what might break in the future. You don't have to freak out right away, but it is useful to take a good look at your log after using your site and manager, to see what's at risk. Perhaps there are third party extras that will need to be updated, or you could also have custom systems running that need some tweaks.

It's better to find out now, so you can plan ahead, then when 3.0 comes out and your site does break.

How do I know what needs fixing?

Hopefully, the messages contain enough detail that it's clear where the problem is. That's not always the case, unfortunately, such as with the flat file processor message (which should be clearer in 2.7.1) and the rather vague "Old modTemplateVar getRender inputmethod" that ended up being a false positive in most cases.

My expectation is the you'll see the "modAction support since version 2.3.0 is deprecated" and "Flat file processor support is deprecated since version 2.7.0" messages the most.

In the modAction message, you'll see the namespace mentioned which should correspond with one of your extras or custom components.

Once 2.7.1 comes out, the "Flat file processor support" (which means a processor doesn't use the modProcessor class) should become rarer as it wont get triggered on every manager request anymore, and will also include the actual processor file that was called. That should pinpoint exactly what extra (or core feature, that's not ruled out!) is at fault and needs some work.

I'm a developer, how do I fix my extra?

Here are some resources to get started:

I'll also be working on my extras (both free and premium ones) to replace deprecated features as much as possible. A few of my extras still use modAction and modRestClient is also in use in various places. If I find the time I'll try to write more about dealing with specific deprecated features.

My log is now huge! How do I possible parse through all of this?

Now that you've asked... give SiteDash a try! Connect your site, and use its error log analyser to quickly summarise large error logs. It will group messages together for you, and try to explain what it finds.

(As of this week, it can also remotely upgrade sites for you, so if you're not on 2.7 yet, that's cool to try!)

Is it possible to disable the deprecated notices?

Yes, there's a new setting called log_deprecated that you can change. When disabled, you'll no longer get any deprecated notices in your logs. I would however recommend leaving it on at least for a little while to see what features your site uses that need to be updated. Report those logs to the developers of extras you use to make sure they're aware of what needs to be addressed. That gives both you and them the time to fix them well ahead of MODX 3.

Is the proper term "deprecation" or "depreciation"?

Deprecation, or deprecated.

If something it depreciated (with the extra i), it means the monetary value of a thing has decreased over time (like a car), but to deprecate something means to discourage its use as it will become obsolete.

I'm pretty sure it was the wedding of two of my best friends at the end of July 2016 that finally tipped the scale. Seeing their love and commitment broke down the last wall I had built up, and made me decide to admit to what I had been hiding for years. In the following weeks I came out as bisexual to the people closest to me, including my parents and those best friends after they returned from their honeymoon.

While my first romantic thoughts for men probably date back to high school, those had been neatly tucked away behind layers of insecurity and telling myself "it's just a phase" and "everyone probably feels confused like this" until I believed it myself. Even though I live in one of the most accepting countries in the world when it comes to LGBT, it took me a long time to accept these feelings - and myself.

Being bisexual also didn't help. While it's fine if you have trouble choosing what you want for dinner because the entire menu looks amazing, or being unsure about how business decisions will pan out, for a long time I had more-or-less accepted that I was different from the norm but couldn't figure it out. At times I thought I was just so deep in the closet that I didn't want to accept I was just gay (and since coming out as bi, several people have suggested this to be the case too), but I knew the feelings I've had for women were just as true. That just confused me even more for a while.

Eventually I accepted that on a scale from 0 (straight) to 100 (gay), I'm about a 65 right now. Everyone's somewhere on that scale, and may be on different places throughout their life. I just happen to be more towards the middle than most people. (While writing this post, I learned about the Kinsey Scale which is the same idea, but uses a scale of 0 to 6; I'd put myself as a 4 on that scale).

So, to get back to why I started writing this post...

Since the summer of 2016 I've been telling people of my sexuality regularly, but I've not made a big deal about it or announced it to the world. Even within my family, many people probably don't know. Typically I tell people when they ask if I have a girlfriend yet, by saying something along the lines of that it could've been a boyfriend too.

I don't introduce myself as "Mark Hamstra, 27, bisexual", I've not posted unambiguously on Facebook or Twitter about my coming out, and you wont find me dancing half-naked on a boat during the Amsterdam Gay Pride anytime soon either (you're welcome). While my sexuality is part of who I am, it is not what primarily defines me, and I've been treating it like a detail not everyone has to be made instantly aware of.

From time to time that has made some things a little more complicated than strictly necessary. In situations where people who I have not told unintentionally touch on the topic (for example "are you seeing anyone?", "did you buy your house by yourself?"), there's sometimes an (unintentional) undertone that assumes I'm straight. This can come from people that I've known for ages who I trust enough that I want to correct their assumption. But as I have about a split second to decide to either come out to them (and whoever else may be part of/listening to the conversation), or to fall back to pretending to be straight like I've done for so long, I sometimes choose the latter and regret it a few hours later. It feels like I'm lying to those people, which is also holding me back. As if one leg is still stuck in the closet, and I need to break it down to really get out.

So, long story short, I'm bisexual, and now that it's public knowledge I can stop caring as much about who does and who doesn't know.