Incomplete padding messages are propagated to message Function<String> with long-polling

[slovdahl]

We're getting some unexpected messages passed down to the message function. And also the padding seems to be one character too long (see the inline comment). In my debugging it looked like it could be caused by chunking, because the method would be invoked twice, first with a string with e.g. 1779 whitespace characters and immediately after that with 270 whitespace characters (1779 + 270 = 2049).

AtmosphereClient client = ClientFactory.getDefault().newClient(AtmosphereClient.class);
AtmosphereRequestBuilder requestBuilder = client.newRequestBuilder();
requestBuilder.transport(Request.TRANSPORT.LONG_POLLING);
requestBuilder.enableProtocol(true);
requestBuilder.trackMessageLength(true);
requestBuilder.trackMessageLengthDelimiter("|");

// The default in org.atmosphere.interceptor.PaddingAtmosphereInterceptor is 2048, but
// for some reason, it's 2049 characters of padding when wasync receives it. Maybe the
// newline character in the end of the line is counted?
requestBuilder.paddingSize(2049);

Socket socket = client.create();
socket.on(Event.MESSAGE, new Function<String>() {
    @Override
    public void on(String message) {
        // Sometimes a message with only spaces is empty is received here. 
    }
});

Seems like this is reproducible in an existing test (that's disabled) too: org.atmosphere.tests.LongPollingTest#noMessageLostTest. Enable the test and add a breakpoint on the assertEquals(response.get().size(), 5) line and check what the messages in the set looks like. Even easier seen by changing the type of response to AtomicReference<List> to retain the order of messages.

Nothing critical, it's easy to handle in the message function itself, but just wanted to log an issue for it in case others are seeing the same problem.