Maybe some more logging will help identify the root cause.
Enable TRACE level logging for the following packages:
org.apache.activemq.broker.region
org.apache.activemq.network
org.apache.activemq.command
and open a ticket and attach the log if you can still reproduce.
On 17 May 2012 23:32, Chris
I've been able to successfully reproduce the issue in a dev environment,
but it's hard to identity exactly what is causing it. It is almost like it
is a race condition of some kind.
On Wed, May 16, 2012 at 10:27 PM, Gary Tully wrote:
> sorry, yes, there is one more piece to the puzzle. The temp
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
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
I tried that last suggestion and it appears as though
the allowTempAutoCreationOnSend is not working. The client keep receiving a
"cannot send to a deleted destination" error.
Chris
On Mon, May 14, 2012 at 4:19 PM, Gary Tully wrote:
> this is expected, but the flooding impact should be minimal
I will give that a shot. Thanks.
But the reason I think something is wrong is that once the flooding starts,
it doesn't stop until I restart the activemq service on one of the
machines. The flooding occurs even if the session that created the queue is
long since gone. It only takes one request-rep
this is expected, but the flooding impact should be minimal with a
small number of brokers in the network and a reasonable number of
connections.
each network bridge will register interest in all temp destination
advisories, so that it will be in a position to receive messages for
those destinatio
Another interesting observation: as a test, I connected all producers and
consumers to MSTMIP102 (the machine that doesn't have the network
connector). I then started MSIPAP101 so that its network connector could
start and connect to MSTMIP102. Request request-reply works fine between
all producers
Here is the log from the latest run with the TTL down to 1. It still floods
after about 1 or 2 request-reply calls. It just seems to be alternating
between add temp queue and remove temp queue messages.
On Fri, May 11, 2012 at 9:52 AM, Chris Robison wrote:
> Yes, because we have a spoke and hub t
Yes, because we have a spoke and hub topology where a client in one spoke
may need to request info from a client connected to a different spoke. I
suppose I could lower that value.
On Fri, May 11, 2012 at 9:47 AM, Gary Tully wrote:
> Do you have a good reason to have networkTTL="5", if there is
Do you have a good reason to have networkTTL="5", if there is only one
broker, the default value of 1 will be fine.
On 11 May 2012 16:32, Chris Robison wrote:
> If it helps, I've attached the configuration files for both machines.
>
>
> On Fri, May 11, 2012 at 9:07 AM, Chris Robison
> wrote:
>>
If it helps, I've attached the configuration files for both machines.
On Fri, May 11, 2012 at 9:07 AM, Chris Robison wrote:
> One thing I have noticed though is that when I restart the broker on the
> other end, everything starts to work again until it floods again.
>
>
> On Fri, May 11, 2012 at
One thing I have noticed though is that when I restart the broker on the
other end, everything starts to work again until it floods again.
On Fri, May 11, 2012 at 9:05 AM, Chris Robison wrote:
> I'm on 5.6. And all brokers remain up and running.
>
>
> On Fri, May 11, 2012 at 8:48 AM, Gary Tully
I'm on 5.6. And all brokers remain up and running.
On Fri, May 11, 2012 at 8:48 AM, Gary Tully wrote:
> what version are you on?
> Is there any chance that the broker at the other end of the network
> bridge is shutting down?
>
> On 11 May 2012 14:34, Chris Robison wrote:
> > I have a network o
what version are you on?
Is there any chance that the broker at the other end of the network
bridge is shutting down?
On 11 May 2012 14:34, Chris Robison wrote:
> I have a network of brokers and I am using a request-reply system across
> that network, but I've noticed that after a few request-rep
16 matches
Mail list logo
