That should be fine. You can use it any way you want. (as long as you keep each session in a thread)
(forinstance don't create multiple consumers in a single session and have multiple sessions using it)
But the way you describe is fine.
Thank you Clebert. Is the factory backed by a single connection? I may want to create multiple factories in that case. And just to clarify, I should keep it to a single producer/consumer per session, right? Even if they are used only by the session that created them, I should not use multiple at the same time?
I just ran into an issue using delayed redelivery on a queue. I hoped someone could shed some light on it.
I narrowed it to an easy-to-reproduce test:
1) Successfully write a message to a queue
2) Start a receiver
3) Read the message but do not acknowledge (auto acknowledge is turned off)
4) I have a breakpoint set here, so I can confirm that the message count in the queue is still 1, even though I have read the message (good)
5) I start a second receiver in a separate JVM, leaving the first one stuck at that breakpoint
6) I confirm that the message is not delivered to the second receiver, while it is still waiting on the first to acknowledge (good)
7) Now the problem... I waited a while to emulate the case the first receiver is hung, and after a significant wait, another receiver picked up the message originally read by the first receiver.
I am not using transactions, and I thought the redelivery settings applied only if you're using transactions. I'm just trying to use acknowledgement to ensure that the receiver is able to process the messages before acknowledging them. What settings should I use to control the redelivery delay in my case?
If the system goes down after receiving but before acknowledging, I want to know (approximately) when it will be redelivered so it can be picked up by another node's receiver.
Thanks again for the help!
You really should really read the manual.
Look at the time to live section. you will get answer on why the message was not redelivered yet.
Each Connection factory is backed by single TCP Connection. That's covered on the manual also.
Since you held a breakpoint in a message, you broke the ping/pong...what made the server to fail the client.. and hence re-deliver the message.
Thank you Clebert. I am referencing the manual -- thanks for the pointer.
Just to clarify, if my client session were partially hung for some reason but the ping/pong on the connection were still succeeding, can I do anything to have the message redelivered? Thanks.
you were holding a breakpoint on debug.
The message will be redelivered as soon as the client failure was perceived/realized on the server
Yes, I actually did understand that the ping/pong failed because the breakpoint interrupted my JVM. Even if ping/pong is not broken, is there a way to force redelivery? Duplicates are okay in this case. I imagine there is an in-between state where a client can be someone hung in processing a message but not to the point that the ping/pong will break. Thanks for any help.
If the ping/pong is not broken.. the message will be held on the consumer as long as you're not acking that:
Look also at no buffering at consumers (or slow consumers). Maybe you need to set consumer-size to 0 depending on how your consumer is doing. Maybe what you meant is the message is at the client's buffer while your consumer is not getting more messages.
>> Even if ping/pong is not broken, is there a way to force redelivery? <<
I'm not sure what you're suggesting here...
Messaging systems are supposed to guarantee the delivery of a message only once.
The message won't be redelivered as long as you still have your messaging pending. You could close the connection without acknowledging what will force the redelivery based on a possible failure.