Message delimiter is added several times if message payload exceeds 8192 when using jersey

[xenster86]

Found an interesting issue.
Jersey uses BufferedWriter behind the scenes to write the message. If message payload exceeds 8192 (which is default defaultCharBufferSize in BufferedWriter) then postPayload in MessageLengthInterceptor is invoked several times for each 8192 bytes of the message. As result separator is added several times in the middle of message.

[xenster86]

The problem is in com.sun.jersey.core.util.ReaderWriter#writeToAsString. Even if you override BUFFER_SIZE using system property, it will still use default buffer size in writeToAsString method. Need to override the whole class in the classpath...

[jfarcand]

I think the issue is in the interceptor itself, e.g a property needs to be added that check the size of the chunk and buffer it until Jersey send a smaller chunk. I will investigate...

[xenster86]

I will try to remove MessageLengthInterceptor and manually add the delimiter at message level

[xenster86]

So, the following workaround works:
broadcaster.broadcast(content + messageDelimiter)

[jfarcand]

Just to make sure, try with the TrackMessageLengthInterceptor (not the MessageLengthInterceptor). Also the workaround will work as well using the TrackMessageLengthFilter. Thanks!

[jfarcand]

Documented: https://github.com/Atmosphere/atmosphere/wiki/Multiple-messages-arrive-as-single-response-body-or-message-received-are-incomplete A custon interceptor can always be created to buffer the response, but it is recommended to use the BroadcastFilter instead.

[bcopy]

Hello Jean-Francois,

I'm afraid http://goo.gl/T1yeq now points to a non-existent page (github shows a "CREATE NEW PAGE" dialog) - can you restore that link so we can give a it a try ?

[profes]

Hi,
In my case the problem was not caused by Jersey's 8192 buffer size. I tried to set it to 32K and 64K and it still was splitting my messages to 8K frames.
I fixed the problem by copying com.sun.jersey.core.util.ReaderWriter and putting it first on the class path.
My ReaderWrited class had a modified writeToAsString(String s, OutputStream out, MediaType type) method, that doesn't use BufferedWriter and OutuputStreamWriter. The latter one falls back to sun.nio.cs.StreamEncoder which has DEFAULT_BYTE_BUFFER_SIZE = 8192, which can't be overridden at all.

Before the change:
com.sun.jersey.core.util.ReaderWriter
public static final void writeToAsString(String s, OutputStream out,
MediaType type) throws IOException {
Writer osw = new BufferedWriter(new OutputStreamWriter(out,
getCharset(type)));
osw.write(s);
osw.flush();
}

After the change:
com.sun.jersey.core.util.ReaderWriter
public static final void writeToAsString(String s, OutputStream out,
MediaType type) throws IOException {
out.write(s.getBytes(getCharset(type)));
out.flush();
}
https://gist.github.com/profes/8645032

I hope that saves you hours of debugging and wondering why all messages above 8K length are chunked.

[bcopy]

profes : Has your fix been filed as an issue against JERSEY ?