Thanks to reports from several developers, we have discovered that with a recent backend change, [node:2835] now misbehaves on Twitter4J.
Before deploying the change, our engineering teams did extensive testing against raw cURLs and our homegrown Hosebird Client (https://github.com/twitter/hbc) and we found no problems when conforming to established HTTP standards.
While we cannot conclude with 100% certainty at this time that the error lives with the Twitter4J library, we advise you to check your applications and code to make sure that you are not affected.
Some developers have reported that a temporary workaround is disabling gzip compression on Control Streams requests.
If you have anything to share on this matter, including any inquiries, please use this discussion thread.