I see a bunch of these messages in the logs of Node-2 :
2017-11-13 15:30:06,506 | INFO | Establishing network connection from
vm://SecondaryBroker?create=false=false to tcp://x.x.x.x:61616 |
org.apache.activemq.network.DiscoveryNetworkConnector | ActiveMQ Task-4
2017-11-13 15:37:49,129 | INFO |
name,destinationType=Topic,type=Broker","attribute":"DequeueCount","type":"read"},"value":0}
I had used same configuration in my test environment before rolling into
production and in my test env, my subscriber would always receive the
messages sent
I want to monitor my broker using JMX MBeans; useJmx is set to true. I use
AMQ v 5.14.5. I have a few questions:
a) How can I get current connections count? I see TotalConnectionsCount but
I think this gives a count of all connections since the broker was started
even if the connection is no
Hi Abhishek,
Did you figure out why flow control got triggered even though flow control
was disabled?
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Hi Tim,
The log content quoted in my post was from broker log.
I'll try to reproduce this in a test environment. Meanwhile if you could
think of any common (generic) reasons why broker may becomes unresponsive,
please share.
Thanks,
Shobhana
--
Sent from: http://activemq.2283324.n4
@clebertsuconic, ActiveMQ also supports NIO and we have already configured to
use it. How is this different from that supported in Artemis?
--
View this message in context:
Tim, each client process will open just one connection.
There can be hundreds of thousands of different client processes (as many as
no of users using our app) connected to the broker at the same time.
In another thread
Hahah .. that's okay :-)
I have never used JVisualVM; will understand how to use this tool and report
my observations. Thanks for all inputs so far!
--
View this message in context:
We use a single AMQ broker (using 5.14.1 version) node to exchange MQTT
messages between our server and apps running on mobile devices (both Android
and iOS).
The app establishes a connection with AMQ broker using Eclipse Paho client
lib. To be able to receive messages as soon as they are
Tim, full GC takes 8 seconds, not 8 minutes.
Also, after full GC, large amount of memory is reclaimed (13G to <2G) :
2017-05-17T14:01:46.179+0530: 34205.488: [Full
GC2017-05-17T14:01:46.179+0530: 34205.488: [CMS:
13039360K->1895795K(26214400K), 8.5260340 secs]
13578056K->1895795K(27158144K),
Is "Fresh KahaDB" equivalent to deleting the entire contents of KahaDB
folder? If yes, we do this every early morning to prevent the issue, but it
has never helped us!
--
View this message in context:
>From last 3 days' GC logs I observe something consistently :
When full GC happens which takes about 8 and odd seconds, 15 minutes later
our servers loose connection to the broker; all further attempts to
reconnect fail with "Timeout" exception. New connection attempts also fail
with same
I observed closely for last 3 days, but couldn't identify anything wrong with
CPU, memory, Network I/O, Disk I/O, etc
a) CPU usage on this EC2 instance (has 8 vCPUs) has never crossed 35%
b) Memory usage varies between 1GB to 18 GB (Total available is 32 GB and
Xmx assigned for this broker process
destination is holding up which journal file. Any help will be greatly
appreciated.
P.S : We use AMQ 5.14.1 and exchange MQTT messages mostly (thousands of
topics will be created on the fly and both persistent and non-persistent
messages are exchanged over these topics) and a few JMS messages
duction server where I cannot enable trace or JMX.
Is there any other way to identify what is causing this issue?
TIA,
Shobhana
--
View this message in context:
http://activemq.2283324.n4.nabble.com/KAHADB-clean-up-old-log-files-tp4716661p4717977.html
Sent from the ActiveMQ - User
enable trace or JMX.
Is there any other way to identify what is causing this issue?
TIA,
Shobhana
--
View this message in context:
http://activemq.2283324.n4.nabble.com/AMQ-5-13-2-Kaha-DB-logs-cleanup-issue-tp4712046p4717976.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
We are using AMQ version 5.14.0 and we have observed that sometimes, the
messages don't get delivered from the topics to active durable subscribers
(Android app connected via MQTT). I observed following log when this
happened in our production server :
Transport Connection to: tcp://x.y.z.a:2686
When checked using the Jolokia Rest APIs, I get same result ... enqueued
message count on these topics show 0; so I guess the Jolokia Rest APIs also
give only stats since the broker started last.
--
View this message in context:
Sure, I'll check when I have some time.
Btw, I tried to use JConsole to view the current status of consumers. I
tried hard getting JConsole to connect to my broker that runs on an EC2
instance, but couldn't succeed. Can I use the Jolokia Rest APIs instead? Do
these APIs give same result as JMX
Thanks Tim, I did not know that the stats are reset when the broker is
restarted. I'll check how to use JConsole to view the current status of
consumers.
Yes, all topics have durable subscribers.
I used the logic mentioned in the example given at
We use AMQ to exchange MQTT messages. I observed that the log files in Kaha
DB don't get deleted even after many days.
I used the steps mentioned in
http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html
In our production environment, we use AMQ broker with Kaha DB persistence. We
have set the following in broker configuration:
schedulePeriodForDestinationPurge="60"
offlineDurableSubscriberTimeout="25920"
offlineDurableSubscriberTaskSchedule="360"
Sometimes, I have observed that
No Tim, there are no more stack traces. Maybe the implementation of
TopicMessageStore.recoverNextMessages() just throws a new ClassCastException
?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ClassCastException-while-subscribing-to-a-topic-tp4710870p4711256.html
Sent
Sorry Tim, I don't know how to reproduce this issue.
After this issue happened, I restarted AMQ broker by deleting the whole data
directory. I have been observing AMQ logs, but haven't found this issue
again.
Another point to note : Our app will try to subscribe again if subscription
fails for
]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_95]
a) What is the reason behind this error? Under what conditions is this
triggered?
b) Why is this surfacing now after AMQ has run fine for 3+ weeks?
c) Is this fixed in 5.13.2 version?
Any inputs will be appreciated.
Thanks,
Shobhana
--
View
I looked at only the thread dumps. I will profile with some profiler first
and see where is the broker spending more time.
--
View this message in context:
Hi Tim,
I said indexing was the point of contention after seeing that Thread
"ActiveMQ NIO Worker 169" was still working on
org.apache.activemq.store.kahadb.MessageDatabase.updateIndex even after >
3.5 minutes.
These are full thread dumps. I guess the lock (read lock) is held by threads
ng them.
>
> On Mon, Apr 4, 2016 at 5:01 PM, Shobhana <[hidden email]
> > wrote:
>
> > If you can enable advisories, you can use the solution suggested above by
> > Tim.
> >
> >
> >
> > --
> > View this message in context:
>
If you can enable advisories, you can use the solution suggested above by
Tim.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Is-there-a-way-to-be-notified-when-a-durable-subscriber-receives-a-MQTT-message-tp4710173p4710345.html
Sent from the ActiveMQ - User mailing
Thank you Tim!
In our production env, we have disabled advisories since the number of
destinations are already high in number and we have this issue
Publisher sends a persistent message to a topic which has more than one
durable subscribers. One or more of these durable subscribers may be offline
when the message is sent. Is there any way to get notified when the message
is delivered to all subscribers?
--
View this message in context:
/n4710055/histo.txt>
What are these org.apache.activemq.management.CountStatisticImpl instances?
Is there any way to avoid them?
Thanks,
Shobhana
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-with-KahaDB-as-persistent-store-becomes-very-slow-alm
Thank you Christopher for your suggestion. I'll check this with 5.13.2
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-with-KahaDB-as-persistent-store-becomes-very-slow-almost-unresponsive-after-creating-large-s-tp4709985p4710043.html
Sent from the ActiveMQ -
Thank you Tim for super-quick response :-)
I will check this option.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Support-for-setting-default-message-expiry-for-MQTT-messages-tp4710015p4710018.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
ubscribers even if
there are unconsumed messages?
b) Is there any better mechanism to achieve the desired result?
Appreciate any help.
Thanks,
Shobhana
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Support-for-setting-default-message-expiry-for-MQTT-messages-tp4710015
I enabled debug logs to see what was happening when AMQ could not send ACK
within 30 secs. I started the AMQ broker on 28-Mar around 17:40 and to my
surprise, I find that the server startup is still going on even now at
29-Mar 09:30 (~16 hours!!). I see a lot of following messages in the logs :
am not using the right AMQ configurations, but I am not able to
figure out which config is missing/wrong.
Any help / pointers would be greatly appreciated!
Thanks,
Shobhana
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-with-KahaDB-as-persistent-store-beco
any solution or workaround to get rid of this problem?
Thanks,
Shobhana
--
View this message in context:
http://activemq.2283324.n4.nabble.com/MQTT-Link-Stealing-tp4682263p4701866.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
39 matches
Mail list logo
