4th International Conference on Principles and Practices ... - MADOC

01 public void sendFile(ResourceNode parent,
02 File f) {
03 try {
04 ManagedSocket s = new //...
05 FileInputStream in =
06 new ManagedFileInputStream(f,g);
07 ManagedOutputStream out =
08 s.getOutputStream();
09 byte[] buf = new byte[4096];
10 int len;
11 while ((len = in.read(buf)) >= 0) {
12 out.write(buf, 0, len);
13 }
14 } catch (IOException exc) {}
15 parent.release();
16 }
Figure 2-12. A “leaky” method
2.5 Automatic Resource Cleanup
When properly used, Furm opens up new possibilities for resource
auditing. Furm provides a WatchDog class for monitoring threads
for proper resource cleanup. A WatchDog is given a thread to
guard, and a reference to the root of the resource tree (or subtree)
being used by that thread. Whenever that thread dies, the
WatchDog can take some action on any resources abandoned by
that thread. This can be used as a safeguard to prevent resource
leaks at runtime. The WatchDog can also be used as a resource
profiler. If resource leaks are suspected or known to exist, every
thread in a program can be assigned a WatchDog for tracing
purposes. As threads die, any resources they leave open can be
inspected. Information about those resources can aid in tracking
down the leak.
There are two ways to control what action will take place when a
thread dies. The first is to provide a ThreadListener. When a
WatchDog observes that its thread has died, it will call the
threadDied() method on the ThreadListener, much the way a
ResourceNode calls exceptionThrown() on an ExceptionListener.
To specify a ThreadListener, simply pass it to the WatchDog
constructor. The second way to control what action the
WatchDog should take is to extend the WatchDog class and
override its threadDied() method. The WatchDog class itself
implements the ThreadListener interface, and so has the
threadDied() method. 5
WatchDog has two WatchLevels. The WatchLevel determines
what forms of thread termination will be monitored. The two
WatchLevels are exceptional (declared as EXCEPTIONAL_END)
and general (declared as ANY_END). If the WatchLevel is
exceptional, then the threadDied() method will only be called if
the thread dies by throwing an uncaught exception. If the
WatchLevel is general, then the threadDied() method will be
called regardless of the circumstances of thread termination.
As an example of how to use the WatchDog class, we present a
small, “leaky” method which uses Furm. This method simply
creates a socket connection and sends a file to the output stream
of the socket. Figure 2-12 contains its full implementation.
5 This model follows that of the Thread class, which has a
constructor that accepts a Runnable object, but also implements
the Runnable interface.
01 class Examiner implements ThreadListener {
02 private void printRes(ResourceNode res) {
03 Class c = res.getResource().getClass()
04 System.out.println(c.getCanonicalName());
05 for (ResourceNode rn : res) {
06 printResource(rn);
07 }
08 }
09 public void threadDied(Thread t,
10 ResourceNode node,
11 Throwable e) {
12 synchronized(node.getMonitor()) {
13 if (!node.isReleased()) {
14 printRes(node);
15 node.release();
16 }
17 }
18 }
19 }
20 // ...
21 new WatchDog(Thread.currentThread(),group,
22 new Examiner(),WatchLevel.ANY_END);
Figure 2-13. Utilizing WatchDog
Notice that the file transfer code is wrapped in a try-catch block
which catches IOException (lines 3-14). The release() call is
made on line 15. While this code will work in cases when no
errors occur or when an IOException is thrown, if the File
reference passed into the method is null, a NullPointerException
will occur on line 6, and the release() call will never be made.
The Socket and socket output stream will be leaked. The correct
solution is to add a finally handler, but here this has not been
done. If the code were part of a very large project, it may be
reasonable to assume that no one has discovered the bug.
Let us assume that the WatchDog class is being used to hunt for a
suspected bug, or that the WatchDog is simply being used as an
additional safeguard in development code. To this end, the
Examiner class (Figure 2-13) is added. Lines 21 and 22 create a
WatchDog to monitor the thread. A WatchDog can be created to
watch any thread. In this case, it is created to monitor the current
thread. The Examiner class used here implements ThreadListener
and performs two tasks in the threadDied() callback. First, it
traverses the tree to discover any unreleased resources and prints
that information. Second, it releases the tree.
An Examiner object is passed to the WatchDog constructor, and
the general WatchLevel is specified. When the current thread
dies, whether normally or as the result of an uncaught exception,
the Examiner object will inspect the thread’s resource tree. This
simple auditing may reveal the problem with the sendFile()
method. The WatchDog class is not a replacement for correct
resource management, but it can make it simpler to track down
cases of incorrect behavior.
One major benefit of the WatchDog class is that its use does not
require watched threads to be aware of its presence. In fact, it is
entirely possible for multiple WatchDogs to watch the same
thread, each oblivious to the others, and the thread itself blind to
them all. The main restriction on the use of the WatchDog class
is that it requires that any thread monitored by a WatchDog place
its resources in a resource tree. The WatchDog class cannot
monitor resources which are not in a resource tree. Watched
threads can ignore the WatchDogs, but must utilize Furm resource
trees.
121