Forum: Building VoltDB Applications

Post: Calling a persistent client connection for multiple procedures?

Calling a persistent client connection for multiple procedures?
will
Jul 14, 2010
Is there a way to keep a client connection to the Volt server open so that each time you want to call a procedure re-connecting is not necessary?

For example, could you do something like this:

Start VoltDB cluster

Start VoltDB client application that has a connection to the cluster

Call seperate java applications which use the already started VoltDB client to call procedures so that they don't need to connect to the VoltDB cluster as well.
Nevermind ,figured it out,
will
Jul 14, 2010
Nevermind ,figured it out, thanks.
Hi Will, What solution did
aweisberg
Jul 14, 2010
Nevermind ,figured it out, thanks.


Hi Will,

What solution did you find? The Java client API is thread safe so you can run multiple threads, but we haven't implemented anything like a proxy process.

Ariel Weisberg
I used an RMI instance to
will
Jul 15, 2010
I used an RMI instance to hold a persistent connection to a VoltDB cluster and connected to the RMI instance through separate processes.

So basically my starting of VoltDB goes:

Start VoltDB server.

Start RMI server with the persistent connection to the VoltDB cluster

Use separate java processes to access the RMI server and pass it strings which the RMI server will parse to call specific VoltDB procedures.
Very cool. What motivated
aweisberg
Jul 15, 2010
I used an RMI instance to hold a persistent connection to a VoltDB cluster and connected to the RMI instance through separate processes.

So basically my starting of VoltDB goes:..


Very cool. What motivated this approach? Are you starting and stopping JVMs regularly or do you have a couple of JVMs that you want to be able to share connections to the database?

In the first case RMI seems like a good approach for avoiding the overhead and latency of creating a connection(s) to the cluster. There is a dedicated acceptor thread and a cached thread pool that does blocking IO for the authentication portion so the servers can accept connections at a decent clip if you are willing to tolerate the overhead at the client.

In the second case, we don't really want you to have to bend over backwards for performance. We do recommend trying to multiplex as much works as possible through the smallest number of connections possible (1 connection between each client host and Volt host), but Volt will still run fast with a large number of connections. We do nonblocking IO and readiness selection and have tested up to 3k connections. If these are long lived process and the load generation is roughly even you might consider connecting each one to a subset of the cluster.

-Ariel
I'm stopping and starting
will
Jul 15, 2010
I'm stopping and starting JVM's regularly and wanted as little overhead as possible on the client side.
I'd just like to say that VoltDB is really a cool database system to work with, you guys did a great job.