Provide message interceptors in client & broker.
------------------------------------------------
Key: QPID-406
URL: https://issues.apache.org/jira/browse/QPID-406
Project: Qpid
Issue Type: New Feature
Components: C++ Broker, C++ Client, Dot Net Client, Java Broker, Java
Client, Python Client, Ruby Client
Reporter: Alan Conway
The interceptor pattern (also known as
http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern) allows dynamic
extension of processing by delegating work to a dynamically constructed chain
of interceptors (or "handlers".) It's well established (CORBA, J2EE, JAXWS
etc.) and very flexible.
The immediate use case for qpid is to support the interop test suite
http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Specification.
This calls for automatic timeouts if there is no communication to or from the
client for a certain period of time. Resetting the timeout at every
send/receive point in test code is tedious and error-prone. A better solution
is to allow the test setup to register a timeout interceptor (callback,
handler) that resets the timeout for every communication event.
I'm not stuck on terminology,Interceptor or Handler work for me - the C++
broker already uses handler.
I suggest a simple generic/templated recursive handler pattern, like the
following pseudo-code:
// Framework:
interface Handler<T> { void handle(T); }
interface HandlerFactory<T> { Handler<T> create(Handler<T> next); }
// Now for the current use case we would write a handler like this:
class TImeoutHandler : implements Handler<Frame>, HandlerFactory<Frame> {
Timer timeout;
Handler<Frame> create(Handler<Frame> next) { return this; }
void handle(Frame f) { timeout.reset(); }
}
// Test setup
FooTest {
TimeoutHandler timeoutHandler;
void setUp() {
connection = ...;
connection.addFrameOutHandler(timeoutHandler);
connection.addFrameInHandler(timeoutHandler);
}
// Not shown: the timer needs run a thread that kills the connection if the
timer times out.
The pattern can be extended to other kinds of interceptor, e.g. higher level
interceptors for send/receive message, send/receive acknowldgement etc. We can
also put interception points at different places in the architecture: per
channel, per connection etc. We can start with just solving the current use
case and extend as needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
