|








|
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.
|