Java 持久消息确认如何与虚拟主题一起工作?

Java 持久消息确认如何与虚拟主题一起工作?,java,jms,activemq,middleware,Java,Jms,Activemq,Middleware,如果我没有错的话 当生产者发布关于主题的持久性消息时,代理首先将消息存储在持久性存储中(让kahadb),然后将确认发送回生产者 那个么,对于带有逻辑队列的虚拟主题,它将如何工作呢?因为消息也将存储在队列中 (假设主题上有一个持久订户) 谢谢 编辑: 我将解释我的用例。。。。一个制作人发布到一个主题上,有5个订阅者,我希望在这5个订阅者中,前3个正常获取消息,其余2个只有一个获取消息,所以我认为虚拟主题可以在这方面有所帮助,对于这2个订阅者,我将让他们听逻辑队列而不是主题。。。但我想知道,如果中

如果我没有错的话

当生产者发布关于主题的持久性消息时,代理首先将消息存储在持久性存储中(让kahadb),然后将确认发送回生产者

那个么,对于带有逻辑队列的虚拟主题,它将如何工作呢?因为消息也将存储在队列中

(假设主题上有一个持久订户)

谢谢

编辑
我将解释我的用例。。。。一个制作人发布到一个主题上,有5个订阅者,我希望在这5个订阅者中,前3个正常获取消息,其余2个只有一个获取消息,所以我认为虚拟主题可以在这方面有所帮助,对于这2个订阅者,我将让他们听逻辑队列而不是主题。。。但我想知道,如果中间代理崩溃/重启,持久消息会发生什么情况……发送到代理的持久消息会发生什么情况……可能是在复制到队列的持久存储之前,代理停止了。那么,是否有任何确认机制,如直接生产者对经纪人的确认。

这里有些术语混淆了。生产商排队生产。出版商发布主题。尽管发布者可以发布持久性消息,但它们不会像使用生产者时那样持久化。虽然我相信仍然存在一个块,但我看到在使用虚拟主题和队列时出现了一些奇怪的行为,该队列已超过存储/内存限制,并且发布者仍在继续发布。因此,这让我相信,排队并不像制作人那样直截了当,从经纪人到出版商的回执对出版商的作用与对制作人的作用不同。@Erikwillams感谢更正我的术语,我现在已经进行了适当的编辑。那么,这里的实际问题是什么?你想解决什么问题?@TimBish我在编辑我的问题时给出了详细信息……所以你打算将最后两个附加到同一队列并竞争消息?或者让其中一个成为独家消费者?