[
https://issues.apache.org/jira/browse/QPID-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie updated QPID-406:
--------------------------------
Fix Version/s: M3
> 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
> Fix For: M3
>
>
> 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.
