Spring convertAndSend Locks the current process and completely ignores the timeout

Spring version: 2.7.1 We have found some sort of problem when submitting messages to clients We have a scheduled task which tries to group users every second. Sometimes, the convertAndSend method from the SimpMessagingTemplate simply locks, ignoring timeouts. An example of the log attached. As well as a simplified version of the code that provokes the behaviour.

2023-09-25 07:37:52.695  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : RUNNING SCHEDULED TASK
2023-09-25 07:37:52.696  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : Finished scheduled task
2023-09-25 07:37:53.696  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : RUNNING SCHEDULED TASK
2023-09-25 07:37:53.698  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : Finished scheduled task
Hibernate: SELECT 1
2023-09-25 07:37:54.699  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : RUNNING SCHEDULED TASK
2023-09-25 07:37:54.700  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : Finished scheduled task
2023-09-25 07:37:55.701  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : RUNNING SCHEDULED TASK
2023-09-25 07:37:55.704  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : Found 1 open rooms
Hibernate: SELECT 1
2023-09-25 07:37:57.183  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : Grouped 1 users in room
2023-09-25 07:37:57.183  INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling                  : Notifying user admin2023
2023-09-25 07:38:09.665 DEBUG 1 --- [nnection closer] com.zaxxer.hikari.pool.PoolBase          : HikariPool-1 

messagingTemplate.setSendTimeout(3000);

try {
      logger.info("RUNNING SCHEDULED TASK");
      val rooms = waitroomService.getWaitrooms();
      if (rooms.size() > 0)
          logger.info("Found {} open rooms", rooms.size());
       for (val room : rooms) {
          val users = waitroomService.getUsersInWaitRoom(room);
          logger.info("Found {} users waiting in room {}", users.size(), new String(room));
          val groupedUsers = groupMaker.tryAndMakeGroups(users);
          logger.info("Grouped {} users in room", groupedUsers.size());
          for (val user : groupedUsers) {
               logger.info("Notifying user {}", user.getUsername());
               WebSocketResponseSchema response = new WebSocketResponseSchema(user.getRoomName());
               messagingTemplate.convertAndSend("/topic/client-" + user.getUsername(), response);
               logger.info("USER={}, ROOM={}", user.getUsername(), user.getRoomName());
            }
        } catch (Exception e) {
            logger.info("Exception in scheduler");
        } finally {
            messagingTemplate.setSendTimeout(sendTimeout);
            logger.info("Finished scheduled task");
        }

Expected output would be that after logging notifying user, the app logged 2023-09-25 07:37:57.183 INFO 1 --- [MessageBroker-1] org.uv.tutor.Scheduling : USER=admin2023, ROOM=whatevertheroomnameis But it hangs forever in the convertAndSend. I cannot guarantee there is a client subscribed to 'topic/client-admin2023', should I check it before hand? I have seen a similar issue. https://github.com/spring-projects/spring-framework/issues/26464 and checked that we are running with a posterior version of reactor netty i.e 1.0.20 EDIT: I must say that this behaviour does not happen all the time, only sometimes EDIT 2: Found out, Broker was not connecting. Still messaging should not lock the thread forever, should probably say something of the like destination unreachable, or launch an exception.

Comment From: snicoll

EDIT 2: Found out, Broker was not connecting. Still messaging should not lock the thread forever, should probably say something of the like destination unreachable, or launch an exception.

Can you share a small sample that reproduces what you've described? I can't see why we'd silently ignore the fact that the broker is not reachable.

Comment From: mixtoism

Sure, Will prepare a small sample this weekend

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.