Last Summer I implemented a non-blocking client API in MariaDB, and it was included in the MariaDB 5.5 release. But somehow I never got around to announcing it.

However, that did not prevent Brian White from noticing it, and using it to implement a new mysql binding for node.js called mariasql.

Now, node.js is a single-threaded, event-driven framework for web application sever development. In such frameworks, all I/O is done non-blocking or asynchronously, as are all other actions that may need to wait for external events. There is a single event loop which uses a poll() or similar system call to wait for any pending I/O or other event to complete, and then dispatches the appropriate event handler(s). Such frameworks are often used instead of a multi-threaded model, eg. if threads are not available or to avoid complex inter-thread synchronisations and expensive context switch overhead.

Such frameworks are exactly where the non-blocking client library in MariaDB is useful. The Knowledgebase has all the details, but here is the basic idea:

To run a query, the application does a call like this:

mysql_real_query_start(&status, mysql, “SELECT * FROM t1”);

This will send data on the socket, and the server will start executing the query. But instead of waiting for the results, like in the normal  API, the call then returns immediately. The application can then check the status of the running query; in this case it finds that the query is waiting for data to arrive on such-and-such socket descriptor. The application will then register a callback and include the socket descriptor in the poll() call in its main loop. When data arrives, the callback fires and invokes:

mysql_real_query_cont(&status, mysql, <data_is_ready>)

Then the query processing continues, possibly returning multiple times while waiting for more data to arrive, and finally completing the operation.

The API is carefully designed to be just what is needed for event-driven frameworks like node.js to use it conveniently and efficiently. So I was really pleased to discover the mariasql project apply this theory to practise. I was of course especially pleased to see the benchmarks, where the non-blocking library is significantly faster than other MySQL bindings for node.js when queries (and thus waiting on the network) is involved. Without a proper non-blocking API, frameworks must resort to spawning background threads and defering blocking operations to such background threads; presumably the speedup comes from avoiding the inter-thread synchronisation and context switches. Of course avoiding the maintenance of background threading also simplifies the implementation.

Note by the way that the MariaDB non-blocking client library is fully compatible with all versions of the server, including all MySQL versions. So while mariasql must be linked against the MariaDB client library, it can be used with any MySQL server (the mariasql source tree seems to include the MariaDB client library to make this even easier for users).

In June, I told about the consolidation of the MariaDB project tools. The final piece of this consolidation, to report bugs in the MariaDB project tracking tool called JIRA has now been finalized.

Bug reporting stays open! JIRA is open to anyone. The bug reports are publicly available, even without logging in and as a bonus it will be easier to follow what is going on in the project since you don’t have to jump between several tools to get the complete picture.

All bugs that existed in Launchpad have been migrated to JIRA. To find a bug that was originally reported on Launchpad use the following approaches:

  • If you happen to have the original bug id you can search for the bug by typing lp:bugid into the search field in the upper right corner of JIRA. Also, if you have the link to the bug report on Launchpad, you’ll be able to open that bug report and get hold of the id (which by the way also can be seen in the URL).
  • You can also search on keywords, e.g. “ALTER TABLE” or “microsecond”
  • In addition JIRA includes a nice search functionality with which more advanced searches can be done like searching for issues reported by a specific user. This search is found in the top navigation under “Issues” and is called “Search for issues”.

Getting the bugs into the project tracking tool of MariaDB can be seen as an enabler of the personal task I set for myself in my MariaDB Directions blog post last week, on creating a longer-term roadmap for MariaDB. Now with the development tasks, bug reports and planning inside the same tool, anyone can see what is going into which version of MariaDB.

Please make yourself familiar with MariaDB development by checking out JIRA and do participate in the development by:

  • Creating new issues in JIRA for features you would like to see in upcoming versions of MariaDB
  • Reporting possible bugs in MariaDB, “Create Issue” in JIRA
  • Commenting and adding more information to existing issues in JIRA

You’ll have to create an account for yourself to do that, which is very straight forward. Just click on the Sign Up –link in conjunction with the Login and follow the instructions.

If you did report MariaDB bugs on Launchpad before you’re also seen as the reporter of the bug in JIRA and an account has automatically been created for you in JIRA. However this account doesn’t hold your email address, since it was not (easily at least) possible to export that from Launchpad (probably because of privacy reasons). We are glad to activate your automatically created account in JIRA. Todo so please send us your name and email address through the Monty Program contact form.