How to check if I/O operation is blocking or non-blocking?

Question

I am using Netty as the base of my server and JDBC for MySQL. I used BoneCP to pool my JDBC connections.

In my server, the only I/O operation is JDBC connections.(and PrintWriter for logging exception to a text file)

I know that each JDBC connection uses single thread. However, if I use BoneCP to pool my connections, it will somewhat simulate an asynchronous I/O until all connections are filled. Correct me if I'm wrong.

So I was wondering how many connection creations(or JDBC executions) per given period will generate a blocking I/O. What are some ways that I could test if my server is blocked or not?

Answer 1

JDBC is a synchronous API meaning that the calling thread blocks for each operation to complete. Given that an operation can take a long time (relatively speaking) to complete then, regardless of whether the JDBC driver uses blocking or non-blocking I/O, from Netty's perspective it should be considered a blocking operation. Using a connection pool doesn't change this - it just reduces the overhead in obtaining a connection to the database.

Assume you perform a select operation, and that operation takes 100's of milliseconds to complete because it's returning a lot of data. If you perform that operation on Netty's I/O worker thread then all channels managed by that thread will stall until the JDBC operation completes.

How you resolve this really depends on your application requirements. For example

• test if the database can respond fast enough such that you can perform Netty JDBC operations in the I/O worker thread without impacting clients. This is probably only viable for a lightly loaded server with few client connections.
• depending on which version of Netty you're using there are different thread pool and executor models you can add to your pipeline to offload JDBC operations from the I/O thread.
• If you're using a recent enough version of Netty 3 (3.6 I think) or Netty 4 you could offload the JDBC operation to a completely independent thread pool and then raise a custom event on the Netty I/O thread when the JDBC operation completes to continue processing the request.

Another point to consider is that, if the database is relatively slow, and your server is under load, you'll need to either place an upper bound on the number of connections you allow or you'll have to suspend reads on Netty channels to give the database an opportunity to catch up