Comments on Regular Expressions: Java Retry Framework

I'm currently working on a project with a few jbos...

2007-05-14T15:16:00.000-07:00

I'm currently working on a project with a few jboss clusters and tangosol caches on the server side, and a swing client for the users.

To handle connection issues and other remote explosions I decided to place all tasks that interact with a remote resource within a Callable object, and pass this object to a task service.

The components:

Manager
* facade to control access to remote resources

ManagerTaskService
* uses backing ExecutorService for async tasks

TaskFailedHandler
* controls reconnect/retry logic

ManagerConnection
* Maintains connection state safely in concurrent environments. Uses notify/wait for responsiveness, and immutable state objects.

Synchronous tasks are executed using ManagerTaskService.invokeAndWait, which handles waiting for the manager to be ready, deciding whether a failed task should be retried, and whether the manager needs to reconnect.

Asynchronous tasks are wrapped by a Callable that runs invokeAndWait, and then added to the ExecutorService.

Here's the code I used for invokeAndWait:

public <CVal> CVal invokeAndWait(final String name, final Callable<CVal> task) {
TaskFailedHandler failureHandler = failureHandlerFactory.newInstance();

for (;;) {
try {
manager.waitFor();
return task.call();
}
catch (Exception ex) {
failureHandler.exceptionThrown(ex);
if (failureHandler.shouldReconnect(ex)) {
manager.requestReconnect();
}
if (false == failureHandler.shouldRetry(ex)) {
log.error("invokeAndWait - not retrying due to TaskFailureHandler policy - " + name);
return null;
}
}
}
}

There isn't a defacto way of doing something later...

2007-01-13T01:53:00.000-08:00

There isn't a defacto way of doing something later - you're right - but there's a few common sense ways, like Runnables, and a stab at a retry framework could promote a common way of writing logic that a developer wants to keep attempting until success...

... as an afterthought

JMX Timers are J2SE ...

2006-11-09T07:43:00.000-08:00

... as an afterthought

JMX Timers are J2SE based, and if you could find a sensible way to persist them such that they survived a JVM restart then a retry framework is only a day's coding away.

The problem with a retry framework is that there i...

2006-11-09T07:34:00.000-08:00

The problem with a retry framework is that there is no real de facto technique for 'doing something later' in Java yet.

If you had such a technique, then writing a retry framework would be a sensible step.

Candidates for the technique to do something later are:

Quartz Jobs
Weblogic 'send later' JMS messages
...and other persistent events

Comments on Regular Expressions: Java Retry Framework

I'm currently working on a project with a few jbos...

There isn't a defacto way of doing something later...

... as an afterthoughtJMX Timers are J2SE ...

The problem with a retry framework is that there i...

... as an afterthought

JMX Timers are J2SE ...