This is pretty serious. I have been testing against java 8 (1.8.0_45), but not seen this; maybe I've not been using java 8 as the client in the functional test suite.
Looking at the comments there, especially stackoverflow, it's re-use of an existing httpconnection that's the problem, or changing HTTP request headers while the connection has already started [ http://stackoverflow.com/questions/5368535/java-httpurlconnection-issues-with-illegalstateargument-already-connected]
Looking at the code chain for the registry GET operation, we aren't doing that in our code. Our AM webapp is set to redirect to the RM proxy if it gets a direct GET request -but at the same time, it should be GETs everywhere.
I recall we encountered something like this before using Jersey to do the REST client, where we were trying to do some security/rest work dealing with RM Redirects that were also doing some HTTPS/HTTP conversion (when we were trying to run the AM as HTTPS).
And looking at the code, I can see a possible code path where our code UrlConnectionOperations is trying to do some setup of the new HTTP connection (setting cache and redirect policy) after the security token has been set. Which doesn't look like a codepath to trigger the error string you are seeing in setRequestMethod].
I'll switch my IDE to using the Java 8 SDK (I bond it to java 7 to avoid accidentally using any Java 8 classes/methods); to see how the codepath looks there.
meanwhile, I have one question: is this a secure cluster?