Hi, Gary,
I just tried that. The network connector hasn't that property, just the
connection. we have set this on the connection factory in our client and
server sample application but it did not improve the issue.
Cheers,
Kai
2012/3/13 Gary Tully
> one other thought, assuming non duplex, if y
one other thought, assuming non duplex, if you set dispatchAsync=false
for your network connector, advisories should always reach the other
broker before messages.
On 12 March 2012 22:21, Gary Tully wrote:
> I think that is a reasonable theory, depending on load, the order or
> reaction to adviso
I think that is a reasonable theory, depending on load, the order or
reaction to advisories may not be totally reliable.
One way to validate your theory is to enable the
sendAdvisoryIfNoConsumers option and subscribe to that advisory to see
if your messages end up there. The message will be the pa
Hello,
- Given a network of V5.5.1 brokers named "brokerA" and "brokerB", and
- application "serviceA" is connected to "brokerA" and subscribed to a
"request" topic and ready to produce on a "response" topic, and
- client application "clientB" is connected to "brokerB", and
- named client is first
You could leave out the second uri.
How to set the "options" varies with AMQ version, see:
http://activemq.apache.org/failover-transport-reference.html
(I presume you are looking at an unreleased 5.6.x snapshot as you are
specifiying "-1".)
However, if you leave out the maxReconnectAttempts "opti
Thanks for the help. Works as expected now.
colomb
On Sat, Mar 10, 2012 at 7:29 AM, Rob Davies [via ActiveMQ] <
ml-node+s2283324n4462038...@n4.nabble.com> wrote:
> Unfortunately - when you disable persistence in the broker, it also
> prevents any use of storage to disk. I suggest you don't set
If you do
telnet 192.168.100.11 61616
from the client machine, you should get back the openwire handshake from the
broker.
If you don't, it's probably not an activemq problem, rather a configuration
issue.
Are you happy to change the broker connector to
tcp://0.0.0.0:61616
i.e. *INADDR_ANY *
this looks like something that is missing, there is no
org.apache.activemq.broker.region.policy.SubscriptionRecoveryPolicy
that will peek at the topic store, they are all memory based so they
don't survive a restart.
What is needed is a
org.apache.activemq.broker.region.policy.SubscriptionRecovery
Sure thing, thanks!
https://issues.apache.org/jira/browse/AMQ-3762
Larry
On Mon, Mar 12, 2012 at 5:11 AM, Dejan Bosanac wrote:
> Hi Larry,
>
> can you raise a Jira for this, so it doesn't get lost in the emails.
>
>
> Regards
> --
> Dejan Bosanac
> Senior Software Engineer | FuseSource Corp.
>
Hi Larry,
can you raise a Jira for this, so it doesn't get lost in the emails.
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dej...@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.mannin
Hi,
unfortunately this will not work as with exclusive consumer only one
consumer will get all the messages, so concurrentConsumers will have no
effect.
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dej...@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @de
11 matches
Mail list logo
