Chunked encoding doesn't always flush the terminating 0

FYI, this seems to be reproducilble about 60-70% of the time. Occasionally the test succeeds, so you may need to run it a few times to trigger the bug.

Also, I tried this with the latest code in SVN, and the test still fails.

What version of HttpClient are you using?
Your code does not appear to match any version I can find.

I have the code running, but I am not getting any failures at all.

I have attached the code as I have modified it.

Can you give me an exact list of jars and versions that you are using

The test was written with the 3.0 version of HttpClient – the production code (seeing the same problem) is with the 4.0 NIO-based codebase.

I'll grab your code and see if I can repro the problem with it.

My test fails, your test works – I'm digging into why there's a difference. Hopefully I can give you a fully-formed test case as a result.

OK – when I run your test code repeatedly, it fails for me about as often as my own test. Any chance there is some difference between windows & linux that makes the difference?

I'll try to repro this on linux as well.

The test doesn't fail on linux but fails reliably on windows – any chance you get try it out on windows?

Any chance that you can get a tcpdump of the failure.

I have windows now in vmware.... but it will take me a little while to get a java dev env setup within that

Here's a data dump from CommView (ethereal doesn't support loopback captures).

ASCII version of the dump.

Simplified

I have attached a simplified test that I have run on my vmware windows XP system without any problems.

looking at your dump now....

Thanks for your dumps.... but not enough detail. They do show the missing trailing 0, but
I need to see the actual packets

can you do the same but with a raw packet dump?

Can you try this jar with a bit of debug in it.

I'll give this a shot in the morning – didn't have time to get back to it today.

Can you test this against the SVN head.

I have made some changes to flushing (for JETTY-256) that might also fix this issue

What's in SVN head seems to make things worse, not better. Now I'm seeing non-chunked output not getting flushed.

My next step: roll back to your debug jar and try to give you the output from that, plus a real packet dump.

With the debug jar, I occasionally get this exception:

java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
	at java.util.HashMap$KeyIterator.next(HashMap.java:827)
	at java.util.AbstractCollection.addAll(AbstractCollection.java:305)
	at java.util.HashSet.<init>(HashSet.java:100)
	at org.mortbay.jetty.bio.SocketConnector.doStop(SocketConnector.java:152)
	at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
	at org.mortbay.jetty.Server.doStop(Server.java:239)
	at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)

OOOOOOOOOOOOOooooooooooooooooooooooohhhhhhhhhhhhhhhhhhhhhhhh!!!!!

This test is using the SocketConnector rather than the SelectChannelConnector!!!!!

Can you try the SelectChannelConnector and see if you get the same issues.

I will check the SocketConnector.

I think I can see the failure mode for the loss of the end of the chunk. If you have a situation where two calls
to HttpGenerator.flush() are needed to complete a response (due to buffer size or similar), then you may block in
the read for the next request BEFORE everything is flushed.

I am trying to make writing a while loop to avoid this

I have committed a possible fix

Applying r1694 to the 6.1.1 sources (offset -1 lines) fixed this issue for us, with apache-2.2.4 in a reverse-proxy, load-balancing configuration. We were seeing large SOAP responses from Axis introduce a regular 30 second pause. Viewing the tcpdump between the two indicated this chunked-encoding termination issue. After 30 seconds of idle, FIN,ACK on the connection was forced, and apache flushed out the front.

We originally tried the svn 6.1-SNAPSHOT jars, but they were very unstable, introducing random pauses throughout our SOAP API test; I suspect synchronization issues. Unfortunately, I'm not at liberty to disclose the test or wire/content details of those problems. Frankly, we immediately reverted and patched the 6.1.1 sources instead.