This should be 'fixed' in the SVN trunk, and will appear in 5.5.17.

The message itself is harmless (except for the disk space it takes up in the 
log), but it suggests a problem with your mod_jk configuration (so WARNING is 
an appropriate level).  If you continue to have problems, follow up on 
users@tomcat for possible ways to resolve this.

Yep, I get it also:tomcat-5.0.29

Jun 24, 2006 6:57:45 PM org.apache.jk.core.MsgContext action
WARNING: Error sending end packet
java.net.SocketException: Broken pipe
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
        at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:518)
        at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112)
        at org.apache.jk.core.MsgContext.action(MsgContext.java:293)
        at org.apache.coyote.Response.action(Response.java:182)
        at org.apache.coyote.Response.finish(Response.java:304)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:204)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
        at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
        at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
        at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)

# grep -ir mod_jk /opt/httpd-2.2.0/conf/*
# locate mod_jk

shows nothing.  Any hints on WHAT might be misconfigured?

This bug still occurs in Tomcat 5.5.17.  We are able to recreate the bug by
putting the server under heavy load and frequently clicking new links in the
navigation tree of our web application.

It seems as though Tomcat is not correctly handling connections to Apache that
are closed (due to end-user's browser aborting the connection).  It seems that
Tomcat is in the process of writing to the output stream when it is closed.

We are experiencing this now and then with Tomcat 5.5.20 and an application
called DivePort (part of the Dimensional Insight Inc. Diver Solution) on IBM AIX
5.3 with Apache 2.2.4 and mod_jk 1.2.19.

When it happens, the application stops responding (the requests reach Apache
HTTPd and are presumably reaching Apache Tomcat via mod_jk as well, but nothing
happens).

Requiring a restart of Tomcat -- when requesting one, one gets this in catalina.out:

---8<---
2007-jan-31 09:16:19 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 8 instance(s) to be deallocated
--->8---

...which seems to take an eternity, so using 'kill' on the Tomcat PID seems to
be needed.

The catalina.out log from the error appearing looks like:

--->8---
2007-jan-30 11:22:25 org.apache.jk.core.MsgContext action
WARNING: Error sending end packet
java.net.SocketException: Broken pipe
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java(Compiled Code))
        at java.net.SocketOutputStream.write(SocketOutputStream.java(Compiled Code))
        at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java(Inlined
Compiled Code))
        at
org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java(Compiled Code))
        at org.apache.jk.core.MsgContext.action(MsgContext.java(Compiled Code))
        at org.apache.coyote.Response.action(Response.java(Compiled Code))
        at org.apache.coyote.Response.finish(Response.java(Inlined Compiled Code))
        at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java(Compiled Code))
        at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java(Compiled Code))
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java(Compiled
Code))
        at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java(Compiled
Code))
        at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java(Compiled
Code))
        at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:570)
2007-jan-30 11:22:25 org.apache.jk.common.ChannelSocket processConnection
WARNING: processCallbacks status 2
--->8---

Best regards,
Björn

(In reply to comment #4)
> It seems as though Tomcat is not correctly handling connections to Apache that
> are closed (due to end-user's browser aborting the connection).  It seems that
> Tomcat is in the process of writing to the output stream when it is closed.

Tomcat correctly handles this situation and logs the message you see to tell you
what it has done. These messages are expected in the circumstances you describe.

(In reply to comment #5)
> ---8<---
> 2007-jan-31 09:16:19 org.apache.catalina.core.StandardWrapper unload
> INFO: Waiting for 8 instance(s) to be deallocated
> --->8---
> 
> ...which seems to take an eternity, so using 'kill' on the Tomcat PID seems to
> be needed.

This is indicative of an application issue. I have seen this when the request
processing gets into an infinite loop due to a coding error. The looping can
consume large amounts of CPU making Tomcat unresponsive.

I am marking this issue as fixed as per comment #1 since this is most
appropriate for the original issue.

Had the report in comment #5 been in a separate issue it would be resolved as
invalid.