{"action":"created","issue":{"url":"https://api.github.com/repos/netty/netty/issues/4615","labels_url":"https://api.github.com/repos/netty/netty/issues/4615/labels{/name}","comments_url":"https://api.github.com/repos/netty/netty/issues/4615/comments","events_url":"https://api.github.com/repos/netty/netty/issues/4615/events","html_url":"https://github.com/netty/netty/issues/4615","id":123450878,"number":4615,"title":"Message size estimation issues","user":{"login":"technocoreai","id":206269,"avatar_url":"https://avatars.githubusercontent.com/u/206269?v=3","gravatar_id":"","url":"https://api.github.com/users/technocoreai","html_url":"https://github.com/technocoreai","followers_url":"https://api.github.com/users/technocoreai/followers","following_url":"https://api.github.com/users/technocoreai/following{/other_user}","gists_url":"https://api.github.com/users/technocoreai/gists{/gist_id}","starred_url":"https://api.github.com/users/technocoreai/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/technocoreai/subscriptions","organizations_url":"https://api.github.com/users/technocoreai/orgs","repos_url":"https://api.github.com/users/technocoreai/repos","events_url":"https://api.github.com/users/technocoreai/events{/privacy}","received_events_url":"https://api.github.com/users/technocoreai/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-12-22T10:00:24Z","updated_at":"2015-12-23T10:01:02Z","closed_at":null,"body":"#4380 introduced message size estimation for messages written outside the event loop. However, the implementation is problematic and leads to more problems than it solves. For example, our software uses writability checks to determine if it should start dropping events, and after updating to 4.0.33 we've got massive drops even though the TCP send buffer never goes above 10–20% of the configured `highWatermark` value.\r\n\r\nI see the following problems with the current solution:\r\n\r\n1. It pollutes *every single thread* writing to a Netty channel with a thread-local map used for caching message sizes. That's not very significant, since usually writes are done from a limited-size thread pool, but it's still not very tidy.\r\n2. It doesn't take into account JVM flags. We're running with `CompressedOOPS`, but every single reference is still counted as 8 bytes instead of 4. Again, insignificant, but pretty much doubles the size of most estimated classes.\r\n3. And, finally, the most important one: the message size estimations are **very** wrong. A basic `WriteAndFlushTask`, for example, is estimated as a whopping `1272` bytes for me, and most of it (`1192` bytes) is from the `ctx` variable which is shared between all outbound messages and so shouldn't be counted."},"comment":{"url":"https://api.github.com/repos/netty/netty/issues/comments/166852079","html_url":"https://github.com/netty/netty/issues/4615#issuecomment-166852079","issue_url":"https://api.github.com/repos/netty/netty/issues/4615","id":166852079,"user":{"login":"sirmax","id":868418,"avatar_url":"https://avatars.githubusercontent.com/u/868418?v=3","gravatar_id":"","url":"https://api.github.com/users/sirmax","html_url":"https://github.com/sirmax","followers_url":"https://api.github.com/users/sirmax/followers","following_url":"https://api.github.com/users/sirmax/following{/other_user}","gists_url":"https://api.github.com/users/sirmax/gists{/gist_id}","starred_url":"https://api.github.com/users/sirmax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sirmax/subscriptions","organizations_url":"https://api.github.com/users/sirmax/orgs","repos_url":"https://api.github.com/users/sirmax/repos","events_url":"https://api.github.com/users/sirmax/events{/privacy}","received_events_url":"https://api.github.com/users/sirmax/received_events","type":"User","site_admin":false},"created_at":"2015-12-23T10:01:02Z","updated_at":"2015-12-23T10:01:02Z","body":"@normanmaurer the point is #4380 does much more harm than good. I'd revert it, to start with, and then wait for a better PR.\r\n\r\nPersonally I think Netty shouldn't impose this kind of task size estimation at all. Netty _might_ provide ways to make it easier, but ultimately it should be up to the client code to use it or not. "}}