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:
java.net.ConnectException: 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
A bug has been filed. Please add any additional information to the bug report.
The R Goose fails to connect to the Gaggle.
- Make sure the Boss has been started, and is actually running.
- Make sure you are using the correct version of R.
See the R Installation
page to find out which version you should be using.
Some buttons (and/or other visible areas of any goose) have no labels.
- This seems to be a Windows-only problem.
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....).
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
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.
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:
java.net.MalformedURLException: 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.
We believe that it is caused by a malformed URL registered with a class loader
URLClassLoader instances) somewhere in your application.
In order to handle the RMI protocol a
to be registered for this protocol. Your application usually searches for such
handlers in various places. The API docs for the
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.)
The malformed URLs in your class loaders are probably due to the
toURL() function of
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.
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
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