Java Thread lags/long sleeps на Ubuntu/Jetty

Question

Я запускаю веб-сервер Java на Jetty 6 на Ubunu, для веб-сайтов, основанных на обратном аяксе. И у меня серьезные проблемы с задержкой потоков, которые пересылают данные в браузеры. Очень часто какой-то поток просто начинает спать в течение длительного времени. Как 1 с и более, иногда даже часы. Сначала я думал, что это ошибка библиотеки ajax (DWR), чем проблема Jetty, чем ошибка Java, но все подозрения, вероятно, неверны. Я потерял недели, пытаясь решить эту проблему. Я полностью потерян. Единственное, что я не пробовал, это запустить его на другой ОС, например, на окнах. Вот StackTrace нити, которые, как правило, запаздывает:

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) 

Когда я пробовал различные Selector подключения молы, трассировки стека отличается, но он ждет на некотором другом подобном месте. Я пробовал много версий комбинаций Jetty и Java. Я думал, что это может быть ошибка NIO, но когда я сменил селектор на non-nio, он был уложен на другое место.

Возможно, проблема в Linux? Я запускаю его как root. Есть ли какие-то настройки в ubuntu, которые я могу изменить, чтобы заставить ожидающие потоки ослаблять, как они должны? Pls. помогите, я полностью потерял здесь.

благодаря

Answer 1

Я не уверен, что я знаю, что обратный AJAX, но я предполагаю, что это то, где сервер отправляет запросы в браузере пользователя в браузере (в сущности) посылает периодические запросы задавать запросы ,

Я предполагаю, что происходит то, что браузер иногда не запрашивает запросы, и это приводит к тому, что потоки серверной стороны иногда застревают.

Это вряд ли будет ошибкой в ​​nio против non-nio, в версии Java, которую вы используете, в версии Jetty или Linux.

Это может быть ошибка в библиотеке DWR, которую вы используете, но также может быть просто неотъемлемой частью того, что вы делаете. Например, если пользователь закрывает окно браузера или панель, на которой запущена клиентская сторона ... или если есть сетевое нарушение ... тогда браузер может просто не выполнить запрос на запрос. Поток сервера затем потенциально застревает в ожидании клиента, который никогда не возвращается. Если это то, что происходит, тогда должно быть что-то, чтобы разблокировать потоки на стороне сервера. (Я бы подумал, что это ответственность DWR, но я не эксперт ...).