You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <qp...@incubator.apache.org> on 2007/03/07 16:10:24 UTC
[jira] Created: (QPID-406) Provide message interceptors in client &
broker.
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.
[jira] Closed: (QPID-406) Provide message interceptors in client &
broker.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway closed QPID-406.
----------------------------
Resolution: Fixed
See qpid/framing/Handler.h
> 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
> Assignee: 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.
[jira] Assigned: (QPID-406) Provide message interceptors in client
& broker.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway reassigned QPID-406:
--------------------------------
Assignee: Alan Conway
> 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
> Assignee: 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.
[jira] Updated: (QPID-406) Provide message interceptors in client &
broker.
Posted by "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.