Java Thread lags/lange schläft auf Ubuntu/Jetty

Question

Ich benutze Java Web Server auf Jetty 6 auf Ubunu, für Reverse-Ajax-basierte Web. Und ich habe ernsthafte Probleme mit verzögerten Threads, die Daten an Browser senden. Sehr oft fängt ein Thread erst lange an zu schlafen. Wie 1 Sekunde und mehr, manchmal sogar Stunden. Ich dachte zuerst, dass es Bug der Ajax-Bibliothek (DWR), als dass es Jetty Problem ist, als dass es Java-Bug ist, aber alle Vermutungen sind wahrscheinlich falsch. Ich habe Wochen verloren, um dieses Problem zu lösen. Ich bin komplett verloren. Der einzige Gedanke, den ich nicht versucht habe, ist, es auf einem anderen Betriebssystem wie Windows auszuführen. Hier ist die Stacktrace des Fadens in der Regel hinkt:

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) 

Wenn ich verschiedene Anlegesteg Verbindung Selector versucht, Stack-Trace war anders, aber es war auf einem ähnlichen Ort warten. Ich habe viele Versionen von Kombinationen von Jetty und Java ausprobiert. Ich dachte, es könnte ein NIO-Fehler sein, aber als ich den Selektor auf "Nicht-Nio" änderte, wurde er an anderer Stelle gestapelt.

Kann das Problem auf Linux sein? Ich führe es als root. Gibt es eine Einstellung in Ubuntu, die ich ändern kann, um wartende Threads zu schwächen, so wie sie sollten? Pls. Hilfe, ich bin hier völlig verloren.

dank

Answer 1

Ich bin nicht sicher, ich weiß, was Reverse AJAX ist, aber ich nehme an, es ist, wo der Server Anforderungen an den Browser des Benutzers durch den Browser (in der Tat) sendet regelmäßig Anfragen für Anfragen stellen Senden .

Ich stelle mir vor, dass der Browser gelegentlich Anfragen nicht anfordert, und dies verursacht, dass serverseitige Threads gelegentlich hängen bleiben.

Dies ist wahrscheinlich ein Fehler in nio versus non-nio, in der Version von Java, die Sie verwenden, in der Version von Jetty oder in Linux.

Es könnte sich um einen Fehler in der DWR-Bibliothek handeln, die Sie verwenden, aber es könnte auch in Ihrem Verhalten enthalten sein. Wenn der Benutzer beispielsweise das Browserfenster oder den Fensterbereich schließt, auf dem die Clientseite ausgeführt wird ... oder wenn eine Netzwerkstörung auftritt, kann der Browser die Anforderung für eine Anforderung einfach nicht ausführen. Der Server-Thread ist dann möglicherweise festgefahren und wartet auf einen Client, der niemals zurückkommt. Wenn dies der Fall ist, müssen die serverseitigen Threads entsperrt werden. (Ich hätte gedacht, dass DWR dafür verantwortlich ist, aber ich bin kein Experte ...).