[Isomorphic]

Hi bbruyn,

Just to clarify - you're saying you're only experiencing this issue with an intervening lighttpd?

If so, try setting the very large flushBufferSize (129000) suggested toward the beginning of this thread. If buffering is the issue, this will make it work, then you can either disable buffering or lower the flushBufferSize until you find the minimum.

As another poster noted, if compression is enabled on the lighttpd instance it may be willing to buffer to a much larger number, so for that, use Firebug to check the http response headers for a normal request (say, an .html file) to see if compression is on (you are looking for Content-Encoding: gzip in the response headers). If it is, you'll need to check lighttpd's docs for how to turn it off (just for the messaging servlet, or for the whole site - up to you).

[bbruyn]

We see the same behavior with either a lighttpd server or the F5 out front.

We had the Isomorphic compression filter enabled, but again, that doesn't seem to cause a problem when going to the app server directly. Disabled it to see if that would somehow have some effect but it did not. Compression does not seem to be turned on in lighttpd (I have not checked the F5).

We actually have tried the 129k limit with no change... We had not tried to go higher, as anything bigger than that seems fairly ridiculous. Question though: I shouldn't necessarily see the flushBuffer property in the response, right? In a normal response (i.e., going straight to Tomcat on 8080) I see:

<SCRIPT>
parent.isc.Messaging._connectCallback('isc_HiddenFrame_4', {keepaliveInterval: 3000,connectionTTL: 120000,connectTimeout: 10000,keepaliveReestablishDelay: 1000});

Thanks for your help, as always.

[Isomorphic]

Just to be sure about compression, we'd recommend looking with Firebug at the HTTP response headers.

As far as verifying flushBufferSize has been set properly, what you'll see is that the response is much larger because it's being padded out.

This is visible in Firebug's Net panel, which you can also look at to see if data is being delivered at all. If it sits there at 0 bytes, then the data is never leaving the server. You can contrast this with what you see in the public Showcase.

[bbruyn]

Sorry, I guess I could have been clearer before:

Just to be sure about compression, we'd recommend looking with Firebug at the HTTP response headers.

Sure, done that.

As far as verifying flushBufferSize has been set properly, what you'll see is that the response is much larger because it's being padded out.

This is visible in Firebug's Net panel, which you can also look at to see if data is being delivered at all. If it sits there at 0 bytes, then the data is never leaving the server. You can contrast this with what you see in the public Showcase.

Right, I am using Firebug. The 0 bytes symptom is what I was trying to describe. I have another idea, looking into it shortly.

[Isomorphic]

Another thing that could cause the data to never leave the server would be any servlet Filter you may have installed, if it introduced a BufferedOutputStream. You might have something like a Spring Security-related filter?

[bbruyn]

That was a really good guess, but I'm also able to reproduce with a trimmed up StockQuotes example. No, it must be some other setting. Will keep digging.

[bbruyn]

Just to close the loop, we seem to have had a different problem on each environment.

Compression was indeed the culprit on the F5.

The lighttpd server apparently has a problem with chunking the proxied response to POST requests (http://redmine.lighttpd.net/boards/3/topics/81). We have not yet patched that server to see whether it helps, but suspect that it will.

[Isomorphic]

Great to hear that you got to the bottom of it - thanks for letting us know.