Why do that instead of having an idempotent consumer taking messages off of the
queue?
In the comments from a similar question on stackoverflow.com, Rob Davies
suggests also just using a well defined header/property for this purpose:
Because in that way we can use activeMQ's built in duplicate detection.
--Kaustubh
On Fri, Sep 23, 2011 at 7:46 PM, Jason Whaley jasonwha...@gmail.com wrote:
Agreed with Gary's question here... why not use your database to generate a
unique ID for each record and then shove that ID in to a
Please correct me if I am wrong, but in same onSend method one could
override the messageId as well right?
We also planning to use same, are there any ill-effects of that?
Thanks and regards
Kaustubh
On Thu, Sep 22, 2011 at 11:49 PM, Martin C. mart...@gmx.at wrote:
Hi,
ok I see, but this is
be careful, you need to retain the uniqueness constraints of the
component attributes of a message id. have a peek at how the message
id is generated so that you can understand the intent of each
component.
Why do you want to override the messageId?
On 23 September 2011 14:19, kaustubh khasnis
Agreed with Gary's question here... why not use your database to generate a
unique ID for each record and then shove that ID in to a property with an
application specific name on the JMS message?
On Sep 23, 2011, at 8:08 AM, Gary Tully wrote:
be careful, you need to retain the uniqueness
Hi,
I'd like to know the message ID of a message I am going to send before
actually sending it. Is this possible?
Reason is that I want to delay sending the JMS messages until my
database transaction has been comitted, but I already want to record
the message IDs as correlation IDs in exactly
you would need to pass use your own message impl that extends
ActiveMQMessage and override
org.apache.activemq.command.ActiveMQMessage#onSend
on that callback, you will have the messageId and be able to commit
the db transaction. On return from that method the message will be
sent.
be sure and
Hi,
ok I see, but this is only possible if sending is done directly before
committing the database transaction. It wouldn't work so well if
sending was done somewhere during the process. I had hoped that I
could feed something along a UUID as the message ID and it would be
used then, but I can
