{"action":"created","issue":{"url":"https://api.github.com/repos/Particular/NServiceBus/issues/2859","labels_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2859/labels{/name}","comments_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2859/comments","events_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2859/events","html_url":"https://github.com/Particular/NServiceBus/issues/2859","id":105182357,"number":2859,"title":"Remove support for message throughput throttling","user":{"login":"andreasohlund","id":125028,"avatar_url":"https://avatars.githubusercontent.com/u/125028?v=3","gravatar_id":"","url":"https://api.github.com/users/andreasohlund","html_url":"https://github.com/andreasohlund","followers_url":"https://api.github.com/users/andreasohlund/followers","following_url":"https://api.github.com/users/andreasohlund/following{/other_user}","gists_url":"https://api.github.com/users/andreasohlund/gists{/gist_id}","starred_url":"https://api.github.com/users/andreasohlund/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andreasohlund/subscriptions","organizations_url":"https://api.github.com/users/andreasohlund/orgs","repos_url":"https://api.github.com/users/andreasohlund/repos","events_url":"https://api.github.com/users/andreasohlund/events{/privacy}","received_events_url":"https://api.github.com/users/andreasohlund/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-09-07T09:33:53Z","updated_at":"2015-11-10T12:42:39Z","closed_at":null,"body":"### Background\r\n\r\nWe added throttling in v4 due to a license model that allowed users to buy a throttled down version. We used to throttle to 1 msg/s if no license was found but that limit was removed in v4.5 due to a bad implementation. The issue was that if you requested throughput throttling we also limited concurrency to 1 which caused issues if handlers had long execution time. This license limit sort of was converted to a \"feature\"\r\n\r\n### Problems\r\n\r\nImplementing this on the core/transport level is tricky since we need to have a generic enough solution that is good enough and safe for all use cases. \r\n\r\n\r\n#### Need to take concurrency into account\r\n\r\nv5 is doing the throttling inside the pipeline by keepinging track of the number of \"pipelines\" that have completed per second. And when going past that we don't allow more pipelines to start for that second. The problem here is that the transport is still pushing messages when this happens and if the endpoint is transactional the \"commit\" will be delayed until the message in flight is allowed to complete. This can turn into issues with transaction timeouts if you don't also tune the concurrency appropriately. So to do this properly we need to start passing the throughput limit to the transport to allow it to optimize. This makes the transports more complex. Most of the time its really on the users who can find the right balance btw concurrency and throughput limits based on their scenario. \r\n\r\nWhich leads us to the next problem.\r\n\r\n#### It's not suitable for real world use cases\r\n\r\nIf you lookt at eg. gihub they rate limit on messages per hour,  https://developer.github.com/v3/rate_limit/, so our api is useless here since you can't really use a msg/s limit to mimic this efficiently. The fix here would be to make the \"period\" configurable. This would make the api even more complex and we also have to decide what periods to support since we store the actual values inmemory and longer periods means that endpoint restarts/crashes would mean we loose track of state and thereby not honoring the setting. Making this durable would also complicate things further.\r\n\r\n#### It's endpoint wide\r\n\r\nYes we can always guide users to use separate endpoints for all msg types but if they go with a single endpoint per integration thottling the entire endpoint isn't suitable. We are actually exposed to this our self since out own GH integration endpoint is doing a send local for incoming webhooks. So we'd want that to be unlimited while outgoing ones should be rate limited. This means that if not all messages handled should be throttled our api isn't good enough. Adding that would further complicate it.\r\n\r\nThis would be better handled by a sample showing the users how to inject their \"rate limiter\" into selected handlers to get the exact scope they want.\r\n\r\n\r\n### Examples of others doing this\r\n\r\nThe only one I could find was a contrib module for akka.net using a timer http://doc.akka.io/docs/akka/snapshot/contrib/throttle.html\r\n\r\n\r\n### Proposal\r\n\r\n* Deprecate msg/s throttling as of v6\r\n* Update doco with above mentioned caveats\r\n* Provide samples, docs on how to do throttling based on real life scenarios ( I propose the github rate limit)"},"comment":{"url":"https://api.github.com/repos/Particular/NServiceBus/issues/comments/155410330","html_url":"https://github.com/Particular/NServiceBus/issues/2859#issuecomment-155410330","issue_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2859","id":155410330,"user":{"login":"danielmarbach","id":174258,"avatar_url":"https://avatars.githubusercontent.com/u/174258?v=3","gravatar_id":"","url":"https://api.github.com/users/danielmarbach","html_url":"https://github.com/danielmarbach","followers_url":"https://api.github.com/users/danielmarbach/followers","following_url":"https://api.github.com/users/danielmarbach/following{/other_user}","gists_url":"https://api.github.com/users/danielmarbach/gists{/gist_id}","starred_url":"https://api.github.com/users/danielmarbach/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danielmarbach/subscriptions","organizations_url":"https://api.github.com/users/danielmarbach/orgs","repos_url":"https://api.github.com/users/danielmarbach/repos","events_url":"https://api.github.com/users/danielmarbach/events{/privacy}","received_events_url":"https://api.github.com/users/danielmarbach/received_events","type":"User","site_admin":false},"created_at":"2015-11-10T12:42:39Z","updated_at":"2015-11-10T12:42:39Z","body":"@ramonsmits we didn't remove it. You can still control the concurrency "}}