Pub-Sub错误处理策略
这是我的通道设置：
- jdbc 消息存储支持的队列
- 将队列连接到 pub-sub 通道的桥
- 在 pub-sub 通道上配置的轮询器是事务性的
现在，当任何一个订阅者中引发异常时然后事务回滚并永远重试消息。该消息再次被所有订阅者处理。如果这是至少订阅者中的永久异常，则该消息不会被其他订阅者处理。
这里最好的异常处理策略是什么？
我更喜欢对订阅者进行异常处理，即只有失败的订阅者才会重试，其他订阅者将处理消息并继续。
这在spring集成中如何实现呢？
更多详细信息请参见此处。
如果轮询器设为事务性且消息在至少一个订阅者中处理失败，则该消息将回滚到消息存储并重试。我还为 errorChannel 配置了 jdbc 消息存储。每次消息处理失败时，消息都会回滚到原始消息存储，并且错误通道消息存储每次重试都会有一个条目。
- 非事务性且消息在第一个订阅者中处理失败，则该消息将被放入错误通道，但第二个订阅者永远不会获取该消息。
看来有一些根本性的错误..是否与我的配置有关？
Here is my channels set-up:
- A jdbc message-store backed queue
- A bridge connecting the queue to a pub-sub channel
- The poller configured on the pub-sub channel is transactional
Now when there is an exception raised in any one of the subscribers then the transaction rolls back and the message is retried for ever. The message is again processed by all the subscribers again. If this is a permanent exception in at least subscriber then the message is not getting processed by none of the other subscribers.
What is the best exception handling strategy here?
I prefer exception handling on the subscriber i.e.only the failing subscriber will retry, other subscribers will process the message and move on.
How can this be implemented in spring integration?
More details here..
If the poller is made transactional and the message fails processing in at least one of the subscribers, then the message is rolled back to the message store and retried. I also configured a jdbc message store for the errorChannel. Every time the message processing fails, the message gets rolled back to the original message store and the error channel message store has one entry for each retry.
If the poller is made non-transactional and the message fails processing in the first subscriber, then the message is put to the error channel, but the second subscriber never gets the message.
It appears that there is something fundamentally wrong.. Is it with my configuration?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
http://forum.springsource.org/archive/index.php/ t-75000.html
上述线程中的讨论解释了该框架相对于 pubsub impl 的优点和缺点。
我们选择采用以下方法：
轮询器将是事务性的，这意味着所有订阅者都成功处理消息，或者都没有。消息将与所有订阅者一起重试，直到所有订阅者都成功完成。
错误处理是订阅者的责任
只有系统异常才会被冒泡回轮询器。业务异常将由订阅者处理，并且消息将被手动放入某个错误通道。
http://forum.springsource.org/archive/index.php/t-75000.html
The discussion in the above thread explains the ups and downsides of the framework with respect to pubsub impl.
We chose to go with the below approach:
Pollers will be transactional, meaning all subscribers process the message successfully or none of them. Message will be retried with all subs until all of them complete successfully.
Error handling is the subscribers responsibility
Only system exceptions will be bubbled back to the poller. Business exceptions will be handled by the subscriber and the message will be put to some error channel manually.