MDB process rate limiting - JBAS-2325

[genman]

Forum for discussing JBAS-2325

The discussion is mostly focused on: What would be the best approach for implementation?

Also, is there any way we might generalize "rate limiting" to other aspects of EJBs? How might we expose metrics/telemetry and configuration via MBeans?

[adrian.brock]

You are talking about flow control?
http://jira.jboss.com/jira/browse/JBAS-1585

Metrics are already exposed through JSR77

[genman]

Thanks for replying. I'll take a look at what's available via JSR-77, I thought what was available were things like average/min/max time to process, number of messages processed, etc. Does it cover things like average rate, etc.?

The bug JBAS-1585 (flow support) seems to be more about how JBoss throttles for performance. This request is more about regulating flow for other reasons.

It may be better to have flow control at the consumer/producer level than at the MDB/EJB level.

[adrian.brock]

"genman" wrote:

Thanks for replying. I'll take a look at what's available via JSR-77, I thought what was available were things like average/min/max time to process, number of messages processed, etc. Does it cover things like average rate, etc.?

I'm not saying you'll necessarily find what you need, but any new metrics should
be done through JSR77.

[adrian.brock]

"genman" wrote:

The bug JBAS-1585 (flow support) seems to be more about how JBoss throttles for performance. This request is more about regulating flow for other reasons.

JBAS-1585 is a feature request.
It is implementation primitives - throttle/schedule/priortise.
Who/where/what/why/when it is getting done is a separate issue (policy).

It may be better to have flow control at the consumer/producer level than at the MDB/EJB level.

It is better to have it at the wait state where it is not consuming resources.

[genman]

I'm not saying you'll necessarily find what you need, but any new metrics should
be done through JSR77.

Are there any metric classes for computing rate of traffic in JBoss or a third party library? I wrote a simple one I could add.

Just as an example:

http://www.javaworld.com/javaworld/jw-06-2002/jw-0614-mgmt-p3.html

Would I create a "RateStatistic" interface and implementation and have it returned by "MessageDrivenBeanStats" ? Unfortunately there's no "Rate" sort of statistic part of JSR77, maybe I'm missing something.

I was thinking of having the blocking done by this class:

src/main/org/jboss/jms/asf/StdServerSessionPool.java

In pseudocode:

public ServerSession getServerSession() throws JMSException {
float r = rate();
if (r > maximumrate)
sleep(maxiumrate - r * K);
// return a server session and/or block
}

Any thoughts?

[adrian.brock]

The metrics stuff should be developed independently and discussed in the
management forum.
It has "knock on" implications for jsr77, the admin console, web console, etc.
The ServerSessionPool currently has zero management/monitoring exposure. :-(

Like I said before "flow control" policy should be "plugged in" not coded
directly into implementations.
Besides the fact it isn't good design, since it is a cross cutting concern.

[genman]

The metrics stuff should be developed independently and discussed in the
management forum.
It has "knock on" implications for jsr77, the admin console, web console, etc.
The ServerSessionPool currently has zero management/monitoring exposure. :-(

I raised the issue in the management dev forum.

Like I said before "flow control" policy should be "plugged in" not coded
directly into implementations.
Besides the fact it isn't good design, since it is a cross cutting concern.

But, in regards to rate limiting an MDB, what sort of plug in design would you recommend? I do notice the DLQ handler is a plug-in now, so would that be the recommended procedure for something like this? Or, am I just not thiking at the right level?

There are statistics at the MDB level. But if there were management statistics for a ServerSessionPool, would it have the same data, would it be shared, or be disjoint sets?

I would expect you'd have some sort of statistics through JCA 1.5.

[adrian.brock]

Let me reiterate it another way.

First there will be some "joinpoint" where flow control is applied.
Whether this is MDB delivery, JMS Message addition or something else does not
matter.

Whether the flow control does random sleeps, limits the concurrency
or rejects requests is one aspect of the policy.

When it does these (sleep, wait, reject, etc.) will depend upon how it interprets the
statistics, which will depend upon the context.

in pseudo config:

<!-- Where-->
<interceptor name="org.jboss.flow.FlowControl">
 <!-- What-->
 <flow-control-config type="org.jboss.flow.Sleep">
 <sleep>1000</sleep>
 </flow-control-config>
 <!-- When -->
 <metrics name="org.jboss.flow.FlowRate>
 <condition>flowrate &gt; 10</condition>
 </metrics>
</interceptor>

This is just thinking out load.

[adrian.brock]

The other issue (on the other thread) is how you expose the flow control component
and the metric through jsr77 as a child of the component it is applied to.

[adrian.brock]

"I would expect you'd have some sort of statistics through JCA 1.5. "

There is a general feature request to improve the stats and monitoring
capabilities of JCA.