I added following config
and tried to send a messaage of 150 MB, it failed with following message
Failed to send the message on '/queue/testDSize.0' (error: ***
Net::STOMP::Client::IO::send_data(): cannot syswrite(): Broken pipe); will
try to failover and resend
[20150122 16:05:26.33
/queue/testDSize.0' (error: ***
Net::STOMP::Client::IO::send_data(): cannot syswrite(): Broken pipe); will
try to failover and resend
[20150122 16:05:26.335 XYZ::Net::Stomp::_failover_to_new_broker():939 WARN]
Failing over to the new broker with the uri:
failover://(stomp://localBroker:61613)?m
[20150122 13:06:44.729 IST (ActiveMQ Transport: tcp:///ip:41961@61613)
org.apache.activemq.transport.stomp.ProtocolConverter#handleException 280
WARN] - Exception occurred processing:
null
^@: org.apache.activemq.transport.stomp.ProtocolException: The maximum data
length was exceeded
[20150122
tbain98 wrote
> So what happens when the subscriber comes back online? Are other messages
> delivered, just not the ones that were sent while the subscriber was
> offline? After the subscriber comes back online, do you still see those
> messages pending in the JMX stats and/or the web console? I
What kind of stats did you have in mind?
On Jan 22, 2015 12:15 AM, "bansalp" wrote:
> I have started using virtual topic in myActiveMQ setup and I was wondering
> if
> there are any stats available for virtual topic which I can log.
>
> --bansalp
>
>
>
> --
> View this message in context:
> http:
JMX exposes MBeans for each subscription (which is a connected consumer in
the case of queues), and one of the attributes is the selector for that
subscription. So you can periodically connect to the broker's JMX
endpoint, query for all subscriptions, and log each one including its
selector.
On Ja
That's strange. Is this a network of brokers or a standalone broker?
Also, can you reliably reproduce this (in a rest environment) just by
turning advisory messages back on? That test would confirm (or refute) the
link between advisory messages and the problem, and make it more likely
that someo
Stats like
- List of topics which are virtual.
- which all queue are consumer queue for each virtual topic.
- Message size and count related stats for consumer queue.
- Any other stats that is exposed.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Stats-for-Virtual-To
Can this be done from java code. I am extending BrokerPluginSupport to log
certain stats related to broker and per destination stats.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Stats-for-selector-tp4690236p4690264.html
Sent from the ActiveMQ - User mailing list arch
Hi,
Tks for the answer. It works perfectly
Kind Regards
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Non-Persistent-Queue-tp4690148p4690270.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Hi,
I'm trying to use the "maxReconnectAttempts" parameter, but without success.
I'm using a client connection with the following URI:
failover:(tcp://localhost:61616,tcp://localhost:61626)?randomize=false&useExponentialBackOff=false&initialReconnectDelay=1000&startupMaxReconnectAttempts=40&maxR
It's a standalone broker. Unfortunately, I cannot reproduce the problem in a
test enviroment, mainly because I cannot generate all the traffic the
production broker has to support. Anyway, within the limits of a test
simulation, the presence or not of Advisory topics seemed not to influence
the beh
On 01/22/2015 09:35 AM, nelsoncc wrote:
Hi,
I'm trying to use the "maxReconnectAttempts" parameter, but without success.
I'm using a client connection with the following URI:
failover:(tcp://localhost:61616,tcp://localhost:61626)?randomize=false&useExponentialBackOff=false&initialReconnectDelay
by default the broker retains the sub in memory for an offline durable
sub, that can be disabled with keepDurableSubsActive=false broker
attribute. That may sort out the behaviour because the sub will be
replayed from the store.
One other thought, there was an issue with the default advisory
consum
Tks for your quick feedback. So what configuration should I use in the client
so it tries to reconnect always once, even if the broker is down?
Kind Regards,
Nelson Cintra
--
View this message in context:
http://activemq.2283324.n4.nabble.com/maxReconnectAttempts-parameter-tp4690272p4690281.ht
On 01/22/2015 10:04 AM, nelsoncc wrote:
Tks for your quick feedback. So what configuration should I use in the client
so it tries to reconnect always once, even if the broker is down?
Kind Regards,
Nelson Cintra
--
View this message in context:
http://activemq.2283324.n4.nabble.com/maxReconn
That parameter is what I'm using, but it ignores the parameter and never
reconnects again.
Kind Regards
--
View this message in context:
http://activemq.2283324.n4.nabble.com/maxReconnectAttempts-parameter-tp4690272p4690283.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Have you looked at what's exposed in JMX (e.g. in JConsole)? Are those
things not available for virtual destinations? (I don't use them, so I
don't know.)
On Jan 22, 2015 6:55 AM, "bansalp" wrote:
> Stats like
> - List of topics which are virtual.
> - which all queue are consumer queue for each
On 01/22/2015 10:14 AM, nelsoncc wrote:
That parameter is what I'm using, but it ignores the parameter and never
reconnects again.
Kind Regards
--
View this message in context:
http://activemq.2283324.n4.nabble.com/maxReconnectAttempts-parameter-tp4690272p4690283.html
Sent from the ActiveMQ
JMX can be queried from Java code (from a separate program, not from the
broker itself). Just make sure you enable the JMX endpoint in the broker
config; details are on the ActiveMQ website.
I haven't done anything with BrokerPluginSupport, so I can't speak to
whether this is possible there.
On J
In Jconsole, there is nothing which says anything about virtual destination.
It will all topics and queues as normal only. There is no distinguishing
factor.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Stats-for-Virtual-Topic-tp4690237p4690287.html
Sent from the Activ
Hi,
If I use the URI:
failover:(tcp://localhost:61616,tcp://localhost:61626)?randomize=false
The thread blocks in sending message, and only unlocks when broker is
started.
Since I don't want to block the thread I can fix my problem using timeout
parameter.
I thought the reconnect attempt was mad
On 01/22/2015 11:00 AM, nelsoncc wrote:
Hi,
If I use the URI:
failover:(tcp://localhost:61616,tcp://localhost:61626)?randomize=false
The thread blocks in sending message, and only unlocks when broker is
started.
Since I don't want to block the thread I can fix my problem using timeout
parameter
Good find - thanks for the reference!
--
View this message in context:
http://activemq.2283324.n4.nabble.com/How-to-send-a-struct-via-ActiveMQ-CMS-tp4689843p4690292.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Well, the default configuration for Virtual Topics (
http://activemq.apache.org/virtual-destinations.html) specifies that all
topics that are virtual begin with "VirtualTopic." and all consumer queues
for virtual topics begin with "Consumer.*.VirtualTopic.", and even if
you've changed the default c
Hi,
we have the following problem with ActiveMQ:
we have some consumer code running in an app server and acknowledging
messages manually. ActiveMQ broker is running outside the app server as a
separate process. Everything is ok until we restart the broker. After we
restart it resends several (a fe
Tonight we got new experience with the problem:
before we restart ActiveMQ we looked at the messages in a queue and we saw
that the size of the queue was 0.
After having restarted ActiveMQ we looked at the messages in the queue again
and there were 4 messages from today morning. All 4 messages corr
What I mean is there is no indicator if I change defaults. All I can do is
remember all topics which I have configure as virtual along with their
consumer queue.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Stats-for-Virtual-Topic-tp4690237p4690309.html
Sent from the A
Two brokers networked.
Transport connectors configured on both with:
*rebalanceClusterClients="true" updateClusterClients="true"
updateClusterClientsOnRemove="true"*
network connector properties
*suppressDuplicateQueueSubscriptions="true" conduitSubscriptions="true"
decreaseNetworkConsumerPriorit
29 matches
Mail list logo
