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.
Keith Babo <kbabo> made a comment on jira SWITCHYARD-1718 pushed
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: https://github.com/jboss-switchyard/core/blob/master/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployment.java#L599 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.
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). Thanks, Rick
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?
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. Rick
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.
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." Anton.
Hi Keith, do you have any update on the status of this issue ? Thanks, Anton.
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. Rick
Keith Babo <kbabo> updated the status of jira SWITCHYARD-1718 to Closed
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'.
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.
changes have been pushed to 1.x branch and should be available p8 or later.
I've just tested that with a test from our testsuite and it works like a charm. Good job Keith.