[jira] [Commented] (ARTEMIS-4733) Mirror Infinite loops (mirror infinite Reflection) from Internal Queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839470#comment-17839470 ] ASF subversion and git services commented on ARTEMIS-4733: -- Commit 44e78d42a22bdf7c59a22364d6c2d57de793b15a in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=44e78d42a2 ] ARTEMIS-4733 Internal queues should not be mirrored > Mirror Infinite loops (mirror infinite Reflection) from Internal Queues > --- > > Key: ARTEMIS-4733 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4733 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I am seeing Mirroring causing infinite reflections on createAddresses > I couldn't make the test I wrote to fail before ARTEMIS-4498 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on AMQ-9481 started by Christopher L. Shannon.
---
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by: javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
>
[jira] [Work logged] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?focusedWorklogId=915708=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915708
]
ASF GitHub Bot logged work on AMQ-9481:
---
Author: ASF GitHub Bot
Created on: 21/Apr/24 16:46
Start Date: 21/Apr/24 16:46
Worklog Time Spent: 10m
Work Description: cshannon opened a new pull request, #1206:
URL: https://github.com/apache/activemq/pull/1206
This fixes AsyncServletRequest to correctly call context.dispatch() when the
async request times out so that the consumer can be re-used.
Issue Time Tracking
---
Worklog Id: (was: 915708)
Remaining Estimate: 0h
Time Spent: 10m
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
>
[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839406#comment-17839406
]
ASF subversion and git services commented on AMQ-9481:
--
Commit 72befc14fbb69c24bdec0c7d4a1002da8874380d in activemq's branch
refs/heads/AMQ-9841 from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=72befc14f ]
AMQ-9481 - Correctly complete async servlet request on timeout
This fixes AsyncServletRequest to correctly call context.dispatch() when
the async request times out so that the consumer can be re-used.
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
>
[jira] [Comment Edited] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839405#comment-17839405
]
Christopher L. Shannon edited comment on AMQ-9481 at 4/21/24 4:41 PM:
--
I don't have a windows environment to test but I was able to reproduce this by
using a clientId like the example and just hitting the rest API from my browser
multiple times. It works the first time, but then the second time I get the
error since the original async request never completes correctly even on
timeout when there are no messages.
I took a look at this and it turns out this was _almost_ fixed in AMQ-9330. The
root cause is AsyncServletRequest that was created to replace the Jetty
Continuation object does not handle timeouts correctly. In AMQ-9330 the code
was changed to call {{{}complete(){}}}but turns out that makes things better
but is stil not all the way correct.
As shown here, we should be calling {{dispatch()}} on the context when timing
out:
[https://github.com/jetty/jetty.project/blob/jetty-9.4.54.v20240208/jetty-continuation/src/main/java/org/eclipse/jetty/continuation/Servlet3Continuation.java#L239]
I have a fix and test and will open up a Pull request, with the new fix after
the async request times out then things are cleaned up correctly and future
requests will work. If the original async request is still open then the
concurrent access error will be given.
was (Author: christopher.l.shannon):
I don't have a windows environment to test but I was able to reproduce this by
using a clientId like the example and just hitting the rest API from my browser
multiple times. It works the first time, but then the second time I get the
error since the original async request never completes correctly even on
timeout when there are no messages.
I took a look at this and it turns out this was _almost_ fixed in AMQ-9330. The
root cause is AsyncServletRequest that was created to replace the Jetty
Continuation object does not handle timeouts correctly. In AMQ-9330 the code
was changed to call complete() but turns out that makes things better but is
stil not all the way correct.
As shown here, we should be calling dispatch() on the context when timing out:
[https://github.com/jetty/jetty.project/blob/jetty-9.4.54.v20240208/jetty-continuation/src/main/java/org/eclipse/jetty/continuation/Servlet3Continuation.java#L239]
I have a fix and test and will open up a Pull request, with the new fix after
the async request times out then things are cleaned up correctly and future
requests will work. If the original async request is still open then the
concurrent access error will be given.
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException:
[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839405#comment-17839405
]
Christopher L. Shannon commented on AMQ-9481:
-
I don't have a windows environment to test but I was able to reproduce this by
using a clientId like the example and just hitting the rest API from my browser
multiple times. It works the first time, but then the second time I get the
error since the original async request never completes correctly even on
timeout when there are no messages.
I took a look at this and it turns out this was _almost_ fixed in AMQ-9330. The
root cause is AsyncServletRequest that was created to replace the Jetty
Continuation object does not handle timeouts correctly. In AMQ-9330 the code
was changed to call complete() but turns out that makes things better but is
stil not all the way correct.
As shown here, we should be calling dispatch() on the context when timing out:
[https://github.com/jetty/jetty.project/blob/jetty-9.4.54.v20240208/jetty-continuation/src/main/java/org/eclipse/jetty/continuation/Servlet3Continuation.java#L239]
I have a fix and test and will open up a Pull request, with the new fix after
the async request times out then things are cleaned up correctly and future
requests will work. If the original async request is still open then the
concurrent access error will be given.
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
>
[jira] [Closed] (AMQ-9409) AMQ returns 500 instead of 204 when message not found
[ https://issues.apache.org/jira/browse/AMQ-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-9409. --- Resolution: Duplicate > AMQ returns 500 instead of 204 when message not found > - > > Key: AMQ-9409 > URL: https://issues.apache.org/jira/browse/AMQ-9409 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.2 >Reporter: Pratap >Priority: Major > > Starting with ActiveMQ 5.18.2, the REST API returns "500 Server Error" > instead of "204 No Content" when a message is not found in the response > queue. We rely on 204 being returned to indicate that the request message is > still being processed, and we continue to poll the response queue based on > this response code. > Was the change in behavior in 5.18.2 intentional? It is helpful to have AMQ > return 204 when a message is not found instead of 500 error which could mean > any number of other issues. > Thank you for looking into this! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon reassigned AMQ-9481:
---
Assignee: Christopher L. Shannon (was: Jean-Baptiste Onofré)
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by: javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
>
[jira] [Comment Edited] (AMQ-9483) Non Daemon Connection Keeping JVM alive when combined with optimizedAckScheduledAckInterval
[ https://issues.apache.org/jira/browse/AMQ-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839395#comment-17839395 ] Christopher L. Shannon edited comment on AMQ-9483 at 4/21/24 3:16 PM: -- This is something that would need to be carefully considered and tested to make sure changing something like this does not re-introduce this problem https://issues.apache.org/jira/browse/AMQ-796 At first glance I think a change like this might be ok since AMQ-796 appeared to make the change in ActiveMQConnection here: [https://github.com/apache/activemq/blob/6084867b26619ab614bc117667a32649def5887a/activemq-client/src/main/java/org/apache/activemq/ActiveMQConnection.java#L238] and by default this feature is disabled anyways, but it needs to be looked at more to double check was (Author: christopher.l.shannon): This is something that would need to be carefully considered and tested to make sure changing something like this does not re-introduce this problem https://issues.apache.org/jira/browse/AMQ-796 At first glance I think a change like this might be ok since AMQ-796 appeared to make the change in ActiveMQConnection here: [https://github.com/apache/activemq/blob/6084867b26619ab614bc117667a32649def5887a/activemq-client/src/main/java/org/apache/activemq/ActiveMQConnection.java#L238] but it needs to be looked at more > Non Daemon Connection Keeping JVM alive when combined with > optimizedAckScheduledAckInterval > --- > > Key: AMQ-9483 > URL: https://issues.apache.org/jira/browse/AMQ-9483 > Project: ActiveMQ Classic > Issue Type: Bug > Components: JMS client >Affects Versions: 5.18.4 >Reporter: Matthew Washburn >Priority: Major > Attachments: > 0001-make-sure-the-executor-service-for-deliveryingAcknow.patch > > > The thread used to send ack unacked messages when using the > optimizedAckScheduledAckInterval is not daemon even if the connection is set > to daemon. This is probably advantageous as you would not want a queue or > durable topic consumer to shutdown before it has finished acking a message > causing it to be redelivered on restart. On the other hand, it means that if > the optimized ack scheduler ever kicks in on a daemon connection the JVM will > never exit. Also the thread isn't uniquely named so it's hard to track down. > > I'm not sure how to get in the situation where there are unacked messages > that are acked by the timer so I'm not sure how to create a simple repo > script but the attached patch fixes my application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9483) Non Daemon Connection Keeping JVM alive when combined with optimizedAckScheduledAckInterval
[ https://issues.apache.org/jira/browse/AMQ-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839395#comment-17839395 ] Christopher L. Shannon commented on AMQ-9483: - This is something that would need to be carefully considered and tested to make sure changing something like this does not re-introduce this problem https://issues.apache.org/jira/browse/AMQ-796 At first glance I think a change like this might be ok since AMQ-796 appeared to make the change in ActiveMQConnection here: [https://github.com/apache/activemq/blob/6084867b26619ab614bc117667a32649def5887a/activemq-client/src/main/java/org/apache/activemq/ActiveMQConnection.java#L238] but it needs to be looked at more > Non Daemon Connection Keeping JVM alive when combined with > optimizedAckScheduledAckInterval > --- > > Key: AMQ-9483 > URL: https://issues.apache.org/jira/browse/AMQ-9483 > Project: ActiveMQ Classic > Issue Type: Bug > Components: JMS client >Affects Versions: 5.18.4 >Reporter: Matthew Washburn >Priority: Major > Attachments: > 0001-make-sure-the-executor-service-for-deliveryingAcknow.patch > > > The thread used to send ack unacked messages when using the > optimizedAckScheduledAckInterval is not daemon even if the connection is set > to daemon. This is probably advantageous as you would not want a queue or > durable topic consumer to shutdown before it has finished acking a message > causing it to be redelivered on restart. On the other hand, it means that if > the optimized ack scheduler ever kicks in on a daemon connection the JVM will > never exit. Also the thread isn't uniquely named so it's hard to track down. > > I'm not sure how to get in the situation where there are unacked messages > that are acked by the timer so I'm not sure how to create a simple repo > script but the attached patch fixes my application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9482) Broker crashes after runaway threads spawn
[
https://issues.apache.org/jira/browse/AMQ-9482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839394#comment-17839394
]
Christopher L. Shannon commented on AMQ-9482:
-
To look at something like this more information is needed such as a thread dump
to to see what is going on. From the description it seems like a bunch of tasks
are running and not completing which makes me think there might be a deadlock
or something else blocking the tasks, but without a thread dump showing what
all the tasks are doing it's impossible to tell.
> Broker crashes after runaway threads spawn
> --
>
> Key: AMQ-9482
> URL: https://issues.apache.org/jira/browse/AMQ-9482
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.17.6, 6.0.1
> Environment: Bitnami created AMI in AWS
>Reporter: Tom Tichy
>Priority: Major
> Attachments: brokerInfo-after-crash-redacted.json
>
>
> Running on Bitnami created AMI in AWS. The broker has about 7000 devices
> connected via MQTT. Each devices has its own topic name.
> Broker stays up for about 4-5 days before being hobbled and unable to create
> any new tasks/accept any new connections.
> (There is identical setup for staging environment with about 100 devices
> connected. It runs without any issues.)
> I have troubleshot the cause to be the systemd task limit. The current
> `TasksMax` is 18100. When running normally, the number of tasks is about 300.
> Then (every 4-5 days) there is a quick spike to the max 18100 tasks and it
> stays there never coming back down. The result is that the broker just sits
> there, does nothing useful and keeps logging the following message
>
> {code:java}
> [659914.788s][warning][os,thread] Failed to start thread "Unknown thread" -
> pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, g
> uardsize: 0k, detached.
> [659914.788s][warning][os,thread] Failed to start the native thread for
> java.lang.Thread "ActiveMQ BrokerService[localhost] Task-281805"
> ERROR | Scheduled task error
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> at java.lang.Thread.start0(Native Method) ~[?:?]
> at java.lang.Thread.start(Thread.java:809) ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:945)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
> ~[?:?]
> at
> org.apache.activemq.thread.TaskRunnerFactory.execute(TaskRunnerFactory.java:173)
> ~[activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.thread.TaskRunnerFactory.execute(TaskRunnerFactory.java:165)
> ~[activemq-client-6.0.1.jar:6.0.1]
> at org.apache.activemq.broker.region.Topic$7.run(Topic.java:820)
> ~[activemq-broker-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:39)
> ~[activemq-client-6.0.1.jar:6.0.1]
> at java.util.TimerThread.mainLoop(Timer.java:566) ~[?:?]
> at java.util.TimerThread.run(Timer.java:516) ~[?:?]
> Exception in thread "ActiveMQ Broker[localhost] Scheduler"
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:809)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:945)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
> at
> org.apache.activemq.thread.TaskRunnerFactory.execute(TaskRunnerFactory.java:173)
> at
> org.apache.activemq.thread.TaskRunnerFactory.execute(TaskRunnerFactory.java:165)
> at org.apache.activemq.broker.region.Topic$7.run(Topic.java:820)
> at
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:39)
> at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
> at java.base/java.util.TimerThread.run(Timer.java:516)
> {code}
>
> The start command is
> {code:java}
> /opt/bitnami/java/bin/java -Xms2G -Xmx4G
> -Djava.util.logging.config.file=logging.properties
> -Djava.security.auth.login.config=/opt/bitnami/activemq/conf/login.config
> -Dorg.apache.activemq.UseDedicatedTaskRunner=false
> -Dcom.sun.management.jmxremote -Djava.awt.headless=true
> -Djava.io.tmpdir=/opt/bitnami/activemq/tmp --add-reads=java.xml=java.logging
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens
>
[jira] [Commented] (ARTEMIS-4182) fill client-id for cluster connections
[ https://issues.apache.org/jira/browse/ARTEMIS-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839378#comment-17839378 ] Erwin Dondorp commented on ARTEMIS-4182: [~jbertram] The screenshot is already in the description. The image shows that cluster-connections do not fill the column ClientID, The remote address column indeed shows the ip-number of the remote node. But (for me) these ip-numbers are assigned dynamically. From these ip-numbers, I cannot determine which node did not connect to the cluster. e.g. Assume the screenshot is from a 6-node cluster. The "own" node (where we are viewing from) is never in the list, but which one of the other 5 nodes is not connected and therefore not in this list? To answer that question, I must either lookup the ip-addresses and eliminate the good ones to find the missing one, or open the consoles of all 5 other nodes. > fill client-id for cluster connections > -- > > Key: ARTEMIS-4182 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4182 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Broker >Affects Versions: 2.28.0 >Reporter: Erwin Dondorp >Priority: Major > Attachments: image-2023-02-25-13-27-08-542.png > > > when running Artemis in a cluster, the brokers have connections between them. > these are easily identifiable in the list of connections because the "Users" > field is filled in with the username that was specified in setting > `cluster-user`. > but it is unclear where each connection goes to. > !image-2023-02-25-13-27-08-542.png! > > additional information: > the field "Client ID" is filled in with the remote hostname when using > broker-connection/amqp-connection. > wish: > (also) fill in field ClientID of the cluster connections. > e.g. with the broker-name or from a new parameter `cluster-clientid` -- This message was sent by Atlassian Jira (v8.20.10#820010)
