[jira] [Commented] (ARTEMIS-3416) Message count is not zero even after all messages are consumed and acknowledged
[
https://issues.apache.org/jira/browse/ARTEMIS-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396775#comment-17396775
]
Justin Bertram commented on ARTEMIS-3416:
-
It's proving difficult to correlate your log with your screenshots. According
to the log 61 messages were sent to {{analysis_status}} and 41 were
acknowledged. However, according to your screenshot only 41 messages were sent
and 28 were acknowledged.
Also the code snippet you provided doesn't help much. I need something I can
run to reproduce what you're seeing. I think we're past the point now where
logs are going to be very helpful. Can you provide a minimal reproducible
example?
> Message count is not zero even after all messages are consumed and
> acknowledged
> ---
>
> Key: ARTEMIS-3416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3416
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
> Environment: Single artemis instance running as a K8s deployment with
> single replica on CentOS 7.9
>Reporter: Amit Herlekar
>Priority: Minor
> Attachments: artemis.zip, artemis.zip, artemis.zip,
> image-2021-08-06-17-19-37-446.png, image-2021-08-06-17-20-45-445.png,
> image-2021-08-06-17-24-45-732.png, image-2021-08-09-23-27-22-180.png,
> image-2021-08-09-23-29-38-568.png, image-2021-08-09-23-31-51-213.png,
> image-2021-08-10-15-49-59-960.png, image-2021-08-10-15-52-23-921.png
>
>
> We have switched from ActiveMQ Classic to ActiveMQ Artemis. Thanks to the
> nice documentation on github that we are able to containerize it and deploy
> it as a K8s deployment for [KEDA|https://keda.sh/docs/2.4/scalers/artemis/].
> Coming to the issue, we are using STOMP using stomp.py python module. The
> ACK-mode is set as client-individual and consumerWindowSize = 0 on the
> connection. We are promptly acknowledging the message as soon as we read it.
> The problem is, sometimes, the message count in the web console does not
> become zero even after all the messages are actually consumed and
> acknowledged. When I browse the queue, I don't see any messages in it. This
> is causing KEDA to spin up pods unnecessarily.
> Please refer to the screenshots attached.
> As a temporary arrangement, can you let me now how to make the delivery
> message count = 0.
> !image-2021-08-06-17-24-45-732.png|width=638,height=571!
> !image-2021-08-06-17-19-37-446.png|width=811,height=674!
> !image-2021-08-06-17-20-45-445.png|width=671,height=300!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3416) Message count is not zero even after all messages are consumed and acknowledged
[
https://issues.apache.org/jira/browse/ARTEMIS-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396763#comment-17396763
]
Justin Bertram commented on ARTEMIS-3416:
-
For what it's worth, you're using the wrong header for flow control on your
{{SUBSCRIBE}} frame. You're using {{consumerWindowSize}} and you should be
using {{consumer-window-size}} as indicated in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/stomp.html#flow-control].
> Message count is not zero even after all messages are consumed and
> acknowledged
> ---
>
> Key: ARTEMIS-3416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3416
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
> Environment: Single artemis instance running as a K8s deployment with
> single replica on CentOS 7.9
>Reporter: Amit Herlekar
>Priority: Minor
> Attachments: artemis.zip, artemis.zip, artemis.zip,
> image-2021-08-06-17-19-37-446.png, image-2021-08-06-17-20-45-445.png,
> image-2021-08-06-17-24-45-732.png, image-2021-08-09-23-27-22-180.png,
> image-2021-08-09-23-29-38-568.png, image-2021-08-09-23-31-51-213.png,
> image-2021-08-10-15-49-59-960.png, image-2021-08-10-15-52-23-921.png
>
>
> We have switched from ActiveMQ Classic to ActiveMQ Artemis. Thanks to the
> nice documentation on github that we are able to containerize it and deploy
> it as a K8s deployment for [KEDA|https://keda.sh/docs/2.4/scalers/artemis/].
> Coming to the issue, we are using STOMP using stomp.py python module. The
> ACK-mode is set as client-individual and consumerWindowSize = 0 on the
> connection. We are promptly acknowledging the message as soon as we read it.
> The problem is, sometimes, the message count in the web console does not
> become zero even after all the messages are actually consumed and
> acknowledged. When I browse the queue, I don't see any messages in it. This
> is causing KEDA to spin up pods unnecessarily.
> Please refer to the screenshots attached.
> As a temporary arrangement, can you let me now how to make the delivery
> message count = 0.
> !image-2021-08-06-17-24-45-732.png|width=638,height=571!
> !image-2021-08-06-17-19-37-446.png|width=811,height=674!
> !image-2021-08-06-17-20-45-445.png|width=671,height=300!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1925) Allow message redistribution even with STRICT or OFF message-load-balancing semantics
[
https://issues.apache.org/jira/browse/ARTEMIS-1925?focusedWorklogId=636444&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-636444
]
ASF GitHub Bot logged work on ARTEMIS-1925:
---
Author: ASF GitHub Bot
Created on: 10/Aug/21 13:20
Start Date: 10/Aug/21 13:20
Worklog Time Spent: 10m
Work Description: AntonRoskvist commented on pull request #3676:
URL: https://github.com/apache/activemq-artemis/pull/3676#issuecomment-896022399
The same basic thing was attempted here:
https://github.com/apache/activemq-artemis/pull/2893
I for one would really welcome this change, weather it's a separate option
or the default behavior. I see a lot of excessive "forwarding" caused by
ON_DEMAND when the feature I am really after is just the redistribution.
Br,
Anton
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 636444)
Time Spent: 7h 10m (was: 7h)
> Allow message redistribution even with STRICT or OFF message-load-balancing
> semantics
> -
>
> Key: ARTEMIS-1925
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1925
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Priority: Major
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently if the {{message-load-balancing}} is {{STRICT}} or {{OFF}} then
> message redistribution is disabled. Message redistribution should be
> controlled only by the {{redistribtion-delay}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Deleted] (AMQNET-720) Maintaining Balance in a Technological World
[ https://issues.apache.org/jira/browse/AMQNET-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-720: > Maintaining Balance in a Technological World > > > Key: AMQNET-720 > URL: https://issues.apache.org/jira/browse/AMQNET-720 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Nerea Kaufman >Priority: Major > > In the modern age of texts, tweets, and status updates, it is of utmost > importance that parents maintain open lines of face-to-face, soul-to-soul > communication with their children. This does not mean resisting a highly > technological world that is not going away, but rather continually exploring > new ways to connect with one another both on and beyond the keyboard. The new > technology in and of itself is not detrimental to children and can be quite > useful to them in many ways, but it must be coupled with daily opportunities > for personal reflection, creative inspiration, and heart connection with > others. It becomes the parents' role to both monitor technological use as > their children's sole means of communication and to provide the space and > encouragement for life-affirming communication and choices. > Today's children often become immersed in a world of technology and > friendships that may seem quite foreign to parents. The more attuned parents > are to their children's interests other than technology, the better able they > are to utilize those interests as opportunities for expanded connection. > Parents can view all interests as possible pathways to enhance real life > interactions. Parents must observe closely what truly brings their children > joy, where they are most authentic, and what makes their eyes sparkle. To > light the path of infusing deeper meaning into everyday life, parents must > continually assess whether they are offering a true understanding of core > concepts like authenticity, self-love, connectedness, gratitude and presence > in tandem with their children's inevitable foray into a fast-paced and > ever-changing technological world. Parents must not only teach these concepts > but also model ways for their children to integrate them into life > experiences and relationships. > The invitation for all parents is to actively participate in as many areas of > their children's lives as possible without decreasing their natural move > towards independence. Children's passions when viewed from an expanded > perspective offer rich material and opportunity to connect with them in deep > and joyous ways. Songs, movies, and all veins of creative expression (even > technology) provide optimal entry points into daily conversation and in-depth > discussion. Parents can utilize everyday life to dissect and review the core > concepts mentioned above to expand perspective and enhance the parent/child > bond. The space and opportunity to discuss the touchstones of the day can be > created through a weekly family discussion, a nightly chat at bedtime, the > family dinner, or time spent together in the car with technology off. Parents > must be continually on the lookout for a bridge into their children's world, > while at the same time enforce time-outs from computerized communication. > Due to the fact that the new technology is here to stay, to resist it > outright will create a backlash for parents and children alike. Instead, the > best strategy is to discuss often and enforce expectations regarding > appropriate use. Parents must explain to their children why balance in this > area is vital to their overall well-being. The capacity to be inspired to > create in any venue requires downtime, reflection, openness, and connection > to the deeper space within. It is important for children to understand that > there is a place for multi-tasking and technological communication, but it is > the relationship with their own interior and life itself that ignites their > highest potential. > As parents give their children permission to be authentic in their choices, > they must also offer them the parental insight that there are multiple angles > to every choice. Parents can encourage transparency and honesty by creating a > family structure that helps children monitor their choices-such as computer > use on the first floor only and no hand-held devices allowed during meal > times, family outings, or after 8pm. Parents should not be afraid to expect > and enforce accountability, while at the same time remain open to the child's > new world. It is imperative that parents take the time to teach children that > current choices affect future reality. In other words, parents should assist > them in coming to understand that they are the source, not the effect-joy > begets more joy, inspiration begets mor
[jira] [Deleted] (AMQNET-726) abc
[ https://issues.apache.org/jira/browse/AMQNET-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-726: > abc > --- > > Key: AMQNET-726 > URL: https://issues.apache.org/jira/browse/AMQNET-726 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: clifford9988 >Priority: Critical > > in which To enter the business hard at all as there are very few hindrances > to section, anyway somebody who is intrigued requirements to consider of the > significant expenses in setting up an auto vendor. All organizations in this > market are for the most part dependent on item separation to contend and > keeping in mind that costs are not "tacky", evaluating rivalry is set up by > the market. https://junkcaryard.ca/scrap-car-removal-niagara-falls/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-726) abc
[ https://issues.apache.org/jira/browse/AMQNET-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clifford9988 updated AMQNET-726: Description: in which To enter the business hard at all as there are very few hindrances to section, anyway somebody who is intrigued requirements to consider of the significant expenses in setting up an auto vendor. All organizations in this market are for the most part dependent on item separation to contend and keeping in mind that costs are not "tacky", evaluating rivalry is set up by the market. https://junkcaryard.ca/scrap-car-removal-niagara-falls/ (was: in which To enter the business hard at all as there are very few hindrances to section, anyway somebody who is intrigued requirements to consider of the significant expenses in setting up an auto vendor. All organizations in this market are for the most part dependent on item separation to contend and keeping in mind that costs are not "tacky", evaluating rivalry is set up by the market. https://junkcaryard.ca/scrap-car-removal-niagara-falls/";>auto wreckers Niagara ) > abc > --- > > Key: AMQNET-726 > URL: https://issues.apache.org/jira/browse/AMQNET-726 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: clifford9988 >Priority: Critical > > in which To enter the business hard at all as there are very few hindrances > to section, anyway somebody who is intrigued requirements to consider of the > significant expenses in setting up an auto vendor. All organizations in this > market are for the most part dependent on item separation to contend and > keeping in mind that costs are not "tacky", evaluating rivalry is set up by > the market. https://junkcaryard.ca/scrap-car-removal-niagara-falls/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQNET-726) abc
clifford9988 created AMQNET-726: --- Summary: abc Key: AMQNET-726 URL: https://issues.apache.org/jira/browse/AMQNET-726 Project: ActiveMQ .Net Issue Type: Bug Reporter: clifford9988 in which To enter the business hard at all as there are very few hindrances to section, anyway somebody who is intrigued requirements to consider of the significant expenses in setting up an auto vendor. All organizations in this market are for the most part dependent on item separation to contend and keeping in mind that costs are not "tacky", evaluating rivalry is set up by the market. https://junkcaryard.ca/scrap-car-removal-niagara-falls/";>auto wreckers Niagara -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-3416) Message count is not zero even after all messages are consumed and acknowledged
[
https://issues.apache.org/jira/browse/ARTEMIS-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396591#comment-17396591
]
Amit Herlekar edited comment on ARTEMIS-3416 at 8/10/21, 10:22 AM:
---
Here is the debug log file of the recent run which includes all messages and
ACKs.
The reported issue is happening on queue: {{fe_unsupervised}} and
{{analysis_status}}.
[^artemis.zip]
Here is the glimpse of code how we are processing the message:
{code:java}
class processCallback(aMQ.Listener):
# Actual function that process the message in a separate thread
def process_message(self, headers, body):
res_dict = json.loads(body)
job_id = res_dict['job_id']
vm_uuid = res_dict['vm_uuid']
print('Processing the request with message body: ',body)
print('To Be implemented!')
self.send_ack(headers['ack'])
self.send_message_to_model(job_id,vm_uuid)
##:TODO Finish implementation
{code}
!image-2021-08-10-15-49-59-960.png|width=434,height=381!
!image-2021-08-10-15-52-23-921.png|width=523,height=461!
was (Author: amitherlekar):
Here is the debug log file of the recent run which includes all messages and
ACKs.
The reported issue is happening on queue: {{fe_unsupervised}} and
{{analysis_status}}.
[^artemis.zip]
Here is the glimpse of code how we are processing the message:
{code:java}
class processCallback(aMQ.Listener):
# Actual function that process the message in a separate thread
def process_message(self, headers, body):
res_dict = json.loads(body)
job_id = res_dict['job_id']
vm_uuid = res_dict['vm_uuid']
print('Processing the request with message body: ',body)
print('To Be implemented!')
self.send_ack(headers['ack'])
self.send_message_to_model(job_id,vm_uuid)
##:TODO Finish implementation
{code}
> Message count is not zero even after all messages are consumed and
> acknowledged
> ---
>
> Key: ARTEMIS-3416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3416
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
> Environment: Single artemis instance running as a K8s deployment with
> single replica on CentOS 7.9
>Reporter: Amit Herlekar
>Priority: Minor
> Attachments: artemis.zip, artemis.zip, artemis.zip,
> image-2021-08-06-17-19-37-446.png, image-2021-08-06-17-20-45-445.png,
> image-2021-08-06-17-24-45-732.png, image-2021-08-09-23-27-22-180.png,
> image-2021-08-09-23-29-38-568.png, image-2021-08-09-23-31-51-213.png,
> image-2021-08-10-15-49-59-960.png, image-2021-08-10-15-52-23-921.png
>
>
> We have switched from ActiveMQ Classic to ActiveMQ Artemis. Thanks to the
> nice documentation on github that we are able to containerize it and deploy
> it as a K8s deployment for [KEDA|https://keda.sh/docs/2.4/scalers/artemis/].
> Coming to the issue, we are using STOMP using stomp.py python module. The
> ACK-mode is set as client-individual and consumerWindowSize = 0 on the
> connection. We are promptly acknowledging the message as soon as we read it.
> The problem is, sometimes, the message count in the web console does not
> become zero even after all the messages are actually consumed and
> acknowledged. When I browse the queue, I don't see any messages in it. This
> is causing KEDA to spin up pods unnecessarily.
> Please refer to the screenshots attached.
> As a temporary arrangement, can you let me now how to make the delivery
> message count = 0.
> !image-2021-08-06-17-24-45-732.png|width=638,height=571!
> !image-2021-08-06-17-19-37-446.png|width=811,height=674!
> !image-2021-08-06-17-20-45-445.png|width=671,height=300!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7470) ActiveMQ producer thread hangs on setXid
[
https://issues.apache.org/jira/browse/AMQ-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396593#comment-17396593
]
Anton Roskvist commented on AMQ-7470:
-
I did, yes. And also timeouts for the inactivityMonitor and all settings I
could think of that could be even remotely related in the TCP transport for
connection, sockets and so on.
> ActiveMQ producer thread hangs on setXid
>
>
> Key: AMQ-7470
> URL: https://issues.apache.org/jira/browse/AMQ-7470
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP, Broker, JMS client
>Affects Versions: 5.15.6
>Reporter: Rajesh Pote
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
> Attachments: setXid_bug.tar.gz
>
>
> I've noticed issues with distributed transactions (XA) on karaf when using
> ActiveMQ with JDBC storeage (postgres). After some time (it isn't
> deterministic) I've observed that on database side 'idle in transaction'
> appeared (it's other schema than used by ActiveMQ). After debugging it seams
> that the reason why transactions are hanging is ActiveMQ and
> org.apache.activemq.transport.FutureResponse.getResult method that waits
> forever for a response.
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000768585aa8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
> at
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:48)
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:87)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1388)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.TransactionContext.setXid(TransactionContext.java:751)
> at
> org.apache.activemq.TransactionContext.invokeBeforeEnd(TransactionContext.java:424)
> at
> org.apache.activemq.TransactionContext.end(TransactionContext.java:408)
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.end(WrapperNamedXAResource.java:61)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:588)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:567)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:414)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:262)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
> at
> org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1020)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
> at
> org.apache.aries.transaction.internal.AriesPlatformTransactionManager.commit(AriesPlatformTransactionManager.java:75)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:484)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> . custom service
> {code}
> {code}
> "DefaultMessageListenerContainer-3" #13199 prio=5 os_prio=0
> tid=0x7fb8687e6800 nid=0x3954 waiting on condition [0x7fb7b0b98000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000765f532c0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurr
[jira] [Commented] (ARTEMIS-3416) Message count is not zero even after all messages are consumed and acknowledged
[
https://issues.apache.org/jira/browse/ARTEMIS-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396591#comment-17396591
]
Amit Herlekar commented on ARTEMIS-3416:
Here is the debug log file of the recent run which includes all messages and
ACKs.
The reported issue is happening on queue: {{fe_unsupervised}} and
{{analysis_status}}.
[^artemis.zip]
Here is the glimpse of code how we are processing the message:
{code:java}
class processCallback(aMQ.Listener):
# Actual function that process the message in a separate thread
def process_message(self, headers, body):
res_dict = json.loads(body)
job_id = res_dict['job_id']
vm_uuid = res_dict['vm_uuid']
print('Processing the request with message body: ',body)
print('To Be implemented!')
self.send_ack(headers['ack'])
self.send_message_to_model(job_id,vm_uuid)
##:TODO Finish implementation
{code}
> Message count is not zero even after all messages are consumed and
> acknowledged
> ---
>
> Key: ARTEMIS-3416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3416
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
> Environment: Single artemis instance running as a K8s deployment with
> single replica on CentOS 7.9
>Reporter: Amit Herlekar
>Priority: Minor
> Attachments: artemis.zip, artemis.zip, artemis.zip,
> image-2021-08-06-17-19-37-446.png, image-2021-08-06-17-20-45-445.png,
> image-2021-08-06-17-24-45-732.png, image-2021-08-09-23-27-22-180.png,
> image-2021-08-09-23-29-38-568.png, image-2021-08-09-23-31-51-213.png
>
>
> We have switched from ActiveMQ Classic to ActiveMQ Artemis. Thanks to the
> nice documentation on github that we are able to containerize it and deploy
> it as a K8s deployment for [KEDA|https://keda.sh/docs/2.4/scalers/artemis/].
> Coming to the issue, we are using STOMP using stomp.py python module. The
> ACK-mode is set as client-individual and consumerWindowSize = 0 on the
> connection. We are promptly acknowledging the message as soon as we read it.
> The problem is, sometimes, the message count in the web console does not
> become zero even after all the messages are actually consumed and
> acknowledged. When I browse the queue, I don't see any messages in it. This
> is causing KEDA to spin up pods unnecessarily.
> Please refer to the screenshots attached.
> As a temporary arrangement, can you let me now how to make the delivery
> message count = 0.
> !image-2021-08-06-17-24-45-732.png|width=638,height=571!
> !image-2021-08-06-17-19-37-446.png|width=811,height=674!
> !image-2021-08-06-17-20-45-445.png|width=671,height=300!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3416) Message count is not zero even after all messages are consumed and acknowledged
[ https://issues.apache.org/jira/browse/ARTEMIS-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Herlekar updated ARTEMIS-3416: --- Attachment: artemis.zip > Message count is not zero even after all messages are consumed and > acknowledged > --- > > Key: ARTEMIS-3416 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3416 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.16.0 > Environment: Single artemis instance running as a K8s deployment with > single replica on CentOS 7.9 >Reporter: Amit Herlekar >Priority: Minor > Attachments: artemis.zip, artemis.zip, artemis.zip, > image-2021-08-06-17-19-37-446.png, image-2021-08-06-17-20-45-445.png, > image-2021-08-06-17-24-45-732.png, image-2021-08-09-23-27-22-180.png, > image-2021-08-09-23-29-38-568.png, image-2021-08-09-23-31-51-213.png > > > We have switched from ActiveMQ Classic to ActiveMQ Artemis. Thanks to the > nice documentation on github that we are able to containerize it and deploy > it as a K8s deployment for [KEDA|https://keda.sh/docs/2.4/scalers/artemis/]. > Coming to the issue, we are using STOMP using stomp.py python module. The > ACK-mode is set as client-individual and consumerWindowSize = 0 on the > connection. We are promptly acknowledging the message as soon as we read it. > The problem is, sometimes, the message count in the web console does not > become zero even after all the messages are actually consumed and > acknowledged. When I browse the queue, I don't see any messages in it. This > is causing KEDA to spin up pods unnecessarily. > Please refer to the screenshots attached. > As a temporary arrangement, can you let me now how to make the delivery > message count = 0. > !image-2021-08-06-17-24-45-732.png|width=638,height=571! > !image-2021-08-06-17-19-37-446.png|width=811,height=674! > !image-2021-08-06-17-20-45-445.png|width=671,height=300! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3416) Message count is not zero even after all messages are consumed and acknowledged
[ https://issues.apache.org/jira/browse/ARTEMIS-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Herlekar updated ARTEMIS-3416: --- Attachment: artemis.zip > Message count is not zero even after all messages are consumed and > acknowledged > --- > > Key: ARTEMIS-3416 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3416 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.16.0 > Environment: Single artemis instance running as a K8s deployment with > single replica on CentOS 7.9 >Reporter: Amit Herlekar >Priority: Minor > Attachments: artemis.zip, artemis.zip, > image-2021-08-06-17-19-37-446.png, image-2021-08-06-17-20-45-445.png, > image-2021-08-06-17-24-45-732.png, image-2021-08-09-23-27-22-180.png, > image-2021-08-09-23-29-38-568.png, image-2021-08-09-23-31-51-213.png > > > We have switched from ActiveMQ Classic to ActiveMQ Artemis. Thanks to the > nice documentation on github that we are able to containerize it and deploy > it as a K8s deployment for [KEDA|https://keda.sh/docs/2.4/scalers/artemis/]. > Coming to the issue, we are using STOMP using stomp.py python module. The > ACK-mode is set as client-individual and consumerWindowSize = 0 on the > connection. We are promptly acknowledging the message as soon as we read it. > The problem is, sometimes, the message count in the web console does not > become zero even after all the messages are actually consumed and > acknowledged. When I browse the queue, I don't see any messages in it. This > is causing KEDA to spin up pods unnecessarily. > Please refer to the screenshots attached. > As a temporary arrangement, can you let me now how to make the delivery > message count = 0. > !image-2021-08-06-17-24-45-732.png|width=638,height=571! > !image-2021-08-06-17-19-37-446.png|width=811,height=674! > !image-2021-08-06-17-20-45-445.png|width=671,height=300! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7470) ActiveMQ producer thread hangs on setXid
[
https://issues.apache.org/jira/browse/AMQ-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396584#comment-17396584
]
Jean-Baptiste Onofré commented on AMQ-7470:
---
Did you try timeout on failover ? That’s the most important.
> ActiveMQ producer thread hangs on setXid
>
>
> Key: AMQ-7470
> URL: https://issues.apache.org/jira/browse/AMQ-7470
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP, Broker, JMS client
>Affects Versions: 5.15.6
>Reporter: Rajesh Pote
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
> Attachments: setXid_bug.tar.gz
>
>
> I've noticed issues with distributed transactions (XA) on karaf when using
> ActiveMQ with JDBC storeage (postgres). After some time (it isn't
> deterministic) I've observed that on database side 'idle in transaction'
> appeared (it's other schema than used by ActiveMQ). After debugging it seams
> that the reason why transactions are hanging is ActiveMQ and
> org.apache.activemq.transport.FutureResponse.getResult method that waits
> forever for a response.
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000768585aa8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
> at
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:48)
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:87)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1388)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.TransactionContext.setXid(TransactionContext.java:751)
> at
> org.apache.activemq.TransactionContext.invokeBeforeEnd(TransactionContext.java:424)
> at
> org.apache.activemq.TransactionContext.end(TransactionContext.java:408)
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.end(WrapperNamedXAResource.java:61)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:588)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:567)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:414)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:262)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
> at
> org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1020)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
> at
> org.apache.aries.transaction.internal.AriesPlatformTransactionManager.commit(AriesPlatformTransactionManager.java:75)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:484)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> . custom service
> {code}
> {code}
> "DefaultMessageListenerContainer-3" #13199 prio=5 os_prio=0
> tid=0x7fb8687e6800 nid=0x3954 waiting on condition [0x7fb7b0b98000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000765f532c0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
[jira] [Commented] (AMQ-7470) ActiveMQ producer thread hangs on setXid
[
https://issues.apache.org/jira/browse/AMQ-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396581#comment-17396581
]
Anton Roskvist commented on AMQ-7470:
-
Hi,
I did try those options and also "jms.connectResponseTimeout" and pretty much
all other settings I could find for the transport and connection relating to
timeouts and none of them helped in my case.
Br,
Anton
> ActiveMQ producer thread hangs on setXid
>
>
> Key: AMQ-7470
> URL: https://issues.apache.org/jira/browse/AMQ-7470
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP, Broker, JMS client
>Affects Versions: 5.15.6
>Reporter: Rajesh Pote
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
> Attachments: setXid_bug.tar.gz
>
>
> I've noticed issues with distributed transactions (XA) on karaf when using
> ActiveMQ with JDBC storeage (postgres). After some time (it isn't
> deterministic) I've observed that on database side 'idle in transaction'
> appeared (it's other schema than used by ActiveMQ). After debugging it seams
> that the reason why transactions are hanging is ActiveMQ and
> org.apache.activemq.transport.FutureResponse.getResult method that waits
> forever for a response.
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000768585aa8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
> at
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:48)
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:87)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1388)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.TransactionContext.setXid(TransactionContext.java:751)
> at
> org.apache.activemq.TransactionContext.invokeBeforeEnd(TransactionContext.java:424)
> at
> org.apache.activemq.TransactionContext.end(TransactionContext.java:408)
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.end(WrapperNamedXAResource.java:61)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:588)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:567)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:414)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:262)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
> at
> org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1020)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
> at
> org.apache.aries.transaction.internal.AriesPlatformTransactionManager.commit(AriesPlatformTransactionManager.java:75)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:484)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> . custom service
> {code}
> {code}
> "DefaultMessageListenerContainer-3" #13199 prio=5 os_prio=0
> tid=0x7fb8687e6800 nid=0x3954 waiting on condition [0x7fb7b0b98000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000765f532c0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175
