Bug 1017768 - Throttling timePeriod configuration in switchyard.xml not used at runtime
Throttling timePeriod configuration in switchyard.xml not used at runtime
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: SwitchYard (Show other bugs)
Unspecified Unspecified
high Severity high
: CR1
: 6.1.0
Assigned To: Keith Babo
Matej Melko
Depends On:
Blocks: 1146192
  Show dependency treegraph
Reported: 2013-10-10 09:26 EDT by Keith Babo
Modified: 2016-01-04 02:49 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SWITCHYARD-1718 Major Closed Throttling timePeriod configuration in switchyard.xml not used at runtime 2016-04-25 16:24 EDT
JBoss Issue Tracker SWITCHYARD-2306 Major Resolved Throttling timePeriod configuration in switchyard.xml not used at runtime 2016-04-25 16:24 EDT
Red Hat Knowledge Base (Solution) 701413 None None None Never

  None (edit)
Description Keith Babo 2013-10-10 09:26:00 EDT
Time period for throttling defaults to 1 second, but can be changed to a different value in switchyard.xml.  This value is not used when setting up throttling at runtime, however.

Note that max requests per time period works today and can be configured statically (via switchyard.xml) and dynamically (via console, admin APIs) at runtime.  The time period can *only* be set statically via switchyard.xml.  This is not a bug, it's a limitation of the camel throttling processor which we use under the covers.
Comment 2 JBoss JIRA Server 2013-10-21 09:06:48 EDT
Keith Babo <kbabo@redhat.com> made a comment on jira SWITCHYARD-1718

Comment 3 Keith Babo 2014-01-02 22:44:07 EST
Reopening this issue as it's not completely fixed.  The bus has been updated to accept the throttling time period, unfortunately the deployer updates the throttling metadata after the reference is created and the Camel bus route is configured:


The bus route is created in registerServiceReference() and the reference is updated with throttling info after that point, which is too late.  The fix for this requires some deeper surgery in core to build/start the route after the throttling information is updated.
Comment 4 Rick Wagner 2014-02-05 12:08:54 EST
Note to Engineering:  CEE (GSS) has a couple of support cases, we're getting 'when' requests.  Have we got a reasonable ETA we can supply?  (Please consider only time to produce the source, we'll pad for build and QE).


Comment 5 Keith Babo 2014-02-05 12:17:57 EST
Hey Rick - there is not a when yet as the work has not been scheduled.  It would be interesting to hear the use cases people have for using this capability as the only things that are not possible now are:

1) Setting sub-second rate limiters. For example, specifying 10 messages every 10 milliseconds.  This can be approximated using the current support by saying 1000 messages per second.  Of course, these are not identical, but they are likely close in real world use cases.

2) Allowing only one message over a multi-second interval.  For example, one message every 10 seconds.

Do you know which one of those use cases customers are asking about?
Comment 6 Rick Wagner 2014-02-05 14:10:44 EST

Case 1019469-- closed, they decided they wanted to go about it a different way.  The original request was for 2 messages per minute.  
<throttling maxRequests="2" timePeriod="60000"/>

Case 1035302-- have referenced this BZ.  They haven't said which use case is of interest to them.  I'll ask, will report back when they reply.

Comment 7 Keith Babo 2014-02-05 14:12:38 EST
One thing to keep in mind there is that depending on the type and configuration of the client, the client could timeout with a 60-second window.  This may be perfectly acceptable to the user as they expect the client to resubmit at some point, but wanted to point it out.
Comment 8 Anton Giertli 2014-02-06 03:09:12 EST
Hi Keith,

forwarding customer's reply:

"I think it eventually would be better to available both.
But use case 2 is more important than 1 as I see it."

Comment 9 Anton Giertli 2014-02-10 03:40:50 EST
Hi Keith,

do you have any update on the status of this issue ?

Comment 10 Rick Wagner 2014-02-27 12:33:55 EST
Removing this BZ from the dependencies list for the current Roll up.

Analysis shows this fix will not be one we can quickly implement.  Please look for other ways to deal with this deficiency, we currently can offer no ETA on a solution.

Comment 11 JBoss JIRA Server 2014-06-16 19:48:05 EDT
Keith Babo <kbabo@redhat.com> updated the status of jira SWITCHYARD-1718 to Closed
Comment 13 Rick Wagner 2014-06-25 13:49:39 EDT
Moving this Bug from Roll up 2 to Roll up 3 of 2014.  It's known to be difficult to fully implement, if not ready by RU3 consider marking it 'Won't fix'.
Comment 14 Rob Cernich 2014-08-29 18:06:54 EDT
This issue was only partially fixed, so moving back to assigned.  To summarize, the configured value is used at runtime, but applied after the creation of the internal bus route, which means the default value is used anyway.
Comment 15 Rob Cernich 2014-09-25 13:33:20 EDT
changes have been pushed to 1.x branch and should be available p8 or later.
Comment 18 Tomas Rohovsky 2015-02-17 14:03:10 EST
I've just tested that with a test from our testsuite and it works like a charm. Good job Keith.

Note You need to log in before you can comment on or make changes to this bug.