Is there a conflict when sending a message (having the _HQ_SCHED_DELIVERY property) to a last-value-queue? The problem I am experiencing is that the message gets stuck on the queue and is not delivered to the queue consumer until HornetQ is stopped and restarted.
Sending multiple messages with the same _HQ_LVQ_NAME property value appears to work as expected for a last-value-queue. Inspecting the queue using jconsole shows the multiple messages have been eliminated with the scheduledCount set to 1 as expected. However, when the scheduled time for message occurs the message is not delivered. Only when HornetQ is restarted is the message delivered.
What is the problem? And how to get around it if possible? Could this be a bug?
Any help would be greatly appreciated!
I believe I understand the concept of last-value-queues. When a message has the JMS header _HQ_LVQ_NAME property set, it will replace another message on the queue that has the same property value. So, sending multiple messages containing the same _HQ_LVQ_NAME property value to a queue will result in only the last message of those remaining on queue.
A scheduled message, having the JMS header _HQ_SCHED_DELIVERY specifying the time for delivery, will sit on the queue until the scheduled time.
I don't see any reason that these two JMS headers cannot co-exist in the same message. If they are conflicting, it is not documented in the HornetQ User's Manual. If there is a scheduled-message on the last-value-queue, why shouldn't it be delivered at the scheduled time? If another message comes along with the _HQ_LVQ_NAME property value that is the same as the scheduled-message, it should replace that message with the new one and deliver it at the new scheduled time. Do you agree?
Please let me know if there is an undocument conflict - invalid usage - of these two headers in the same message being delivered to a last-value-queue. Otherwise, is there a workaround? Is is a bug?
Thanks for your quick reply,
As you requested, I have attached a test case for you to explore this issue. The test is a modifiication of the last-value-queue example provided in the HornetQ distribution. We are using the latest HornetQ 2.2.5 Final distribution.
Running the test case illustrates the problem. Three messages are placed on the last-value-queue. The first message also has has a scheduled-delivery property with a delivery time of 60 seconds after the time the message is sent. The second message has a delivery time one second past the first, and the third message has a delivery time of two seconds past the first. However, the message is never delivered. The queue consumer waits two minutes (one minute beyond the scheduled delivery time) and no messages are delivered.
If the test case is re-run, the third message -- the only one on the last-value-queue (as should be the case) -- gets delivered! Notice hornetQ had to be restarted for the message delivery to occur.
I believe this is bug... any chance you could provide a workaround?
Clebert Suconic wrote:
This is not a bug...
The last-value check is done at the time the message entered the queue. The message will be scheduled already to enter the internal queue but all the verifications on the hashMap are done at the time of sending.
Could you please explain this using more details? I think any correct message must be delivered to the consumer at last, is this right?
I am having a similar issue to one described by Sergey.
Basically the use case is the following.
We have a need to send a message to a queue, but we don't want that message to be delivered to some time in the future.
Prior to that future time being reached, a new updated message is sent to the queue, however we only want the latest message to be there. So when the consumer does consume the message, they only consume the second message.
This seems like a valid use case for using a last value queue coupled with a scheduled delivery time. But as previously described, when running thru my scenario I see that there is only one message on the queue, but it never gets delivered until after a server restart.
Can you elaborate a bit more, on way this is or is not a proper use case and why HornetQ is not delivering the message until after the restart?
Thanks for your time.
like clebert said, the message is verified at the point it arrives at the queue not the time the client sends it so this is correct. When you restart the server the messages are loaded in the order they were received at the server so if the scheduled time has elapsed it will take precedent. to be honest i dont think using last val queues and scheduling is a good mix.