This issue crops up when using Apache 2.2 (and possibly 2.0 with mod_jk), and is due to the Apache config variable ProxyIOBufferSize (for 2.2, not sure what it's called in mod_jk) having an undefined size.

By adding "ProxyIOBufferSize 8192" to the vhost connected to the Confluence instance this problem goes away.

This has to do with how transfers between the Apache and Tomcat instance gets chunked up and buffer use, and fixes similar problems in other projects I work on, too, such as OpenNMS with an Apache front.

Untill Apache 2.2.14-ish "ProxyIOBufferSize 16384" would also work for more efficient transfers, but recent doc changes at apache.org vaguely states it has to be set to 8192 or less. The default is stated as being 8192, but does not work, explicityly defining it fixes the problem.

mvh,
A

Closing things we don't have time for anyway.

Reduced priority from Critial to Minor (it doesn't seem to be a blocker anymore?).

Set to 'Unassigned' – it can go back into the 'big queue of stuff' and isn't important enough to warrant attention over the next couple of weeks (given James being away, and stability problems on EAC and CAC).

I still would like to see some progress here in terms of figuring out if we should document this properly, e.g. in our upgrade notes, or general notes.

Glenn, what do we do with this issue now? I want to get rid of it, but atm it serves as a reminder that we should still document this on our knowledge-base. The same applies to http://jira.atlassian.com/browse/CONF-16739 and to http://jira.atlassian.com/browse/CONF-16741

Not sure how to proceed here. Glenn, will IT take care of this issue, and also write the documentation?

Just some follow up to those watching this issue. I can reproduce this problem using the stock apache shipped with RHEL5 using mod_proxy_ajp.

Unable to replicate using EAC once changes to the infrastructure were made.

Given it only seems to occur with a very specific set of variables, we should proceed as Dave has written. Upgrading atlassian10 to rhel5 has other benefits as well.

We should also advise customers to upgrade to the latest version of Apache if they are using ajp.

After investigation, this appears to be an unfortunate confluence (no
pun intended) of bugs

When SSL, mod_proxy_ajp and apache 2.2.8 are combined on atlassian10,
I can reliably reproduce the error. If I change any one of these
factors the problem goes away.

The problem with the hand compiled apache 2.2.8 atl10 has been known
for some time. https://extranet.atlassian.com/jira/browse/ADM-4614.
Nobody knows why it has a custom version, and even Contegix, who did
the installation, have lost the source for that RPM. This means this
apache instance is out of line for security updates and patches from
redhat.

A very similar configuration exists on CAC, mod_proxy_ajp + apache.
However SSL is not enforced, and the apache is the current mainline
apache 2.2.3 from redhat*

In Coho, a similar configuration exists, using mod_proxy_http, apache
(2.2.3) and ssl, again unaffected.

Conversely, Jed was able to reproduce results which I think are
similar enough to be the same underlying cause, using an apache
shipped with OS X (2.2 series), no SSL and mod_proxy_ajp.

I'm pretty sure that this is not a problem in the confluence code
base, and as such, should be resolved as a problem local to our
peculiar instance.

My recommendation is:

• Switch to mod_proxy_http on atl10 to resolve the situation right
  now. This has already been done and tested using https://node1.extranet.atlassian.com/
• We are currently not clustered, but this can be done easily with
  mod_proxy_balancer.
• Resolve https://extranet.atlassian.com/jira/browse/ADM-4614 and https://extranet.atlassian.com/jira/browse/ADM-4615
• Move back to mod_proxy_ajp if necessary once we are on a known good
  working version of apache.

• Note, the listed version may be 2.2.3, but it is heavily patched
  with updates.