[jira] [Commented] (AMQ-9484) Support exporting kahadb messages from a queue with an offset
[ https://issues.apache.org/jira/browse/AMQ-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840160#comment-17840160 ] Christopher L. Shannon commented on AMQ-9484: - What is the use case for this and what are you trying to accomplish here and why? This is the kind of thing that needs a sufficient amount of detail to explain why we should make a change like this as this is not trivial. > Support exporting kahadb messages from a queue with an offset > - > > Key: AMQ-9484 > URL: https://issues.apache.org/jira/browse/AMQ-9484 > Project: ActiveMQ Classic > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0, 5.18.5 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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 resolved AMQ-9481.
-
Resolution: Fixed
> 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: 20m
> 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 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] [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] (AMQ-9478) Add unit test for modernized IntrospectionSupport
[ https://issues.apache.org/jira/browse/AMQ-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836267#comment-17836267 ] Christopher L. Shannon commented on AMQ-9478: - This is a generic testing ticket but AMQ-9473 drove the creation so we we should definitely make sure the tests cover the changes in that issue. > Add unit test for modernized IntrospectionSupport > - > > Key: AMQ-9478 > URL: https://issues.apache.org/jira/browse/AMQ-9478 > Project: ActiveMQ Classic > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0 > > > Update unit test to verify transport connector and network connector uri > handling for > IntrospectionSupport to deal with TcpSocket properties > IntrospectionSupport to deal with SSLSocket properties -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9330) Polling empty queue via REST returns 500 Server Error
[ https://issues.apache.org/jira/browse/AMQ-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836200#comment-17836200 ] Christopher L. Shannon commented on AMQ-9330: - The issue was we needed to call the complete() method on the context (otherwise the spec says 500 error is returned) and also set the right status code, I made the change updated tests to verify > Polling empty queue via REST returns 500 Server Error > - > > Key: AMQ-9330 > URL: https://issues.apache.org/jira/browse/AMQ-9330 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.2 >Reporter: Michael Hoyt >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.5, 6.1.2 > > Time Spent: 20m > Remaining Estimate: 0h > > In AMQ 5.18.1 Polling an empty queue via the REST api returned a 204 No > Content response. In 5.18.2 that same method now returns a 500 Server Error > response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9330) Polling empty queue via REST returns 500 Server Error
[ https://issues.apache.org/jira/browse/AMQ-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9330. - Resolution: Fixed > Polling empty queue via REST returns 500 Server Error > - > > Key: AMQ-9330 > URL: https://issues.apache.org/jira/browse/AMQ-9330 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.2 >Reporter: Michael Hoyt >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.5, 6.1.2 > > Time Spent: 20m > Remaining Estimate: 0h > > In AMQ 5.18.1 Polling an empty queue via the REST api returned a 204 No > Content response. In 5.18.2 that same method now returns a 500 Server Error > response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AMQ-9330) Polling empty queue via REST returns 500 Server Error
[ https://issues.apache.org/jira/browse/AMQ-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned AMQ-9330: --- Assignee: Christopher L. Shannon (was: Jean-Baptiste Onofré) > Polling empty queue via REST returns 500 Server Error > - > > Key: AMQ-9330 > URL: https://issues.apache.org/jira/browse/AMQ-9330 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.2 >Reporter: Michael Hoyt >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.5, 6.1.2 > > > In AMQ 5.18.1 Polling an empty queue via the REST api returned a 204 No > Content response. In 5.18.2 that same method now returns a 500 Server Error > response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9473) Client SSL Socket configuration fails while settings parameters
[
https://issues.apache.org/jira/browse/AMQ-9473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836140#comment-17836140
]
Christopher L. Shannon commented on AMQ-9473:
-
I think this fix should be backported to 5.18.x as well as it's related to the
JDK and in 5.18.x it has the check for the SSLServerSocket already
> Client SSL Socket configuration fails while settings parameters
> ---
>
> Key: AMQ-9473
> URL: https://issues.apache.org/jira/browse/AMQ-9473
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows and Java 21
>Reporter: Jukka Aalto
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 6.2.0, 6.1.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Client connection creation fails when setting socket parameters.
> Exception was thrown, when I tried to set enabledProtocols parameter using
> url:
> ssl://127.0.0.1:12345?socket.enabledProtocols=TLSv1.3
> Exception is also thrown, when using tcpNoDelay parameter. It is thrown
> probably with most of the parameters related to sockets.
> Here is the exception thrown:
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make public void
> sun.security.ssl.SSLSocketImpl.setEnabledProtocols(java.lang.String[])
> accessible: module java.base does not "exports sun.security.ssl" to unnamed
> module @48f2bd5b
> 13:22:43.976 [main] ERROR org.apache.activemq.util.IntrospectionSupport -
> Could not set property enabledProtocols on SSLSocket[hostname=127.0.0.1,
> port=12345, Session(...)]
> at
> java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:391)
> ~[?:?]
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:367)
> ~[?:?]
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:315)
> ~[?:?]
> at
> java.lang.reflect.Method.checkCanSetAccessible(Method.java:203) ~[?:?]
> at java.lang.reflect.Method.setAccessible(Method.java:197) ~[?:?]
> at
> org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:184)
> [test/:6.0.1]
> at
> org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:155)
> [test/:6.0.1]
> at
> org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:140)
> [test/:6.0.1]
> at
> org.apache.activemq.transport.tcp.TcpTransport.initialiseSocket(TcpTransport.java:449)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.tcp.SslTransport.initialiseSocket(SslTransport.java:137)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:542)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.tcp.TcpTransport.doStart(TcpTransport.java:488)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.start(AbstractInactivityMonitor.java:172)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.InactivityMonitor.start(InactivityMonitor.java:52)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:399)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:349)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:245)
> [activemq-client-6.0.1.jar:6.0.1]
> at
> test.ActiveMQClientSSLSocketParameter.main(ActiveMQClientSSLSocketParameter.java:25)
> [test/:?]
> {code}
> Here is example to reproduce issue:
> {code:java}
> package test;
> import java.io.IOException;
> import java.net.ServerSocket;
> import
[jira] [Resolved] (AMQ-9475) ConsumerControl commands for wildcard consumers should not auto-create destinations
[ https://issues.apache.org/jira/browse/AMQ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9475. - Resolution: Fixed > ConsumerControl commands for wildcard consumers should not auto-create > destinations > --- > > Key: AMQ-9475 > URL: https://issues.apache.org/jira/browse/AMQ-9475 > Project: ActiveMQ Classic > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.2 > > Time Spent: 50m > Remaining Estimate: 0h > > While investigating AMQ-9472, it was > [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2046523027] > out in some cases (like with Stomp) wildcard destinations that do not exist > could be auto created on subscribe which besides creating the extra > destination, can also lead to errors if proper ACLs are not set up. > As > [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2047625950] > out, the bug here is that wildcard destinations should not be auto-created > just by subscribing using a wildcard. There is a check for this in > [addConsumer()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L344-L346] > but > [processConsumerControl()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L694] > does not have the checks. So any time that command is sent (like prefetch > update) this could be an issue. > This can be fixed by only looking up destinations that are wildcards and not > auto creating them when processing consumer control objects just like > addConsumer() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9475) ConsumerControl commands for wildcard consumers should not auto-create destinations
[ https://issues.apache.org/jira/browse/AMQ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9475: Fix Version/s: 6.2.0 > ConsumerControl commands for wildcard consumers should not auto-create > destinations > --- > > Key: AMQ-9475 > URL: https://issues.apache.org/jira/browse/AMQ-9475 > Project: ActiveMQ Classic > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.2 > > Time Spent: 50m > Remaining Estimate: 0h > > While investigating AMQ-9472, it was > [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2046523027] > out in some cases (like with Stomp) wildcard destinations that do not exist > could be auto created on subscribe which besides creating the extra > destination, can also lead to errors if proper ACLs are not set up. > As > [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2047625950] > out, the bug here is that wildcard destinations should not be auto-created > just by subscribing using a wildcard. There is a check for this in > [addConsumer()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L344-L346] > but > [processConsumerControl()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L694] > does not have the checks. So any time that command is sent (like prefetch > update) this could be an issue. > This can be fixed by only looking up destinations that are wildcards and not > auto creating them when processing consumer control objects just like > addConsumer() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9475) ConsumerControl commands for wildcard consumers should not auto-create destinations
[ https://issues.apache.org/jira/browse/AMQ-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9475: Fix Version/s: (was: 6.2.0) > ConsumerControl commands for wildcard consumers should not auto-create > destinations > --- > > Key: AMQ-9475 > URL: https://issues.apache.org/jira/browse/AMQ-9475 > Project: ActiveMQ Classic > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.5, 6.1.2 > > Time Spent: 50m > Remaining Estimate: 0h > > While investigating AMQ-9472, it was > [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2046523027] > out in some cases (like with Stomp) wildcard destinations that do not exist > could be auto created on subscribe which besides creating the extra > destination, can also lead to errors if proper ACLs are not set up. > As > [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2047625950] > out, the bug here is that wildcard destinations should not be auto-created > just by subscribing using a wildcard. There is a check for this in > [addConsumer()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L344-L346] > but > [processConsumerControl()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L694] > does not have the checks. So any time that command is sent (like prefetch > update) this could be an issue. > This can be fixed by only looking up destinations that are wildcards and not > auto creating them when processing consumer control objects just like > addConsumer() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9476) Jetty config has invalid constraint mapping
[ https://issues.apache.org/jira/browse/AMQ-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9476: Description: Fix constraint mapping that is incorrect (was: Fix contraint mapping) > Jetty config has invalid constraint mapping > --- > > Key: AMQ-9476 > URL: https://issues.apache.org/jira/browse/AMQ-9476 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 6.1.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 6.1.2 > > > Fix constraint mapping that is incorrect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9476) Jetty config has invalid constraint mapping
Christopher L. Shannon created AMQ-9476: --- Summary: Jetty config has invalid constraint mapping Key: AMQ-9476 URL: https://issues.apache.org/jira/browse/AMQ-9476 Project: ActiveMQ Classic Issue Type: Bug Affects Versions: 6.1.1 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 6.2.0, 6.1.2 Fix contraint mapping -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-9472. --- Resolution: Not A Problem Closing this as not a problem as the scenario here makes sense in how it works as described in the comments and the PR. I opened AMQ-9475 as a follow on bug fix issue related to this. > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9475) ConsumerControl commands for wildcard consumers should not auto-create destinations
Christopher L. Shannon created AMQ-9475: --- Summary: ConsumerControl commands for wildcard consumers should not auto-create destinations Key: AMQ-9475 URL: https://issues.apache.org/jira/browse/AMQ-9475 Project: ActiveMQ Classic Issue Type: Bug Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 6.2.0, 5.18.5, 6.1.2 While investigating AMQ-9472, it was [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2046523027] out in some cases (like with Stomp) wildcard destinations that do not exist could be auto created on subscribe which besides creating the extra destination, can also lead to errors if proper ACLs are not set up. As [pointed|https://github.com/apache/activemq/pull/1198#issuecomment-2047625950] out, the bug here is that wildcard destinations should not be auto-created just by subscribing using a wildcard. There is a check for this in [addConsumer()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L344-L346] but [processConsumerControl()|https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java#L694] does not have the checks. So any time that command is sent (like prefetch update) this could be an issue. This can be fixed by only looking up destinations that are wildcards and not auto creating them when processing consumer control objects just like addConsumer() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835076#comment-17835076 ] Christopher L. Shannon edited comment on AMQ-9472 at 4/8/24 11:38 PM: -- I think this issue should be closed as "Not a Problem" or 'Won't Fix" and I explained why on the PR: [https://github.com/apache/activemq/pull/1198|https://github.com/apache/activemq/pull/1198#issuecomment-2043752900] The reason is that we are not going to change how consumers work with regards to adding multiple subscriptions if it matches a wildcard *Edit:* I think if we wanted to do anything here it would be more considered a new feature or improvement and not a bug fix and need to be configurable as explained in: https://github.com/apache/activemq/pull/1198#issuecomment-2043856614 was (Author: christopher.l.shannon): I think this issue should be closed as "Not a Problem" or 'Won't Fix" and I explained why on the PR: [https://github.com/apache/activemq/pull/1198|https://github.com/apache/activemq/pull/1198#issuecomment-2043752900] The reason is that we are not going to change how consumers work with regards to adding multiple subscriptions if it matches a wildcard > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835076#comment-17835076 ] Christopher L. Shannon commented on AMQ-9472: - I think this issue should be closed as "Not a Problem" or 'Won't Fix" and I explained why on the PR: [https://github.com/apache/activemq/pull/1198|https://github.com/apache/activemq/pull/1198#issuecomment-2043752900] The reason is that we are not going to change how consumers work with regards to adding multiple subscriptions if it matches a wildcard > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-5130) If a STOMP listener attempts to connect to an OpenWire transport connector the broker dies
[
https://issues.apache.org/jira/browse/AMQ-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835050#comment-17835050
]
Christopher L. Shannon commented on AMQ-5130:
-
I'm unassigning target versions for this because this Issue has been open for
10 years and continuously moved to the next version and ignored. I think at
this point it needs to be re-evaluated to see if it's still a problem and if it
is then decide if it will actually be fixed or not, or otherwise we should
close the issue.
> If a STOMP listener attempts to connect to an OpenWire transport connector
> the broker dies
> --
>
> Key: AMQ-5130
> URL: https://issues.apache.org/jira/browse/AMQ-5130
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.13
> Environment: Linux Centos 6.4 Apache ActiveMQ 5.9.0, Apache ActiveMQ
> demo STOMP listener
>Reporter: Matthew Western
>Assignee: Matt Pavlovich
>Priority: Major
> Attachments: AMQ5130.patch
>
>
> If a STOMP listener attempts to connect to the broker with an NIO OpenWire
> transport connector URI the broker dies (The JVM terminates with an out of
> memory error).
> I have consistently reproduced this using the test STOMP listener provided
> with 5.9.0. I have not checked to see what happens with the STOMP publisher
> but I imagine the results would be the same.
> I discovered this due to accidentally using the wrong URI with my STOMP
> client.
> I think this is a serious issue as it could be exploited as a DOS attack on
> known broker URIs.
> My configuration file is as follows:
> {code:xml}
> http://activemq.apache.org/schema/core; brokerName="broker2"
> dataDirectory="${activemq.data}" networkConnectorStartAsync="true"
> advisorySupport="true">
>
>
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
> useQueueForQueueMessages="true" />
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
>
>
>
>
> {code}
> The listener terminates immediately upon starting with:
> {noformat}
> cannot sysread(): Connection reset by peer{noformat}
> And the broker JVM dies with the following hs_errpid*.log error:
> {noformat}
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 693723136 bytes for
> committing reserved memory.
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # In 32 bit mode, the process size limit was hit
> # Possible solutions:
> # Reduce memory load on the system
> # Increase physical memory or swap space
> # Check if swap backing store is full
> # Use 64 bit Java on a 64 bit OS
> # Decrease Java heap size (-Xmx/-Xms)
> # Decrease number of Java threads
> # Decrease Java thread stack sizes (-Xss)
> # Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> # Out of Memory Error (os_linux.cpp:2718), pid=8783, tid=140478943950592
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> 1.7.0_45-b18)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> --- T H R E A D ---
> Current thread (0x7fc3c8086000): VMThread [stack:
> 0x7fc3cd7d7000,0x7fc3cd8d8000] [id=8785]
> Stack: [0x7fc3cd7d7000,0x7fc3cd8d8000], sp=0x7fc3cd8d62d0, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x992c8a] VMError::report_and_die()+0x2ea
> V [libjvm.so+0x49319b] report_vm_out_of_memory(char const*, int, unsigned
> long, char const*)+0x9b
> V [libjvm.so+0x81310e] os::Linux::commit_memory_impl(char*, unsigned long,
> bool)+0xfe
> V [libjvm.so+0x8135bf] os::Linux::commit_memory_impl(char*, unsigned long,
> unsigned long, bool)+0x4f
> V [libjvm.so+0x81377c] os::pd_commit_memory(char*, unsigned long, unsigned
> long, bool)+0xc
> V [libjvm.so+0x80d86a] os::commit_memory(char*, unsigned long, unsigned long,
> bool)+0x2a
> V [libjvm.so+0x98e5d9] VirtualSpace::expand_by(unsigned long, bool)+0x1c9
> V [libjvm.so+0x571725] OneContigSpaceCardGeneration::grow_by(unsigned
> long)+0x25
> V [libjvm.so+0x571b3e]
[jira] [Updated] (AMQ-5130) If a STOMP listener attempts to connect to an OpenWire transport connector the broker dies
[
https://issues.apache.org/jira/browse/AMQ-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-5130:
Fix Version/s: (was: 6.2.0)
(was: 5.18.5)
> If a STOMP listener attempts to connect to an OpenWire transport connector
> the broker dies
> --
>
> Key: AMQ-5130
> URL: https://issues.apache.org/jira/browse/AMQ-5130
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.13
> Environment: Linux Centos 6.4 Apache ActiveMQ 5.9.0, Apache ActiveMQ
> demo STOMP listener
>Reporter: Matthew Western
>Assignee: Matt Pavlovich
>Priority: Major
> Attachments: AMQ5130.patch
>
>
> If a STOMP listener attempts to connect to the broker with an NIO OpenWire
> transport connector URI the broker dies (The JVM terminates with an out of
> memory error).
> I have consistently reproduced this using the test STOMP listener provided
> with 5.9.0. I have not checked to see what happens with the STOMP publisher
> but I imagine the results would be the same.
> I discovered this due to accidentally using the wrong URI with my STOMP
> client.
> I think this is a serious issue as it could be exploited as a DOS attack on
> known broker URIs.
> My configuration file is as follows:
> {code:xml}
> http://activemq.apache.org/schema/core; brokerName="broker2"
> dataDirectory="${activemq.data}" networkConnectorStartAsync="true"
> advisorySupport="true">
>
>
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
> useQueueForQueueMessages="true" />
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
>
>
>
>
> {code}
> The listener terminates immediately upon starting with:
> {noformat}
> cannot sysread(): Connection reset by peer{noformat}
> And the broker JVM dies with the following hs_errpid*.log error:
> {noformat}
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 693723136 bytes for
> committing reserved memory.
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # In 32 bit mode, the process size limit was hit
> # Possible solutions:
> # Reduce memory load on the system
> # Increase physical memory or swap space
> # Check if swap backing store is full
> # Use 64 bit Java on a 64 bit OS
> # Decrease Java heap size (-Xmx/-Xms)
> # Decrease number of Java threads
> # Decrease Java thread stack sizes (-Xss)
> # Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> # Out of Memory Error (os_linux.cpp:2718), pid=8783, tid=140478943950592
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> 1.7.0_45-b18)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> --- T H R E A D ---
> Current thread (0x7fc3c8086000): VMThread [stack:
> 0x7fc3cd7d7000,0x7fc3cd8d8000] [id=8785]
> Stack: [0x7fc3cd7d7000,0x7fc3cd8d8000], sp=0x7fc3cd8d62d0, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x992c8a] VMError::report_and_die()+0x2ea
> V [libjvm.so+0x49319b] report_vm_out_of_memory(char const*, int, unsigned
> long, char const*)+0x9b
> V [libjvm.so+0x81310e] os::Linux::commit_memory_impl(char*, unsigned long,
> bool)+0xfe
> V [libjvm.so+0x8135bf] os::Linux::commit_memory_impl(char*, unsigned long,
> unsigned long, bool)+0x4f
> V [libjvm.so+0x81377c] os::pd_commit_memory(char*, unsigned long, unsigned
> long, bool)+0xc
> V [libjvm.so+0x80d86a] os::commit_memory(char*, unsigned long, unsigned long,
> bool)+0x2a
> V [libjvm.so+0x98e5d9] VirtualSpace::expand_by(unsigned long, bool)+0x1c9
> V [libjvm.so+0x571725] OneContigSpaceCardGeneration::grow_by(unsigned
> long)+0x25
> V [libjvm.so+0x571b3e] OneContigSpaceCardGeneration::expand(unsigned long,
> unsigned long)+0x3e
> V [libjvm.so+0x571878]
> OneContigSpaceCardGeneration::expand_and_allocate(unsigned long, bool,
> bool)+0xc8
> V [libjvm.so+0x4270e4] GenCollectorPolicy::expand_heap_and_allocate(unsigned
> long, bool)+0xa4
> V [libjvm.so+0x428122]
[jira] [Updated] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9435: Fix Version/s: 5.17.7 > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 > > Time Spent: 20m > Remaining Estimate: 0h > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9436) StoreQueueCursor creates different audits for persistent and non persistent cursors
[ https://issues.apache.org/jira/browse/AMQ-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9436. - Resolution: Fixed > StoreQueueCursor creates different audits for persistent and non persistent > cursors > --- > > Key: AMQ-9436 > URL: https://issues.apache.org/jira/browse/AMQ-9436 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 > > Time Spent: 20m > Remaining Estimate: 0h > > While working on AMQ-9435 I noticed that StoreQueueCursor incorrectly sets > the start flag to true first before calling calling super.start() in the > start method. This means that when super is called the message audit is never > initialized as it thinks it was already started so it stays null forever. > This causes both the persistent and non-persistent cursors to create their > own audits which ends up duplicating objects when they should share the same > audit so we get duplicate detection across persistent and non persistent > messages and also so that we save memory by not duplicating the objects and > allowing audit depth config to control how large the audit is. > Something else I noticed is that the start/stop methods do not protect > against calling them more than once and they should to prevent duplicate > initialization so I also will fix that. > I checked and durables are already correct with their audit tracking (the > audit is passed down to all of the sub prefetches and shared) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9436) StoreQueueCursor creates different audits for persistent and non persistent cursors
[ https://issues.apache.org/jira/browse/AMQ-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9436: Fix Version/s: 5.17.7 > StoreQueueCursor creates different audits for persistent and non persistent > cursors > --- > > Key: AMQ-9436 > URL: https://issues.apache.org/jira/browse/AMQ-9436 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 > > Time Spent: 20m > Remaining Estimate: 0h > > While working on AMQ-9435 I noticed that StoreQueueCursor incorrectly sets > the start flag to true first before calling calling super.start() in the > start method. This means that when super is called the message audit is never > initialized as it thinks it was already started so it stays null forever. > This causes both the persistent and non-persistent cursors to create their > own audits which ends up duplicating objects when they should share the same > audit so we get duplicate detection across persistent and non persistent > messages and also so that we save memory by not duplicating the objects and > allowing audit depth config to control how large the audit is. > Something else I noticed is that the start/stop methods do not protect > against calling them more than once and they should to prevent duplicate > initialization so I also will fix that. > I checked and durables are already correct with their audit tracking (the > audit is passed down to all of the sub prefetches and shared) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9436) StoreQueueCursor creates different audits for persistent and non persistent cursors
Christopher L. Shannon created AMQ-9436: --- Summary: StoreQueueCursor creates different audits for persistent and non persistent cursors Key: AMQ-9436 URL: https://issues.apache.org/jira/browse/AMQ-9436 Project: ActiveMQ Classic Issue Type: Bug Components: Broker Affects Versions: 6.0.1, 5.18.3 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 6.1.0, 5.18.4, 6.0.2 While working on AMQ-9435 I noticed that StoreQueueCursor incorrectly sets the start flag to true first before calling calling super.start() in the start method. This means that when super is called the message audit is never initialized as it thinks it was already started so it stays null forever. This causes both the persistent and non-persistent cursors to create their own audits which ends up duplicating objects when they should share the same audit so we get duplicate detection across persistent and non persistent messages and also so that we save memory by not duplicating the objects and allowing audit depth config to control how large the audit is. Something else I noticed is that the start/stop methods do not protect against calling them more than once and they should to prevent duplicate initialization so I also will fix that. I checked and durables are already correct with their audit tracking (the audit is passed down to all of the sub prefetches and shared) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9435. - Resolution: Fixed > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > Time Spent: 20m > Remaining Estimate: 0h > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned AMQ-9435: --- Assignee: Christopher L. Shannon > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9435: Description: There is a bug in KahaDB on message add where if a message is marked as a duplicate the orderIndex next message Id is not rolled back. When a duplicate is detected and ignored the index is supposed to be rolled back so that the state isn't broken but in this case the sequence id is still incremented and this leads to gaps in the order index sequence. KahaDB tracks pending messages that need to be acknowledged for durable subs in a SequenceSet and that set is expected to be contiguous and if it isn't it breaks. The gaps lead to the store reporting messages still exist for durables and they appear as "stuck" even though there are no messages. The fix is to roll back the counter (this is already done in another spot) so it is only incremented if the message is stored. If an existing store is broken by this bug an index rebuild is likely necessary but then it wouldn't come back. was: There is a bug in KahaDB on message add where if a message is marked as a duplicate the orderIndex next message Id is not rolled back. When a duplicate is detected and ignored the index is supposed to be rolled back so that the state isn't broken but in this case the sequence id is still incremented and this leads to gaps in the order index sequence. KahaDB tracks pending messages that need to be acknowledged for durable subs in a SequenceSet and that set is expected to be contiguous and if it isn't it breaks. The gaps lead to the store reporting messages still exist for durables and they appear as "stuck" even though there are no messages. The fix is to roll back the counter (this is already done in another spot) so it is only incremented if the message is stored > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9435: Component/s: KahaDB > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-9435 started by Christopher L. Shannon. --- > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
Christopher L. Shannon created AMQ-9435: --- Summary: KahaDB durable sub tracking breaks on duplicate messages Key: AMQ-9435 URL: https://issues.apache.org/jira/browse/AMQ-9435 Project: ActiveMQ Classic Issue Type: Bug Affects Versions: 6.0.1, 5.18.3 Reporter: Christopher L. Shannon Fix For: 6.1.0, 5.18.4, 6.0.2 There is a bug in KahaDB on message add where if a message is marked as a duplicate the orderIndex next message Id is not rolled back. When a duplicate is detected and ignored the index is supposed to be rolled back so that the state isn't broken but in this case the sequence id is still incremented and this leads to gaps in the order index sequence. KahaDB tracks pending messages that need to be acknowledged for durable subs in a SequenceSet and that set is expected to be contiguous and if it isn't it breaks. The gaps lead to the store reporting messages still exist for durables and they appear as "stuck" even though there are no messages. The fix is to roll back the counter (this is already done in another spot) so it is only incremented if the message is stored -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9420) KahaDB durable subscription stats can go negative on duplicate acks
[ https://issues.apache.org/jira/browse/AMQ-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9420. - Resolution: Fixed > KahaDB durable subscription stats can go negative on duplicate acks > --- > > Key: AMQ-9420 > URL: https://issues.apache.org/jira/browse/AMQ-9420 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > AMQ-6375 added support for non blocking durable subscription statistics to > KahaDB to track pending message count and message size metrics. By default > this is disabled and can be enabled with the enableSubscriptionStatistics > flag on KahaDB. > On rare occasions I have noticed that sometimes the metrics may got negative > or be slightly off. I found an area where it's possible if a duplicate ack > comes in then in some scenarios the metrics may be deprecated twice. This > issue only applies to the subscription stats and not the store statistics for > the overall destination as those stats would only get decremented once when > the message is removed from the order index. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (AMQ-9420) KahaDB durable subscription stats can go negative on duplicate acks
[ https://issues.apache.org/jira/browse/AMQ-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-9420 started by Christopher L. Shannon. --- > KahaDB durable subscription stats can go negative on duplicate acks > --- > > Key: AMQ-9420 > URL: https://issues.apache.org/jira/browse/AMQ-9420 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 > > > AMQ-6375 added support for non blocking durable subscription statistics to > KahaDB to track pending message count and message size metrics. By default > this is disabled and can be enabled with the enableSubscriptionStatistics > flag on KahaDB. > On rare occasions I have noticed that sometimes the metrics may got negative > or be slightly off. I found an area where it's possible if a duplicate ack > comes in then in some scenarios the metrics may be deprecated twice. This > issue only applies to the subscription stats and not the store statistics for > the overall destination as those stats would only get decremented once when > the message is removed from the order index. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9420) KahaDB durable subscription stats can go negative on duplicate acks
Christopher L. Shannon created AMQ-9420: --- Summary: KahaDB durable subscription stats can go negative on duplicate acks Key: AMQ-9420 URL: https://issues.apache.org/jira/browse/AMQ-9420 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 6.0.1, 5.18.3 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 AMQ-6375 added support for non blocking durable subscription statistics to KahaDB to track pending message count and message size metrics. By default this is disabled and can be enabled with the enableSubscriptionStatistics flag on KahaDB. On rare occasions I have noticed that sometimes the metrics may got negative or be slightly off. I found an area where it's possible if a duplicate ack comes in then in some scenarios the metrics may be deprecated twice. This issue only applies to the subscription stats and not the store statistics for the overall destination as those stats would only get decremented once when the message is removed from the order index. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OPENWIRE-6) Fix build on JDK 8
[ https://issues.apache.org/jira/browse/OPENWIRE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned OPENWIRE-6: - Assignee: Christopher L. Shannon > Fix build on JDK 8 > --- > > Key: OPENWIRE-6 > URL: https://issues.apache.org/jira/browse/OPENWIRE-6 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > Currently there are some incompactible dependencies with scalate and scala > causing the build to fail on JDK 8 update 60. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENWIRE-75) Support mapping javax -> jakarta exceptions in openwire
[ https://issues.apache.org/jira/browse/OPENWIRE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved OPENWIRE-75. Resolution: Fixed > Support mapping javax -> jakarta exceptions in openwire > --- > > Key: OPENWIRE-75 > URL: https://issues.apache.org/jira/browse/OPENWIRE-75 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > This issue is to migrate the changes from > https://issues.apache.org/jira/browse/AMQ-9418 so that if the clients using > Openwire generated by this project (which will always be new clients jakarta) > talk to an older 5.x broker that uses javax exception types then the > exceptions can be translated correctly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-75) Support mapping javax -> jakarta exceptions in openwire
Christopher L. Shannon created OPENWIRE-75: -- Summary: Support mapping javax -> jakarta exceptions in openwire Key: OPENWIRE-75 URL: https://issues.apache.org/jira/browse/OPENWIRE-75 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 1.0.0 This issue is to migrate the changes from https://issues.apache.org/jira/browse/AMQ-9418 so that if the clients using Openwire generated by this project (which will always be new clients jakarta) talk to an older 5.x broker that uses javax exception types then the exceptions can be translated correctly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807441#comment-17807441 ] Christopher L. Shannon commented on AMQ-9418: - One more thing to do is to migrate these changes to the [OPENWIRE|https://issues.apache.org/jira/projects/OPENWIRE/] project since that will be used for new versions going forward > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 5.16.8, 6.0.2 > > Time Spent: 50m > Remaining Estimate: 0h > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9418. - Resolution: Fixed > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 5.16.8, 6.0.2 > > Time Spent: 50m > Remaining Estimate: 0h > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807433#comment-17807433 ] Christopher L. Shannon commented on AMQ-9418: - Another option for Openwire v13 for conversion is to just update the ExceptionResponse to no longer have exception type (just code and message) and push the conversion logic into the marshallers for old version so the broker doesn't need to worry about the conversion > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 5.16.8, 6.0.2 > > Time Spent: 50m > Remaining Estimate: 0h > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9418: Fix Version/s: 6.1.0 > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 5.16.8, 6.0.2 > > Time Spent: 40m > Remaining Estimate: 0h > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9418: Fix Version/s: 5.17.7 5.16.8 > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.4, 5.17.7, 5.16.8, 6.0.2 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807410#comment-17807410 ] Christopher L. Shannon commented on AMQ-9418: - I decided to go with a client side approach as described here https://lists.apache.org/thread/pr2ty60xx54tm3tfnfb1k2hbrmvm59no We can provide updated clients (5.18.x, 6.0.x, etc) that can do the conversion to the correct JMS package if the wrong type is received which is much simpler than the broker having to try and figure out what to send back and doesn't require the broker to keep both versions on the classpath. The downside is any client that wants to handle the conversion needs an upgrade but I think that is ok as long as we document it. Any other clients will just get back a generic JMSException type so would still work just with a less specific exception. The main use case would be for users that have a client or a broker that is mismatched for whatever reason (maybe stuck on an old JDK version, etc) so one is using jakarta and one is using javax. In this case they can still upgrade to the latest versions of that client library line if they want the conversion to work (5.17.x or 5.18.x or whatever) and we can document this on the website for people looking at compatibility between brokers. This obviously means NMS clients or other non-java clients would need an update as well. Going forward with a new version of OpenWire (maybe v13 or v14 etc) ideally we would replace the ExceptionResponse command with a new version (ExceptionResponseV2 or whatever we want to call it) and it can use error codes and allow the client to decide how to convert to exceptions so we are not having to send them back. This also prevents future security issues like the one we recently patched. > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.4, 5.17.7, 5.16.8, 6.0.2 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9418: Fix Version/s: 5.18.4 6.0.2 (was: 6.1.0) > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.18.4, 6.0.2 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9418: Description: For javax clients to connect to jakarta-based broker, we need to map exceptions to the javax namespace from jakarta-based broker-side exceptions and vice versa for jakarta clients talking to a javax broker. (was: For javax clients to connect to jakarta-based broker, we need to map exceptions to the javax namespace from jakarta-based broker-side exceptions) > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9418: Issue Type: Bug (was: Task) > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-9418 started by Christopher L. Shannon. --- > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions > and vice versa for jakarta clients talking to a javax broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned AMQ-9418: --- Assignee: Christopher L. Shannon > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9418) Support mapping jakarta -> javax exceptions in openwire
[ https://issues.apache.org/jira/browse/AMQ-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806228#comment-17806228 ] Christopher L. Shannon commented on AMQ-9418: - https://issues.apache.org/jira/browse/AMQ-6379 added support for Java clients starting with 5.14.0 to send their client version which could likely be used to detect the version and to do a mapping. We could also obviously assume for any future OpenWire versions that it would be Jakarta or maybe change the exception handling entirely (use something like error codes and decouple it). For future clients we could even add an extra piece of metadata to the negotiation to signal they want Jakarta exceptions but getting a way from exception types altogether might be nice. There are definitely a few options to fix it for new clients but for legacy we have to handle it either way. A new OpenWire version will be needed for shared subscription support so we can make this better going forward for sure in some way. But to handle the legacy stuff maybe we could do something like that following: # If the OpenWire version is >12 (new) then assume Jakarta # If OpenWire version is <= 12 then check if the client reported that it is 5.x or 6.x. This also goes for the jakarta client that we added for 5.18.x (guess we need to check that too). If it's a legacy client then we can do the mapping to javax exception types. # If OpenWire version <=12 and no client version is sent then we just assume legacy and send back javax exception types as that means they are a very old client or a non-java client so would be expecting javax. Any non java clients would need to send metadata to signal they want jakarta (or use a new upgraded Openwire version). > Support mapping jakarta -> javax exceptions in openwire > --- > > Key: AMQ-9418 > URL: https://issues.apache.org/jira/browse/AMQ-9418 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Major > Fix For: 6.1.0 > > > For javax clients to connect to jakarta-based broker, we need to map > exceptions to the javax namespace from jakarta-based broker-side exceptions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-73) Add tests for all commands to verify universal marshaller byte equivalency with all versions
Christopher L. Shannon created OPENWIRE-73: -- Summary: Add tests for all commands to verify universal marshaller byte equivalency with all versions Key: OPENWIRE-73 URL: https://issues.apache.org/jira/browse/OPENWIRE-73 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Fix For: 1.0.0 Right now the OpenWire interop tests try and check that the new commands and marshallers produce the same bytes as the existing marshallers that are in activemq-client and currently used. This is done indirectly by using the new marshallers to send commands to an embedded broker which reads them. This works but it doesn't cover all cases and requires running a broker. Instead, a better approach would be to simply check the resulting bytes produced are exactly equivalent and just test the different marshallers without a broker. We should create tests for every single OpenWire command and version that will check that the marshalled bytes are exactly equivalent as the existing verison in use today with activemq-client. In theory these tests could be generated automatically so we can explore that but we may not need to as we really only need to create the tests once for the legacy versions today because going forward with the universal marshaller being used there won't be any new legacy versions and we will keep the new tests up to date. Also note that this project includes a legacy module with copies of the legacy marshallers but still a bit refactored and repackaged. So we should likely run the tests to verify the universal marshaller output matches both the re-packaged legacy module as well as the legacy marshallers that are packaged currently with activemq-client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENWIRE-68) Import v12 OpenWire version
[ https://issues.apache.org/jira/browse/OPENWIRE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved OPENWIRE-68. Resolution: Fixed > Import v12 OpenWire version > --- > > Key: OPENWIRE-68 > URL: https://issues.apache.org/jira/browse/OPENWIRE-68 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The project currently only contains up to version 11, we need to import > version 12. There will need to be some refactoring and packaging done for > this. The CVE fix is actually handled at the base class level so we just need > to update the legacy test for the marshalling CVE fix. The CVE is fixed in > OPENWIRE-67 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OPENWIRE-68) Import v12 OpenWire version
[ https://issues.apache.org/jira/browse/OPENWIRE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned OPENWIRE-68: -- Assignee: Christopher L. Shannon > Import v12 OpenWire version > --- > > Key: OPENWIRE-68 > URL: https://issues.apache.org/jira/browse/OPENWIRE-68 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > The project currently only contains up to version 11, we need to import > version 12. There will need to be some refactoring and packaging done for > this. The CVE fix is actually handled at the base class level so we just need > to update the legacy test for the marshalling CVE fix. The CVE is fixed in > OPENWIRE-67 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (OPENWIRE-68) Import v12 OpenWire version
[ https://issues.apache.org/jira/browse/OPENWIRE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on OPENWIRE-68 started by Christopher L. Shannon. -- > Import v12 OpenWire version > --- > > Key: OPENWIRE-68 > URL: https://issues.apache.org/jira/browse/OPENWIRE-68 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > The project currently only contains up to version 11, we need to import > version 12. There will need to be some refactoring and packaging done for > this. The CVE fix is actually handled at the base class level so we just need > to update the legacy test for the marshalling CVE fix. The CVE is fixed in > OPENWIRE-67 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-71) Align OpenWire project major version to protocol major version (12.0.0)
[ https://issues.apache.org/jira/browse/OPENWIRE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794669#comment-17794669 ] Christopher L. Shannon commented on OPENWIRE-71: I was thinking more about this and I think either versioning is probably ok, I think you could make an argument for either. We can leave this open for now and just figure out the versioning later before we release but as of now I still think I'm more in favor of the approach [~tabish] suggested and not tying the version to the implementation so we would just keep it as version 1.0.0 to start and document what is there. > Align OpenWire project major version to protocol major version (12.0.0) > --- > > Key: OPENWIRE-71 > URL: https://issues.apache.org/jira/browse/OPENWIRE-71 > Project: ActiveMQ OpenWire > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > > OpenWire v12 should be served by activemq-openwire-12.0.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OPENWIRE-71) Align OpenWire project major version to protocol major version (12.0.0)
[ https://issues.apache.org/jira/browse/OPENWIRE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794351#comment-17794351 ] Christopher L. Shannon edited comment on OPENWIRE-71 at 12/7/23 5:55 PM: - Yeah we just need to move v12 into the legacy module that already exists was (Author: christopher.l.shannon): Yeah we just need to move v12 into the legacy module that already exists and not create another jar > Align OpenWire project major version to protocol major version (12.0.0) > --- > > Key: OPENWIRE-71 > URL: https://issues.apache.org/jira/browse/OPENWIRE-71 > Project: ActiveMQ OpenWire > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > > OpenWire v12 should be served by activemq-openwire-12.0.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-71) Align OpenWire project major version to protocol major version (12.0.0)
[ https://issues.apache.org/jira/browse/OPENWIRE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794360#comment-17794360 ] Christopher L. Shannon commented on OPENWIRE-71: There's another issue here for this https://issues.apache.org/jira/browse/OPENWIRE-68 > Align OpenWire project major version to protocol major version (12.0.0) > --- > > Key: OPENWIRE-71 > URL: https://issues.apache.org/jira/browse/OPENWIRE-71 > Project: ActiveMQ OpenWire > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > > OpenWire v12 should be served by activemq-openwire-12.0.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794358#comment-17794358 ] Christopher L. Shannon commented on OPENWIRE-67: Fixed in https://github.com/apache/activemq-openwire/commit/cfdf4840514a3619cf2df679fabc6045e3f93076 > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions. Because of the refactoring done all the legacy versions > will be fixed as well with this. Tests will be added to verify both legacy > and universal codec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved OPENWIRE-67. Resolution: Fixed > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions. Because of the refactoring done all the legacy versions > will be fixed as well with this. Tests will be added to verify both legacy > and universal codec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned OPENWIRE-67: -- Assignee: Christopher L. Shannon > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions. Because of the refactoring done all the legacy versions > will be fixed as well with this. Tests will be added to verify both legacy > and universal codec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on OPENWIRE-67 started by Christopher L. Shannon. -- > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions. Because of the refactoring done all the legacy versions > will be fixed as well with this. Tests will be added to verify both legacy > and universal codec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-68) Import v12 OpenWire version
[ https://issues.apache.org/jira/browse/OPENWIRE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-68: --- Description: The project currently only contains up to version 11, we need to import version 12. There will need to be some refactoring and packaging done for this. The CVE fix is actually handled at the base class level so we just need to update the legacy test for the marshalling CVE fix. The CVE is fixed in OPENWIRE-67 (was: Need to update all the legacy versions to make sure the CVE for throwable validation is fixed. Openwire is up to version 12 so all versions should be imported and the tests as well.) Priority: Major (was: Blocker) Summary: Import v12 OpenWire version (was: Import all updated OpenWire versions that have Throwable CVE fix) > Import v12 OpenWire version > --- > > Key: OPENWIRE-68 > URL: https://issues.apache.org/jira/browse/OPENWIRE-68 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > The project currently only contains up to version 11, we need to import > version 12. There will need to be some refactoring and packaging done for > this. The CVE fix is actually handled at the base class level so we just need > to update the legacy test for the marshalling CVE fix. The CVE is fixed in > OPENWIRE-67 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-67: --- Description: Need to make sure to update the generator to include the fix from https://issues.apache.org/jira/browse/AMQ-9370 to prevent https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly generated versions. Because of the refactoring done all the legacy versions will be fixed as well with this. Tests will be added to verify both legacy and universal codec. (was: Need to make sure to update the generator to include the fix from https://issues.apache.org/jira/browse/AMQ-9370 to prevent https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly generated versions) > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions. Because of the refactoring done all the legacy versions > will be fixed as well with this. Tests will be added to verify both legacy > and universal codec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-71) Align OpenWire project major version to protocol major version (12.0.0)
[ https://issues.apache.org/jira/browse/OPENWIRE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794351#comment-17794351 ] Christopher L. Shannon commented on OPENWIRE-71: Yeah we just need to move v12 into the legacy module that already exists and not create another jar > Align OpenWire project major version to protocol major version (12.0.0) > --- > > Key: OPENWIRE-71 > URL: https://issues.apache.org/jira/browse/OPENWIRE-71 > Project: ActiveMQ OpenWire > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > > OpenWire v12 should be served by activemq-openwire-12.0.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-70) Upgrade to Junit 5
[ https://issues.apache.org/jira/browse/OPENWIRE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794269#comment-17794269 ] Christopher L. Shannon commented on OPENWIRE-70: [~mattrpav] - You mentioned possibly wanted to take a look at this, so if you want you can assign this to yourself or I can also do it when I get a chance, up to you. We should import the new JUnit 5 bom for when we do update. The main thing that has to get fixed is going to be the parameterized tests as JUnit5 changes the set up for that so that will require a bit of refactoring. > Upgrade to Junit 5 > -- > > Key: OPENWIRE-70 > URL: https://issues.apache.org/jira/browse/OPENWIRE-70 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > Project is still using the latest Junit 4 version after OPENWIRE-66, we > should upgrade to Junit 5 instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved OPENWIRE-69. Fix Version/s: 1.0.0 Resolution: Fixed > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 1h > Remaining Estimate: 0h > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-70) Upgrade to Junit 5
Christopher L. Shannon created OPENWIRE-70: -- Summary: Upgrade to Junit 5 Key: OPENWIRE-70 URL: https://issues.apache.org/jira/browse/OPENWIRE-70 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Fix For: 1.0.0 Project is still using the latest Junit 4 version after OPENWIRE-66, we should upgrade to Junit 5 instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on OPENWIRE-69 started by Christopher L. Shannon. -- > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved OPENWIRE-66. Resolution: Fixed > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OPENWIRE-46) Consider archiving this project/repo
[
https://issues.apache.org/jira/browse/OPENWIRE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon closed OPENWIRE-46.
--
Resolution: Won't Do
This project is planned to be revived and will be used for new Openwire versions
> Consider archiving this project/repo
>
>
> Key: OPENWIRE-46
> URL: https://issues.apache.org/jira/browse/OPENWIRE-46
> Project: ActiveMQ OpenWire
> Issue Type: Task
>Reporter: Lucas Tétreault
>Priority: Minor
>
> {color:#00}Neither Active Classic nor Artemis appear to use this. Should
> this repo be archived to avoid confusion and drift?
> {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-67: --- Priority: Blocker (was: Critical) > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-68) Import all updated OpenWire versions that have Throwable CVE fix
Christopher L. Shannon created OPENWIRE-68: -- Summary: Import all updated OpenWire versions that have Throwable CVE fix Key: OPENWIRE-68 URL: https://issues.apache.org/jira/browse/OPENWIRE-68 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Fix For: 1.0.0 Need to update all the legacy versions to make sure the CVE for throwable validation is fixed. Openwire is up to version 12 so all versions should be imported and the tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
Christopher L. Shannon created OPENWIRE-67: -- Summary: Update generator to fix Throwable type validation CVE Key: OPENWIRE-67 URL: https://issues.apache.org/jira/browse/OPENWIRE-67 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Fix For: 1.0.0 Need to make sure to update the generator to include the fix from https://issues.apache.org/jira/browse/AMQ-9370 to prevent https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly generated versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-67: --- Issue Type: Bug (was: Task) > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Priority: Critical > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Description: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. I also noticed there is the openwire-website module that we may just want to remove as it is currently commented out and very out of date. was: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. I also noticed there is the openwire-website module that we may just want to remove as it is currently commented out and very out of date. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Description: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. I also noticed there is the openwire-website module that we may just want to remove as it is currently commented out and very out of date. was: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Fix Version/s: 1.0.0 > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on OPENWIRE-66 started by Christopher L. Shannon. -- > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Description: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. was: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Summary: Bring the Openwire project build up to date (was: Bring the Openwire project up to date) > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-66) Bring the Openwire project up to date
Christopher L. Shannon created OPENWIRE-66: -- Summary: Bring the Openwire project up to date Key: OPENWIRE-66 URL: https://issues.apache.org/jira/browse/OPENWIRE-66 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9388) camel-activemq transitively pulls in activemq-client-jakarta
[
https://issues.apache.org/jira/browse/AMQ-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon resolved AMQ-9388.
-
Resolution: Fixed
> camel-activemq transitively pulls in activemq-client-jakarta
>
>
> Key: AMQ-9388
> URL: https://issues.apache.org/jira/browse/AMQ-9388
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Blocker
> Fix For: 6.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While reviewing the 6.0.0 release I noticed that the newly added
> {{camel-activemq}} module pulls in {{activemq-client-jakarta}} as a
> transitive dependency. This makes sense since the version used is based on
> ActiveMQ 5.18.2 as 6.0.0 isn't released yet.
> We need to exclude this because with version 6.0.0 this module no longer
> exists so is not needed and secondly the 5.18.2 version has a CVE against it.
> The dependency in the current release is not included in the tar distribution
> but since it is transitively being pulled in with maven if someone has a
> dependency on the apache-activemq pom they will have the jar pulled into
> their build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9388) camel-activemq transitively pulls in activemq-client-jakarta
[
https://issues.apache.org/jira/browse/AMQ-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9388:
Priority: Blocker (was: Major)
> camel-activemq transitively pulls in activemq-client-jakarta
>
>
> Key: AMQ-9388
> URL: https://issues.apache.org/jira/browse/AMQ-9388
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Blocker
> Fix For: 6.0.0
>
>
> While reviewing the 6.0.0 release I noticed that the newly added
> {{camel-activemq }}module pulls in {{activemq-client-jakarta}} as a
> transitive dependency. This makes sense since the version used is based on
> ActiveMQ 5.18.2 as 6.0.0 isn't released yet.
> We need to exclude this because with version 6.0.0 this module no longer
> exists so is not needed and secondly the 5.18.2 version has a CVE against it.
> The dependency in the current release is not included in the tar distribution
> but since it is transitively being pulled in with maven if someone has a
> dependency on the apache-activemq pom they will have the jar pulled into
> their build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9388) camel-activemq transitively pulls in activemq-client-jakarta
[
https://issues.apache.org/jira/browse/AMQ-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9388:
Description:
While reviewing the 6.0.0 release I noticed that the newly added
{{camel-activemq}} module pulls in {{activemq-client-jakarta}} as a transitive
dependency. This makes sense since the version used is based on ActiveMQ 5.18.2
as 6.0.0 isn't released yet.
We need to exclude this because with version 6.0.0 this module no longer exists
so is not needed and secondly the 5.18.2 version has a CVE against it. The
dependency in the current release is not included in the tar distribution but
since it is transitively being pulled in with maven if someone has a dependency
on the apache-activemq pom they will have the jar pulled into their build.
was:
While reviewing the 6.0.0 release I noticed that the newly added
{{camel-activemq }}module pulls in {{activemq-client-jakarta}} as a transitive
dependency. This makes sense since the version used is based on ActiveMQ 5.18.2
as 6.0.0 isn't released yet.
We need to exclude this because with version 6.0.0 this module no longer exists
so is not needed and secondly the 5.18.2 version has a CVE against it. The
dependency in the current release is not included in the tar distribution but
since it is transitively being pulled in with maven if someone has a dependency
on the apache-activemq pom they will have the jar pulled into their build.
> camel-activemq transitively pulls in activemq-client-jakarta
>
>
> Key: AMQ-9388
> URL: https://issues.apache.org/jira/browse/AMQ-9388
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Blocker
> Fix For: 6.0.0
>
>
> While reviewing the 6.0.0 release I noticed that the newly added
> {{camel-activemq}} module pulls in {{activemq-client-jakarta}} as a
> transitive dependency. This makes sense since the version used is based on
> ActiveMQ 5.18.2 as 6.0.0 isn't released yet.
> We need to exclude this because with version 6.0.0 this module no longer
> exists so is not needed and secondly the 5.18.2 version has a CVE against it.
> The dependency in the current release is not included in the tar distribution
> but since it is transitively being pulled in with maven if someone has a
> dependency on the apache-activemq pom they will have the jar pulled into
> their build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9388) camel-activemq transitively pulls in activemq-client-jakarta
[
https://issues.apache.org/jira/browse/AMQ-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9388:
Description:
While reviewing the 6.0.0 release I noticed that the newly added
{{camel-activemq }}module pulls in {{activemq-client-jakarta}} as a transitive
dependency. This makes sense since the version used is based on ActiveMQ 5.18.2
as 6.0.0 isn't released yet.
We need to exclude this because with version 6.0.0 this module no longer exists
so is not needed and secondly the 5.18.2 version has a CVE against it. The
dependency in the current release is not included in the tar distribution but
since it is transitively being pulled in with maven if someone has a dependency
on the apache-activemq pom they will have the jar pulled into their build.
was:
While reviewing the 6.0.0 release I noticed that the newly added camel-activemq
module pulls in activemq-client-jakarta as a transitive dependency. This makes
sense since the version used is based on ActiveMQ 5.18.2 as 6.0.0 isn't
released yet.
We need to exclude this because with version 6.0.0 this module no longer exists
so is not needed and secondly the 5.18.2 version has a CVE against it. The
dependency in the current release is not included in the tar distribution but
since it is transitively being pulled in with maven if someone has a dependency
on the apache-activemq pom they will have the jar pulled into their build.
> camel-activemq transitively pulls in activemq-client-jakarta
>
>
> Key: AMQ-9388
> URL: https://issues.apache.org/jira/browse/AMQ-9388
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.0.0
>
>
> While reviewing the 6.0.0 release I noticed that the newly added
> {{camel-activemq }}module pulls in {{activemq-client-jakarta}} as a
> transitive dependency. This makes sense since the version used is based on
> ActiveMQ 5.18.2 as 6.0.0 isn't released yet.
> We need to exclude this because with version 6.0.0 this module no longer
> exists so is not needed and secondly the 5.18.2 version has a CVE against it.
> The dependency in the current release is not included in the tar distribution
> but since it is transitively being pulled in with maven if someone has a
> dependency on the apache-activemq pom they will have the jar pulled into
> their build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (AMQ-9388) camel-activemq transitively pulls in activemq-client-jakarta
Christopher L. Shannon created AMQ-9388: --- Summary: camel-activemq transitively pulls in activemq-client-jakarta Key: AMQ-9388 URL: https://issues.apache.org/jira/browse/AMQ-9388 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 6.0.0 While reviewing the 6.0.0 release I noticed that the newly added camel-activemq module pulls in activemq-client-jakarta as a transitive dependency. This makes sense since the version used is based on ActiveMQ 5.18.2 as 6.0.0 isn't released yet. We need to exclude this because with version 6.0.0 this module no longer exists so is not needed and secondly the 5.18.2 version has a CVE against it. The dependency in the current release is not included in the tar distribution but since it is transitively being pulled in with maven if someone has a dependency on the apache-activemq pom they will have the jar pulled into their build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9383) Websocket transport options do not get applied
[
https://issues.apache.org/jira/browse/AMQ-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784934#comment-17784934
]
Christopher L. Shannon commented on AMQ-9383:
-
[~jbonofre] - That makes sense, thanks for the clarification
> Websocket transport options do not get applied
> --
>
> Key: AMQ-9383
> URL: https://issues.apache.org/jira/browse/AMQ-9383
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
>Affects Versions: 5.15.16, 5.18.3, 5.17.6, 5.16.7
>Reporter: Kostiantyn Miklevskyi
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 6.0.0, 5.18.4, 5.17.7, 5.16.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Configure broker transport connector like this:
> {code:java}
> uri="ws://0.0.0.0:5680?amqp.traceFrames=truewireFormat=amqpwireFormat.transformer=jmswireFormat.allowNonSaslConnections=true"/>
> {code}
>
> Try to connect to this instance with rhea.js library.
> First attempt to connect would be successful.
> Second and all subsequent attempts would fail.
> The only way to "fix" this would be a broker restart.
>
> The issue is here:
> [https://github.com/apache/activemq/blob/4bbb055187166706103d785e9665efb439792c51/activemq-http/src/main/java/org/apache/activemq/transport/ws/jetty9/WSServlet.java#L162]
>
> transportOptions would be "consumed" by introspection on the first connection
> attempt, and on subsequent attempts "allowNonSaslConnections" and
> "transformer" would not be there, so won't be applied to wireformat and the
> result would be an error.
>
> Interestingly this was already spotted and fixed in the same class for MQTT
> subprotocol here:
> [https://github.com/apache/activemq/blob/4bbb055187166706103d785e9665efb439792c51/activemq-http/src/main/java/org/apache/activemq/transport/ws/jetty9/WSServlet.java#L115C86-L115C86]
> by simply creating a copy of transport options before sending it into
> introspecting setters.
>
> Please apply the same fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9383) Websocket transport options do not get applied
[
https://issues.apache.org/jira/browse/AMQ-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784608#comment-17784608
]
Christopher L. Shannon commented on AMQ-9383:
-
We should not be releasing another 5.16.x release. 5.16.x was announced as EOL
1.5 years ago in May 2022. We only recently did the 5.16.7 because of the
security issue but I'm not in favor if doing anymore 5.15.x or 5.16.x releases
etc.
> Websocket transport options do not get applied
> --
>
> Key: AMQ-9383
> URL: https://issues.apache.org/jira/browse/AMQ-9383
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
>Affects Versions: 5.15.16, 5.18.3, 5.17.6, 5.16.7
>Reporter: Kostiantyn Miklevskyi
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 6.0.0, 5.18.4, 5.17.7, 5.16.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Configure broker transport connector like this:
> {code:java}
> uri="ws://0.0.0.0:5680?amqp.traceFrames=truewireFormat=amqpwireFormat.transformer=jmswireFormat.allowNonSaslConnections=true"/>
> {code}
>
> Try to connect to this instance with rhea.js library.
> First attempt to connect would be successful.
> Second and all subsequent attempts would fail.
> The only way to "fix" this would be a broker restart.
>
> The issue is here:
> [https://github.com/apache/activemq/blob/4bbb055187166706103d785e9665efb439792c51/activemq-http/src/main/java/org/apache/activemq/transport/ws/jetty9/WSServlet.java#L162]
>
> transportOptions would be "consumed" by introspection on the first connection
> attempt, and on subsequent attempts "allowNonSaslConnections" and
> "transformer" would not be there, so won't be applied to wireformat and the
> result would be an error.
>
> Interestingly this was already spotted and fixed in the same class for MQTT
> subprotocol here:
> [https://github.com/apache/activemq/blob/4bbb055187166706103d785e9665efb439792c51/activemq-http/src/main/java/org/apache/activemq/transport/ws/jetty9/WSServlet.java#L115C86-L115C86]
> by simply creating a copy of transport options before sending it into
> introspecting setters.
>
> Please apply the same fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AMQ-9370) Openwire marshaller should validate Throwable class type
[ https://issues.apache.org/jira/browse/AMQ-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9370. - Resolution: Fixed Nevermind, false alarm, 5.18.x is working fine. I build 5.16.x, 5.17.x, 5.18.x and main branches and ran the newly added Openwire tests in them and they passed in all 4 branches. > Openwire marshaller should validate Throwable class type > > > Key: AMQ-9370 > URL: https://issues.apache.org/jira/browse/AMQ-9370 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.18.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.0.0, 5.18.3, 5.17.6, 5.16.7 > > Time Spent: 20m > Remaining Estimate: 0h > > When openwire commands are unmarshalled the marshallers should validate the > provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (AMQ-9370) Openwire marshaller should validate Throwable class type
[ https://issues.apache.org/jira/browse/AMQ-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reopened AMQ-9370: - Looks like there's an issue with the Jakarta client in 5.18.x to fix > Openwire marshaller should validate Throwable class type > > > Key: AMQ-9370 > URL: https://issues.apache.org/jira/browse/AMQ-9370 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.18.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.0.0, 5.18.3, 5.17.6, 5.16.7 > > Time Spent: 20m > Remaining Estimate: 0h > > When openwire commands are unmarshalled the marshallers should validate the > provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9370) Openwire marshaller should validate Throwable class type
[ https://issues.apache.org/jira/browse/AMQ-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9370. - Resolution: Fixed > Openwire marshaller should validate Throwable class type > > > Key: AMQ-9370 > URL: https://issues.apache.org/jira/browse/AMQ-9370 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.18.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.0.0, 5.18.3, 5.17.6, 5.16.7 > > Time Spent: 20m > Remaining Estimate: 0h > > When openwire commands are unmarshalled the marshallers should validate the > provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9370) Openwire marshaller should validate Throwable class type
[ https://issues.apache.org/jira/browse/AMQ-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9370: Fix Version/s: (was: 5.16.7) > Openwire marshaller should validate Throwable class type > > > Key: AMQ-9370 > URL: https://issues.apache.org/jira/browse/AMQ-9370 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.18.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.0.0, 5.18.3, 5.17.6 > > Time Spent: 20m > Remaining Estimate: 0h > > When openwire commands are unmarshalled the marshallers should validate the > provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9370) Openwire marshaller should validate Throwable class type
[ https://issues.apache.org/jira/browse/AMQ-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9370: Fix Version/s: 5.16.7 > Openwire marshaller should validate Throwable class type > > > Key: AMQ-9370 > URL: https://issues.apache.org/jira/browse/AMQ-9370 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.18.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.0.0, 5.18.3, 5.17.6, 5.16.7 > > Time Spent: 20m > Remaining Estimate: 0h > > When openwire commands are unmarshalled the marshallers should validate the > provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9370) Openwire marshaller should validate Throwable class type
[ https://issues.apache.org/jira/browse/AMQ-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9370: Fix Version/s: 5.16.6 > Openwire marshaller should validate Throwable class type > > > Key: AMQ-9370 > URL: https://issues.apache.org/jira/browse/AMQ-9370 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.18.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.16.6, 6.0.0, 5.18.3, 5.17.6 > > Time Spent: 10m > Remaining Estimate: 0h > > When openwire commands are unmarshalled the marshallers should validate the > provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9370) Openwire marshaller should validate Throwable class type
Christopher L. Shannon created AMQ-9370: --- Summary: Openwire marshaller should validate Throwable class type Key: AMQ-9370 URL: https://issues.apache.org/jira/browse/AMQ-9370 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.18.2 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 6.0.0, 5.18.3, 5.17.6 When openwire commands are unmarshalled the marshallers should validate the provided throwable class type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9344) Add limits to uncommitted transactions
[ https://issues.apache.org/jira/browse/AMQ-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776795#comment-17776795 ] Christopher L. Shannon commented on AMQ-9344: - This would be something nice to add for some 6.x version. Would probably need to add a couple flags to the broker settings and have the transaction broker plugin check things and handle the roll back and exception. Setting a default could break existing users (Even if high) so it might make sense to have the limits as off by default in 6.x and then the next major 7.0 version pick a sensible limit. > Add limits to uncommitted transactions > -- > > Key: AMQ-9344 > URL: https://issues.apache.org/jira/browse/AMQ-9344 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Matt Pavlovich >Priority: Major > Fix For: 6.0.1 > > > 1. Add a config flag to limit the max number of uncommitted message per > transaction > 2. Add a config flag to limit the max number of simultaneous transactions per > destination > On limit exceeding, rollback the tx and return a ResourceAllocationException > to the client > Possible default values: > 6.x - unlimited (current behavior) > 7.x - 10,000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
