Hi,
It's been quite some time now and I just wanted to follow up for
archiving purposes. Since we updated everything to 5.13, we don't see
the issue any more. I am convinced it had been caused by the 5.7
client library.
Best regards,
Martin
On Sat, Jan 9, 2016 at 6:24 AM, Tim Bain wrote:
> Grea
Great, thanks for reporting back.
Tim
On Fri, Jan 8, 2016 at 1:04 PM, Martin C. wrote:
> Hello,
>
> sorry for the late response, missed the message. We are currently very
> confident that the issue was triggered because one of the client
> applications was still using a very old 5.7 library to
Hello,
sorry for the late response, missed the message. We are currently very
confident that the issue was triggered because one of the client
applications was still using a very old 5.7 library to connect to the
5.12 broker. Once we updated the client library in that particular
application, thing
Martin, did you ever resolve this issue?
If not, I'd recommend looking at the messages that expire to see if there
is a pattern to them.
Also, do you have a single broker, or a network of brokers? If the latter,
what is your networkTTL set to?
Tim
On Dec 2, 2015 9:50 AM, "Martin Carpella" wrot
I just took a stack trace from my box and I'm seeing this:
Thread 7: (state = BLOCKED)
Thread 6: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
imprecise)
- java.lang.ref.ReferenceQueue.remove(long) @bci=44 (Compiled frame)
- java.lang.ref.Reference
Double-check that the consuming processes are trying to consume messages.
Looking at a stack trace should do the job. Look for a thread waiting to
receive a message. If none can be found, then the consumers may be too busy
doing other things to pull the messages.
--
View this message in conte
I do have a network-of-brokers. When you say restart the broker, I'm not
sure what you mean. When I restart the application that has the consumers
it clears the jam.
I doesn't happen all the time. It will run 3-4 days without happening and
then might happen a couple days in a row. Our process
That problem actually happens commonly and there are many possible causes.
Is a network-of-brokers involved? Does restarting the broker clear the
"jam"? Does it happen all of the time?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-Stuck-in-Queue-tp4688438p46
Currently we are using 5.6.0. :
Setting in the server side:
Consumer is AUTO_ACH, and prefetch = 100.
there was not any error in the server and consumer, but there are 100
message in QUEUE, is pending, but the new message continue in and consumed
by the consumers.
Any fix or sett
In JMX, can you see the subscriptions? Are they growing at all? Are the
numbers of subscriptions consistent with the numbers expected?
One thing that may help - check the stack traces on the broker and clients.
Things to look for: are there consumer threads active on the clients? Is
the broker
two config options to disable some (possibly related) thread
complexity broker side:
On 4 April 2014 03:48, Yin Wang wrote:
> Can you try to disable cache consumer option?
> Or can you use a plain jms consumer to try to reproduce the issue?
> Just guess it's maybe
Can you try to disable cache consumer option?
Or can you use a plain jms consumer to try to reproduce the issue?
Just guess it's maybe related with cache consumer and spring jms template.
2014-03-29 4:19 GMT+08:00 lookers :
> Just checked the queuesize and it is increasing when it is blocked.
>
Just checked the queuesize and it is increasing when it is blocked.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-5-9-0-tp4679266p4679651.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Thanks again Artnaseef,
Just to answer your questions:
no it is not a network of brokers. Standalone broker,producer,consumer.
The producers is using failover in the connection URL. Yes the messages are
persistent and use transactions.
No, I'm not using JMSXGroups.
I think that I posted a stack
That helps. Is this a network of brokers? Are clients using transactions?
In addition to the diagnostics Gary mentioned, grabbing a stack trace when
this happens may be helpful.
Are JMSXGroups in-use?
Also, are the producers using the failover transport, or using any other
technology that migh
Hi Artnaseef,
Unconsumed messages are detected with the application which is time
sensitive is not updating.
I am sure that there is data in the queue. When blocked for a period of time
the enqueue will increase until the broker is restarted. The data payload is
time stamped to I can tell that
I recommend taking a step back and looking at a few fundamentals.
First, how are unconsumed messages on the queue detected? The following
seems to indicate there are none (pagedInMessage.size 0):
{noformat}
ReceiveQueue toPageIn: 200, Inflight: 0, pagedInMessages.size 0,
enqueueCount: 120149, de
Hi gtully,
here is the output of the consumer when it fails
27/03/14 12:35:39 - [TRACE,MessageListenerAdapter:360] No result object
given - no result to handle
27/03/14 12:35:39 - [TRACE,TransactionSynchronizationManager:140] Retrieved
value
[org.springframework.jms.listener.LocallyExposedJmsReso
On a tcp transport url, client or broker.
tcp://localhost:2345?trace=true
If broker side all commands are logged. If client side it is per connection
in the clients log.
On 26 Mar 2014 09:09, "lookers" wrote:
> Hi gtully
> where do you put the trace = true parameter. Is it on the consumer?
>
> R
Hi gtully
where do you put the trace = true parameter. Is it on the consumer?
Regards
lookers
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-5-9-0-tp4679266p4679528.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Hi,
Please find attached a log file and thread dump of the incident. The freeze
happen around 08:13:51.
I am using openwire to connect to the broker
failover:(tcp://localhost:2345,tcp://localhost:2345)?initialReconnectDelay=100&randomize=false
and consumer url
tcp://localhost:2345
activemq.l
Hi,
I am unable to view messages in the queue through the JMX console when it is
stuck
I can browse other queues in the same broker though.
lookers
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-5-9-0-tp4679266p4679390.html
Sent from the ActiveM
There are no message selectors on this queue. There are on others, but they
are processed in a different thread.
There is just one consumer and it consumes messages in FIFO manner.
they are consumer using spring jms template.
--
View this message in context:
http://activemq.2283324.n4.nabbl
any message selectors?
Is it just one consumer that does not get messages? Are they stomp/operwire?
I think the best bet to understand what is going is to capture full
trace logging.
Also trace=true on the openwire (or relevant) tcp transport url.
Possibly a broker side thread dump. Any chance t
There is no ttl on the messages. I have not tried browsing with JMS when
they are stuck. I can try that when it fails again
No there is nothing in the DLQ for this queue.
It is happening quiet regularly. At lease twice a day. I have similar
environment set up of different instance and it does not
that looks fine. Is there a ttl on the messages, anything in the DLQ?
Can you browse the messages via jmx?
On 20 March 2014 14:36, lookers wrote:
> Hi gtully
>
> Here is a line in the logs with
> ReceiveQueue toPageIn: 200, Inflight: 0, pagedInMessages.size 0,
> enqueueCount: 120149, dequeueCount
Hi gtully
Here is a line in the logs with
ReceiveQueue toPageIn: 200, Inflight: 0, pagedInMessages.size 0,
enqueueCount: 120149, dequeueCount: 113644 |
org.apache.activemq.broker.region.Queue | ActiveMQ BrokerService[localhost]
Task-619
This was when the messages are stuck
Does this give you an
is the inflight count 0 in the jconsole jmx view for your consumer?
enable trace level logging for org.apache.activemq.broker in log4j and
use jmx to have it refresh the log4j config - a broker operation.
send another message to that dest and see what is in the logs.
in other words, jmx and logg
Have you a network connector? If yes did your network connector loss
sometimes the connection to the server broker?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3495716.html
Sent from the ActiveMQ - User mailing list archive at Nabble.co
We solved the problem by upgrading the server to 5.4.2.
Not running combination:
Solaris 10 Sparc
JDK 1.6.0_24
ActiveMQ 5.2.0
Running combination:
Solaris 10 Sparc
JDK 1.6.0_24
ActiveMQ 5.4.2
No more hickups in the last 2 days. *Knock on wood*
--
View this message in context:
http://activemq
there is a prefetchSize attribute for that on the NetworkConnector
xbean, inherited from
org.apache.activemq.network.NetworkBridgeConfiguration
On 3 May 2011 15:08, lernen.2007 wrote:
> I think the problem is that the there is no prefetchSize option for
> networkconnector and that can be the reas
I think the problem is that the there is no prefetchSize option for
networkconnector and that can be the reason why the messages stuck.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3492540.html
Sent from the ActiveMQ - User mailing list
Hi,
we are using prefetch=0 with Spring, works well, still we are seeing
the same issue but for _non-persistent_ messages. (With prefetch=0 and
with prefetch=1.) Any ideas if this could correlate to the issues
mentioned here?
As an interesting side-effect, the consumption starts again if we
delet
Unfortunately, we do not use selectors. Just a plain Queue where a producer
sends Text Messages and a consumer is listening to the queue to consume the
messages. Nothing advanced on my site.
And I see no error messages in my logfile. Just the wrong behaviour . Really
Annoying.
--
View this messa
The Testcase what I get from you can reproduce the problem.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3489873.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Erpolat, at this stage do you have a reproducedable junit test case?
On 28 Apr 2011 16:59, "lernen.2007" wrote:
> We experiment with all settings and the messages stuck further. We can not
> need a messaging system in which the messages stuck.
>
> --
> View this message in context:
http://activemq
We experiment with all settings and the messages stuck further. We can not
need a messaging system in which the messages stuck.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3481443.html
Sent from the ActiveMQ - User mailing list archive
FWIW we experienced the same issue when using a single queue with selectors.
Simply moving to multiple queues without selectors resolved the issue. Most
definitely related to the default page size setting others have mentioned, but
we didn't have time to experiment with different settings.
YM
Great to find this thread. This is exactly my own setup and we have exactly
the same problem here.
The backend db is a Oracle DB and we run into this situation frequently. We
see some messages in the admin view. When we try to look into them, no
messages are shown on the detailed view of the Admi
I changed to AUTO_ACKNOWLEDGE too but same situation etc. message stuck
further.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3449715.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
you need the tests dependency:
${project.groupId}
activemq-core
test-jar
test
On 14 April 2011 10:32, lernen.2007 wrote:
> I want to execute the test class
>
> BrokerNetworkWithStuckMessagesTest
>
>
> the following class are not found
>
> Wait
> StubConnection
I want to execute the test class
BrokerNetworkWithStuckMessagesTest
the following class are not found
Wait
StubConnection
I bind the jar file activemq-all too and but it doesn't can bind this
classes.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-
:57 AM
To: Nakarikanti, Nageswara
Subject: Re: Messages stuck in queue
Can this exception be the reason for stuck of messages:
Async error occurred: java.lang.IllegalArgumentException: The subscription
does not exist: ID:n11-1681-1159779699684-5:1:1:1
If you
Can this exception be the reason for stuck of messages:
Async error occurred: java.lang.IllegalArgumentException: The subscription
does not exist: ID:n11-1681-1159779699684-5:1:1:1
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3447558
But there a confusion in lernen.2007's previous reply message that he could
reproduce the problem
How can a producer get messages when you shutdown a consumer.
The description of the problem is "When a consumer is active and eagerly
looking for messages, AMQ queues won't deliver messages that we
that is great progress, can you turn that into a junit test case?
In that way it will be obvious what the exact use case is, including
configuration and we can commit the test to protect any changes that
ensue.
There is an existing test case that may provide you with a good
template. If that does
I could reproduce the problem. Following situation:
Producer(Client) Consumer(Server)
NetworkConnector
I shutdown the consumer and the producer get messages further. If I start
the connection between producer and consumer again then at first I see the
followin
I tested it further and it is only a problem if we send messages over gsm
with lan it works fine.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3444072.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
I test it with prefetch=0 and prefetch=1 and a lot of messages stuck further.
Can you say me which activemq version should I use that there no messages
stuck?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3441189.html
Sent from the Active
I will try following:
and then I report the result if the messages stuck further or not.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3435510.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
But in the link
http://activemq.apache.org/what-is-the-prefetch-limit-for.html it is stated
that
"When using Spring JMS and MessageDrivenPojo, you cannot use a prefetch of
0, so use 1 instead." and we are using 1 for prefetch.
-Nag.
--
View this message in context:
http://activemq.2283324
The messages stuck not only if a active consumer get the messages. We have
the same effect by a active network connector too.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3433825.html
Sent from the ActiveMQ - User mailing list archive a
one other thought is to use a prefetch=0 such that any cached
consumers are out of the mix.
On 7 April 2011 15:53, lernen.2007 wrote:
> The problem should be resolve as soon as possible. Otherwiese we must look
> after an another messaging system.
>
> --
> View this message in context:
> http://
Hi Gary,
I am trying my level best to give you right inputs.
Please go through the below link where at the last I provided a scenario
http://activemq.2283324.n4.nabble.com/Message-stuck-on-queue-td3338786.html#a3341660
when that scenario was happening I captured the log and he
The problem should be resolve as soon as possible. Otherwiese we must look
after an another messaging system.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3433651.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
I see only that the application try following:
011-04-07 15:14:14,780 | DEBUG | Executing SQL: DELETE FROM ACTIVEMQ_MSGS
WHERE ( EXPIRATION<>0 AND EXPIRATION web console shows that but if we want to
see in queue then there was no messages but in database we had all 57
messages.
2.We restart activ
No Guys,
till yesterday, we have been facing the same problem with 5.2.0 version and
upgraded to 5.4.2.
After reading your posts, I am really afraid how we can survive in
production, Please look into this issue links i created.
http://activemq.2283324.n4.nabble.com/Message-stuck-on-queue-td3338
is there any correlation between the memory limit and the message
getting stuck. Can you remove the limit and see if you can reproduce
or increase the limit. Also, if you enable trace level logging and can
reproduce there may be some interesting information in the log. If so,
please share.
If you
The same problem we have with the latest activemq version 5.0.0 too. Have you
any idea how we can resolve this problem?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3433435.html
Sent from the ActiveMQ - User mailing list archive at Nabbl
That doesn't help further. I think that is a bug in activemq. The version
5.3.1 hasn't problem with that.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-tp3244342p3250840.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Here's my setup using 5.4.0
I'm not sure if it will solve your database storage is
That doesn't help. I use not kahadb. As persistence I use the jdbc adapter.
There is a part of my configuration:
We had a similar issue with 1 message getting stuck on the queue using
kahadb.
we added useCache="false" and the problem was solved.
I think this is the link, cant confirm as apache jira down at the moment.
https://issues.apache.org/jira/browse/AMQ-2955
https://issues.apache.org/jira/brow
Quick follow-up: After another restart, JMX reported the queue size as 75 for
over a day, but now the queue size is -17. How reliable is this metric?
On Dec 1, 2010, at 2:04 PM, Geoffrey Arnold wrote:
> Hello us...@!
>
> We have a queue defined in an embedded broker that when viewed through th
I wonder if you could try reproducing this issue on the latest 4.1
branch - as we will release 4.1.1 soon with some fixes in this area
On 2/21/07, David Kendall <[EMAIL PROTECTED]> wrote:
I am testing failover scenarios with ActiveMq 4.1 and with Shared File
System
Master Slave. The failover se
65 matches
Mail list logo
