[jira] (AMQ-9505) ActiveMQ classic with postgres data source gives errors on start
[ https://issues.apache.org/jira/browse/AMQ-9505 ]
Justin Bertram deleted comment on AMQ-9505:
-
was (Author: JIRAUSER305550):
Tried both of the below configs but same error
5432
activemq
x.database.azure.com
x
x
true
> ActiveMQ classic with postgres data source gives errors on start
>
>
> Key: AMQ-9505
> URL: https://issues.apache.org/jira/browse/AMQ-9505
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 6.1.1
> Environment: Fresh 6.1.1 installation on Ubuntu + java 17
>
>
>Reporter: Susinda Perera
>Priority: Major
>
> I get this error when I start ActiveMQ
> {noformat}
> 2024-05-21 23:59:32,959 | INFO | Using Persistence Adapter:
> JDBCPersistenceAdapter(HikariDataSource (null)) |
> org.apache.activemq.broker.BrokerService | main
> 2024-05-21 23:59:32,968 | INFO | Starting Persistence Adapter:
> JDBCPersistenceAdapter(HikariDataSource (null)) |
> org.apache.activemq.broker.BrokerService | main
> 2024-05-21 23:59:32,969 | INFO | HikariPool-1 - Starting... |
> com.zaxxer.hikari.HikariDataSource | main
> 2024-05-21 23:59:35,211 | INFO | HikariPool-1 - Added connection
> org.postgresql.jdbc.PgConnection@70101687 | com.zaxxer.hikari.pool.HikariPool
> | main
> 2024-05-21 23:59:35,214 | INFO | HikariPool-1 - Start completed. |
> com.zaxxer.hikari.HikariDataSource | main
> 2024-05-21 23:59:35,433 | INFO | Database adapter driver override recognized
> for : [postgresql_jdbc_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> 2024-05-21 23:59:38,423 | WARN | Could not create JDBC tables; they could
> already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP CONSTRAINT
> "activemq_acks_pkey" Message: ERROR: constraint "activemq_acks_pkey" of
> relation "activemq_acks" does not exist SQLState: 42704 Vendor code: 0 |
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter | main
> 2024-05-21 23:59:38,423 | WARN | Failure details: ERROR: constraint
> "activemq_acks_pkey" of relation "activemq_acks" does not exist |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> org.postgresql.util.PSQLException: ERROR: constraint "activemq_acks_pkey" of
> relation "activemq_acks" does not exist
>at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2725)
>at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2412)
>at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:371)
>at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:502)
>at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:419)
>at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:341)
>at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:326)
>at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
>at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:297)
>at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94)
>at
> com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
>at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.executeStatement(DefaultJDBCAdapter.java:112)
>at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:90)
>at
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:318)
>at
> org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:99)
>at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54)
>at
> org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681)
>at
> org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:663)
>at org.apache.activemq.broker.BrokerService.start(BrokerService.java:627)
>at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1890)
>at
>
[jira] [Updated] (AMQ-9505) ActiveMQ classic with postgres data source gives errors on start
[
https://issues.apache.org/jira/browse/AMQ-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated AMQ-9505:
Description:
I get this error when I start ActiveMQ
{noformat}
2024-05-21 23:59:32,959 | INFO | Using Persistence Adapter:
JDBCPersistenceAdapter(HikariDataSource (null)) |
org.apache.activemq.broker.BrokerService | main
2024-05-21 23:59:32,968 | INFO | Starting Persistence Adapter:
JDBCPersistenceAdapter(HikariDataSource (null)) |
org.apache.activemq.broker.BrokerService | main
2024-05-21 23:59:32,969 | INFO | HikariPool-1 - Starting... |
com.zaxxer.hikari.HikariDataSource | main
2024-05-21 23:59:35,211 | INFO | HikariPool-1 - Added connection
org.postgresql.jdbc.PgConnection@70101687 | com.zaxxer.hikari.pool.HikariPool |
main
2024-05-21 23:59:35,214 | INFO | HikariPool-1 - Start completed. |
com.zaxxer.hikari.HikariDataSource | main
2024-05-21 23:59:35,433 | INFO | Database adapter driver override recognized
for : [postgresql_jdbc_driver] - adapter: class
org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter |
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
2024-05-21 23:59:38,423 | WARN | Could not create JDBC tables; they could
already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP CONSTRAINT
"activemq_acks_pkey" Message: ERROR: constraint "activemq_acks_pkey" of
relation "activemq_acks" does not exist SQLState: 42704 Vendor code: 0 |
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter | main
2024-05-21 23:59:38,423 | WARN | Failure details: ERROR: constraint
"activemq_acks_pkey" of relation "activemq_acks" does not exist |
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
org.postgresql.util.PSQLException: ERROR: constraint "activemq_acks_pkey" of
relation "activemq_acks" does not exist
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2725)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2412)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:371)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:502)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:419)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:341)
at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:326)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:297)
at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94)
at
com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
at
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.executeStatement(DefaultJDBCAdapter.java:112)
at
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:90)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:318)
at
org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:99)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54)
at
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681)
at
org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:663)
at org.apache.activemq.broker.BrokerService.start(BrokerService.java:627)
at
org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1890)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1843)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1782)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522)
at
org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:325)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
at
[jira] [Updated] (AMQ-9505) ActiveMQ classic with postgres data source gives errors on start
[
https://issues.apache.org/jira/browse/AMQ-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated AMQ-9505:
Component/s: (was: AMQP)
> ActiveMQ classic with postgres data source gives errors on start
>
>
> Key: AMQ-9505
> URL: https://issues.apache.org/jira/browse/AMQ-9505
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 6.1.1
> Environment: Fresh 6.1.1 installation on Ubuntu + java 17
>
>
>Reporter: Susinda Perera
>Priority: Major
>
> I get this error when I start ActiveMQ
> {noformat}
> 2024-05-21 23:59:32,959 | INFO | Using Persistence Adapter:
> JDBCPersistenceAdapter(HikariDataSource (null)) |
> org.apache.activemq.broker.BrokerService | main
> 2024-05-21 23:59:32,968 | INFO | Starting Persistence Adapter:
> JDBCPersistenceAdapter(HikariDataSource (null)) |
> org.apache.activemq.broker.BrokerService | main
> 2024-05-21 23:59:32,969 | INFO | HikariPool-1 - Starting... |
> com.zaxxer.hikari.HikariDataSource | main
> 2024-05-21 23:59:35,211 | INFO | HikariPool-1 - Added connection
> org.postgresql.jdbc.PgConnection@70101687 | com.zaxxer.hikari.pool.HikariPool
> | main
> 2024-05-21 23:59:35,214 | INFO | HikariPool-1 - Start completed. |
> com.zaxxer.hikari.HikariDataSource | main
> 2024-05-21 23:59:35,433 | INFO | Database adapter driver override recognized
> for : [postgresql_jdbc_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> 2024-05-21 23:59:38,423 | WARN | Could not create JDBC tables; they could
> already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP CONSTRAINT
> "activemq_acks_pkey" Message: ERROR: constraint "activemq_acks_pkey" of
> relation "activemq_acks" does not exist SQLState: 42704 Vendor code: 0 |
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter | main
> 2024-05-21 23:59:38,423 | WARN | Failure details: ERROR: constraint
> "activemq_acks_pkey" of relation "activemq_acks" does not exist |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> org.postgresql.util.PSQLException: ERROR: constraint "activemq_acks_pkey" of
> relation "activemq_acks" does not exist
>at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2725)
>at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2412)
>at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:371)
>at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:502)
>at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:419)
>at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:341)
>at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:326)
>at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
>at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:297)
>at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94)
>at
> com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
>at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.executeStatement(DefaultJDBCAdapter.java:112)
>at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:90)
>at
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:318)
>at
> org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:99)
>at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54)
>at
> org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681)
>at
> org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:663)
>at org.apache.activemq.broker.BrokerService.start(BrokerService.java:627)
>at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1890)
>at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1843)
>at
>
[jira] [Updated] (AMQ-9505) ActiveMQ classic with postgres data source gives errors on start
[
https://issues.apache.org/jira/browse/AMQ-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated AMQ-9505:
Description:
I get this error when I start ActiveMQ
{noformat}
2024-05-21 23:59:32,959 | INFO | Using Persistence Adapter:
JDBCPersistenceAdapter(HikariDataSource (null)) |
org.apache.activemq.broker.BrokerService | main
2024-05-21 23:59:32,968 | INFO | Starting Persistence Adapter:
JDBCPersistenceAdapter(HikariDataSource (null)) |
org.apache.activemq.broker.BrokerService | main
2024-05-21 23:59:32,969 | INFO | HikariPool-1 - Starting... |
com.zaxxer.hikari.HikariDataSource | main
2024-05-21 23:59:35,211 | INFO | HikariPool-1 - Added connection
org.postgresql.jdbc.PgConnection@70101687 | com.zaxxer.hikari.pool.HikariPool |
main
2024-05-21 23:59:35,214 | INFO | HikariPool-1 - Start completed. |
com.zaxxer.hikari.HikariDataSource | main
2024-05-21 23:59:35,433 | INFO | Database adapter driver override recognized
for : [postgresql_jdbc_driver] - adapter: class
org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter |
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
2024-05-21 23:59:38,423 | WARN | Could not create JDBC tables; they could
already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP CONSTRAINT
"activemq_acks_pkey" Message: ERROR: constraint "activemq_acks_pkey" of
relation "activemq_acks" does not exist SQLState: 42704 Vendor code: 0 |
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter | main
2024-05-21 23:59:38,423 | WARN | Failure details: ERROR: constraint
"activemq_acks_pkey" of relation "activemq_acks" does not exist |
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
org.postgresql.util.PSQLException: ERROR: constraint "activemq_acks_pkey" of
relation "activemq_acks" does not exist
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2725)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2412)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:371)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:502)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:419)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:341)
at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:326)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:297)
at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94)
at
com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
at
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.executeStatement(DefaultJDBCAdapter.java:112)
at
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:90)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:318)
at
org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:99)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54)
at
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681)
at
org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:663)
at org.apache.activemq.broker.BrokerService.start(BrokerService.java:627)
at
org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1890)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1843)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1782)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522)
at
org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:325)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:323)
at
[jira] [Commented] (AMQ-9505) ActiveMQ classic with postgres data source gives errors on start
[ https://issues.apache.org/jira/browse/AMQ-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848775#comment-17848775 ] Susinda Perera commented on AMQ-9505: - Tried both of the below configs but same error 5432 activemq x.database.azure.com x x true > ActiveMQ classic with postgres data source gives errors on start > > > Key: AMQ-9505 > URL: https://issues.apache.org/jira/browse/AMQ-9505 > Project: ActiveMQ Classic > Issue Type: Bug > Components: AMQP >Affects Versions: 6.1.1 > Environment: Fresh 6.1.1 installation on Ubuntu + java 17 > > >Reporter: Susinda Perera >Priority: Major > > I get this error when I start activemq > > > 2024-05-21 23:59:32,959 | INFO | Using Persistence Adapter: > JDBCPersistenceAdapter(HikariDataSource (null)) | > org.apache.activemq.broker.BrokerService | main > 2024-05-21 23:59:32,968 | INFO | Starting Persistence Adapter: > JDBCPersistenceAdapter(HikariDataSource (null)) | > org.apache.activemq.broker.BrokerService | main > 2024-05-21 23:59:32,969 | INFO | HikariPool-1 - Starting... | > com.zaxxer.hikari.HikariDataSource | main > 2024-05-21 23:59:35,211 | INFO | HikariPool-1 - Added connection > org.postgresql.jdbc.PgConnection@70101687 | com.zaxxer.hikari.pool.HikariPool > | main > 2024-05-21 23:59:35,214 | INFO | HikariPool-1 - Start completed. | > com.zaxxer.hikari.HikariDataSource | main > 2024-05-21 23:59:35,433 | INFO | Database adapter driver override recognized > for : [postgresql_jdbc_driver] - adapter: class > org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter | > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main > 2024-05-21 23:59:38,423 | WARN | Could not create JDBC tables; they could > already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP CONSTRAINT > "activemq_acks_pkey" Message: ERROR: constraint "activemq_acks_pkey" of > relation "activemq_acks" does not exist SQLState: 42704 Vendor code: 0 | > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter | main > 2024-05-21 23:59:38,423 | WARN | Failure details: ERROR: constraint > "activemq_acks_pkey" of relation "activemq_acks" does not exist | > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main > org.postgresql.util.PSQLException: ERROR: constraint "activemq_acks_pkey" of > relation "activemq_acks" does not exist > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2725) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2412) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:371) > at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:502) > at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:419) > at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:341) > at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:326) > at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:302) > at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:297) > at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94) > at > com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java) > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.executeStatement(DefaultJDBCAdapter.java:112) > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:90) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:318) > at > org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:99) > at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54) > at > org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681) > at > org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:663) > at org.apache.activemq.broker.BrokerService.start(BrokerService.java:627) > at > org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1890) > at >
[jira] [Created] (AMQ-9505) ActiveMQ classic with postgres data source gives errors on start
Susinda Perera created AMQ-9505: --- Summary: ActiveMQ classic with postgres data source gives errors on start Key: AMQ-9505 URL: https://issues.apache.org/jira/browse/AMQ-9505 Project: ActiveMQ Classic Issue Type: Bug Components: AMQP Affects Versions: 6.1.1 Environment: Fresh 6.1.1 installation on Ubuntu + java 17 Reporter: Susinda Perera I get this error when I start activemq 2024-05-21 23:59:32,959 | INFO | Using Persistence Adapter: JDBCPersistenceAdapter(HikariDataSource (null)) | org.apache.activemq.broker.BrokerService | main 2024-05-21 23:59:32,968 | INFO | Starting Persistence Adapter: JDBCPersistenceAdapter(HikariDataSource (null)) | org.apache.activemq.broker.BrokerService | main 2024-05-21 23:59:32,969 | INFO | HikariPool-1 - Starting... | com.zaxxer.hikari.HikariDataSource | main 2024-05-21 23:59:35,211 | INFO | HikariPool-1 - Added connection org.postgresql.jdbc.PgConnection@70101687 | com.zaxxer.hikari.pool.HikariPool | main 2024-05-21 23:59:35,214 | INFO | HikariPool-1 - Start completed. | com.zaxxer.hikari.HikariDataSource | main 2024-05-21 23:59:35,433 | INFO | Database adapter driver override recognized for : [postgresql_jdbc_driver] - adapter: class org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter | org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main 2024-05-21 23:59:38,423 | WARN | Could not create JDBC tables; they could already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP CONSTRAINT "activemq_acks_pkey" Message: ERROR: constraint "activemq_acks_pkey" of relation "activemq_acks" does not exist SQLState: 42704 Vendor code: 0 | org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter | main 2024-05-21 23:59:38,423 | WARN | Failure details: ERROR: constraint "activemq_acks_pkey" of relation "activemq_acks" does not exist | org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main org.postgresql.util.PSQLException: ERROR: constraint "activemq_acks_pkey" of relation "activemq_acks" does not exist at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2725) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2412) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:371) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:502) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:419) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:341) at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:326) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:302) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:297) at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:94) at com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java) at org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.executeStatement(DefaultJDBCAdapter.java:112) at org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:90) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:318) at org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:99) at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54) at org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:681) at org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:663) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:627) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1890) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1843) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1782) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522) at
[jira] [Commented] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848716#comment-17848716 ] ASF subversion and git services commented on ARTEMIS-4726: -- Commit 1ee3e884b707a659d924188048c2960a3b22df35 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1ee3e884b7 ] ARTEMIS-4726 removing scheduled msg from q via mngmnt can cause negative msg count > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > Time Spent: 0.5h > Remaining Estimate: 0h > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?focusedWorklogId=920486=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920486 ] ASF GitHub Bot logged work on ARTEMIS-4726: --- Author: ASF GitHub Bot Created on: 22/May/24 19:10 Start Date: 22/May/24 19:10 Worklog Time Spent: 10m Work Description: jbertram merged PR #4894: URL: https://github.com/apache/activemq-artemis/pull/4894 Issue Time Tracking --- Worklog Id: (was: 920486) Time Spent: 0.5h (was: 20m) > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > Time Spent: 0.5h > Remaining Estimate: 0h > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848717#comment-17848717
]
ASF subversion and git services commented on ARTEMIS-4420:
--
Commit e13d65b16d4ac1c5edccc51f99cc7c33994f07f1 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e13d65b16d ]
ARTEMIS-4420 user auth leaks into non-Artemis servlets
> User authentication leaks into non-Artemis servlets
> ---
>
> Key: ARTEMIS-4420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Dries Harnie
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis supports audit logs, which log all administrative actions
> that happen on the broker.
> These logs identify the "current user" for an administrative access [by one
> of two
> methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
> # The {{Subject}} associated with the current security manager context, or
> # A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
> interaction with the admin console.
> For a non-Artemis servlet such as [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin],
> this {{ThreadLocal}} is set to whatever {{Subject}} made the previous request
> on this thread. This leads to situations where metric accesses are logged as
> being done by ghost users.
> To reproduce the issue:
> # Set up Artemis with the default admin/admin user and [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
> # Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}}
> level)
> # Tail -f the audit log and start the server
> # Log in to the admin console
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
> # Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*},
> even though these requests are completely anonymous.
>
> I think the solution involves a modification to
> {{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not
> understand the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-4768?focusedWorklogId=920488=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920488 ] ASF GitHub Bot logged work on ARTEMIS-4768: --- Author: ASF GitHub Bot Created on: 22/May/24 19:10 Start Date: 22/May/24 19:10 Worklog Time Spent: 10m Work Description: jbertram merged PR #4929: URL: https://github.com/apache/activemq-artemis/pull/4929 Issue Time Tracking --- Worklog Id: (was: 920488) Time Spent: 50m (was: 40m) > Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after > broker restart > > > Key: ARTEMIS-4768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.1, 2.33.0 >Reporter: Ajay P >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Im seeing something peculiar related to messages with Scheduled Delivery on > artemis 2.33.0 and a few prev versions too. > We transmit persistent messages for scheduled delivery with the property > _AMQ_SCHED_DELIVERY set to the time. There is a use case for being able to > browse these queues for scheduled messages and remove them if they need to be > canceled before delivery. This works fine and when browsing the queue using > listScheduledMessages, all properties on said message are visible. We use > this to show a list of scheduled messages that will be transmitted in the > future. > However, if the broker is restarted, then the message does not have that > _AMQ_SCHED_DELIVERY property set anymore. The broker still delivers the > message on the scheduled time but while browsing through the queue messages > that specific property is not on the message. > > Here is a link to a fork with a test case checked in. > [https://github.com/aahrimaan/activemq-scheduled-messages-issue] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920487=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920487
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 19:10
Start Date: 22/May/24 19:10
Worklog Time Spent: 10m
Work Description: jbertram merged PR #4897:
URL: https://github.com/apache/activemq-artemis/pull/4897
Issue Time Tracking
---
Worklog Id: (was: 920487)
Time Spent: 1h 10m (was: 1h)
> User authentication leaks into non-Artemis servlets
> ---
>
> Key: ARTEMIS-4420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Dries Harnie
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis supports audit logs, which log all administrative actions
> that happen on the broker.
> These logs identify the "current user" for an administrative access [by one
> of two
> methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
> # The {{Subject}} associated with the current security manager context, or
> # A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
> interaction with the admin console.
> For a non-Artemis servlet such as [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin],
> this {{ThreadLocal}} is set to whatever {{Subject}} made the previous request
> on this thread. This leads to situations where metric accesses are logged as
> being done by ghost users.
> To reproduce the issue:
> # Set up Artemis with the default admin/admin user and [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
> # Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}}
> level)
> # Tail -f the audit log and start the server
> # Log in to the admin console
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
> # Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*},
> even though these requests are completely anonymous.
>
> I think the solution involves a modification to
> {{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not
> understand the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848718#comment-17848718 ] ASF subversion and git services commented on ARTEMIS-4768: -- Commit 7e151ee1cee02496e0552d3be8da034ded4aa08f in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7e151ee1ce ] ARTEMIS-4768 _AMQ_SCHED_DELIVERY msg prop lost after broker restart > Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after > broker restart > > > Key: ARTEMIS-4768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.1, 2.33.0 >Reporter: Ajay P >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Im seeing something peculiar related to messages with Scheduled Delivery on > artemis 2.33.0 and a few prev versions too. > We transmit persistent messages for scheduled delivery with the property > _AMQ_SCHED_DELIVERY set to the time. There is a use case for being able to > browse these queues for scheduled messages and remove them if they need to be > canceled before delivery. This works fine and when browsing the queue using > listScheduledMessages, all properties on said message are visible. We use > this to show a list of scheduled messages that will be transmitted in the > future. > However, if the broker is restarted, then the message does not have that > _AMQ_SCHED_DELIVERY property set anymore. The broker still delivers the > message on the scheduled time but while browsing through the queue messages > that specific property is not on the message. > > Here is a link to a fork with a test case checked in. > [https://github.com/aahrimaan/activemq-scheduled-messages-issue] > -- 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=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
>
[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=17848695#comment-17848695
]
ritesh adval commented on AMQ-9504:
---
We are still on jdk 11 and would like to use next release 5.18.5. it seems the
page here shows ETA of june 24th for next 5.18.5 release
[https://activemq.apache.org/components/classic/download/] let me know if this
will happen or should I address the release question to someone else who does
it ?
Would like this patch release available sooner if possible so we can use it.
Thx
> 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
>
[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=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
>
[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=17848667#comment-17848667
]
ritesh adval commented on AMQ-9504:
---
This is great, thanks [~cshannon] for applying the patch, can you please let me
know if there will be a new patch release from activemq-5.18.x release branch ?
I would look to use official release version with this fix.
> 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
>
[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=17848632#comment-17848632
]
ASF subversion and git services commented on AMQ-9504:
--
Commit a12f030090bdf593b4c7bbaf10cd2d553f14bf89 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=a12f03009 ]
AMQ-9504 - Add missing license header
(cherry picked from commit 527d245831fb95fa3a25180ecf404d5a316f2425)
> 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
>
[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=17848629#comment-17848629
]
ASF subversion and git services commented on AMQ-9504:
--
Commit 527d245831fb95fa3a25180ecf404d5a316f2425 in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=527d24583 ]
AMQ-9504 - Add missing license header
> 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
>
[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=17848630#comment-17848630
]
ASF subversion and git services commented on AMQ-9504:
--
Commit ba3d395fc3f077f41381ad801f2a898caebb1eaa in activemq's branch
refs/heads/activemq-6.1.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ba3d395fc ]
AMQ-9504 - Add missing license header
(cherry picked from commit 527d245831fb95fa3a25180ecf404d5a316f2425)
> 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
>
[jira] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920433=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920433
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 14:10
Start Date: 22/May/24 14:10
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4897:
URL: https://github.com/apache/activemq-artemis/pull/4897#discussion_r1610049746
##
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java:
##
@@ -219,6 +239,18 @@ public synchronized void start() throws Exception {
cleanupTmp();
server.start();
+ /*
Review Comment:
That's fair. Reverted.
Issue Time Tracking
---
Worklog Id: (was: 920433)
Time Spent: 1h (was: 50m)
> User authentication leaks into non-Artemis servlets
> ---
>
> Key: ARTEMIS-4420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Dries Harnie
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> ActiveMQ Artemis supports audit logs, which log all administrative actions
> that happen on the broker.
> These logs identify the "current user" for an administrative access [by one
> of two
> methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
> # The {{Subject}} associated with the current security manager context, or
> # A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
> interaction with the admin console.
> For a non-Artemis servlet such as [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin],
> this {{ThreadLocal}} is set to whatever {{Subject}} made the previous request
> on this thread. This leads to situations where metric accesses are logged as
> being done by ghost users.
> To reproduce the issue:
> # Set up Artemis with the default admin/admin user and [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
> # Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}}
> level)
> # Tail -f the audit log and start the server
> # Log in to the admin console
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
> # Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*},
> even though these requests are completely anonymous.
>
> I think the solution involves a modification to
> {{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not
> understand the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4779) UNCHECKED_FUNC_RES.STAT Return value of function is not checked
[ https://issues.apache.org/jira/browse/ARTEMIS-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Slepykh updated ARTEMIS-4779: Description: in line: https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/config/impl/ConnectionFactoryConfigurationImpl.java#L625 In this case, the readBoolean() function reads short values from the component. Checking for the existence of values is necessary in all cases, since the developer cannot be sure that the value of a variable will not be returned with an error. !image-2024-05-22-17-02-37-538.png! Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. Author: Firsov Vladimir, BMSTU (fvv22u...@student.bmstu.ru) was:In this case, the readBoolean() function reads short values from the component. Checking for the existence of values is necessary in all cases, since the developer cannot be sure that the value of a variable will not be returned with an error. > UNCHECKED_FUNC_RES.STAT Return value of function is not checked > --- > > Key: ARTEMIS-4779 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4779 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.25.0 >Reporter: Andrey Slepykh >Priority: Major > Attachments: image-2024-05-22-17-02-37-538.png > > > in line: > https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/config/impl/ConnectionFactoryConfigurationImpl.java#L625 > In this case, the readBoolean() function reads short values from the > component. Checking for the existence of values is necessary in all cases, > since the developer cannot be sure that the value of a variable will not be > returned with an error. > !image-2024-05-22-17-02-37-538.png! > > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author: Firsov Vladimir, BMSTU (fvv22u...@student.bmstu.ru) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4779) UNCHECKED_FUNC_RES.STAT Return value of function is not checked
[ https://issues.apache.org/jira/browse/ARTEMIS-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Slepykh updated ARTEMIS-4779: Attachment: image-2024-05-22-17-02-37-538.png > UNCHECKED_FUNC_RES.STAT Return value of function is not checked > --- > > Key: ARTEMIS-4779 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4779 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.25.0 >Reporter: Andrey Slepykh >Priority: Major > Attachments: image-2024-05-22-17-02-37-538.png > > > In this case, the readBoolean() function reads short values from the > component. Checking for the existence of values is necessary in all cases, > since the developer cannot be sure that the value of a variable will not be > returned with an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4779) UNCHECKED_FUNC_RES.STAT Return value of function is not checked
Andrey Slepykh created ARTEMIS-4779: --- Summary: UNCHECKED_FUNC_RES.STAT Return value of function is not checked Key: ARTEMIS-4779 URL: https://issues.apache.org/jira/browse/ARTEMIS-4779 Project: ActiveMQ Artemis Issue Type: Bug Components: JMS Affects Versions: 2.25.0 Reporter: Andrey Slepykh In this case, the readBoolean() function reads short values from the component. Checking for the existence of values is necessary in all cases, since the developer cannot be sure that the value of a variable will not be returned with an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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
>
[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=17848617#comment-17848617
]
ASF subversion and git services commented on AMQ-9504:
--
Commit c71965176ac4acec78779fbc626c98fc310603e1 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=c71965176 ]
AMQ-9504 - Prevent registering duplicate mKahadb adapters
This fixes an issue on start up of a broker that is configured with
multiple mKahaDB filtered adapters and one is configured with
perDestination=true. Before this fix a duplicate persistence adapter
could be created because the filter did not check for existing matches.
Patch applied with thanks to Ritesh Adval
(cherry picked from commit ddfb36515c0e9588d2e322365f56a3f53fb094ad)
> 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
>
[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=17848615#comment-17848615
]
ASF subversion and git services commented on AMQ-9504:
--
Commit d719df23007393660547b58c9ff17c3d0bd72f8a in activemq's branch
refs/heads/activemq-6.1.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=d719df230 ]
AMQ-9504 - Prevent registering duplicate mKahadb adapters
This fixes an issue on start up of a broker that is configured with
multiple mKahaDB filtered adapters and one is configured with
perDestination=true. Before this fix a duplicate persistence adapter
could be created because the filter did not check for existing matches.
Patch applied with thanks to Ritesh Adval
(cherry picked from commit ddfb36515c0e9588d2e322365f56a3f53fb094ad)
> 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
>
[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
>
[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=17848614#comment-17848614
]
ASF subversion and git services commented on AMQ-9504:
--
Commit ddfb36515c0e9588d2e322365f56a3f53fb094ad in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ddfb36515 ]
AMQ-9504 - Prevent registering duplicate mKahadb adapters
This fixes an issue on start up of a broker that is configured with
multiple mKahaDB filtered adapters and one is configured with
perDestination=true. Before this fix a duplicate persistence adapter
could be created because the filter did not check for existing matches.
Patch applied with thanks to Ritesh Adval
> 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
>
[jira] [Work logged] (ARTEMIS-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?focusedWorklogId=920414=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920414
]
ASF GitHub Bot logged work on ARTEMIS-4777:
---
Author: ASF GitHub Bot
Created on: 22/May/24 13:04
Start Date: 22/May/24 13:04
Worklog Time Spent: 10m
Work Description: tabish121 opened a new pull request, #4941:
URL: https://github.com/apache/activemq-artemis/pull/4941
Add additional configuration for the broker connection senders and receivers
that allows for setting the source or target address value and optional source
and target capabilities to allow providing address mapping on some remote peers.
Issue Time Tracking
---
Worklog Id: (was: 920414)
Remaining Estimate: 0h
Time Spent: 10m
> Broker connections (AMQP) with receiver operation not working
> -
>
> Key: ARTEMIS-4777
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4777
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
> Environment: Server installed on CentOS Linux release 7.9.2009
>Reporter: Piero Cena
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to connect an Artemis instance to an instance of ActiveMQ Classic 5.15
> in order to receive messages from one destination (preferably a topic
> destination). Here is the configuration on Artemis instance:
> {code:xml}
>
> retry-interval="1000" reconnect-attempts="2" user="xxx{*}" password="xxx{*}">
>
>
> {code}
> The address "test" is predefined as multicast on Artemis and exists on the
> other side:
> {code:xml}
>
>
> {code}
> On startup Artemis will connect correctly to Classic but no message is
> received on the Artemis side when published to the Classic destination "test".
> The same test has done with two Artemis brokers, one configured as above, but
> the results are the same.
> Only "sender" or "mirror" operations seem to work properly (between 2
> Artemis).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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
>
[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] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920378=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920378
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 09:10
Start Date: 22/May/24 09:10
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4897:
URL: https://github.com/apache/activemq-artemis/pull/4897#discussion_r1609588605
##
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java:
##
@@ -219,6 +239,18 @@ public synchronized void start() throws Exception {
cleanupTmp();
server.start();
+ /*
Review Comment:
I would revert this change.
the metrics call to jmx which is instrumented to audit, with out this filter
the audit on metrics will be less informative.
in addition, there are cases where access to metrics will need
authentication, especially when there is RBAC on JMX mbeans.
##
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java:
##
@@ -166,6 +173,19 @@ public synchronized void start() throws Exception {
handlers.addHandler(webContext);
webContext.setInitParameter(DIR_ALLOWED, "false");
webContext.getSessionHandler().getSessionCookieConfig().setComment("__SAME_SITE_STRICT__");
+ webContext.addEventListener(new ServletContextListener() {
+ @Override
+ public void contextInitialized(ServletContextEvent sce) {
+ sce.getServletContext().addListener(new
ServletRequestListener() {
+@Override
+public void requestDestroyed(ServletRequestEvent sre) {
+ ServletRequestListener.super.requestDestroyed(sre);
+ AuditLogger.currentCaller.remove();
Review Comment:
that looks right
Issue Time Tracking
---
Worklog Id: (was: 920378)
Time Spent: 50m (was: 40m)
> User authentication leaks into non-Artemis servlets
> ---
>
> Key: ARTEMIS-4420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Dries Harnie
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis supports audit logs, which log all administrative actions
> that happen on the broker.
> These logs identify the "current user" for an administrative access [by one
> of two
> methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
> # The {{Subject}} associated with the current security manager context, or
> # A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
> interaction with the admin console.
> For a non-Artemis servlet such as [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin],
> this {{ThreadLocal}} is set to whatever {{Subject}} made the previous request
> on this thread. This leads to situations where metric accesses are logged as
> being done by ghost users.
> To reproduce the issue:
> # Set up Artemis with the default admin/admin user and [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
> # Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}}
> level)
> # Tail -f the audit log and start the server
> # Log in to the admin console
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
> # Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*},
> even though these requests are completely anonymous.
>
> I think the solution involves a modification to
> {{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not
> understand the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
