-
Notifications
You must be signed in to change notification settings - Fork 3
Description
The implementation or readThrottling and writeThrottling makes no sense. Each read/write blocks the whole queue from executing further tasks, which includes other read/write tasks for other items that would also have different throttling values. Also the throttling of all endpoints will sum up that way, so if you have three endpoinds, each throttled by 2 seconds, it will take 10 seconds until the first endpoint is read again. Finally, blocking threads is never a good implementation, threads are a scare resource, even if you can have many of them.
Better implementation: Remember when a read/write has last been performed (System.currentTimeMillis()) and within a periodic timer method (e.g. execute that is called once per second) check if more than the throttle value has passed and if yes, then perform the call, otherwise keep waiting. That way throttling can only be accurate to the second but that is okay.
Actually I'd kick both options, throttling write requests seems pointless to me to begin with. What would that be good for? In scripts throttling can be done by the script and in UI, if I change a value three times in a row, I want all three changes to happen ASAP. I'd rename the option to "pollInterval", it is in seconds (not ms)), and only throttle the polling of the current value using the method described above.