Glassfish 4.0应用启动/登录/登出时出现Broken Pipe异常求助

Hey there, let's break down this annoying Broken Pipe and Connection closed issue you're seeing in your app. These errors are super common in web apps, especially with stacks like yours—let's dig into why they happen and how to fix them.

异常原因分析 #

First, let's get clear on what these errors actually mean:

• java.io.IOException: Broken Pipe: This pops up when GlassFish tries to send data to a client socket that's already been closed. The client (like a user's browser) might have disconnected early—maybe they closed the tab before the page finished loading, lost network, or hit refresh mid-request.
• org.glassfish.grizzly.asyncqueue.TaskQueue.onClose: This ties to GlassFish's Grizzly web server handling async tasks. If a connection drops while Grizzly is still processing a task for it, this error gets thrown.

Specific to your tech stack, here are the most likely triggers:

1. Client-side premature disconnections: Slow page loads (from unoptimized Hibernate queries, heavy JSF components) make users impatient, leading them to refresh/close the page before the server finishes responding.
2. GlassFish connection timeout misconfiguration: Too-short connection/read timeouts or misconfigured Grizzly async queues can cause the server to close connections while requests are still in flight.
3. JSF view state overhead: If you're using client-side state saving (default in some JSF setups), large view state payloads increase the chance of a disconnect mid-transmission.

解决办法 #

Let's go through actionable fixes, ordered by impact:

1. Cut the root cause: Optimize app performance #

The best way to reduce these errors is to make your app respond faster so users don't have reason to disconnect early:

• Optimize Hibernate queries: Fix N+1 fetch issues with fetch join, add second-level caching for frequently accessed data, and avoid over-fetching unnecessary entity fields.
• Optimize JSF views: Compress CSS/JS resources, use lazy loading for non-critical components (like <o:lazyLoad> if using OmniFaces), and split heavy pages into smaller, faster-loading segments.

2. Configure GlassFish to handle these exceptions gracefully #

These errors are non-fatal (they don't crash your app), so we can stop them from cluttering your logs:

• Adjust Grizzly settings: Edit your GlassFish domain.xml and add the following property to your <network-listener> section to suppress broken pipe warnings:

  <property name="org.glassfish.grizzly.io.OutputBuffer.allowBrokenPipe" value="true"/>
  

• Tweak log levels: Modify glassfish/domains/domain1/config/logging.properties to lower the verbosity of the problematic packages:

  sun.nio.ch.level=WARNING
  org.glassfish.grizzly.level=WARNING
  

  This will stop the endless stream of broken pipe logs without hiding actual critical errors.

3. Adjust GlassFish connection timeouts #

Make sure the server isn't closing connections too early:

• Open the GlassFish Admin Console, navigate to Configurations > [your config] > HTTP Service > HTTP Listeners > [your listener].
• Increase values for Connection Timeout and Read Timeout (start with 30-60 seconds if they're set much lower). This gives slower clients more time to complete requests.

4. Optimize JSF view state handling #

If you're using client-side state saving, consider switching to server-side to reduce payload size:

• Add this to your faces-config.xml:

  <application>
    <state-saving-method>server</state-saving-method>
  </application>
  

  Server-side state is stored on the GlassFish server, so less data is sent over the wire, lowering the chance of disconnects during transmission.

Final Note #

Keep in mind: You can't eliminate these errors entirely—users will always close tabs mid-request or lose network. But with the above steps, you can drastically reduce their frequency and stop them from cluttering your logs, so you can focus on actual critical issues.

内容的提问来源于stack exchange，提问作者Gustavo de Freitas