Gaggle Components
Data Standards

Gaggle FAQ

Loss of connection when switching networks

When a machine is assigned a new IP, which happens when it sleeps connected to one network (say at work) and is moved to new network (home), Gaggle loses its socket connections. Gaggle apps may hang for a few minutes waiting for connections to time out. Finally, an error is thrown: Connection timed out: connect

At present, the only known work-around is to shut down all gaggle apps and restart. Better is to proactively save and shut down before switching networks.

A bug has been filed. Please add any additional information to the bug report.

R Problems

The R Goose fails to connect to the Gaggle.

  1. Make sure the Boss has been started, and is actually running.
  2. Make sure you are using the correct version of R.
    See the R Installation page to find out which version you should be using.

Windows Problems

Some buttons (and/or other visible areas of any goose) have no labels.

  1. This seems to be a Windows-only problem.
  2. It may be due to the interaction of Microsoft Windows, Sun's Java implementation, and the Gaggle's use of RMI (but this is merely speculation....).
  3. The mostly likely solution (alas!) is to reboot. If you still have troubles, make sure you have the latest Java from Sun. You might wish to make sure your Windows Operating System is up to date.

"MalformedURLException: no protocol" when trying to connect to the Gaggle
  1. This problem is most likely to occur when you are trying to implement a goose for a 3rd party application that dynamically loads Java classes, e.g. plug-ins.
  2. Upon calling Naming.lookup( "rmi://localhost/gaggle" ) a MalformedURLException is thrown. The error message will look similar to this:

    RemoteException occurred in server thread;
    nested exception is:
    java.rmi.UnmarshalException: error unmarshalling arguments;
    nested exception is: no protocol: and [...]

    The error message is quite misleading since the exception is not caused by the URL "rmi://localhost/gaggle", which is a correct URL.

  3. We believe that it is caused by a malformed URL registered with a class loader (usually URLClassLoader instances) somewhere in your application. In order to handle the RMI protocol a URLStreamHandlerFactory has to be registered for this protocol. Your application usually searches for such handlers in various places. The API docs for the URL class explain this in great detail. (The API docs don't mention this explicitly, but we assume that during the search process all registered class loaders are queried for the availability of a handler for the RMI protocol.)
  4. The malformed URLs in your class loaders are probably due to the toURL() function of the File class. The function is seriously flawed since it doesn't encode illegal URL characters correctly. This problem is also known as Bug 4273532. In this particular case space characters in a file path (e.g. to a class you want to load) aren't encoded but left in the URL. According to RFC 2396, Section 2.4.3, space characters are URI (and URL) separators. If you're class loader has been fed with a (malformed) URL like "file:///my plugin directory/plugin.class" a function interpreting this URL correctly with find three URLs out of which two don't have a protocol. We concluded that this causes the MalformedURLException described above.
  5. The recommened workaround for this problem (and for the stability of your application in general) is to ensure that all URLs are encoded correctly. For instance, this can be achieved by using the encode(String,String) function in the class URLEncoder (make sure any backslashes in your file path are replaced by slashes before you call this function). Other workarounds are listed in the bug report for Bug 4273532.
© 2006, Institute for Systems Biology, All Rights Reserved