Bug Database




bug database

We cheerfully admit that Hive has lots of bugs. However, we think it is reliable enough to be useful and interesting.

Thanks to SourceForge we now have an online bug tracker which we are starting to use. Feel free to tell us about the bugs you have encountered.

The following is a list of important things we know are issues:

  • Hive does not always shut down cleanly. If you have trouble killing Hive, try to shut it down nicely, wait a bit, then kill it with control-C.
  • There are occasional inconsistencies when one UI is monitoring multiple cells. Most of the issues seem to be in the UI agent which presents the view, rather than the AgentMonitoringAgent which maintains the model. We are working on these, but it's a hard problem.
  • Our method of doing asynchronous messages can result in lots of threads and sockets being spawned. If you are sending many asynchronous messages quickly (say, over 50 a second), you may find problems.
  • Hive does not work through firewalls. Too many random ports are being created, and RMI's firewall support isn't quite working for us.
  • Mobile agents mostly work OK, but mobile code does not work as well as we'd like.
    • Currently, mobile code is one-hop only. This problem is relatively easy to fix by caching class bytes in the class loader.
    • Because of limitations in Java's resource loading, Hive has to have a pointer to a directory with all the .class files you want to serve up. The -agentclassdir flag sets this up. It doesn't currently work with a jar file.
    • Java's demand loading of classes means that sometimes an agent might not get all of its classfiles before the cell it came from disappears. This is a hard problem to solve.
    • Hive currently does not manage classloader namespaces entirely correctly. Classes sometimes get loaded and then are not available to an agent. This is more of a problem when RMI interfaces are loaded; simple implementations are less of an issue.
    • Mobile code engenders problems with code versioning. We do not guarantee any particular behaviour if you try to load two versions of the same agent into one cell.
  • Mobile agents (and agent death in general) are broken in one respect - when the agent moves or dies, we stop its threads, but we cannot actually invalidate old references to that agent. This means that if any agent that still has a reference to the newly dead-or-moved one, methods can still be invoked on it and the agent won't be garbage collected. We can only fix this using Java2's UnicastRemoteObject.unexportObject.

Last Modified: May 20, 2000
Comments to: