[jira] [Commented] (AMQ-9569) WriteTimeoutFilter does not timeout SSL write (handshake)
[ https://issues.apache.org/jira/browse/AMQ-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882537#comment-17882537 ] Christopher L. Shannon commented on AMQ-9569: - A change like this should have some tests written before merging to verify > WriteTimeoutFilter does not timeout SSL write (handshake) > - > > Key: AMQ-9569 > URL: https://issues.apache.org/jira/browse/AMQ-9569 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.5 >Reporter: Martin Lichtin >Assignee: Jean-Baptiste Onofré >Priority: Major > Attachments: WriteTimeoutFilter.java > > > WriteTimeoutFilter does not timeout the SSL write (handshake), as can be seen > by this stack trace. > {noformat} > "ActiveMQ Task-5" #195869202 daemon prio=5 os_prio=0 tid=0x7f8b6809 > nid=0xe591 runnable [0x7f8a7f4eb000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:171) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at > sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464) > at > sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) > at sun.security.ssl.SSLTransport.decode(SSLTransport.java:109) > at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1401) > at > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1309) > at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:440) > at sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:822) > at sun.security.ssl.SSLSocketImpl.access$200(SSLSocketImpl.java:73) > at > sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1184) > at > org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115) > at java.io.DataOutputStream.flush(DataOutputStream.java:123) > at > org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:194) > at > org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:335) > at > org.apache.activemq.transport.AbstractInactivityMonitor.oneway(AbstractInactivityMonitor.java:317) > at > org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:181) > at > org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:84) > at > org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:74) > at > org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64) > at > org.apache.activemq.transport.WriteTimeoutFilter.start(WriteTimeoutFilter.java:132) > at > org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1026) > - locked <0x0006caf036c0> (a java.lang.Object) > at > org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:151) > - locked <0x0006cb402778> (a java.lang.Object) > at > org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133) > at > org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:750) {noformat} > WriteTimeoutFilter.start() method should also register and track the timeout, > like already done in the oneway() method. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-8398) 4-byte Unicode message from JMS to STOMP will be corrupted
[ https://issues.apache.org/jira/browse/AMQ-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-8398. - Resolution: Fixed > 4-byte Unicode message from JMS to STOMP will be corrupted > -- > > Key: AMQ-8398 > URL: https://issues.apache.org/jira/browse/AMQ-8398 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker, STOMP, Transport >Affects Versions: 5.16.3 >Reporter: Simon Lundstrom >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.6, 6.1.4 > > Time Spent: 4h > Remaining Estimate: 0h > > When sending a message from: > JMS producer to STOMP consumer > or > STOMP producer to JMS consumer > which contains a 4-byte unicode code points e.g. > https://unicode-table.com/en/1F5A4/ there is a corruption of the message. > In the JMS to STOMP case the code point gets converted to: > {{ef bf bd ef bf bd}} when it should be {{f0 9f 96 a4}}. > and in the STOMP to JMS case the JMS client throws an exception: > {code} > Exception in thread "main" javax.jms.JMSException: > java.io.UTFDataFormatException > at > org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:104) > at > org.apache.activemq.command.ActiveMQTextMessage.getText(ActiveMQTextMessage.java:84) > at testkonsument.App.JMS(App.java:86) > at testkonsument.App.main(App.java:42) > Caused by: java.io.UTFDataFormatException > at > org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:389) > at > org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:101) > ... 3 more > {code} > Using 4-byte unicode points > from STOMP to STOMP > or > from JMS to JMS > is not a problem, both works and does not corrupt the code point. > Note that 2- (e.g. https://unicode-table.com/en/00F6/) or 3-byte (e.g. > https://unicode-table.com/en/2614/) Unicode code points does NOT get > corrupted, even if the same message includes a 4-byte Unicode code point. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work started] (AMQ-8398) 4-byte Unicode message from JMS to STOMP will be corrupted
[ https://issues.apache.org/jira/browse/AMQ-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-8398 started by Christopher L. Shannon. --- > 4-byte Unicode message from JMS to STOMP will be corrupted > -- > > Key: AMQ-8398 > URL: https://issues.apache.org/jira/browse/AMQ-8398 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker, STOMP, Transport >Affects Versions: 5.16.3 >Reporter: Simon Lundstrom >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > When sending a message from: > JMS producer to STOMP consumer > or > STOMP producer to JMS consumer > which contains a 4-byte unicode code points e.g. > https://unicode-table.com/en/1F5A4/ there is a corruption of the message. > In the JMS to STOMP case the code point gets converted to: > {{ef bf bd ef bf bd}} when it should be {{f0 9f 96 a4}}. > and in the STOMP to JMS case the JMS client throws an exception: > {code} > Exception in thread "main" javax.jms.JMSException: > java.io.UTFDataFormatException > at > org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:104) > at > org.apache.activemq.command.ActiveMQTextMessage.getText(ActiveMQTextMessage.java:84) > at testkonsument.App.JMS(App.java:86) > at testkonsument.App.main(App.java:42) > Caused by: java.io.UTFDataFormatException > at > org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:389) > at > org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:101) > ... 3 more > {code} > Using 4-byte unicode points > from STOMP to STOMP > or > from JMS to JMS > is not a problem, both works and does not corrupt the code point. > Note that 2- (e.g. https://unicode-table.com/en/00F6/) or 3-byte (e.g. > https://unicode-table.com/en/2614/) Unicode code points does NOT get > corrupted, even if the same message includes a 4-byte Unicode code point. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (AMQ-8398) 4-byte Unicode message from JMS to STOMP will be corrupted
[ https://issues.apache.org/jira/browse/AMQ-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-8398: Fix Version/s: 6.2.0 5.18.6 6.1.4 > 4-byte Unicode message from JMS to STOMP will be corrupted > -- > > Key: AMQ-8398 > URL: https://issues.apache.org/jira/browse/AMQ-8398 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker, STOMP, Transport >Affects Versions: 5.16.3 >Reporter: Simon Lundstrom >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.6, 6.1.4 > > Time Spent: 3.5h > Remaining Estimate: 0h > > When sending a message from: > JMS producer to STOMP consumer > or > STOMP producer to JMS consumer > which contains a 4-byte unicode code points e.g. > https://unicode-table.com/en/1F5A4/ there is a corruption of the message. > In the JMS to STOMP case the code point gets converted to: > {{ef bf bd ef bf bd}} when it should be {{f0 9f 96 a4}}. > and in the STOMP to JMS case the JMS client throws an exception: > {code} > Exception in thread "main" javax.jms.JMSException: > java.io.UTFDataFormatException > at > org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:104) > at > org.apache.activemq.command.ActiveMQTextMessage.getText(ActiveMQTextMessage.java:84) > at testkonsument.App.JMS(App.java:86) > at testkonsument.App.main(App.java:42) > Caused by: java.io.UTFDataFormatException > at > org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:389) > at > org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:101) > ... 3 more > {code} > Using 4-byte unicode points > from STOMP to STOMP > or > from JMS to JMS > is not a problem, both works and does not corrupt the code point. > Note that 2- (e.g. https://unicode-table.com/en/00F6/) or 3-byte (e.g. > https://unicode-table.com/en/2614/) Unicode code points does NOT get > corrupted, even if the same message includes a 4-byte Unicode code point. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (AMQ-8398) 4-byte Unicode message from JMS to STOMP will be corrupted
[ https://issues.apache.org/jira/browse/AMQ-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned AMQ-8398: --- Assignee: Christopher L. Shannon (was: Jean-Baptiste Onofré) > 4-byte Unicode message from JMS to STOMP will be corrupted > -- > > Key: AMQ-8398 > URL: https://issues.apache.org/jira/browse/AMQ-8398 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker, STOMP, Transport >Affects Versions: 5.16.3 >Reporter: Simon Lundstrom >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > When sending a message from: > JMS producer to STOMP consumer > or > STOMP producer to JMS consumer > which contains a 4-byte unicode code points e.g. > https://unicode-table.com/en/1F5A4/ there is a corruption of the message. > In the JMS to STOMP case the code point gets converted to: > {{ef bf bd ef bf bd}} when it should be {{f0 9f 96 a4}}. > and in the STOMP to JMS case the JMS client throws an exception: > {code} > Exception in thread "main" javax.jms.JMSException: > java.io.UTFDataFormatException > at > org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:104) > at > org.apache.activemq.command.ActiveMQTextMessage.getText(ActiveMQTextMessage.java:84) > at testkonsument.App.JMS(App.java:86) > at testkonsument.App.main(App.java:42) > Caused by: java.io.UTFDataFormatException > at > org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:389) > at > org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:101) > ... 3 more > {code} > Using 4-byte unicode points > from STOMP to STOMP > or > from JMS to JMS > is not a problem, both works and does not corrupt the code point. > Note that 2- (e.g. https://unicode-table.com/en/00F6/) or 3-byte (e.g. > https://unicode-table.com/en/2614/) Unicode code points does NOT get > corrupted, even if the same message includes a 4-byte Unicode code point. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-8398) 4-byte Unicode message from JMS to STOMP will be corrupted
[ https://issues.apache.org/jira/browse/AMQ-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877470#comment-17877470 ] Christopher L. Shannon commented on AMQ-8398: - I opened up a PR which should fix this issue: https://github.com/apache/activemq/pull/1290 > 4-byte Unicode message from JMS to STOMP will be corrupted > -- > > Key: AMQ-8398 > URL: https://issues.apache.org/jira/browse/AMQ-8398 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker, STOMP, Transport >Affects Versions: 5.16.3 >Reporter: Simon Lundstrom >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > When sending a message from: > JMS producer to STOMP consumer > or > STOMP producer to JMS consumer > which contains a 4-byte unicode code points e.g. > https://unicode-table.com/en/1F5A4/ there is a corruption of the message. > In the JMS to STOMP case the code point gets converted to: > {{ef bf bd ef bf bd}} when it should be {{f0 9f 96 a4}}. > and in the STOMP to JMS case the JMS client throws an exception: > {code} > Exception in thread "main" javax.jms.JMSException: > java.io.UTFDataFormatException > at > org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:104) > at > org.apache.activemq.command.ActiveMQTextMessage.getText(ActiveMQTextMessage.java:84) > at testkonsument.App.JMS(App.java:86) > at testkonsument.App.main(App.java:42) > Caused by: java.io.UTFDataFormatException > at > org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:389) > at > org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) > at > org.apache.activemq.command.ActiveMQTextMessage.decodeContent(ActiveMQTextMessage.java:101) > ... 3 more > {code} > Using 4-byte unicode points > from STOMP to STOMP > or > from JMS to JMS > is not a problem, both works and does not corrupt the code point. > Note that 2- (e.g. https://unicode-table.com/en/00F6/) or 3-byte (e.g. > https://unicode-table.com/en/2614/) Unicode code points does NOT get > corrupted, even if the same message includes a 4-byte Unicode code point. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (AMQ-9546) Potential direct buffer memory leak triggered by security scan
[ https://issues.apache.org/jira/browse/AMQ-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-9546. --- Resolution: Not A Problem 256 megs is still a huge amount of memory considering that setting is the max size allowed for all open wire packets. Normally that setting would be used to set a maximum message size and as you can imagine it would not take many messages of that size to run out of memory. In your case it looks like the security scanner is just sending misformed data that Openwire trying to parse and its getting size values that are very large and creating large buffers for those packets so it wouldn't take much to blow memory if you are allowing the creation of 256 meg buffers. > Potential direct buffer memory leak triggered by security scan > -- > > Key: AMQ-9546 > URL: https://issues.apache.org/jira/browse/AMQ-9546 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3 > Environment: Linux version 4.12.14-122.216-default > (gcc version 4.8.5 (SUSE Linux) ) > Tomcat: 9.0.86 > ActiveMQ: 5.18.3 >Reporter: Eddie Wu >Priority: Major > > We encountered following WARN log from Active MQ 5.18.3. which is embed in > Tomcat 9.0.86. > {noformat} > WARN [Transport] Transport Connection to tcp://: failed: Cannot > reserve 1195725860 bytes of direct buffer memory (allocated: 909477781, > limit: 1073741824){noformat} > {{tcp://:}} is our security scan software. > We realize that the security scan software will trigger direct buffer memory > leak from ActiveMQ. > # We have internal metrics for direct buffer memory usage. It is clear that > direct buffer usage will spike when scanning happened. > # We have log as above to know that the scan did cause ActiveMQ to allocate > huge direct buffer memory. > Even though the leak is NOT triggered by usual business code, I think it is > still worth to fix. > Anyway it is a potential memory leak bug inside ActiveMQ. > I have not get call stack yet. but since the code using direct buffer is NOT > that much, maybe you can review the code to figure out the root cause of > memory leak. > Let me know if you need more details. > --just for your information, per our initial check, the log above was from > code below. > [https://github.com/apache/activemq/blob/74086d70bcf2db9ef98e3699c1bf1eb5910c2baa/activemq-broker/src/main/java/org/apache/activemq/broker/TransportConnection.java#L1188] > > {code:java} > @Override > public String toString() { > return "Transport Connection to: " + transport.getRemoteAddress(); > } > public void serviceTransportException(IOException e) { > if (!stopping.get() && status.get() != PENDING_STOP) { > transportException.set(e); > if (TRANSPORTLOG.isDebugEnabled()) { > TRANSPORTLOG.debug("{} failed: {}", this, e.getMessage(), e); > } else if (TRANSPORTLOG.isWarnEnabled() && !suppressed(e)) { > if (connector.isDisplayStackTrace()) { > TRANSPORTLOG.warn("{} failed", this, e); > } else { > TRANSPORTLOG.warn("{} failed: {}", this, e.getMessage()); > } > } > stopAsync(e); > } > }{code} -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9547) KahaDB PageFile can call setLength() on the recovery file which always throws an exception
[ https://issues.apache.org/jira/browse/AMQ-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9547. - Resolution: Fixed > KahaDB PageFile can call setLength() on the recovery file which always throws > an exception > -- > > Key: AMQ-9547 > URL: https://issues.apache.org/jira/browse/AMQ-9547 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.5, 6.1.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.6, 6.1.4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are 3 places in PageFile (part of KahaDB) that call setLength() in > RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it > always throws an exception when called. This method should just be removed > entirely since it always throws an error and in the places where it is used > we need to either stop calling it if we can or throw an exception if the > length is unexpected. > Currently when KahaDB tries to redo recovery updates, if the file length is > encountered as 0 it will call this method which leads to throwing an > exception. This causes the store to detect the error and rebuild the index. > We should be able to just continue without calling this method and recover. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (AMQ-9547) KahaDB PageFile can call setLength() on the recovery file which always throws an exception
[ https://issues.apache.org/jira/browse/AMQ-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9547: Summary: KahaDB PageFile can call setLength() on the recovery file which always throws an exception (was: PageFile can call setLength() on the recovery file which always throws an exception) > KahaDB PageFile can call setLength() on the recovery file which always throws > an exception > -- > > Key: AMQ-9547 > URL: https://issues.apache.org/jira/browse/AMQ-9547 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.5, 6.1.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.6, 6.1.4 > > Time Spent: 10m > Remaining Estimate: 0h > > There are 3 places in PageFile that call setLength() in > RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it > always throws an exception when called. This method should just be removed > entirely since it always throws an error and in the places where it is used > we need to either stop calling it if we can or throw an exception if the > length is unexpected. > Currently when KahaDB tries to redo recovery updates, if the file length is > encountered as 0 it will call this method which leads to throwing an > exception. This causes the store to detect the error and rebuild the index. > We should be able to just continue without calling this method and recover. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (AMQ-9547) KahaDB PageFile can call setLength() on the recovery file which always throws an exception
[ https://issues.apache.org/jira/browse/AMQ-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9547: Description: There are 3 places in PageFile (part of KahaDB) that call setLength() in RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it always throws an exception when called. This method should just be removed entirely since it always throws an error and in the places where it is used we need to either stop calling it if we can or throw an exception if the length is unexpected. Currently when KahaDB tries to redo recovery updates, if the file length is encountered as 0 it will call this method which leads to throwing an exception. This causes the store to detect the error and rebuild the index. We should be able to just continue without calling this method and recover. was: There are 3 places in PageFile that call setLength() in RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it always throws an exception when called. This method should just be removed entirely since it always throws an error and in the places where it is used we need to either stop calling it if we can or throw an exception if the length is unexpected. Currently when KahaDB tries to redo recovery updates, if the file length is encountered as 0 it will call this method which leads to throwing an exception. This causes the store to detect the error and rebuild the index. We should be able to just continue without calling this method and recover. > KahaDB PageFile can call setLength() on the recovery file which always throws > an exception > -- > > Key: AMQ-9547 > URL: https://issues.apache.org/jira/browse/AMQ-9547 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.5, 6.1.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.6, 6.1.4 > > Time Spent: 10m > Remaining Estimate: 0h > > There are 3 places in PageFile (part of KahaDB) that call setLength() in > RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it > always throws an exception when called. This method should just be removed > entirely since it always throws an error and in the places where it is used > we need to either stop calling it if we can or throw an exception if the > length is unexpected. > Currently when KahaDB tries to redo recovery updates, if the file length is > encountered as 0 it will call this method which leads to throwing an > exception. This causes the store to detect the error and rebuild the index. > We should be able to just continue without calling this method and recover. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (AMQ-9547) PageFile can call setLength() on the recovery file which always throws an exception
[ https://issues.apache.org/jira/browse/AMQ-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9547: Fix Version/s: 6.2.0 > PageFile can call setLength() on the recovery file which always throws an > exception > --- > > Key: AMQ-9547 > URL: https://issues.apache.org/jira/browse/AMQ-9547 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.5, 6.1.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.6, 6.1.4 > > > There are 3 places in PageFile that call setLength() in > RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it > always throws an exception when called. This method should just be removed > entirely since it always throws an error and in the places where it is used > we need to either stop calling it if we can or throw an exception if the > length is unexpected. > Currently when KahaDB tries to redo recovery updates, if the file length is > encountered as 0 it will call this method which leads to throwing an > exception. This causes the store to detect the error and rebuild the index. > We should be able to just continue without calling this method and recover. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (AMQ-9547) PageFile can call setLength() on the recovery file which always throws an exception
Christopher L. Shannon created AMQ-9547: --- Summary: PageFile can call setLength() on the recovery file which always throws an exception Key: AMQ-9547 URL: https://issues.apache.org/jira/browse/AMQ-9547 Project: ActiveMQ Classic Issue Type: Bug Components: KahaDB Affects Versions: 6.1.3, 5.18.5 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 5.18.6, 6.1.4 There are 3 places in PageFile that call setLength() in RecoverableRandomAccessFile. This method was changed in AMQ-5578 so that it always throws an exception when called. This method should just be removed entirely since it always throws an error and in the places where it is used we need to either stop calling it if we can or throw an exception if the length is unexpected. Currently when KahaDB tries to redo recovery updates, if the file length is encountered as 0 it will call this method which leads to throwing an exception. This causes the store to detect the error and rebuild the index. We should be able to just continue without calling this method and recover. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (AMQ-9546) Potential direct buffer memory leak triggered by security scan
[ https://issues.apache.org/jira/browse/AMQ-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871977#comment-17871977 ] Christopher L. Shannon edited comment on AMQ-9546 at 8/8/24 12:18 PM: -- Most likely the issue is you need to just set {{maxFrameSize to prevent OOM issues}} as the scanning is not sending proper OpenWire packets. See [https://activemq.apache.org/components/classic/documentation/configuring-wire-formats] was (Author: christopher.l.shannon): Most likely the issue is you need to just set {{maxFrameSize }}to prevent OOM {{issues}} as the scanning is not sending proper OpenWire packets. See [https://activemq.apache.org/components/classic/documentation/configuring-wire-formats] > Potential direct buffer memory leak triggered by security scan > -- > > Key: AMQ-9546 > URL: https://issues.apache.org/jira/browse/AMQ-9546 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3 > Environment: Linux version 4.12.14-122.216-default > (gcc version 4.8.5 (SUSE Linux) ) > Tomcat: 9.0.86 > ActiveMQ: 5.18.3 >Reporter: Eddie Wu >Priority: Major > > we encountered following WARN log from Active MQ 5.18.3. which is embed in > Tomcat 9.0.86. > WARN [Transport] Transport Connection to tcp://: failed: > Cannot reserve 1195725860 bytes of direct buffer memory > (allocated: 909477781, limit: 1073741824) > tcp://: is our security scan software. > We realize that the security scan software will trigger direct buffer memory > leak from Active MQ. > 1. we have internal metrics for direct buffer memory usage, it is clear that > direct buffer usage will spike when scanning happened. > 2. we have log as above to know that the scan did cause Active MQ to allocate > huge direct buffer memory. > even though the leak is NOT triggered by usual business code, I think it is > still worth to fix. > anyway it is a potential memory leak bug inside Active MQ. > I have not get call stack yet. but since the code using direct buffer is NOT > that much, maybe you can review the code to figure out the root cause of > memory leak. > let me know if you need more details. > --just for your information, per our initial check, the log above was from > code below. > [https://github.com/apache/activemq/blob/74086d70bcf2db9ef98e3699c1bf1eb5910c2baa/activemq-broker/src/main/java/org/apache/activemq/broker/TransportConnection.java#L1188] > > > @Override > public String toString() { > return "Transport Connection to: " + transport.getRemoteAddress(); > } > public void serviceTransportException(IOException e) { > if (!stopping.get() && status.get() != PENDING_STOP) { > transportException.set(e); > if (TRANSPORTLOG.isDebugEnabled()) { > TRANSPORTLOG.debug("{} failed: {}", this, e.getMessage(), e); > } else if (TRANSPORTLOG.isWarnEnabled() && !suppressed(e)) { > if (connector.isDisplayStackTrace()) { > TRANSPORTLOG.warn("{} failed", this, e); > } else { > TRANSPORTLOG.warn("{} failed: {}", this, e.getMessage()); > } > } > stopAsync(e); > } > } -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9546) Potential direct buffer memory leak triggered by security scan
[ https://issues.apache.org/jira/browse/AMQ-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871977#comment-17871977 ] Christopher L. Shannon commented on AMQ-9546: - Most likely the issue is you need to just set {{maxFrameSize }}to prevent OOM {{issues}} as the scanning is not sending proper OpenWire packets. See [https://activemq.apache.org/components/classic/documentation/configuring-wire-formats] > Potential direct buffer memory leak triggered by security scan > -- > > Key: AMQ-9546 > URL: https://issues.apache.org/jira/browse/AMQ-9546 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3 > Environment: Linux version 4.12.14-122.216-default > (gcc version 4.8.5 (SUSE Linux) ) > Tomcat: 9.0.86 > ActiveMQ: 5.18.3 >Reporter: Eddie Wu >Priority: Major > > we encountered following WARN log from Active MQ 5.18.3. which is embed in > Tomcat 9.0.86. > WARN [Transport] Transport Connection to tcp://: failed: > Cannot reserve 1195725860 bytes of direct buffer memory > (allocated: 909477781, limit: 1073741824) > tcp://: is our security scan software. > We realize that the security scan software will trigger direct buffer memory > leak from Active MQ. > 1. we have internal metrics for direct buffer memory usage, it is clear that > direct buffer usage will spike when scanning happened. > 2. we have log as above to know that the scan did cause Active MQ to allocate > huge direct buffer memory. > even though the leak is NOT triggered by usual business code, I think it is > still worth to fix. > anyway it is a potential memory leak bug inside Active MQ. > I have not get call stack yet. but since the code using direct buffer is NOT > that much, maybe you can review the code to figure out the root cause of > memory leak. > let me know if you need more details. > --just for your information, per our initial check, the log above was from > code below. > [https://github.com/apache/activemq/blob/74086d70bcf2db9ef98e3699c1bf1eb5910c2baa/activemq-broker/src/main/java/org/apache/activemq/broker/TransportConnection.java#L1188] > > > @Override > public String toString() { > return "Transport Connection to: " + transport.getRemoteAddress(); > } > public void serviceTransportException(IOException e) { > if (!stopping.get() && status.get() != PENDING_STOP) { > transportException.set(e); > if (TRANSPORTLOG.isDebugEnabled()) { > TRANSPORTLOG.debug("{} failed: {}", this, e.getMessage(), e); > } else if (TRANSPORTLOG.isWarnEnabled() && !suppressed(e)) { > if (connector.isDisplayStackTrace()) { > TRANSPORTLOG.warn("{} failed", this, e); > } else { > TRANSPORTLOG.warn("{} failed: {}", this, e.getMessage()); > } > } > stopAsync(e); > } > } -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (AMQ-9546) Potential direct buffer memory leak triggered by security scan
[ https://issues.apache.org/jira/browse/AMQ-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871977#comment-17871977 ] Christopher L. Shannon edited comment on AMQ-9546 at 8/8/24 12:18 PM: -- Most likely the issue is you need to just set {{maxFrameSize}} to prevent OOM issues as the scanning is not sending proper OpenWire packets. See [https://activemq.apache.org/components/classic/documentation/configuring-wire-formats] was (Author: christopher.l.shannon): Most likely the issue is you need to just set {{maxFrameSize to prevent OOM issues}} as the scanning is not sending proper OpenWire packets. See [https://activemq.apache.org/components/classic/documentation/configuring-wire-formats] > Potential direct buffer memory leak triggered by security scan > -- > > Key: AMQ-9546 > URL: https://issues.apache.org/jira/browse/AMQ-9546 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.3 > Environment: Linux version 4.12.14-122.216-default > (gcc version 4.8.5 (SUSE Linux) ) > Tomcat: 9.0.86 > ActiveMQ: 5.18.3 >Reporter: Eddie Wu >Priority: Major > > we encountered following WARN log from Active MQ 5.18.3. which is embed in > Tomcat 9.0.86. > WARN [Transport] Transport Connection to tcp://: failed: > Cannot reserve 1195725860 bytes of direct buffer memory > (allocated: 909477781, limit: 1073741824) > tcp://: is our security scan software. > We realize that the security scan software will trigger direct buffer memory > leak from Active MQ. > 1. we have internal metrics for direct buffer memory usage, it is clear that > direct buffer usage will spike when scanning happened. > 2. we have log as above to know that the scan did cause Active MQ to allocate > huge direct buffer memory. > even though the leak is NOT triggered by usual business code, I think it is > still worth to fix. > anyway it is a potential memory leak bug inside Active MQ. > I have not get call stack yet. but since the code using direct buffer is NOT > that much, maybe you can review the code to figure out the root cause of > memory leak. > let me know if you need more details. > --just for your information, per our initial check, the log above was from > code below. > [https://github.com/apache/activemq/blob/74086d70bcf2db9ef98e3699c1bf1eb5910c2baa/activemq-broker/src/main/java/org/apache/activemq/broker/TransportConnection.java#L1188] > > > @Override > public String toString() { > return "Transport Connection to: " + transport.getRemoteAddress(); > } > public void serviceTransportException(IOException e) { > if (!stopping.get() && status.get() != PENDING_STOP) { > transportException.set(e); > if (TRANSPORTLOG.isDebugEnabled()) { > TRANSPORTLOG.debug("{} failed: {}", this, e.getMessage(), e); > } else if (TRANSPORTLOG.isWarnEnabled() && !suppressed(e)) { > if (connector.isDisplayStackTrace()) { > TRANSPORTLOG.warn("{} failed", this, e); > } else { > TRANSPORTLOG.warn("{} failed: {}", this, e.getMessage()); > } > } > stopAsync(e); > } > } -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (KAFKA-16437) Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032)
[ https://issues.apache.org/jira/browse/KAFKA-16437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated KAFKA-16437: --- Fix Version/s: 4.0.0 > Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032) > > > Key: KAFKA-16437 > URL: https://issues.apache.org/jira/browse/KAFKA-16437 > Project: Kafka > Issue Type: Improvement >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 4.0.0 > > > Jira to track > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+10+in+Kafka+4.0 > > There is an old PR that could be the basis of the work: > [https://github.com/apache/kafka/pull/10176] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-16437) Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032)
[ https://issues.apache.org/jira/browse/KAFKA-16437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned KAFKA-16437: -- Assignee: Christopher L. Shannon > Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032) > > > Key: KAFKA-16437 > URL: https://issues.apache.org/jira/browse/KAFKA-16437 > Project: Kafka > Issue Type: Improvement >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > Jira to track > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+10+in+Kafka+4.0 > > There is an old PR that could be the basis of the work: > [https://github.com/apache/kafka/pull/10176] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-16437) Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032)
[ https://issues.apache.org/jira/browse/KAFKA-16437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated KAFKA-16437: --- Description: Jira to track https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+10+in+Kafka+4.0 There is an old PR that could be the basis of the work: [https://github.com/apache/kafka/pull/10176] was: Jira to track [https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+9+in+Kafka+4.0] There is an old PR that could be the basis of the work: https://github.com/apache/kafka/pull/10176 Summary: Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032) (was: Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032)) > Upgrade to Jakarta and JavaEE 10 in Kafka 4.0 (KIP-1032) > > > Key: KAFKA-16437 > URL: https://issues.apache.org/jira/browse/KAFKA-16437 > Project: Kafka > Issue Type: Improvement >Reporter: Christopher L. Shannon >Priority: Major > > Jira to track > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+10+in+Kafka+4.0 > > There is an old PR that could be the basis of the work: > [https://github.com/apache/kafka/pull/10176] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849115#comment-17849115 ] Christopher L. Shannon commented on AMQ-9504: - Yeah, it would be a problem because it's trying to create duplicate adapters touching the same directory, so it's definitely not going to work right. Turning off JMX as you have shown just pushes the problem downstream if you configure things that way and will cause things to break. The vast majority of people do not use multiKahaDB and if they do obviously don't configure it this way (most people that use the option to create a store per destination set up their config with that as the only filter) otherwise it would have been reported way before now. Is there a reason why you can't build a custom version with the patch temporarily? One of the benefits of using open source like this is you can do whatever you want, you can build your own version at any point. I know you want to use an official release but building your own version with the fix is the fastest way for now. Our plan is to do a 6.2.0 release in the next couple of weeks, after that we could look at doing a 5.18.5 release which would include this fix, but again, I'm not really sure on an exact timeline so if it's that high of a priority you will need to build your own version temporarily until the new version is out. > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.3 > > Attachments: bugfix.patch, test.patch > > > When using Multi KahaDB persistence adapter according to [the > documentation|https://activemq.apache.org/components/classic/documentation/kahadb] > it shows that you can use multiple {{filteredPersistenceAdapters}} but this > does not work if you have two filtered adapter where one is using wildcard > match for topics (or even a specific topic) and second filtered adapter using > per destination filtered adapter. > The idea being you want to use one KahaDB instance for all the topics and per > destination KahaDB instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note JMX > needs to be enabled) : > {code:xml} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > {noformat} > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepositor
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848699#comment-17848699 ] Christopher L. Shannon commented on AMQ-9504: - Any dates are just an estimate and there is no guarantee. This is definitely not a high priority thing that is going to cause us to rush a release so I can't tell you when it will be released as the focus is on the newer 6.x releases now. Asking other people isn't going to change the answer. > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.3 > > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.u
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848684#comment-17848684 ] Christopher L. Shannon commented on AMQ-9504: - 6.2.0 should be getting prepared for release before too long but I'm not sure about 5.18.5, there's not much else pressing at the moment for a release. > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.3 > > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.doStart(MultiK
[jira] [Resolved] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-9504. - Resolution: Fixed [~ritesh.adval] - Thanks for the detailed information, I took a look closely at this and it is indeed just an issue on restart. Things work correctly initially (only 2 stores were created in your unit test) but then on restart the code for {{perDestination=true}} isn't smart enough to check if there are existing adapters that exist that already map to the existing directories. Your fix looks good so I made some small modifications to it and the test and applied a variation of it. > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.3 > > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.j
[jira] [Work started] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-9504 started by Christopher L. Shannon. --- > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.3 > > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.doStart(MultiKahaDBPersistenceAdapter.java:381) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.broker.BrokerService.doStartPersist
[jira] [Assigned] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned AMQ-9504: --- Assignee: Christopher L. Shannon > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.doStart(MultiKahaDBPersistenceAdapter.java:381) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerServi
[jira] [Updated] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9504: Fix Version/s: 6.2.0 5.18.5 6.1.3 > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.2.0, 5.18.5, 6.1.3 > > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.doStart(MultiKahaDBPersistenceAdapter.java:381) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at >
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848405#comment-17848405 ] Christopher L. Shannon commented on AMQ-9504: - This probably needs to be looked at more and i'm not sure if "perDestination" was meant to work for this use case > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Priority: Major > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.doStart(MultiKahaDBPersistenceAdapter.java:381) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > a
[jira] [Updated] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[ https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9504: Fix Version/s: (was: 5.18.4) > activemq multikahadb persistence adapter with topic wildcard filtered adapter > and per destination filtered adapter causes broker failure on restart > --- > > Key: AMQ-9504 > URL: https://issues.apache.org/jira/browse/AMQ-9504 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.4, 6.1.2 >Reporter: ritesh adval >Priority: Major > Attachments: bugfix.patch, test.patch > > > when using Multikahadb persistence adapter per documentation : > [https://activemq.apache.org/components/classic/documentation/kahadb] it > shows that you can use multiple filteredPersistenceAdapters but this does not > work if you have two filtered adapter where one is using wildcard match for > topics (or even a specific topic) and second filtered adapter using per > destination filtered adapter. > The idea being you want to use one kahadb instance for all the topics and per > destination kahadb instance for all other destinations like queues. Something > like this for illustration of the issue see test for more details. (note jmx > needs to be enabled) : > {code:java} > > > > > > > > > > > > > > > > > > > > > > > {code} > With this setting it works for the first time when broker is started. But as > soon as you have atleast one topic created which uses wild card filtered > adapter and you restart the broker, then what happens is there are two > KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered > adapter and another one by the second per destination filtered adapter, and > so second KahaDBPersistenceAdapter fails with below exception: > > [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20 > s <<< FAILURE! – in > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest > [ERROR] > org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter > – Time elapsed: 11.08 s <<< ERROR! > javax.management.InstanceAlreadyExistsException: > org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e] > at > java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890) > at > java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320) > at > java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415) > at > org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93) > at > org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.doStart(MultiKahaDBPersistenceAdapter.java:381) > at > org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55) > at > org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681) > at > org.apache.activemq.brok
[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&focusedCommentId=17847737#comment-17847737 ] Christopher L. Shannon commented on AMQ-9482: - It seems like maybe one of the connections is stuck and not reading (although there should be a timeout). I also wonder if the burst of connections just happens so quickly it exhausts the memory, if the broker runs out of memory then it will just get into a weird state so you may need to bump memory to handle the spike. You could try tweaking some settings with the transport: [https://activemq.apache.org/components/classic/documentation/tcp-transport-reference] I would try setting the {{soTimeout}} and {{soWriteTimeout}} which would hopefully prevent issues with connections blocking forever on a read/write to a socket. You could also try tuning things for the SelectorManager: https://activemq.apache.org/components/classic/documentation/nio-transport-reference > 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: activemq.tdump, 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/b
[jira] [Closed] (AMQ-9502) Unable to upgrade activemq from 5.11.2 to 5.12.0
[ https://issues.apache.org/jira/browse/AMQ-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-9502. --- Resolution: Invalid Questions for help should be directed to the user mailing list or chat [https://activemq.apache.org/contact] Also, these versions are very out of date and no longer supported > Unable to upgrade activemq from 5.11.2 to 5.12.0 > > > Key: AMQ-9502 > URL: https://issues.apache.org/jira/browse/AMQ-9502 > Project: ActiveMQ Classic > Issue Type: Bug >Reporter: sowjanya >Priority: Critical > > We are trying to upgrade from activemq 5.11.2 to 5.12.0, New version of > activemq is being reflected but unfortunately not able to access any module > in our application, Below are the logs we are getting. > {code:java} > 2024-05-09 09:12:15,549 WARN [com.adtran.mvc.view.ViewJSONServiceImpl] JSON > View failed due to com.adtran.common.services.Ser > viceSpecificException: 'java.lang.NoSuchMethodError: > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String > ;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V' {code} > Can you please help in sorting out this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-8082) Upgrade to JUnit 5.x
[ https://issues.apache.org/jira/browse/AMQ-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842707#comment-17842707 ] Christopher L. Shannon commented on AMQ-8082: - Removing version as this will require a lot of work and it isn't clear when it will be completed or which version. We probably need to split this task up and try and migrate pieces at a time > Upgrade to JUnit 5.x > > > Key: AMQ-8082 > URL: https://issues.apache.org/jira/browse/AMQ-8082 > Project: ActiveMQ Classic > Issue Type: Improvement > Components: Performance Test, Test Cases >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-8082) Upgrade to JUnit 5.x
[ https://issues.apache.org/jira/browse/AMQ-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-8082: Fix Version/s: (was: 6.2.0) > Upgrade to JUnit 5.x > > > Key: AMQ-8082 > URL: https://issues.apache.org/jira/browse/AMQ-8082 > Project: ActiveMQ Classic > Issue Type: Improvement > Components: Performance Test, Test Cases >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9253) MQTT5 server support
[ https://issues.apache.org/jira/browse/AMQ-9253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842702#comment-17842702 ] Christopher L. Shannon commented on AMQ-9253: - I removed the version as this hasn't been started and may never even be implemented as no one is looking at this. If work is done on this a target can be added. Pull requests and contributions are always welcome if someone wants to add support MQTT 5 > MQTT5 server support > > > Key: AMQ-9253 > URL: https://issues.apache.org/jira/browse/AMQ-9253 > Project: ActiveMQ Classic > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Jean-Baptiste Onofré >Priority: Major > > Add MQTT5 support -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9253) MQTT5 server support
[ https://issues.apache.org/jira/browse/AMQ-9253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9253: Fix Version/s: (was: 6.2.0) > MQTT5 server support > > > Key: AMQ-9253 > URL: https://issues.apache.org/jira/browse/AMQ-9253 > Project: ActiveMQ Classic > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Jean-Baptiste Onofré >Priority: Major > > Add MQTT5 support -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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&focusedCommentId=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&clientId=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 i
[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&clientId=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 n
[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&focusedCommentId=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&clientId=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.servl
[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&focusedCommentId=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&clientId=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.
[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&clientId=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 no
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 > ja
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 org.apache
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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] OneContigSpaceCardGeneratio
[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] GenCollectorPolicy::satisfy_fa
[jira] [Updated] (KAFKA-16437) Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032)
[ https://issues.apache.org/jira/browse/KAFKA-16437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated KAFKA-16437: --- Description: Jira to track [https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+9+in+Kafka+4.0] There is an old PR that could be the basis of the work: https://github.com/apache/kafka/pull/10176 was: Jira to track [https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+9+in+Kafka+4.0] > Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032) > --- > > Key: KAFKA-16437 > URL: https://issues.apache.org/jira/browse/KAFKA-16437 > Project: Kafka > Issue Type: Improvement >Reporter: Christopher L. Shannon >Priority: Major > > Jira to track > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+9+in+Kafka+4.0] > > There is an old PR that could be the basis of the work: > https://github.com/apache/kafka/pull/10176 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-16437) Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032)
[ https://issues.apache.org/jira/browse/KAFKA-16437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated KAFKA-16437: --- Description: Jira to track [https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+9+in+Kafka+4.0] > Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032) > --- > > Key: KAFKA-16437 > URL: https://issues.apache.org/jira/browse/KAFKA-16437 > Project: Kafka > Issue Type: Improvement >Reporter: Christopher L. Shannon >Priority: Major > > Jira to track > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-1032%3A+Upgrade+to+Jakarta+and+JavaEE+9+in+Kafka+4.0] > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-16437) Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032)
Christopher L. Shannon created KAFKA-16437: -- Summary: Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032) Key: KAFKA-16437 URL: https://issues.apache.org/jira/browse/KAFKA-16437 Project: Kafka Issue Type: Improvement Reporter: Christopher L. Shannon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-16437) Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032)
Christopher L. Shannon created KAFKA-16437: -- Summary: Upgrade to Jakarta and JavaEE 9 in Kafka 4.0 (KIP-1032) Key: KAFKA-16437 URL: https://issues.apache.org/jira/browse/KAFKA-16437 Project: Kafka Issue Type: Improvement Reporter: Christopher L. Shannon -- 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: 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)