When UNICAST3 receives a retransmission request, it starts sending the requested messages immediately, on the same internal thread that received the request. Sometimes the retransmission takes a long time, e.g. if the TP bundler is no-bundler or sender-sends, or if the bundler is transfer-queue and the bundler queue is full.

The internal thread pool normally handling retransmission requests is small, but when it is full TP will create a temporary thread for each new internal message. That means the number of threads that are re-sending the same message to the same destination is bounded only by the JVM's capacity to create new threads.

Sending the same messages multiple times may also take precious resources away from recovering after a bad situation, after a long GC pause or after a burst of application messages fills up the main thread pool and TP starts discarding application messages.

It would be better if the number of retransmission requests being processed at the same time was limited, and duplicate requests for the same message were merged. I'm not sure if a single thread would be enough to handle retransmission requests from all destinations, maybe internal thread pool size / 2 or one thread per destination would be better.