Forkers, be careful please!

I had one of those situations today that I think every person working with IT experiences from time to time.  I had a problem that took 4 hours to resolve.  Once resolved I realized that doing the right things in the right order (and also memorizing a little better) could have saved me 3 hours and 55 minutes.

The problem was related to SQLyog HTTP-tunneling. When new PHP versions are released it is most often me that verifies that our HTTP tunneling is not broken.  Thus I have followed the PHP 5.3 release cycle from early betas to RC and GA and experienced that very early  PHP 5.3.0 beta  releases did not work with our HTTP-tunnel. However as both 5.3.0 RC and 5.3.0 GA worked fine (as every 5.2.x always did) I executed “SET panic = OFF” against my most important system (old but still a little functional!).

However the panic reoccurred when PHP 5.3.1 was released.  Nothing worked from PHP. I sat for a couple of  hours with a colleague. Small and very simple PHP test applications  did not work with PHP 5.3.1 either on my environment (but worked fine on my PHP 5.2.11 and 5.3.0 configurations). Not a single comma was added to the MySQL general log or error when trying to connect from PHP 5.3.1. The client application hang for considerable time and finally came out with an error that the URL to the PHP script could not be found. Even more frustrating: the test applications and SQLyog/HTTP-tunnel worked fine on another machine with a(should be) identical configuration in Webyog office as well. Needless to say any connection not using PHP also worked fine.

We are aware that some functions in PHP are depreciated in  5.3.x (and will be removed in PHP 6 according to plans).  This may cause problems with our current tunneler on some systems with PHP 5.3.1.  But we have the fix ready to be released with next SQLyog release (and anybody experiencing such problems can contact us for an updated tunneler).  But as 5.3.0 was not affected this was obviously not the problem occurring on my system. It was something else.

We agreed that I should try reinstalling MySQL and Apache from scratch on my system. However before doing so I ran the queries:

SELECT VERSION(); — returned ‘5.1.36-log’
SHOW ENGINES; — returned PBXT as one engine available in addition to the engines from MySQL … hhmmmm …
Now I got it! I remember now that this particular server on this particular system of mine was a forked build with the PBXT engine downloaded from Primebase website.  Installing the standard/official MySQL 5.1.41 solved the problem immediately. PHP 5.3.1 (and thus SQLyog/HTTP-tunnel) connect like a charm.

I am not able to tell what the problem with this server and PHP version is in technical terms.  And probably this server is also now historical so it is probably not very important either now.  But I think Primebase, the MariaDB people, the XAMPP distributors (and everybody building MySQL with PBXT) as well as the PHP developer team should know this issue and try to figure it out (as well as test with their recent builds and PHP 5.3.1), so that it will not happen again.  A forked build should not only work with the (command line) clients shipped with the server but the tools and connectors used by people already.

… (and besides the version string ‘5.1.36-log’ is definitely not good enough for a forked server build).


Add yours
  1. 2

    How do you really know that it was a problem with the forked mysql server? You replaced it with a newer version. To accurately determine that it was something that was introduced with the fork, you should have installed the official version of 5.1.36.

    I agree that all forkers should try to maintain api compatibility when ever possible. If you want the problem solved, you’d have to do a little more investigation to determine the cause of the problem, then file a bug report. As your product apparently interacts with both php and mysql, it might be a good idea to understand the interaction between them. It could make mysql better, php better, and life easier for your clients.

  2. 3

    1) I am pretty much sure that if the official MySQL (any version) had a problem wiht PHP (any recent version) that would be known already. But of course PHP 5.3.1 was not released when MySQL 5.0.36 was. So whether PHP 5.3.1 will fail with (the official) MySQL 5.1.36 I do not know (if it is important for MySQL and/or PHP developers they could check it) and I may have been the first person to accidentally bump into this.

    2) I do not know how I should “determine the cause of the problem”. I can state the problem. It is not my job to “determine causes” for failures with software provided by others. The fact remains that this particular server/PHP combination did not work (also not with a simple script executing “SELECT 1;” – just like what you will find in any beginner’s tutorial). Replacing the server and/or replacing PHP solved this immediately. Besides I have no intention (and no skills either) of looking into neither MySQL or PHP *code* at all. I think those that know the code best (ie. the developers of both) should do this.

    3) I was actually looking for a way to get in contact with PBXT developers from Primebase website to ask if they could confirm, explain or provide more information. But I did not find such contact options (forums, support ticket system etc.) on Primebase website.

    Obviously (as nothing was recorded in neither general log or error log) this particular PHP with php_mysql or php_mysqli (I tried both) will not communicate with this server properly during ‘handshake’. The server does not know that a client ‘knocked on the door’ (if it did, it would have been recorded). I cannot tell if ‘knocking was wrong’ or if ‘listening was improper’.

    A few short comments:
    “.. it might be a good idea to understand the interaction between them”. We know what we need to know and did for around 5 years now.
    “As your product apparently interacts with both php and mysql ..”. PHP is only one of more connectivity options we provide.

+ Leave a Comment