Can you explain what you mean by "orderer redelivery" (I assumed you mean "ordered redelivery" ?)
If so, can you explain what you mean in more detail.
HornetQ already provides ordered redelivery of messages.
So, in other words, before sending in a patch, I'd like to know what the problem is that it's supposed to be solving.
yes I mean "ordered redelivery".
I didn't find anything about this feature in the docs and it would be a good starting point for me if you could send me the link where the documentation describes this feature in HornetQ.
About your second question for "ordered redelivery" I mean the ability to re-queuing a message in the right posistion when an exception occurs during the sending phase.
This operation is usefull to maintain the total order of the messages sent via queue.
4 years ago we tried JBoss for this feature, but only the standalone version of JBoss Messaging had the ability to maintain the total order.
The JBoss Messaging inside the application server didn't maintain the order so we created a little patch that allows to our customer to use JBoss in production.
I don't follow this task from the beginning and I know that my description isn't very clear (excuse me for my poor english).
Now I hope that the scenario is much more clear but for any question I'm here to answer you.
I downloaded HornetQ 2.0.0.GA and I'm inspecting the code to verify our solution with the new product.
you can find the first discussion about this question between Adrian Brock and a collegue of mine.
I hope it is usefull to clarify the scenario.
Hmm, still you need to demonstrate there is a problem before providing a solution!
AFAIK HornetQ already provides ordered redelivery of messages.
If you can demonstrate a specific case where it does not, please create a simple test program that demonstrates this, and attach it to a JIRA, and we can go from there.
OK, Tim...You are right.
but I don't tell you that HornetQ doesn't provide ordered redelivery.
Simply I didn't find any information about it in the "features" web page of HornetQ.
so, I trust you but I need a certification for my customer.
Can you send me the link where this feature is described ?
For my part, I will create a test case to verify the situation, and if you want we can contribute to the project with our test.
thanks a lot
I would say ordering is an intrinsic feature of any messaging system. It's kind of redundant having to mention that as a feature.
That's a requirement for us, not a feature.
There's one extra feature regarding ordering though, called message grouping.
Depending on your requirements for ordering, that may be suitable for you.
Message grouping is an interesting features but it doesn't fill my requirements.
I'll test HornetQ 2.0.0.GA within JBoss 5.1.0.GA to verify the ordered redelivery.
I must do it because using an older version of the messaging system I had two different behavior:
* the standalone product (JBoss Messaging 1.2) supports the ordered redelivery
* the embedded version (JBoss 4.0.2) doesn't support it
My only wish is certify the behavior of the product for my customer.
Yes, definitely the first step for you here would be to write a test demonstrating the behaviour that you think needs fixing, then we can debate it from there.
We have a test that verify the ordered redelivery with JBoss/HornetQ.
Are You interested with our contribution ?
The attachment shows the idea behind the test and if you want we can send you the source code.
If we have to modify the sorce to comply the project's policy there are problems...we'll do it.
Can you just post the unit test please?
We don't need any of the other stuff.
Ok, I managed to patch together the Word document - it would have been a lot easier if you'd just posted the JUnit test !
I had to guess some of the constants you omitted from the test, e.g. RECV_TIME and NUM_MESSAGES.
Anyway.. I replicated the issue and opened this JIRA.
I looked at this and there is no underlying ordering issue.
The bug is in receiveNoWait() in the current JMS API not calling the corresponding core receiveImmediate()
The receiveImmediate bug is now fixed in TRUNK and I have rejected the ordering issue JIRA.
See JIRA for more info.