The restlet client resource (org.restlet.resource.ClientResource) has a nasty habit of leaving open handles, even when release() is called and a single client is used with the setNext() call. For example, this sample code will quickly exhaust the file handles on a system (and in my test case cause CouchDB to crash):
Client myClient = new Client(new Context(), Protocol.HTTP);
... loop the following a few thousand times quickly to cause the problem:
ClientResource clientResource = new ClientResource(url);
clientResource.setNext(myClient);
clientResource.put(jNode.toString());
clientResource.release();
...
The problem happens with all current versions of the restlet framework (2.0.10, 2.1 test, 2.1 unstable). The solution is to ensure the representation is exhusted explicitly, like so:
Debian 6 comes with a minimal install that is missing several packages for the installation and configuration of the vmware toolbox for vmware 7.1.1. To get things to install and configure correctly be sure to install the following:
The tools configure and run fine after these changes.
Installation instructions for the drupal services module. This module allows access to drupal through a services interface. The reason for installing this is I am developing a simple android app to allow the uploading of any content (such as text, voice recordings, photos, video, etc.) from my tablet (or phone) into a journaled form of a content management system (CMS). Drupal in this case. Note Drupal v6 (not v7) is needed due to a dependency in the autoload module. The services module allows me to use a REST interface to perform the operations from within the Android app.
This will allow me to journal any little scrap of information I care to, along with time/date, coordinates of where the data was gathered, etc. and then be able to incorporate that data elsewhere as needed, or feed it out through an RSS feed.
In any case, some notes on the Services module install:
There are all sorts of little quirks that pop up when expecting full Java compatibility in Android, such as when trying to implement TLS mutual authentication within an Android application. In mutual authentication certificates are used to authenticate both the server and the client during the TLS handshake. The client application (in this case the Android application) authenticates the server using the server certificate, and the server authenticates the client using client-certificate based authentication. Communication is encrypted, authenticated, and everyone is happy.
Unfortunately one of the quirks is that Android only seems to support BouncyCastle key and trust stores. This means ensuring that in your SSL socket factory you need to ensure you only use the BKS instances, e.g. KeyStore trustStore = KeyStore.getInstance("BKS"). The 'normal' Java Key Stores (JKS) will not work, even though the available documentation suggests it might.
Tested out bluetooth tethering (USB tethering does not seem to work) of the Asus transformer and my iPhone 3GS. iOS update was required (now running 4.3.x) but it now works well. Getting 3G data to the tablet without WiFi! Good stuff for when I travel. Steps: