解决 Tibco EMS 和 .NET API 中的预取问题
所有这些都在 Tibco EMS 5.* 和 .NET API 的上下文中，
我必须按照现有的消息处理模型进行工作，其中循环：
- 创建连接/
- 创建打开会话/
- 创建打开消息使用者
- 调用接收方法
如果 message != null 然后我们使用它并提交或回滚事务（在底层会话上）。系统在该模型中每 x 秒拉一次。
我创建了一个连接工厂，确保只创建新会话（如果上一个会话仍在使用）。这样系统就可以在同一连接上运行。
但是，我遇到了预取问题，因为每个 Receive 调用（通过 .NET 接口）都会返回一条消息并将多条消息 (pre-fetch-1) 放入本地队列。 因此，我应该下次重用同一个会话，以便读取已经拉取的消息。 我已经放入包装器以重用会话和会话。只要有东西就消息消费者（接收不会返回 null）。 这种方法有点有效，但似乎我可能在接收时得到空值，即使仍然有本地获取的东西。 似乎只要我在同一连接上，获取的消息就会被标记为已传递（即使会话已显式关闭）。
有人知道如何使用 pre-fetch = 1 打开连接/会话吗？ 或者有更好的解决方案？
提前致谢，
All in context of Tibco EMS 5.* and .NET API
I've to work along existing model of message processing, in which in a loop:
- connection is created / open
- session is created / open
- message consumer is created
- receive method is called
if message != null then we consume it and either commit or rollback the transaction (on underlying session). System pulls every x sec in that model.
I've created a connection factory that assures that only new sessions are created (if the previous session is still in use). In that way system works on the same connection.
However, I've run into issue with pre-fetch as each Receive call (by .NET interface) returns one message and puts several (pre-fetch-1) to local queue.
So I should reuse the same session next time really in order to read messages that are already pulled.
I've put in wrappers to reuse the session & message consumer as long as there is something there (Receive won't return null).
This approach kind of works, but it seems that I might have get null on Receive, even though there is still something fetched locally.
It also seems that as long as I’m on the same connection fetched messages will be marked as delivered (even if session is explicitly closed).
Would someone have any idea how to either open connection / session with pre-fetch = 1?
Or there is better solution?
Thanks in advance,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
解决方法：关闭队列级别的预取。
Workaround: turn-off prefetching on the queue level.