A JMS message has to be acked to remove it from its queue or topic. Since
you have two queues, if a message goes to both queues you need to ack the
copy from each queue. If it only goes to the first queue, you only need to
ack it there.
The default acknowledgement mode is AUTO_ACK, where the message is
automatically acknowledged when it is first delivered to you (before you
have processed it), and that's the mode it sounds like your Camel route is
using. So the message is acknowledged when it exits your from tag, and if
you want to drop it, you just need to not route it onward to the second
queue. So you should test the message for your criteria of which messages
you want to process, and conditionally route to the to tag (if the message
passes) or end the route without routing the message anywhere (if it
fails). Or instead do what Quinn suggested and route to a new topic with
no consumers in the second case, so you can wiretap in when necessary.
Tim
On Jun 24, 2016 6:03 AM, "daelliott" <my_fo...@outlook.com> wrote:
> Currently the configuration is just pulling from a remote queue to a local
> queue and that is it.
> The Camel XML config file just has a FROM and TO XML tag.
> Some changes are being made upstream that will send messages to my system
> that I may not want.
> That is the reason for wanting this filtering.
>
> The DLQ is currently used if the message can't process so we can do some
> root analysis on it and fix it.
>
> The consuming executable application of the local queue is set to
> Individual
> ACKs of messages.
> How the messages are ACK'ed from the remote server I don't know as there is
> only the "from" and "to" tags.
> You mentioned to ACK the message after consuming it. I'm guessing you meant
> in the consuming executable application.
> If you did, I was hoping to get the message from the remote server and
> filter it out before having it hit the persistent
> storage in ActiveMQ and that way the consuming application doesn't have to
> deal with it at all.
>
> From some of the responses and what I have found online, the following seem
> to be true
> * There is no /dev/null or anything remotely related - I have to route
> the
> message somewhere I create
> * I have to create something to process that queue in some fashion to
> clear it out
>
> Could someone address the retrieving of the property?
> Does that look right?
> <simple>${in.header.FirstProperty}='msgType1'</simple>
>
> Thanks
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Help-with-Camel-Config-routing-using-a-custom-ActiveMQ-Message-Property-tp4713278p4713313.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
