Eric Day

Debug Console in drizzled

Last week on the train to Seattle I was hacking on the new libdrizzle protocol plugin when realized I could really use a debugging console that did not require any socket communication. Since I abstracted a Client plugin in the server (Protocol class for the MySQL folks), this can easily be done by just writing a new plugin. I needed to do some refactoring with the listener plugin to not require a TCP socket/accept and instead poll any arbitrary file descriptor. This allows the the Listen plugin to create the client instance any way it wants. After a bit of hacking and cleanup, we now have this:

shell$ ./drizzled/drizzled --datadir=/home/eday/other/drizzle.data
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins.
090827  0:29:34  InnoDB: highest supported file format is Barracuda.
090827  0:29:34 InnoDB Plugin 1.0.3 started; log sequence number 8157346
Listening on :::4427
Listening on 0.0.0.0:4427
./drizzled/drizzled: ready for connections.
Version: '2009.08.1046' Source distribution (eday-dev)
drizzled> show databases
Database
information_schema
narada
pastebin
test
drizzled> show tables in test
Tables_in_test
drizzled> create table test.a (x int, y int, z varchar(255))
OK
drizzled> insert into test.a values (1,2,"Hello")
OK
drizzled> insert into test.a values (3,4,"World")
OK
drizzled> select * from test.a
x       y       z
1       2       Hello
3       4       World
drizzled> exit
./drizzled/drizzled: Forcing close of thread 1  user: ''
./drizzled/drizzled: Normal shutdown
090827  0:31:25  InnoDB: Starting shutdown...
090827  0:31:26  InnoDB: Shutdown completed; log sequence number 8160010
./drizzled/drizzled: Shutdown complete
shell$

Note that this is all one shell session, there was no breaking out into a separate client program. The embedded console reads commands from standard input of the drizzled process and shoves commands right into the parser. This will make testing and debugging easier, as well as providing a way to manage a database when you don’t want to start up any socket-based client plugins.

So, how does this work? The “listener” interface is actually just a pipe() that returns a new client right away after startup. So what does this mean? Other types of clients are now fairly easy to write, and an embedded client is right around the corner. We just need to put in a query/result queue and provide a way for outside application threads to use that queue. I’m not sure when this will make it into trunk since a bunch of Drizzle folks on on vacation, but I can provide pointers to my development branch if anyone wants to play with it. :)

2 Responses to "Debug Console in drizzled"

1. Paul McCullagh says:

   August 27, 2009 at 5:11 am

   Hi Eric,

   Great stuff! The next step is to create “VM” plugins, that talk to drizzle using the standard client interface, and the internal communications channel you have created.

   For example, you could create a Java VM plugin, that would run a Java procedure from within drizzled.

   Then you could write stored procedures in Java, PHP, Python or any other language.

   Best regards,

   Paul
2. Debug Console in drizzled, Part 2 « PlanetMysql.ru – ?????????? ? ???? MySQL says:

   October 5, 2009 at 9:47 pm

   [...] a month ago I blogged about the debug console I was adding to drizzled. I finished this work up and it’s now in the [...]

Leave a Reply