Socket.read() нить висит между JBoss и ActiveMQ

Question

Учитывая

• Мои Java приложение является WAR развернут на JBoss (4.0.4GA)
• Издает и подписывается на ActiveMQ (5.6.0) экземпляр
• Java приложение использует Apache Camel (2.10.3) для всех интеграции (производства & потребляющего) с ActiveMQ
• JBoss и ActiveMQ на своих собственных (CentOS 5.6 Final) четырехъядерных виртуальных серверов, каждый виртуальный находится на другом физическом

У меня есть вопрос поточно-подвесного и я вижу следующее в моей нити отвале:

java.net.SocketInputStream.socketRead0(Native Method) 
java.net.SocketInputStream.read(SocketInputStream.java:129) 
java.io.BufferedInputStream.fill(BufferedInputStream.java:218) 
java.io.BufferedInputStream.read1(BufferedInputStream.java:258) 
java.io.BufferedInputStream.read(BufferedInputStream.java:317) 
sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) 
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195) 
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379) 
org.springframework.remoting.httpinvoker.SimpleHttpInvokerRequestExecutor.validateResponse(SimpleHttpInvokerRequestExecutor.java:146) 
org.springframework.remoting.httpinvoker.SimpleHttpInvokerRequestExecutor.doExecuteRequest(SimpleHttpInvokerRequestExecutor.java:66) 
org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.executeRequest(AbstractHttpInvokerRequestExecutor.java:136) 
org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:192) 
org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:174) 
org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:142) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) 
$Proxy117.SigmaCruxer(Unknown Source) 
com.tms.SigmaClient.SigmaClient.processMessage(SigmaClient.java:46) 
com.tms.SigmaClient.SigmaServiceEndpoint.doSigma(SigmaServiceEndpoint.java:29) 
com.tms.SigmaClient.SigmaServiceEndpoint.mark(SigmaServiceEndpoint.java:43) 
sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source) 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
java.lang.reflect.Method.invoke(Method.java:597) 
org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:329) 
org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:231) 
org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:169) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:104) 
org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:74) 
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:102) 
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:72) 
org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78) 
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:114) 
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:284) 
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:109) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78) 
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98) 
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89) 
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:69) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78) 
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98) 
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89) 
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:99) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78) 
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:318) 
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:209) 
org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:305) 
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:102) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78) 
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98) 
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89) 
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:69) 
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:104) 
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:85) 
org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:91) 
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:560) 
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:498) 
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467) 
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) 
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058) 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050) 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947) 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 
java.lang.Thread.run(Thread.java:662) 

Согласно этим два artices: (here и here), мое JBoss приложения имеет блокирующие операции ввода/вывод на Socket.read() который ожидает завершения ответа от поставщика услуг, расположенного ниже (в моем случае, ActiveMQ). Опять же, в соответствии с этими статьями, виновником является один из следующих 3-х элементов:

• ActiveMQ в нездоровом/нестабильном состоянии и реагирует слишком медленно, в результате чего мое прослушивание/ожидание/блокирование потоков для свисают; или
• Сам экземпляр ActiveMQ отлично работает, но обрабатывает операцию (запись на KahaDB и т. д.), которая занимает слишком много времени для завершения, снова заставляя мои потоки зависать; или
• Существуют сетевые проблемы между моим приложением JBoss (WAR) и моим экземпляром ActiveMQ.

Я пытаюсь выяснить, из каких трех случаев. Есть ли что-нибудь в этом дампе потока, чтобы указать, какой из них он есть? Мой понимание (после прочтения этих статей) заключается в том, что вешать действительный является тот факт, что сокет на стороне клиента (блокирующий) только что не получил все байты, которые ему нужно, чтобы рассмотреть завершение ответа; то есть он не получил любой ответ 445089083093692858870889008888 от ActiveMQ, или он просто не получил полного ответа.

Так я спрашиваю:

1. Есть четкое указание того, какой из 3-х сценариев является случай? Если да, то что/почему? Если нет, то что должно быть моим следующим шагом (я также являюсь «администратором», который настроил ActiveMQ, чтобы у меня был полный доступ к нему, а также JBoss и WAR, развернутые на нем).
2. Будет ли обновление до нового JBoss исправить это? Возможно, 4.0.4GA использует «старый» (блокирующий) Java I/O, тогда как более новые версии могут использовать NIO? Вероятно, длинный выстрел, но он еще не может дискредитировать его.
3. Обе статьи подчеркивают, что правильная конфигурация сокетов тайм-аут должен быть реализован, который вполне может смягчить все это (хотя он не решает лежащую в основе ActiveMQ невосприимчивость и/или проблемы сети):
   1. Является ли это тайм-аут Я писал бы в моем Java-коде? Если да, то как и с каким API? JMS? Некоторые баннеры на стороне клиента ActiveMQ?
   2. Является ли это тайм-аутом, который я реализую на уровне ОС? Если да, то я не уверен, как продолжить ...
   3. Является ли это тайм-аутом, который я реализую на стороне сервера (ActiveMQ)? Если да, то как?

Я думаю, что я наступая на решение здесь, но вид застрял и жесткое время видеть лес за деревьями. Заранее спасибо!

Answer 1

У меня есть опыт работы с JBoss (и Glassfish) и ActiveMQ, но я никогда раньше не использовал Camel (но знаком с Mule, который я читаю, похож).

Трассировка стека выглядит так, что Camel пытается связать ActiveMQ (JMS-материал в нижней части трассировки) с конечной точкой веб-сайта (HTTP-материал поверх трассы).

Я немного смущен относительно того, где работает Camel (CamelContext). Вы сказали, что у вас есть две виртуальные машины: одна для JBoss и одна для ActiveMQ. В моем случае мы запускаем Mule ESB на машине с нашим ActiveMQ. Где работает ваш верблюд?

Трассировка стека больше похожа на задачу №1 с первого поста. Это как если бы часть Верблюда не могла «видеть» конечную точку Интернета. Убедитесь, что ваша WAR развернута правильно и что ваша веб-конечная точка (WSDL) видна с обеих виртуальных машин. Проверьте конечные точки; возможно, один установлен на localhost или что-то еще, что не позволит ему добраться до другой машины.

Сложно сказать, является ли это неполным прочитанным или полной неспособностью читать. Проходят ли какие-либо данные? Возможно, веб-сервер медленно перегружается и не может идти в ногу с запросами (и голодает некоторые потоки, как в вашей ошибке). Тайм-ауты сокета становятся важными, когда у вас медленные ответы или много запросов; если вы можете создать простой тест (быстрый и с небольшим количеством запросов), вы можете хотя бы проверить, что у вас есть базовая возможность подключения. Какой ввод данных (тест) вызвал эту ошибку?

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