From Eigenpedia

This page is a proposal for moving the default JDBC client/server protocol for Farrago (and dependencies such as LucidDB) from RMI to http.

Contents 1 Rationale 2 New Thirdparty Dependencies 3 Impact 3.1 Server Configuration 3.2 Client Configuration 3.3 Documentation 4 Testing Needed 5 Out of Scope

Rationale

RMI has a number of shortcomings:

• it is sensitive to machine name resolution configurations (see discussion in ClientServerLocalhost and eigenjira:FRG-32), causing trouble for new users and system administrators
• the distributed garbage collector can cause random failures (see eigenjira:FRG-316 for an example)
• by default, it uses dynamic ports, which is firewall-unfriendly; there's a solution (setting the parameter serverSingleListenerPort), but this is less efficient, and still requires two ports to be opened instead of just one
• client-side classloading can lead to bogus exceptions (e.g. due to spaces in .jar paths on Windows; see this mailing list thread for an example)

As a result, we would like to transition from VJDBC's RMI support to its HTTP support as the default (up until now, HTTP support has been considered experimental and has not gotten a lot of testing).

Note that dependencies (such as SQLstream) which are still using RmiJdbc instead of VJDBC will remain on RMI for now.

New Thirdparty Dependencies

In order to make this change, Farrago will need to become dependent on a servlet container to host the VJDBC servlet. We have chosen Jetty 7 for this purpose since it is the most lightweight embeddable container available with known quality.

Deployments which do not need http support (such as SQLstream) or which supply an alternative servlet container (e.g. LucidDbAsManagedBean) will be able to omit the Jetty dependency in order to avoid bloat/conflicts.

Impact

Server Configuration

Existing scripts such as farragoServer, lucidDbServer, and sqllineClient will continue to work unchanged, but using http as the new default.

In order to revert back to RMI support for a server, it will be necessary to set the serverRmiRegistryPort parameter explicitly:

alter system set "serverRmiRegistryPort" = 5434;

Otherwise, the default value of -1 will indicate that HTTP should be used instead. (As a consequence, if the port has already been set explicitly on a server migrated from an earlier version, it will be necessary to set it back to -1 in order to enable HTTP support.)

A new system parameter serverHttpPort will be defined to allow the default HTTP port to be changed. As with the old RMI parameter, a value of -1 will indicate that a system-dependent default should be used. In order to minimize the chance of conflicts with application servers, port 8080 will not be used as a default. Instead, we'll use 80xx where xx is the last two digits of the corresponding RMI port:

RMI Port	HTTP Port	Project
5433	8033	Farrago
5434	8034	LucidDB
5435	8035	SQLstream (http not used yet but reserved)
5437 (reserved, but not used)	8037	DynamoDB

If both the RMI and HTTP ports are explicitly set, the RMI setting will be ignored and HTTP will be used (simultaneous use of both protocols will not be supported).

Client Configuration

Client scripts such as sqllineClient will be updated to default to the new protocol default for the server URL parameter, e.g. jdbc:luciddb:http://localhost. For a server reverted to RMI, it will be necessary to override the URL and driver from client invocations, e.g.

sqllineClient -d com.lucidera.jdbc.LucidDbRmiDriver -u jdbc:luciddb:rmi://localhost

For existing installations of tools such as SQuirreL, it will be necessary to update connection settings to specify HTTP instead of RMI.

Documentation

Wiki pages which need to be updated:

• JdbcUrlConventions
• LucidDbSystemParameters
• LucidDbAsManagedBean
• FarragoSystemParameters
• ClientServerLocalhost
• LucidDbUserFaq
• LucidDbNonJavaClients
• pages such as LucidDbGettingStarted and LucidDbSquirrel which display jdbc:luciddb:rmi and jdbc:farrago:rmi in examples (need to search/replace for wiki text, plus find and update screenshots)

--Jvs 16:00, 24 January 2010 (EST): Also, in LucidDB 0.9.3, we're moving the RMI JDBC driver from com.lucidera.jdbc to org.luciddb.jdbc, so need to roll in those updates too.

Testing Needed

Here are some areas which need to be tested as part of the switch:

• longevity: long-running server can continue to serve new and existing connections without failures or leaks (this should be at least as good and probably better than RMI)
• concurrency: concurrent session execution should be at least as good as RMI
• latency: requests are served with latency no worse than RMI
• throughput: large result sets are streamed back with throughput at least as good as RMI
• reliability: network faults can be recovered or at least result in good diagnostics

Out of Scope

We are not addressing https configuration currently, although in theory it should not be difficult (most of the complexity is in setting up a certificate).