Weblogic 12.2.1.2 - конечная точка websocket - поддержка async отключена по этому запросу

Question

У меня уже есть ответ на вопрос, который я собираюсь представить.

В любом случае я спрашиваю его здесь, чтобы он мог помочь людям, мигрирующим из JEE ​​6 в JEE 7, и которые думают об использовании websocket - например, чтобы заменить длительный опрос на функциональность websocket.

ВОПРОС: В Weblogic 12.2.1.2, который поддерживает JEE 7, и пытается настройки WebSockets с помощью гида, таких как следующее: http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/HomeWebsocket/WebsocketHome.html

ПРИМЕЧАНИЕ: В руководстве выше предельно прост, и все это говорит, правильно и «должно» работать. Не обязательно будет работать в вашем приложении, как это было не в моей. Но по идее это должно быть.

Несмотря на это. Применение websocket вступает в заблуждение во время рукопожатия от браузера к резервному копированию, где предполагается, что HTTP-соединение должно быть обновлено до подключения к веб-сокету tcp/ip.

Weblogic, жалуется, что tyrus не может использовать поведение сервлета Ascyn для обработки этого протокола установления связи. Трассировка стека для ошибки во время квитирования приведена следующая:

2017-01-23 14: 54: 59065 ThreadId: 53 ОШИБКА HTTP - [ServletContext @ 129852715 [Приложение: primefaces-60: модуль primefaces-60

путь: нулевая спецификация версия: 3.1]] сервлет не удался с Exception < [ACTIVE] ExecuteThread: '5' для очереди: 'weblogic.kernel.Default (самонастройка)'> java.lang.IllegalStateException : Асинхронная поддержка отключена в этом запросе : weblogic.servlet.internal.ServletRequestImpl@2c87c663 [GET /primefaces-60/действия HTTP/1.1 Connection: обновление Pragma: no-cache Cache-Control: no-cache Обновление: websocket Начало: http://localhost:7001 Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/55.0.2883.87 Safari/537.36 DNT: 1 Accept-Encoding: gzip, deflate, sdch, br Accept-язык: en-US, en; q = 0.8, pt-PT, q = 0,6, pt; q = 0,4, fr; q = 0,2, it; q = 0,2, de; q = 0,2 Sec-WebSocket-Key: flKcAkxO3CJBIc8cYvwvlA == Sec-WebSocket-Extensions: permessage- выкачать; client_max_window_bits

] на weblogic.servlet.internal.ServletRequestImpl.startAsync (ServletRequestImpl.java:2029) на weblogic.servlet.internal.ServletRequestImpl.startAsync (ServletRequestImpl.java:2005) на javax.servlet. ServletRequestWrapper.startAsync (ServletRequestWrapper.java:432) на weblogic.websocket.tyrus.TyrusServletFilter.doFilter (TyrusServletFilter.java:241) на weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:78) на filter.DummyTimeoutFilter2.doFilter (DummyTimeoutFilter2.java:81) at weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:78) на weblogic.servlet.internal.RequestEventsFilter.doFilter (RequestEventsFilter.java:32) на weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl .java: 78) at weblogic.servlet.internal.WebAppServletContext $ ServletInvocationAction.wrapRun (WebAppServletContext.java:3683) на weblogic.servlet.internal.WebAppServletContext $ ServletInvocationAction.run (WebAppServletContext.java:3649) в weblogic.security.acl.internal.AuthenticatedSubject.doAs (AuthenticatedSubject.java:326) на weblogic.security.service.SecurityManager.runAsForUserCode (SecurityManager.java:197) на weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode (WlsSecurityProvider.java:203) на weblogic.servlet.provider.WlsSubjectHandle.run (WlsSubjectHandle.java:71) по адресу weblogic.servlet.internal.WebAppServletContext.doSecuredExecute (WebAppServletContext.java:2433)на weblogic.servlet.internal.WebAppServletContext.securedExecute (WebAppServletContext.java:2281) на weblogic.servlet.internal.WebAppServletContext.execute (WebAppServletContext.java:2259) на weblogic.servlet.internal.ServletRequestImpl.runInternal (ServletRequestImpl.java:1691) на weblogic.servlet.internal.ServletRequestImpl.run (ServletRequestImpl.java:1651) на weblogic.servlet.provider.ContainerSupportProviderImpl $ WlsRequestExecutor.run (ContainerSupportProviderImpl.java:270) в weblogic.invocation.ComponentInvocationContextManager._runAs (ComponentInvocationContextManager.java:348) на weblogic.invocation.ComponentInvocationContextManager.runAs (ComponentInvocationContextManager.java:333) на weblogic.work.LivePartitionUtility.doRunWorkUnderContext (LivePartitionUtility.java:54) на weblogic.work.PartitionUtility.runWorkUnderContext (PartitionUtility.java:41) на weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext (SelfTuningWorkManagerImpl.java:640) в weblogic.work.ExecuteThread.execute (ExecuteThread.java:406) при weblogic.work.ExecuteThread.run (ExecuteThread.java:346)

Исходя из предположения, что код бэкэнд для настройки конечной точки websocket идеально подходит, и код JavaScript, используемый для попытки установить соединение с веб-узлом, является совершенным. Может ли кто-нибудь объяснить, почему полученная ошибка получена, следуя руководству по письму?

ПРИМЕЧАНИЕ: - Вышеупомянутая трассировка стека уже выделена в примере приложения, в результате которой рабочая точка websocket была повреждена в вышеуказанное исключение, основанное на анализе реального приложения.

Ответ прост, как только вы это знаете ... Я отвечу на день или около того, если никто не вернет правильное решение.

Answer 1

Чтобы ответить на мой собственный вопрос.

Проблема, с которой приложение сталкивалась при попытке открыть соединение с веб-сокетом, была связана с тем, что tyrus использует функции Seplet 3.0 specificaiton, а именно асинхронную обработку сервлетов.

Даже в самых тривиальных веб-приложениях, вероятно, есть фильтры, которые пересекают кропотливо применимо ко всем веб-запросам. Например, фильтр с отображением фильтра/*.

Ну, это была проблема. Как поясняется в следующей ссылке, чтобы асинхронный сервлет, которому разрешено запускать всю цепочку фильтров, ведущих к сервлету, должен иметь поддержку асинхронного запроса.

https://blogs.oracle.com/enterprisetechtips/entry/asynchronous_support_in_servlet_3

Атрибут asyncSupported необходимо дифференцировать код, написанный для синхронной обработки от написана для использования в асинхронном контексте. Фактически, для приложения, использующего асинхронную функцию , вся цепочка обработки запроса должна иметь , если этот атрибут установлен либо через аннотацию, либо в ее дескрипторе развертывания . Исключение IllegalStateException будет вызываться, если приложение пытается запустить асинхронную операцию, и в цепочке обработки запроса есть фильтр сервлета или сервлета, который не поддерживает асинхронную обработку.

Таким образом, чтобы решить эту проблему, набор фильтров должен быть дан дополнительный элемент:

<async-supported>true</async-supported> 

Например:

<filter> 
    <filter-name>AFilter</filter-name> 
    <filter-class>webapp.AFilter</filter-class> 
    <async-supported>true</async-supported> 
</filter> 

В случае трассировки стека выше , все, что было необходимо для того, чтобы проблема, воспроизводимая в автономном приложении, заключалась в добавлении фиктивного фильтра, который абсолютно ничего не делал, кроме как передать запрос на следующий фильтр. Этот фильтр был: DummyTimeoutFilter2. Этот фильтр был объявлен без поддержки async true.

Итак, в заключение, имейте в виду, что вашему контейнеру могут потребоваться асинхронные сервлеты для открытия веб-сокетов. И если у вас есть фильтр, который перехватывает запросы к вашей конечной точке websocket, вы можете быть удивлены таким побочным эффектом. Это особенно верно для приложений, выходящих из JEE ​​6, но это может легко случиться с любым новым приемом JEE 7.

Большинство людей, однако, вероятно, не имеют фильтров, перехватывающих вызов конечной точки websocket ...