Sounds like you're wanting to implement a message-level audit trail? With
Camel, you could very quickly implement a wiretap message pattern
(http://camel.apache.org/wire-tap.html) and have the wiretap route the
tapped messages to a log4j appender. The appender's logfile could rollover
based on
Re AMQ-1648; it would be ideal to avoid as much as possible having to
evict/lose messages, because a queue or some other system resource has
reached its max capacity. Instead, you'd like to proactively monitor system
resources and invoke or trigger some action (e.g., whenever a resource
reaches a
Joe Fernandez wrote:
Sounds like you're wanting to implement a message-level audit trail? With
Camel, you could very quickly implement a wiretap message pattern
(http://camel.apache.org/wire-tap.html) and have the wiretap route the
tapped messages to a log4j appender. The appender's
Hello,
I have an architecture in which one or more message producers place messages
in a shared queue and a consumer pool processes the messages. While I can
use JMX to monitor the number of messages produced and consumed, the
messages are consumed so fast that I often can't browse them with
