先說一下具體的原因：
資料互動中，其中一方單獨認為業務互動失敗，邏輯**而非物理關閉復用的通道，另一方在完成業務操作時將業務資料再次推送到已經被邏輯**的通道上，會導致請求和相應錯位。
**層設計問題：
1. 通道一次業務互動中的多次訊息互動缺少唯一的會話碼，導致中間任何一次互動出現問題，後續的資料會錯位到後續復用此通道其他請求中。
2. 底層通道的**，異常處理，沒有在通道層直接處理，而是將錯誤通過業務堆疊拋到最外層ajp協議解析執行緒管理池去做，導致不論是業務捕獲異常或者是servlet,spring框架捕獲異常都會出現串號。
解決方法：
1. 在協議層增加會話碼，發現會話錯位，關閉通道。
2. 讓底層通道出現異常自己**和關閉通道，連線池獲取連線的時候判斷連線是否已經無效，無效即刻移除。（不需要用拋錯誤堆疊的方式來實現）
後續：top這邊已經在考慮非同步web request請求處理的方式，後續在安全的要求下可以和nginx 做類似通道復用的web伺服器+應用伺服器的模式。
詳細說明看下面的內容：
用兩張說明問題。
第一張是一次請求在jk和jboss-web之間的互動過程。
問題發生在第四步，在jboss-web向jk請求body的資料的時候可能產生超時或者其他io異常，這時候直接會走到9這步，由於異常**獲，連線將不會被物理關閉。
一次請求處理的呼叫順序如上，按照數字順序，當在5出現問題的時候，ajpaprprocessor沒有自己物理關閉，而是依賴異常上拋的方式，返回到ajpaprprotocal來關閉ajpaprprocessor。簡單來做就只需要在5就地處理，關閉連線，雖然會被放入連線池，但是只要在2這個步驟使用連線池的時候檢查一下連線狀態就可以丟棄這些無效的連線。
JBOSS內容錯亂的分析過程
解決 這個簡單了，如果你覺得公升級或降級其它版本都有風險，直接在上面的catch的最後加上return.然後編譯替換原來的jar就行了。附註 這個bug在jboss4.0.5中沒有產生，4.0.5中使用的tomcat5.5，parameters.processparameters formdata,...
mod jk 配置與tomcat整合負載平衡測試
5.在 apache conf 下新增乙個workers.properties檔案，內容如下 ps worker.list worker2,worker1,loadbalancer worker.worker1.port 8019 worker.worker1.host localhost tomc...
JDK6與JBoss的web service的問題
最近寫了簡單的web service,用的最簡單的annotation的方式，然後部署到jboss5上去。後來發現如果我用eclipse生成的web service client去執行這個web service,在jboss端會出現以下異常 後來才知道是jdk6的問題，因為我的jboss是用jdk6...