역방향 아약스 기반 웹용 Ubunu의 Jetty 6에서 Java 웹 서버를 실행 중입니다. 그리고 브라우저에 데이터를 다시 보내는 지연되는 스레드에 심각한 문제가 있습니다. 매우 자주 스레드가 오랫동안 잠을 자도록 시작합니다. 1 초 이상, 경우에 따라 수 시간이 걸릴 수도 있습니다. 처음에는 Ajax 라이브러리 (DWR)의 버그라고 생각했는데, 이는 Java 버그라는 것보다 부두 문제라는 것보다는 모든 의심이 잘못된 것 같습니다. 이 문제를 해결하기 위해 몇 주가 걸렸습니다. 나는 completly 길을 잃었다. 내가 시도하지 않은 유일한 생각은 윈도우 같은 다른 OS에서 실행하는 것입니다. 여기에 일반적으로 지연 스레드의 스택 트레이스입니다 :Java Thread lags/long 우분투/Jetty에서 잠김
Cancelled at this stacktrace: at java.lang.Object.wait(Native Method)
at org.mortbay.io.nio.SelectChannelEndPoint.blockWritable(SelectChannelEndPoint.java:279)
at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:544)
at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:571)
at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:997)
at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:648)
at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:579)
at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109)
at org.mortbay.jetty.AbstractGenerator$OutputWriter.write(AbstractGenerator.java:903)
at org.mortbay.jetty.AbstractGenerator$OutputWriter.write(AbstractGenerator.java:752)
at org.mortbay.jetty.AbstractGenerator$OutputWriter.write(AbstractGenerator.java:741)
at java.io.PrintWriter.write(PrintWriter.java:412)
at java.io.PrintWriter.write(PrintWriter.java:429)
at java.io.PrintWriter.print(PrintWriter.java:559)
at java.io.PrintWriter.println(PrintWriter.java:695)
at org.directwebremoting.dwrp.PlainScriptConduit.addScript(PlainScriptConduit.java:93)
at org.directwebremoting.impl.DefaultScriptSession.addScript(DefaultScriptSession.java:239)
at server.comunication.dwr.OneReverseDWRServer.sendLocalBuffer(OneReverseDWRServer.java:385)
at server.comunication.dwr.OneReverseDWRServer.sendMessageLocal(OneReverseDWRServer.java:363)
at server.comunication.dwr.OneReverseDWRServer.sendMessage(OneReverseDWRServer.java:412)
at server.comunication.messaging.SendTask.call(SendTask.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
내가 다른 부두 연결 선택기를 시도하는 경우는, 스택 트레이스는 달랐다하지만 일부 유사한 장소에서 기다리고 있었다. 나는 Jetty와 Java의 많은 조합을 시도했다. 나는 그것이 NIO 버그일지도 모른다고 생각했지만 셀렉터를 non-nio로 변경했을 때 다른 장소에 쌓여있었습니다.
Linux에서 문제가 될 수 있습니까? 나는 그것을 루트로 실행하고있다. 우분투에서 대기 스레드를 강제로 강제로 약화시킬 수있는 설정이 있습니까? Pls. 도와주세요, 나는 완전히 여기에서 길을 잃는다.
감사
안녕하세요, 답변 주셔서 감사합니다. 그러나 분명히 DWR의 버그는 아닙니다. DWR의 주요 개발자 두 명과 함께 썼습니다. DWR의 버그는 아니지만 Jetty 일 것입니다.하지만 Jetty의 모든 versiond를 시험해 보았습니다. 버그는 모두 동일하며 Jetty 포럼에서 아무런 답변도 얻지 못했습니다. . 문제는 Jetty가 연속적인 Machanism 덕택에 스레드가 일정한 수의 연결에서 수천 개의 연결을 처리 할 수 있다는 것입니다. 다른 웹 컨테이너는 연결 모델 당 스레드를 사용합니다. 그 버그를 검색하여 리눅스에서 NIO와 JAVA 6의 문제점. 하지만 해결책은 없습니다. –