Petals ESB Container

Related to PETALSESBCONT-400, the router contains 3 modules:

• Flow Control aka rate control, which slows down the send of consumers to achieve a limited maximum rate of messages.
• Filter Control, which slows down the send of consumers to achieve a maximum number send in a given window.
• Priority Orderer, which supported the implementation of the previous two.

The Flow Control relied on the Router Monitor (see PETALSESBCONT-400) by asking it to monitor some given exchanges in order to be able to count them and on the Priority Orderer to slow the send down when desired.
The Filter Control was only relying on the Priority Orderer and was counting the exchanges by itself.
The Priority Orderer, because it was slowing down exchanges, was also relying on the Persistence service to persist there exchange when there was no memory available (using a JVM mechanism that would notify it in that case).

In practice, these modules have the following flaws:

• They have big design problem: they would act on exchanges BEFORE the target endpoint was selected (i.e. they relied on the information provided in the exchange and not the resolved endpoint), and thus were maybe slowing down the wrong exchanges or not slowing down desired ones.
• The persistence mechanism on case of memory problem was covering only the exchanges that were slow down, but not those in the queues, i.e., it wasn't generalised.
• The idea of slowing down the send is not so good as it blocks the consumers, even when they were doing asynchronous messaging!

For all these reasons and the fact they were not documented, they should be removed.
As stated in PETALSESBCONT-400, the rate control mechanisms could be reimplemented more cleanly at CDK level (i.e. give the responsibility of not handling too much exchange at once to the components and not the router).
For replacing persistence, see PETALSESBCONT-339.