StatusesSampleEndpoint example fails to connect with 503 about hbc HOT 9 CLOSED

Thanks for the bug report. Does this fail 100% of the time for you with HBC? And work 100% of the time for you with curl?

from hbc.

Yes.

from hbc.

Please make your your tokens don't have weird whitespace characters like "\r" or "\n". Fix incoming

from hbc.

@apurtell: how are you running this example? We have a theory that it has something to do with certain ascii characters not encoding properly.

Also, do you know what version of commons-codec are you using?

from hbc.

No doubt I may be doing something dumb.

JDK/JRE is 1.6.

java version "1.6.0_43"
Java(TM) SE Runtime Environment (build 1.6.0_43-b01)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)

commons-codec is

[INFO] |  |  +- commons-codec:commons-codec:jar:1.4:compile

The full dependency tree is long because I'm pulling in hadoop-common, hbase-client, etc. commons-codec comes in as a dep of hadoop-common. Let me know if that would be useful.

This is how I'm using HBC:

  BlockingQueue<String> queue = new LinkedBlockingQueue<String>(10000);
  StatusesSampleEndpoint endpoint = new StatusesSampleEndpoint();
  endpoint.stallWarnings(false);
  BasicClient client = new ClientBuilder()
    .name("ExampleApplication")
    .hosts(com.twitter.hbc.core.Constants.STREAM_HOST)
    .endpoint(endpoint)
.authentication(new OAuth1(consumerKey, consumerSecret, accessToken, accessTokenSecret))
    .processor(new StringDelimitedProcessor(queue))
    .build();
  client.connect();
  try {
    while (!client.isDone()) {
      String tweet = queue.poll();
      // stuff that stores the tweet to HBase
}
  } finally {
    client.stop();
  }

consumerKey, consumerSecret, accessToken, accessTokenSecret are all hardcoded constant Strings, cut and pasted from the application oauth settings from dev.twitter.com/apps. I know that's bad hygiene but want to keep this as simple as possible at first. I've double checked there are not whitespace characters within.

from hbc.

aha! The problem is probably this:

[INFO] |  |  +- commons-codec:commons-codec:jar:1.4:compile

So there was a change from commons-codec 1.4 to 1.5 in which in 1.4, a \r\n would be inserted after every Base64.encodeBase64String() call. We currently rely on the functionality that 1.5+ provides. If you use commons-codec version 1.5 or higher, this problem should go away.

We'll roll out a long term fix soon.

from hbc.

Excellent, let me make that explicit and give it a go.

from hbc.

Thanks, commons-codec was the problem indeed.

from hbc.

Fixed some joauth issues to help here:
twitter/joauth#4
twitter/joauth#5
twitter/joauth#6

from hbc.