Java Thread отстает / долго спит на Ubuntu / Jetty - PullRequest
Новая
       29

Java Thread отстает / долго спит на Ubuntu / Jetty

0 голосов
/ 28 декабря 2010

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

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? Я запускаю его как root. Есть ли какие-то настройки в Ubuntu, которые я могу изменить, чтобы заставить ожидающие потоки ослабевать, как они должны? Pls. помогите, я полностью потерялся здесь.

спасибо

1 Ответ

0 голосов
/ 28 декабря 2010

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

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

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

...