How to isolate your program from calls to a "bad" API?

Question

When I developed a piece of (academic) software using Java, I was forced to use an API that was rather badly implemented. This means that calls to this API for a certain set of input data would sometimes never return. This must have been a bug in the software as the algorithms that it offered were deterministic ones, and sometimes it would terminate on a set of data, sometimes it would run into an infinite loop on the same set of data...

However, fixing the API or reimplementing it was simply beyond scope. I even had the source but the API heavily relied on other APIs which were undocumented and without source and had by the time vanished from the web (or never been there?). On the other hand, this "bad" API was the only one out there that solved the specific problem I had, so I really had to stick with it.

The question is: what is the cleanest way of dealing with an API that behaves that, well, nasty? When I faced this problem I decided to put the calls to the API into a separate thread. Another thread would then occasionally check if this thread had terminated. If a certain amount of time had passed, I would kill the processing thread using Thread#stop() and start the processing again, hoping that it would return the next time. Now, I know (and knew back then) that this method is deprecated and must not be used. But in this academic context it was acceptable to have the software potentially run into an undefined state instead of having it crash.

It was also not acceptable to just ignore the processing thread that had run into an infinite loop because it did some quite CPU-intensive operations that would slow down the user's machine significantly.

Another way which I didn't try is to start the processing in a separate process instead of a thread, because a sub-process can be killed cleanly without putting the software in an inconsistent state. Or could the new SwingWorker class (which wasn't yet available) have done the job? It has a cancel() method, but the docs say that it "Attempts to cancel execution of this task", so it doesn't look like a reliable approach either.

Answer 1

I would recommend the use of a separate process. There is essentially no safe way for one thread to kill a second thread in Java unless the second thread is periodically checking to see if it has been interrupted.

The ideal solution would be to use isolates. An isolate is essentially a private virtual machine that a Java app can create, managed and communicate with. In particular, the parent app can safely kill an isolate and all its threads.

Reference: JSR-000121 Application Isolation API Specification - Final Release

The problem is finding a JVM that supports Isolates.

Answer 2

I'm a big fan of separate processes for this kind of thing.

Spawn a sub process and wait for results.

If the API is non-deterministic, put the timer thread in a wrapper that makes the bad API into a main program.

That way, the subprocess always ends within the given time. It either produces a useful result or a system exit code that indicates failure.

Answer 3

The best thing to do would be to re-implement the API in question. However, as you say, that's a very heavy weight and probably out-of-scope solution.

The next best thing would be to wrap the API if possible. Basically, if you can determine in advance what it is about the datasets that causes failure you could reject calls to guarantee determinism. It doesn't sound like this will work for you either, as you suggest that repeating a call with the same dataset will sometimes terminate when it had infinitely looped in a prior invocation.

Given the above options above aren't available:
I think your current thread solution is the best of the bad choices. Spinning up a process for a method call seems way too heavy weight to be acceptable from a performance point-of-view, even if it is safer than using threads. Thread.stop() is very dangerous, but if you religiously prevent any locking you can get away with it.

Answer 4

Both @S.Lott and @Stephen C's answers are spot on with regard to how to handle this type of situation, but I'd like to add that in a non-academic environment, you should also be looking to replace the API as soon as practical. In situations where we've been locked into a bad API, typically through choosing a vended solution for other reasons, I've worked to replace the functionality with my own over time. Your customers are not going to be as tolerant as your professor since they actually have to use your software (or not!) instead of merely grade it.

There are certainly situations where using duct tape is an adequate choice to solve a problem. When it results in such poor behavior as you describe, though, it's best not to rely on it too long and start working on a real repair.