gpt4 book ai didi

java - Spring WebSocket - Controller 发送消息后丢失

转载 作者:行者123 更新时间:2023-12-02 05:14:43 25 4
gpt4 key购买 nike

我遇到了 Spring WebSocket 版本 4.1.1.RELEASE 未发送 WebSocket 消息的问题。并不是每条消息都会发生这种情况,只是有些消息由于我不明白的原因而没有发送。消息内容需要一些时间才能加载,但我不确定这是否是问题的原因,因为有时它可以工作,但大多数时候却不能。

我的 Web 应用程序成功订阅 channel /user/queue/overview/reqinfo/events,然后发送四条消息来请求信息。我的 Controller 类通过 spring-data-jpa 和 Hibernate 在数据库上触发 COUNT() 语句,并将结果作为消息返回给请求来源的用户。所有四个消息都由相同的 Controller 方法处理,但只有两个响应传递给发送者。我从Spring日志中提取了相关信息并附在此处。正如您所看到的,最后两条消息没有被 SimpleBrokerMessageHandler 处理,因此不会发送给用户。创建这些消息的内容需要一分多钟的时间。

12:50:54,953 DEBUG clientInboundChannel-12 user.UserDestinationMessageHandler:187 - Translated /user/queue/overview/reqinfo/events -> [/queue/overview/reqinfo/events-user8178efnd]
12:50:54,953 DEBUG clientInboundChannel-12 broker.SimpleBrokerMessageHandler:175 - Processing SUBSCRIBE /queue/overview/reqinfo/events-user8178efnd id=sub-7 session=8178efnd
[...]
12:50:54,957 DEBUG clientInboundChannel-2 support.SimpAnnotationMethodMessageHandler:348 - Searching methods to handle SEND /app/overview/reqinfo/events session=8178efnd
12:50:54,957 DEBUG clientInboundChannel-1 support.SimpAnnotationMethodMessageHandler:348 - Searching methods to handle SEND /app/overview/reqinfo/events session=8178efnd
12:50:54,957 DEBUG clientInboundChannel-16 support.SimpAnnotationMethodMessageHandler:348 - Searching methods to handle SEND /app/overview/reqinfo/events session=8178efnd
12:50:54,959 DEBUG clientInboundChannel-10 support.SimpAnnotationMethodMessageHandler:348 - Searching methods to handle SEND /app/overview/reqinfo/events session=8178efnd
[...]
12:50:54,959 DEBUG clientInboundChannel-16 support.SimpAnnotationMethodMessageHandler:446 - Invoking de.d.i.g.websocket.OverviewController#requestOverviewEvents[2 args]
12:50:54,959 DEBUG clientInboundChannel-10 support.SimpAnnotationMethodMessageHandler:446 - Invoking de.d.i.g.websocket.OverviewController#requestOverviewEvents[2 args]
12:50:54,959 DEBUG clientInboundChannel-2 support.SimpAnnotationMethodMessageHandler:446 - Invoking de.d.i.g.websocket.OverviewController#requestOverviewEvents[2 args]
12:50:54,959 DEBUG clientInboundChannel-1 support.SimpAnnotationMethodMessageHandler:446 - Invoking de.d.i.g.websocket.OverviewController#requestOverviewEvents[2 args]
[...]
12:50:55,006 DEBUG clientInboundChannel-1 websocket.OverviewController:196 - requestOverviewEvents, incoming message: MsgOverviewEventsRequest(timeframe=THIS_WEEK)
12:50:55,006 DEBUG clientInboundChannel-10 websocket.OverviewController:196 - requestOverviewEvents, incoming message: MsgOverviewEventsRequest(timeframe=LAST_WEEK)
12:50:55,006 DEBUG clientInboundChannel-2 websocket.OverviewController:196 - requestOverviewEvents, incoming message: MsgOverviewEventsRequest(timeframe=YESTERDAY)
12:50:55,006 DEBUG clientInboundChannel-16 websocket.OverviewController:196 - requestOverviewEvents, incoming message: MsgOverviewEventsRequest(timeframe=TODAY)
[...]
12:50:55,032 DEBUG clientInboundChannel-16 websocket.OverviewController:225 - requestOverviewEvents, outgoing message: MsgOverviewEvents(timeframe=TODAY, count=31, error=false)
12:50:55,035 DEBUG clientInboundChannel-16 broker.SimpleBrokerMessageHandler:152 - Processing MESSAGE destination=/queue/overview/reqinfo/events-user8178efnd session=null payload={"timeframe":"TODAY","count":31,"error":false}
12:50:55,035 DEBUG clientInboundChannel-16 broker.SimpleBrokerMessageHandler:196 - Broadcasting to 1 sessions.
[...]
12:51:01,018 DEBUG clientInboundChannel-2 websocket.OverviewController:225 - requestOverviewEvents, outgoing message: MsgOverviewEvents(timeframe=YESTERDAY, count=190292, error=false)
12:51:01,020 DEBUG clientInboundChannel-2 broker.SimpleBrokerMessageHandler:152 - Processing MESSAGE destination=/queue/overview/reqinfo/events-user8178efnd session=null payload={"timeframe":"YESTERDAY","count":190292,"error":false}
12:51:01,020 DEBUG clientInboundChannel-2 broker.SimpleBrokerMessageHandler:196 - Broadcasting to 1 sessions.
[...]
12:51:19,081 DEBUG clientInboundChannel-1 websocket.OverviewController:225 - requestOverviewEvents, outgoing message: MsgOverviewEvents(timeframe=THIS_WEEK, count=845956, error=false)
12:51:19,088 DEBUG clientInboundChannel-10 websocket.OverviewController:225 - requestOverviewEvents, outgoing message: MsgOverviewEvents(timeframe=LAST_WEEK, count=1421118, error=false)

这是一个经常出现问题的示例案例。我对遭受相同问题的其他消息和 Controller 有其他看法,并且它们的消息不需要一分钟即可构建,只需要几秒钟甚至更短的时间。我正在使用带有 SockJS 支持的 SimpleMessageBroker (使用 SockJS 0.3.4)。在尝试解决此问题时,我将此 bean 添加到我的 WebSocket 配置类中以手动设置连接超时,但它没有解决问题:

@Bean
public ServletServerContainerFactoryBean createWebSocketContainer() {
long tenMinutesInMillis = 10 * 60 * 1000;

ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean();
container.setAsyncSendTimeout(tenMinutesInMillis);
container.setMaxSessionIdleTimeout(tenMinutesInMillis);

return container;
}

为什么有些消息会被丢弃,而另一些消息会正确发送?如果您需要日志或源代码中的更多信息,请询问。

[更新]有关该行为的一些附加信息:

始终返回计算最少项目数的第一条消息。第二条消息大部分时间都会返回,最后两条消息大约 90% 的时间都会发送失败。在它们加载失败后,其他 View 也不会加载,即使接收并处理了订阅,响应消息也不会发送到 Web 界面。在浏览器中点击刷新以重新加载页面后,一切正常,直到消息再次卡住。

但是,在后台运行并使用 WebSocket 向用户发送消息的心跳系统始终有效。它似乎完全不受该问题的影响。

[更新2]

当问题发生时,sockJsScheduler 似乎没有处理所有请求。 WebSocketMessageBrokerStats 记录的 INFO 消息提供以下输出:

INFO MessageBrokerSockJS-2 config.WebSocketMessageBrokerStats:113 - WebSocketSession[1 current WS(1)-HttpStream(0)-HttpPoll(0), 1 total, 0 closed abnormally (0 connect failure, 0 send limit, 0 transport error)], stompSubProtocol[processed CONNECT(1)-CONNECTED(1)-DISCONNECT(0)], stompBrokerRelay[null], inboundChannel[pool size = 16, active threads = 0, queued tasks = 0, completed tasks = 120], outboundChannelpool size = 16, active threads = 0, queued tasks = 0, completed tasks = 16], sockJsScheduler[pool size = 8, active threads = 1, queued tasks = 4, completed tasks = 18]

它说 sockJsScheduler 有四个排队任务没有被处理,也许这些是没有正确发送的消息?不幸的是,没有进一步的信息说明为什么它们没有在日志中得到处理。

最佳答案

对我的应用程序(尤其是处理的 Spring 代码)进行深入调试后,我找到了该行为的原因。

问题既不是 Controller 也不是 Spring 内部进程,而是我在 Spring Security 身份验证期间用于主体对象的类。它存储用户成功应答的最后一个心跳 ID,以检查向系统发送消息的用户是否还活着,或者 session 是否已被视为已死亡。此 ID 包含在 equals() 中, hashCode()toString()该对象的方法。

Spring 使用其中一种方法(经过一些测试,我猜它是 toString() ,在我看来这不是一个好的选择)来转换 @SendToUser 的目标路径。操作。如果字符串发生变化(当应答新的心跳 ID 时,我的应用程序就是这种情况),Spring 无法转换目标路径并且不会发送消息。指出这一点的日志条目被隐藏为 TRACE 级别消息,这就是为什么我一开始没有找到它。该消息如下所示:

14:29:00,260 TRACE clientInboundChannel-16 user.UserDestinationMessageHandler:175 - No user destinations found for /user/RtAuthorizedUser(super=AuthorizedUser(username=SIEM-User 1, authenticated=true, lastAnsweredHeartbeat=9971f9ea-8e64-4c24-823b-f7e6e277c775, alive=true), rtSessionId=RT_SID_iMonitor.443=782acc747aac01b9e0a7ece3ab2d27bd)/queue/overview/reqinfo/events

我建议开发人员将此消息至少设置为“调试”级别(甚至“警告”或“错误”),因为在发送过程中搜索问题时很难发现此信息。事实上这是一个错误。

从上述三种方法中删除心跳 ID 后,系统运行良好,不再丢失消息。所以这首先是我这边的一个错误,但我认为使用toString()这里不是最佳的。现在 Spring 可以正确翻译消息,生成这些消息(这些消息是 DEBUG 级别而不是上面的 TRACE 级别):

14:37:35,661 DEBUG clientInboundChannel-3 user.UserDestinationMessageHandler:187 - Translated /user/RtAuthorizedUser(super=AuthorizedUser(username=SIEM-User 1, authenticated=true, alive=true), rtSessionId=RT_SID_iMonitor.443=bf3adbaa858932b64a03724b6137e95d)/queue/overview/reqinfo/events -> [/queue/overview/reqinfo/events-user_qtca5il]

关于java - Spring WebSocket - Controller 发送消息后丢失,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27061358/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com