It's a fair point, and I've used both approaches in the past, but when you're
using the Spring framework for almost everything else then it's natural to
also use its messaging abstractions, and in most cases it does simplify JMS
usage and configuration. While looking into the persistence problem I
Two years on I saw the same thing, that Spring's JMSTemplate seems to ignore
non-persistent delivery configuration, and always sends as persistent.
Tracing through JMSTemplate it turns out that deliveryMode, priority, and
timeToLive are ignored during send() unless "explicit QOS" is enabled, ie.
jm
Thanks Tim
The subscriber URI is now:
activemq:tcp://HUSH7:61616?wireFormat.tightEncodingEnabled=true&transport.useLogging=true
but I don't see any log files. I must be missing something - do I need to
enable something else, or install a logger on the subscriber?
On the question of the underlyi
Thanks Tim
I don't think these additional messages are connection/subscribe related
though; I'm pushing 100 messages out of the publisher, one every second, and
see the same sequence between each message. Also the 243 packets come
immediately after the message, whereas I would have expected keep-a
I'm trying to calculate some approximate messaging bandwidth requirements for
a project which is planning to use ActiveMQ. It's a C#/.NET project so I'm
starting out with an NMS + Openwire assumption.
I have a test application which publishes topic messages. No text, just some
properties:
IMessa
