Since PETALSCDK-91, a retry policy has been introduced at message exchange acceptor level. If no message exchange processor is available, a rety is done. But when the retry policy ends, the message exchange will be lost.
So to avoid to lose the message exchange, two ways exist:
- an error should be returned to the consumer,
- the acceptor thread could be used to run the message exchange processor, and so, the consumer will be indirectly slowed down.
The better way is #2
Since
PETALSCDK-91, a retry policy has been introduced at message exchange acceptor level. If no message exchange processor is available, a rety is done. But when the retry policy ends, the message exchange will be lost.So to avoid to lose the message exchange, two ways exist:
The better way is #2
PETALSCDK-91, a retry policy has been introduced at message exchange acceptor level. If no message exchange processor is available, a rety is done. But when the retry policy ends, the message exchange will be lost. So to avoid to lose the message exchange, two ways exist: