sorry, yes, there is one more piece to the puzzle. The temp
destinations need to have a well known naming convention and there
needs to be a wildcard static include in the network bridge to have
matching destinations propagated.
Have a look at the test case to see an example of the xml config requ
So I tried that and the client appears to be sending just fine, but the
producer on the other side of the network connector that expects to hear
back via the temp queue is not receiving the message.
Chris
On Wed, May 16, 2012 at 1:27 AM, Gary Tully wrote:
> you need one additional bit of config
mickhayes wrote
>
> Wondering if anyone has a wireshark plugin or similar for the OpenWire
> protocol that they are willing to share?
>
Hi Michael,
Yes Wireshark supports the OpenWire protocol.
You need the "development version", and least version 1.7.1.
Please share any findings, problems, e
I have a question concerning the consumption process on hierarchical queues
in combination with wildcards.
Defined Queues: "A.B.C.D"
Subscribers subscribes to "A.B.>"
Now messages are published to C and D.
In which order does the subscriber receive the messages?
First all messages from C and th
you need one additional bit of config, to disable the connection from
tracking temp destination advisories so that it allows the request to
go to the broker.
factory.setWatchTopicAdvisories(false);
or ?jms.watchTopicAdvisories=false on the connection factory broker url
On 15 May 2012 23:30, Chris
