Hi Christian,
Correction to what I stated earlier.
In this route with "producerWindowSize" set in broker-config.xml
<from uri="file:/opt/share/EventFileInput?move=.event-done"/>
<setHeader headerName="messageType">
<simple>MICS</simple>
</setHeader>
<to uri="jms:queue:queue.incomingEvents"/>
There were messages Queued in DLQ and (memory limit has been exceeded or
very close to exceeding)
The above route was attempting to publish to Q incomingEvents.
I was assuming that consumer was 'locked/stalled' -
but at this point in time there were no messages in incomingEvents Queue ~
so nothing for the consumer to consume really (my consumer will consume only
from incomingEvents). So don't really think Consumer was blocked (my lack of
understanding there)
I can understand why messages were not published to Q incomingEvents
(because broker's memory limit was exceeding) and we are requesting producer
to hold back (since memory limit close exceeding)
Only issue is - why were the messages still moved from
file:/opt/share/EventFileInput (shouldn't it have ideally rolled back?) -
until DLQ is cleared up?
regards
D
(though the 'to uri' appeared to do nothing)
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Query-around-ActiveMQ-DLQ-tp4666277p4667076.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
