[jira] Updated: (QPID-406) Provide message interceptors in client & broker.

["Martin Ritchie (JIRA)" <qp...@incubator.apache.org>]

     [ 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.