[jira] [Resolved] (AMQ-2766) lost messages using jdbcPersistenceAdapter and mysql
[ https://issues.apache.org/jira/browse/AMQ-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich resolved AMQ-2766. - Resolution: Not A Problem > lost messages using jdbcPersistenceAdapter and mysql > > > Key: AMQ-2766 > URL: https://issues.apache.org/jira/browse/AMQ-2766 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0, 5.3.1, 5.3.2 > Environment: ubuntu >Reporter: Javier Puerto >Priority: Major > Labels: close-pending > > hi, > i was trying durable topics with jdbcPersistenceAdapter and mysql using > JmsDurableTopicTransactionTest class (activemq test sources) and modified > the connection and the method testReceiveRollback adding a reconnect after > the rollback. it should be work fine but it fails and i'm not sure if i'm > doing something wrong or is a bug. > i would appreciate someone can check this test with this little modification > javier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQ-2766) lost messages using jdbcPersistenceAdapter and mysql
[ https://issues.apache.org/jira/browse/AMQ-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-2766. --- > lost messages using jdbcPersistenceAdapter and mysql > > > Key: AMQ-2766 > URL: https://issues.apache.org/jira/browse/AMQ-2766 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0, 5.3.1, 5.3.2 > Environment: ubuntu >Reporter: Javier Puerto >Priority: Major > Labels: close-pending > > hi, > i was trying durable topics with jdbcPersistenceAdapter and mysql using > JmsDurableTopicTransactionTest class (activemq test sources) and modified > the connection and the method testReceiveRollback adding a reconnect after > the rollback. it should be work fine but it fails and i'm not sure if i'm > doing something wrong or is a bug. > i would appreciate someone can check this test with this little modification > javier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2766) lost messages using jdbcPersistenceAdapter and mysql
[ https://issues.apache.org/jira/browse/AMQ-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266407#comment-17266407 ] Javier Puerto commented on AMQ-2766: [~matt.pavlov...@airband.com], you can close it. If nobody has found this issue before, it will be probably fixed or my mistake. > lost messages using jdbcPersistenceAdapter and mysql > > > Key: AMQ-2766 > URL: https://issues.apache.org/jira/browse/AMQ-2766 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0, 5.3.1, 5.3.2 > Environment: ubuntu >Reporter: Javier Puerto >Priority: Major > Labels: close-pending > > hi, > i was trying durable topics with jdbcPersistenceAdapter and mysql using > JmsDurableTopicTransactionTest class (activemq test sources) and modified > the connection and the method testReceiveRollback adding a reconnect after > the rollback. it should be work fine but it fails and i'm not sure if i'm > doing something wrong or is a bug. > i would appreciate someone can check this test with this little modification > javier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3069) Add option to mask using the configured password-codec
[ https://issues.apache.org/jira/browse/ARTEMIS-3069?focusedWorklogId=536642=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536642 ] ASF GitHub Bot logged work on ARTEMIS-3069: --- Author: ASF GitHub Bot Created on: 15/Jan/21 21:51 Start Date: 15/Jan/21 21:51 Worklog Time Spent: 10m Work Description: asfgit merged pull request #3409: URL: https://github.com/apache/activemq-artemis/pull/3409 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 536642) Time Spent: 20m (was: 10m) > Add option to mask using the configured password-codec > -- > > Key: ARTEMIS-3069 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3069 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Artemis documentation describes how to implement and configure a custom codec > class by extending the SensitiveDataCodec class, adding the new class to the > classpath, and configuring a custom-codec element in the broker > configuration; however, there does not seem to be any provision in the > masking utility classes to retrieve and use the custom codec. Instead, the > masking utility is hard-coded to return the DefaultSensitiveStringCodec > bundled with the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3069) Add option to mask using the configured password-codec
[ https://issues.apache.org/jira/browse/ARTEMIS-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266369#comment-17266369 ] ASF subversion and git services commented on ARTEMIS-3069: -- Commit 1f825ee424699b282f9f4b6fe5f0401616a9669b in activemq-artemis's branch refs/heads/master from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1f825ee ] ARTEMIS-3069 Add option to mask using the configured password-codec > Add option to mask using the configured password-codec > -- > > Key: ARTEMIS-3069 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3069 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Artemis documentation describes how to implement and configure a custom codec > class by extending the SensitiveDataCodec class, adding the new class to the > classpath, and configuring a custom-codec element in the broker > configuration; however, there does not seem to be any provision in the > masking utility classes to retrieve and use the custom codec. Instead, the > masking utility is hard-coded to return the DefaultSensitiveStringCodec > bundled with the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3068) Comparator implementation of HierarchicalObjectRepository issue
[
https://issues.apache.org/jira/browse/ARTEMIS-3068?focusedWorklogId=536633=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536633
]
ASF GitHub Bot logged work on ARTEMIS-3068:
---
Author: ASF GitHub Bot
Created on: 15/Jan/21 20:48
Start Date: 15/Jan/21 20:48
Worklog Time Spent: 10m
Work Description: brusdev commented on a change in pull request #3408:
URL: https://github.com/apache/activemq-artemis/pull/3408#discussion_r558117860
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/HierarchicalObjectRepository.java
##
@@ -484,17 +482,10 @@ public int compare(final String o1, final String o2) {
} else if (!o1.contains(singleWord) && o2.contains(singleWord)) {
return -1;
} else if (o1.contains(singleWord) && o2.contains(singleWord)) {
-String[] leftSplits = o1.split(quotedDelimiter);
-String[] rightSplits = o2.split(quotedDelimiter);
-for (int i = 0; i < leftSplits.length; i++) {
- String left = leftSplits[i];
- if (left.equals(singleWord)) {
- if (rightSplits.length < i ||
!rightSplits[i].equals(singleWord)) {
- return -1;
- } else {
- return +1;
- }
- }
+int o1Count = StringUtils.countMatches(o1, singleWord);
+int o2Count = StringUtils.countMatches(o2, singleWord);
+if (o1Count != o2Count) {
+ return o1Count - o2Count;
Review comment:
The MatchComparator should take into account the position of the
`singleWord` wild card too, ie `foo.*.too.*` is more specific than `*.too` in a
hierarchical sense.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 536633)
Time Spent: 1h 10m (was: 1h)
> Comparator implementation of HierarchicalObjectRepository issue
> ---
>
> Key: ARTEMIS-3068
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3068
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.13.0, 2.14.0,
> 2.15.0, 2.16.0
>Reporter: Luis Miguel De Bello
>Priority: Major
> Fix For: 2.17.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hi, I am having an issue with the MatchComparator implemented in the
> HierarchicalObjectRepository class.
> Let me put an example on what's going on right now:
> I have created a class called DynamicRolesSecuritySettingPlugin implementing
> the interface SecuritySettingPlugin so that I can implement the
> setSecurityRepository method. There, I am adding some roles to the
> HierarchicalRepository based on a certificate. The HierarchicalRepository
> type T is Set. To summarize, the HierarchicalObjectRepository ends up
> having two different strings as key to the internal map (they are added with
> the addMatch method):
> - *.Provider.*.Agent.*.State
> - uswest.Provider.RR.Agent.*.State
> For the string "*.Provider.*.Agent.*.State", i end up setting a Role with
> permissions to publish but not to consume.
> For the string "uswest.Provider.RR.Agent.*.State", i end up setting a Role
> with permissions to consume.
> Now, when I create a consumer for a queue named
> uswest.Provider.RR.Agent.1.State (there is already a queue created with that
> name and with messages on it), I get an error on the consumer saying that I
> don't have the permission 'CONSUME' for queue
> uswest.Provider.RR.Agent.1.State.
> So I went ahead and debugged the code. I ended up in the class
> HierarchicalObjectRepository reading the getMatch method:
> @Override
> public T getMatch(final String match) {
> String modifiedMatch = matchModifier.modify(match);
> T cacheResult = cache.get(modifiedMatch);
> if (cacheResult != null) {
> return cacheResult;
> }
> lock.readLock().lock();
> try {
> T actualMatch;
> Map> possibleMatches =
> getPossibleMatches(modifiedMatch);
> Collection> orderedMatches = sort(possibleMatches);
> actualMatch = merge(orderedMatches);
> T value = actualMatch != null ? actualMatch : defaultmatch;
> if (value != null) {
> cache.put(modifiedMatch, value);
> }
> return value;
> } finally {
> lock.readLock().unlock();
> }
> }
> When I set a
[jira] [Work logged] (ARTEMIS-3068) Comparator implementation of HierarchicalObjectRepository issue
[
https://issues.apache.org/jira/browse/ARTEMIS-3068?focusedWorklogId=536597=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536597
]
ASF GitHub Bot logged work on ARTEMIS-3068:
---
Author: ASF GitHub Bot
Created on: 15/Jan/21 19:18
Start Date: 15/Jan/21 19:18
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3408:
URL: https://github.com/apache/activemq-artemis/pull/3408#discussion_r558535368
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/HierarchicalObjectRepository.java
##
@@ -484,17 +482,10 @@ public int compare(final String o1, final String o2) {
} else if (!o1.contains(singleWord) && o2.contains(singleWord)) {
return -1;
} else if (o1.contains(singleWord) && o2.contains(singleWord)) {
-String[] leftSplits = o1.split(quotedDelimiter);
-String[] rightSplits = o2.split(quotedDelimiter);
-for (int i = 0; i < leftSplits.length; i++) {
- String left = leftSplits[i];
- if (left.equals(singleWord)) {
- if (rightSplits.length < i ||
!rightSplits[i].equals(singleWord)) {
- return -1;
- } else {
- return +1;
- }
- }
+int o1Count = StringUtils.countMatches(o1, singleWord);
+int o2Count = StringUtils.countMatches(o2, singleWord);
+if (o1Count != o2Count) {
+ return o1Count - o2Count;
Review comment:
although the tests seem to cover that...
@msingermann ?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 536597)
Time Spent: 1h (was: 50m)
> Comparator implementation of HierarchicalObjectRepository issue
> ---
>
> Key: ARTEMIS-3068
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3068
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.13.0, 2.14.0,
> 2.15.0, 2.16.0
>Reporter: Luis Miguel De Bello
>Priority: Major
> Fix For: 2.17.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Hi, I am having an issue with the MatchComparator implemented in the
> HierarchicalObjectRepository class.
> Let me put an example on what's going on right now:
> I have created a class called DynamicRolesSecuritySettingPlugin implementing
> the interface SecuritySettingPlugin so that I can implement the
> setSecurityRepository method. There, I am adding some roles to the
> HierarchicalRepository based on a certificate. The HierarchicalRepository
> type T is Set. To summarize, the HierarchicalObjectRepository ends up
> having two different strings as key to the internal map (they are added with
> the addMatch method):
> - *.Provider.*.Agent.*.State
> - uswest.Provider.RR.Agent.*.State
> For the string "*.Provider.*.Agent.*.State", i end up setting a Role with
> permissions to publish but not to consume.
> For the string "uswest.Provider.RR.Agent.*.State", i end up setting a Role
> with permissions to consume.
> Now, when I create a consumer for a queue named
> uswest.Provider.RR.Agent.1.State (there is already a queue created with that
> name and with messages on it), I get an error on the consumer saying that I
> don't have the permission 'CONSUME' for queue
> uswest.Provider.RR.Agent.1.State.
> So I went ahead and debugged the code. I ended up in the class
> HierarchicalObjectRepository reading the getMatch method:
> @Override
> public T getMatch(final String match) {
> String modifiedMatch = matchModifier.modify(match);
> T cacheResult = cache.get(modifiedMatch);
> if (cacheResult != null) {
> return cacheResult;
> }
> lock.readLock().lock();
> try {
> T actualMatch;
> Map> possibleMatches =
> getPossibleMatches(modifiedMatch);
> Collection> orderedMatches = sort(possibleMatches);
> actualMatch = merge(orderedMatches);
> T value = actualMatch != null ? actualMatch : defaultmatch;
> if (value != null) {
> cache.put(modifiedMatch, value);
> }
> return value;
> } finally {
> lock.readLock().unlock();
> }
> }
> When I set a breakpoint in the getPossibleMatches I get the two entries
> correctly (both "*.Provider.*.Agent.*.State"
[jira] [Commented] (AMQ-3075) Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key')
[ https://issues.apache.org/jira/browse/AMQ-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266305#comment-17266305 ] Volker Kleinschmidt commented on AMQ-3075: -- Same here > Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key') > - > > Key: AMQ-3075 > URL: https://issues.apache.org/jira/browse/AMQ-3075 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.4.2 > Environment: ActiveMQ 5.4.2 fresh install, Ubuntu 64-bit OpenJDK > 6b20-1.9.2-0ubuntu1 PostgreSQL 8.4 >Reporter: Ned Wolpert >Assignee: Dejan Bosanac >Priority: Major > Fix For: 5.5.0 > > > Trying to do a fresh install with persistence fails to create the database, > with a listed database error. > Persistence support added to activemq.xml file: > > > > > > > > > > > > > useDatabaseLock="false"/> > > postgresql-8.4-701.jdbc4.jar added to the lib directory > Log from startup: > INFO | Pre-instantiating singletons in > org.springframework.beans.factory.support.DefaultListableBeanFactory@40b0095d: > defining beans > [org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#0,postgres-ds,org.apache.activemq.xbean.XBeanBrokerService#0,securityLoginService,securityConstraint,securityConstraintMapping,securityHandler,contexts,Server]; > root of factory hierarchy > WARN | destroyApplicationContextOnStop parameter is deprecated, please use > shutdown hooks instead > INFO | > PListStore:/home/wolpert/Downloads/apache-activemq-5.4.2/data/localhost/tmp_storage > started > INFO | Using Persistence Adapter: > JDBCPersistenceAdapter(org.postgresql.ds.PGPoolingDataSource@3302fc5) > INFO | Database adapter driver override recognized for : > [postgresql_native_driver] - adapter: class > org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter > WARN | Could not create JDBC tables; they could already exist. Failure was: > ALTER TABLE ACTIVEMQ_ACKS DROP PRIMARY KEY Message: ERROR: syntax error at or > near "PRIMARY" > Position: 32 SQLState: 42601 Vendor code: 0 > WARN | Failure details: ERROR: syntax error at or near "PRIMARY" > Position: 32 > org.postgresql.util.PSQLException: ERROR: syntax error at or near "PRIMARY" > Position: 32 > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:345) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455) > at $Proxy5.execute(Unknown Source) > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:101) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:272) > at > org.apache.activemq.broker.BrokerService.start(BrokerService.java:485) > at > org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > ... > Database reports the following with its log turned on full. > 2010-12-08 14:35:31 MST LOG: execute : SET SESSION CHARACTERISTICS > AS TRANSACTION ISOLATION LEVEL READ UNCOMMITTED > 2010-12-08 14:35:31 MST LOG: execute S_1: BEGIN > 2010-12-08 14:35:31 MST LOG: execute : SELECT NULL AS TABLE_CAT, > n.nspname AS TABLE_SCHEM, c.relname AS TABLE_NAME, CASE n.nspname ~ '^pg_' > OR n.nspname = 'information_schema' WHEN true THEN CASE WHEN n.nspname = > 'pg_catalog' OR n.nspname = 'information_schema' THEN CASE c.relkind WHEN > 'r' THEN 'SYSTEM TABLE' WHEN 'v' THEN 'SYSTEM VIEW' WHEN 'i' THEN
[jira] [Commented] (AMQ-3075) Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key')
[ https://issues.apache.org/jira/browse/AMQ-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266301#comment-17266301 ] Ned Wolpert commented on AMQ-3075: -- Matt... I have no insight into this anymore, and no longer have access to an environment (production or otherwise) that uses ActiveMQ. > Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key') > - > > Key: AMQ-3075 > URL: https://issues.apache.org/jira/browse/AMQ-3075 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.4.2 > Environment: ActiveMQ 5.4.2 fresh install, Ubuntu 64-bit OpenJDK > 6b20-1.9.2-0ubuntu1 PostgreSQL 8.4 >Reporter: Ned Wolpert >Assignee: Dejan Bosanac >Priority: Major > Fix For: 5.5.0 > > > Trying to do a fresh install with persistence fails to create the database, > with a listed database error. > Persistence support added to activemq.xml file: > > > > > > > > > > > > > useDatabaseLock="false"/> > > postgresql-8.4-701.jdbc4.jar added to the lib directory > Log from startup: > INFO | Pre-instantiating singletons in > org.springframework.beans.factory.support.DefaultListableBeanFactory@40b0095d: > defining beans > [org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#0,postgres-ds,org.apache.activemq.xbean.XBeanBrokerService#0,securityLoginService,securityConstraint,securityConstraintMapping,securityHandler,contexts,Server]; > root of factory hierarchy > WARN | destroyApplicationContextOnStop parameter is deprecated, please use > shutdown hooks instead > INFO | > PListStore:/home/wolpert/Downloads/apache-activemq-5.4.2/data/localhost/tmp_storage > started > INFO | Using Persistence Adapter: > JDBCPersistenceAdapter(org.postgresql.ds.PGPoolingDataSource@3302fc5) > INFO | Database adapter driver override recognized for : > [postgresql_native_driver] - adapter: class > org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter > WARN | Could not create JDBC tables; they could already exist. Failure was: > ALTER TABLE ACTIVEMQ_ACKS DROP PRIMARY KEY Message: ERROR: syntax error at or > near "PRIMARY" > Position: 32 SQLState: 42601 Vendor code: 0 > WARN | Failure details: ERROR: syntax error at or near "PRIMARY" > Position: 32 > org.postgresql.util.PSQLException: ERROR: syntax error at or near "PRIMARY" > Position: 32 > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:345) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455) > at $Proxy5.execute(Unknown Source) > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:101) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:272) > at > org.apache.activemq.broker.BrokerService.start(BrokerService.java:485) > at > org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > ... > Database reports the following with its log turned on full. > 2010-12-08 14:35:31 MST LOG: execute : SET SESSION CHARACTERISTICS > AS TRANSACTION ISOLATION LEVEL READ UNCOMMITTED > 2010-12-08 14:35:31 MST LOG: execute S_1: BEGIN > 2010-12-08 14:35:31 MST LOG: execute : SELECT NULL AS TABLE_CAT, > n.nspname AS TABLE_SCHEM, c.relname AS TABLE_NAME, CASE n.nspname ~ '^pg_' > OR n.nspname = 'information_schema' WHEN true THEN CASE WHEN n.nspname = > 'pg_catalog' OR n.nspname =
[jira] [Commented] (AMQ-3075) Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key')
[ https://issues.apache.org/jira/browse/AMQ-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266290#comment-17266290 ] Peter Berkman commented on AMQ-3075: Matt, thank you for reviewing - we upgraded to v 5.15 not too long ago and will be upgrading again within a few months. Once we do, I'll remove my "hack" and see if it works - I'll keep this ticket up to date as I go. > Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key') > - > > Key: AMQ-3075 > URL: https://issues.apache.org/jira/browse/AMQ-3075 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.4.2 > Environment: ActiveMQ 5.4.2 fresh install, Ubuntu 64-bit OpenJDK > 6b20-1.9.2-0ubuntu1 PostgreSQL 8.4 >Reporter: Ned Wolpert >Assignee: Dejan Bosanac >Priority: Major > Fix For: 5.5.0 > > > Trying to do a fresh install with persistence fails to create the database, > with a listed database error. > Persistence support added to activemq.xml file: > > > > > > > > > > > > > useDatabaseLock="false"/> > > postgresql-8.4-701.jdbc4.jar added to the lib directory > Log from startup: > INFO | Pre-instantiating singletons in > org.springframework.beans.factory.support.DefaultListableBeanFactory@40b0095d: > defining beans > [org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#0,postgres-ds,org.apache.activemq.xbean.XBeanBrokerService#0,securityLoginService,securityConstraint,securityConstraintMapping,securityHandler,contexts,Server]; > root of factory hierarchy > WARN | destroyApplicationContextOnStop parameter is deprecated, please use > shutdown hooks instead > INFO | > PListStore:/home/wolpert/Downloads/apache-activemq-5.4.2/data/localhost/tmp_storage > started > INFO | Using Persistence Adapter: > JDBCPersistenceAdapter(org.postgresql.ds.PGPoolingDataSource@3302fc5) > INFO | Database adapter driver override recognized for : > [postgresql_native_driver] - adapter: class > org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter > WARN | Could not create JDBC tables; they could already exist. Failure was: > ALTER TABLE ACTIVEMQ_ACKS DROP PRIMARY KEY Message: ERROR: syntax error at or > near "PRIMARY" > Position: 32 SQLState: 42601 Vendor code: 0 > WARN | Failure details: ERROR: syntax error at or near "PRIMARY" > Position: 32 > org.postgresql.util.PSQLException: ERROR: syntax error at or near "PRIMARY" > Position: 32 > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:345) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455) > at $Proxy5.execute(Unknown Source) > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:101) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:272) > at > org.apache.activemq.broker.BrokerService.start(BrokerService.java:485) > at > org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > ... > Database reports the following with its log turned on full. > 2010-12-08 14:35:31 MST LOG: execute : SET SESSION CHARACTERISTICS > AS TRANSACTION ISOLATION LEVEL READ UNCOMMITTED > 2010-12-08 14:35:31 MST LOG: execute S_1: BEGIN > 2010-12-08 14:35:31 MST LOG: execute : SELECT NULL AS TABLE_CAT, > n.nspname AS TABLE_SCHEM, c.relname AS TABLE_NAME, CASE n.nspname ~ '^pg_' > OR n.nspname =
[jira] [Updated] (AMQ-3446) Network of brokers does not pass messages when networkTTL is bigger then 1
[ https://issues.apache.org/jira/browse/AMQ-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-3446: Labels: broker close-pending network networkBridge networkConnector ttl (was: broker network networkBridge networkConnector ttl) > Network of brokers does not pass messages when networkTTL is bigger then 1 > -- > > Key: AMQ-3446 > URL: https://issues.apache.org/jira/browse/AMQ-3446 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.4.1, 5.4.2, 5.5.0 >Reporter: VIctor Perepelitsky >Priority: Major > Labels: broker, close-pending, network, networkBridge, > networkConnector, ttl > Attachments: activemqTest.zip > > > (Unit test is attached to prove the case) > Given 3 brokers A, B and C. > Each broker is connected to the others by a network bridge (so we have 3 > brokers that are connected to each other) > The networkTTL is 2 on all network connectors. > Start broker A and B > Subscribe consumer on A > Start Broker C > Stop Broker B > Publish message to C > Expected result: > The consumer that is subscribed on A receives the message > Actual result: > Sometimes it works and sometimes the consumer does not receive the message. > Additional info: > From my understanding the problem appears since a broker subscribes as a > consumer to other brokers only when there is a consumer that subscribed to > this broker, but it does not try to renew subscription to other brokers when > some (another) broker in its network fails (or stopped). > So we see the following situation: > Client subscribed on topic X on A, A subscribed on topic X on B, B subscribed > on topic X on C > When we stop B, A does not subscribe on topic X on C and the message of topic > X cannot pass from C to A. > This BUG does not occur when networkTTL is 1 because subscription route in a > network will be not be greater then 2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-3446) Network of brokers does not pass messages when networkTTL is bigger then 1
[ https://issues.apache.org/jira/browse/AMQ-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266274#comment-17266274 ] Matt Pavlovich commented on AMQ-3446: - [~victor.prp] This issue is quite dated and most likely resolved up through in 5.16.1. Please update with a reproducible test case against 5.16.1 if this is still an issue for you. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Network of brokers does not pass messages when networkTTL is bigger then 1 > -- > > Key: AMQ-3446 > URL: https://issues.apache.org/jira/browse/AMQ-3446 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.4.1, 5.4.2, 5.5.0 >Reporter: VIctor Perepelitsky >Priority: Major > Labels: broker, network, networkBridge, networkConnector, ttl > Attachments: activemqTest.zip > > > (Unit test is attached to prove the case) > Given 3 brokers A, B and C. > Each broker is connected to the others by a network bridge (so we have 3 > brokers that are connected to each other) > The networkTTL is 2 on all network connectors. > Start broker A and B > Subscribe consumer on A > Start Broker C > Stop Broker B > Publish message to C > Expected result: > The consumer that is subscribed on A receives the message > Actual result: > Sometimes it works and sometimes the consumer does not receive the message. > Additional info: > From my understanding the problem appears since a broker subscribes as a > consumer to other brokers only when there is a consumer that subscribed to > this broker, but it does not try to renew subscription to other brokers when > some (another) broker in its network fails (or stopped). > So we see the following situation: > Client subscribed on topic X on A, A subscribed on topic X on B, B subscribed > on topic X on C > When we stop B, A does not subscribe on topic X on C and the message of topic > X cannot pass from C to A. > This BUG does not occur when networkTTL is 1 because subscription route in a > network will be not be greater then 2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-3420) Unable to integrate ActiveMQ and WebLogic through XBean container adapter (RAR)
[ https://issues.apache.org/jira/browse/AMQ-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266273#comment-17266273 ] Matt Pavlovich commented on AMQ-3420: - [~nsel] This issue is quite dated and most likely resolved up through in 5.16.1. Please update with a reproducible test case against 5.16.1 if this is still an issue for you. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Unable to integrate ActiveMQ and WebLogic through XBean container adapter > (RAR) > --- > > Key: AMQ-3420 > URL: https://issues.apache.org/jira/browse/AMQ-3420 > Project: ActiveMQ > Issue Type: Bug > Components: JCA Container >Affects Versions: 5.5.0 > Environment: Windows XP with SP 2, WebLogic 11g >Reporter: NSEL >Priority: Major > > When we try to integrate ActiveMQ and WebLogic through XBean container > (adapter) we get an error > <08-Jun-2011 11:45:49 o'clock IST> > C:\Temp\activemq-rar-5.5.0.rar > resulted in the following warnings: > The ra.xml class > 'org.apache.activemq.ra.ActiveMQResourceAdapter' should implement > java.io.Serializable but does not.> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-3420) Unable to integrate ActiveMQ and WebLogic through XBean container adapter (RAR)
[ https://issues.apache.org/jira/browse/AMQ-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-3420: Labels: close-pending (was: ) > Unable to integrate ActiveMQ and WebLogic through XBean container adapter > (RAR) > --- > > Key: AMQ-3420 > URL: https://issues.apache.org/jira/browse/AMQ-3420 > Project: ActiveMQ > Issue Type: Bug > Components: JCA Container >Affects Versions: 5.5.0 > Environment: Windows XP with SP 2, WebLogic 11g >Reporter: NSEL >Priority: Major > Labels: close-pending > > When we try to integrate ActiveMQ and WebLogic through XBean container > (adapter) we get an error > <08-Jun-2011 11:45:49 o'clock IST> > C:\Temp\activemq-rar-5.5.0.rar > resulted in the following warnings: > The ra.xml class > 'org.apache.activemq.ra.ActiveMQResourceAdapter' should implement > java.io.Serializable but does not.> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-3281) Messages stuck
[ https://issues.apache.org/jira/browse/AMQ-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266272#comment-17266272 ] Matt Pavlovich commented on AMQ-3281: - [~lernit.2007] This issue is quite dated and most likely resolved up through in 5.16.1. Please update with a reproducible test case against 5.16.1 if this is still an issue for you. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Messages stuck > -- > > Key: AMQ-3281 > URL: https://issues.apache.org/jira/browse/AMQ-3281 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.0 > Environment: Linux and Windows >Reporter: Erkan >Priority: Major > Fix For: NEEDS_REVIEW > > Attachments: activemq-jdbc.xml, activemq.log, activemq.xml, debug.zip > > > Sometimes the messages stuck in queue and after restart of activemq then this > messages redeliver to consumer. There are a lot of of topics: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html > and this some of them: > http://activemq.2283324.n4.nabble.com/Stuck-messages-Dispatch-issues-td2367852.html > http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-td3244342.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-3281) Messages stuck
[ https://issues.apache.org/jira/browse/AMQ-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-3281: Labels: close-pending (was: ) > Messages stuck > -- > > Key: AMQ-3281 > URL: https://issues.apache.org/jira/browse/AMQ-3281 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.0 > Environment: Linux and Windows >Reporter: Erkan >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW > > Attachments: activemq-jdbc.xml, activemq.log, activemq.xml, debug.zip > > > Sometimes the messages stuck in queue and after restart of activemq then this > messages redeliver to consumer. There are a lot of of topics: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html > and this some of them: > http://activemq.2283324.n4.nabble.com/Stuck-messages-Dispatch-issues-td2367852.html > http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-td3244342.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-3234) Memory usage limits may be reported incorrectly.
[
https://issues.apache.org/jira/browse/AMQ-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-3234:
Labels: close-pending (was: )
> Memory usage limits may be reported incorrectly.
> --
>
> Key: AMQ-3234
> URL: https://issues.apache.org/jira/browse/AMQ-3234
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.4.2
> Environment: All
>Reporter: Adrian Trenaman
>Priority: Major
> Labels: close-pending
> Fix For: NEEDS_REVIEW
>
>
> The determination of whether memory usage 'isFull' is performed by first
> checking if the parent memory usage is full, and the checking if the queue's
> memory usage itself is full (See line 91 of MemoryUsage.java). However, the
> reporting of a memory usage full event (at line 548 of Queue.java, reproduced
> below) creates a message based on the memory usage of the queue alone. So,
> it's possible that a memory limit may be hit because of the overall Broker
> memory being consumed, but it will be reported as a limit breach of a smaller
> queue memory usage amount.
> {code}
> LOG.info("Usage Manager Memory Limit ("
> + memoryUsage.getLimit()
> + ") reached on "
> + getActiveMQDestination().getQualifiedName()
> + ". Producers will be throttled to the rate at which messages are removed
> from this destination to prevent flooding it."
> + " See http://activemq.apache.org/producer-flow-control.html for more
> info");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-3234) Memory usage limits may be reported incorrectly.
[
https://issues.apache.org/jira/browse/AMQ-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266270#comment-17266270
]
Matt Pavlovich commented on AMQ-3234:
-
[~adrian.trenaman] This issue is quite dated and most likely resolved up
through in 5.16.1. Please update with a reproducible test case against 5.16.1
if this is still an issue for you.
NOTE: This JIRA is scheduled to close in 30 days if no update is provided.
> Memory usage limits may be reported incorrectly.
> --
>
> Key: AMQ-3234
> URL: https://issues.apache.org/jira/browse/AMQ-3234
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.4.2
> Environment: All
>Reporter: Adrian Trenaman
>Priority: Major
> Fix For: NEEDS_REVIEW
>
>
> The determination of whether memory usage 'isFull' is performed by first
> checking if the parent memory usage is full, and the checking if the queue's
> memory usage itself is full (See line 91 of MemoryUsage.java). However, the
> reporting of a memory usage full event (at line 548 of Queue.java, reproduced
> below) creates a message based on the memory usage of the queue alone. So,
> it's possible that a memory limit may be hit because of the overall Broker
> memory being consumed, but it will be reported as a limit breach of a smaller
> queue memory usage amount.
> {code}
> LOG.info("Usage Manager Memory Limit ("
> + memoryUsage.getLimit()
> + ") reached on "
> + getActiveMQDestination().getQualifiedName()
> + ". Producers will be throttled to the rate at which messages are removed
> from this destination to prevent flooding it."
> + " See http://activemq.apache.org/producer-flow-control.html for more
> info");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-3226) persistent messages expire without being saved to ActiveMQ.DLQ if a master-to-slave failover took place - issue with JDBC master-Slave cluster
[
https://issues.apache.org/jira/browse/AMQ-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-3226:
Labels: close-pending (was: )
> persistent messages expire without being saved to ActiveMQ.DLQ if a
> master-to-slave failover took place - issue with JDBC master-Slave cluster
> --
>
> Key: AMQ-3226
> URL: https://issues.apache.org/jira/browse/AMQ-3226
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.4.2
> Environment: Sun Solaris + JDK 1.6
> a JDBC cluster of 2 nodes running apache-activemq-5.4.2-fuse-01-00
> using MS SQL Server 2008 as a database for JDBC
>Reporter: Oleg Kiorsak
>Priority: Critical
> Labels: close-pending
>
> Setup :
> Sun Solaris + JDK 1.6
> a JDBC cluster of 2 nodes running apache-activemq-5.4.2-fuse-01-00
> using MS SQL Server 2008 as a database for JDBC
> 1. 1 client (NMS STOMP , if that is any relevant) sends 10 persistent
> messages with TTL set to 5 mins
> 2. after all messages have been sent and seen in the destination queue (via
> SQL query)
> but well before the time message are about to even start expirying
> do a 'kill -KILL' of the activemq process on node1 ("master") - so 'failover'
> take place
> - node2 ("slave") now becomes new "master" and resumes connections/etc
> 3. in 5 mins time all 10 messages sitting in the destination queue do expire,
> but they do NOT end up in ActiveMQ.DLQ as they should...
> this is really bad -
> basically the failover event breaks the promise of "guaranteed" delivery of
> persistent messages
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-3226) persistent messages expire without being saved to ActiveMQ.DLQ if a master-to-slave failover took place - issue with JDBC master-Slave cluster
[
https://issues.apache.org/jira/browse/AMQ-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266269#comment-17266269
]
Matt Pavlovich commented on AMQ-3226:
-
[~kiorsak] have you been able to verify if this was fixed with AMQ-2756?
This issue is quite dated and may be resolved up through in 5.16.1. Please
update with a reproducible test case against 5.16.1 if this is still an issue
for you.
NOTE: This JIRA is scheduled to close in 30 days if no update is provided.
> persistent messages expire without being saved to ActiveMQ.DLQ if a
> master-to-slave failover took place - issue with JDBC master-Slave cluster
> --
>
> Key: AMQ-3226
> URL: https://issues.apache.org/jira/browse/AMQ-3226
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.4.2
> Environment: Sun Solaris + JDK 1.6
> a JDBC cluster of 2 nodes running apache-activemq-5.4.2-fuse-01-00
> using MS SQL Server 2008 as a database for JDBC
>Reporter: Oleg Kiorsak
>Priority: Critical
>
> Setup :
> Sun Solaris + JDK 1.6
> a JDBC cluster of 2 nodes running apache-activemq-5.4.2-fuse-01-00
> using MS SQL Server 2008 as a database for JDBC
> 1. 1 client (NMS STOMP , if that is any relevant) sends 10 persistent
> messages with TTL set to 5 mins
> 2. after all messages have been sent and seen in the destination queue (via
> SQL query)
> but well before the time message are about to even start expirying
> do a 'kill -KILL' of the activemq process on node1 ("master") - so 'failover'
> take place
> - node2 ("slave") now becomes new "master" and resumes connections/etc
> 3. in 5 mins time all 10 messages sitting in the destination queue do expire,
> but they do NOT end up in ActiveMQ.DLQ as they should...
> this is really bad -
> basically the failover event breaks the promise of "guaranteed" delivery of
> persistent messages
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-3212) Durable topic subscriptions loose messages during sudden server restart
[ https://issues.apache.org/jira/browse/AMQ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-3212: Labels: close-pending (was: ) > Durable topic subscriptions loose messages during sudden server restart > --- > > Key: AMQ-3212 > URL: https://issues.apache.org/jira/browse/AMQ-3212 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.0 >Reporter: Pierre >Priority: Major > Labels: close-pending > > - Create a durable message consumer with a transacted session > - rollback every message > - put a handful of messages in the topic > - messages start being redelivered > - restart application server during message redelivery > - messages that were currently in the session are lost > - messages after that are still preserved -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-3212) Durable topic subscriptions loose messages during sudden server restart
[ https://issues.apache.org/jira/browse/AMQ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266268#comment-17266268 ] Matt Pavlovich commented on AMQ-3212: - [~jabbah] This issue is quite dated and may be resolved up through in 5.16.1. Please update with a reproducible test case against 5.16.1 if this is still an issue for you. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Durable topic subscriptions loose messages during sudden server restart > --- > > Key: AMQ-3212 > URL: https://issues.apache.org/jira/browse/AMQ-3212 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.0 >Reporter: Pierre >Priority: Major > > - Create a durable message consumer with a transacted session > - rollback every message > - put a handful of messages in the topic > - messages start being redelivered > - restart application server during message redelivery > - messages that were currently in the session are lost > - messages after that are still preserved -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-3075) Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key')
[ https://issues.apache.org/jira/browse/AMQ-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266267#comment-17266267 ] Matt Pavlovich commented on AMQ-3075: - [~wolpert] [~volkerk][~rui.b.zhang] This issue is quite dated and may be resolved in the heavy JDBC updates that came up through 5.16.1. Is this still an issue? > Auto-create database fails with PostgreSQL (Error in SQL: 'drop primary key') > - > > Key: AMQ-3075 > URL: https://issues.apache.org/jira/browse/AMQ-3075 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.4.2 > Environment: ActiveMQ 5.4.2 fresh install, Ubuntu 64-bit OpenJDK > 6b20-1.9.2-0ubuntu1 PostgreSQL 8.4 >Reporter: Ned Wolpert >Assignee: Dejan Bosanac >Priority: Major > Fix For: 5.5.0 > > > Trying to do a fresh install with persistence fails to create the database, > with a listed database error. > Persistence support added to activemq.xml file: > > > > > > > > > > > > > useDatabaseLock="false"/> > > postgresql-8.4-701.jdbc4.jar added to the lib directory > Log from startup: > INFO | Pre-instantiating singletons in > org.springframework.beans.factory.support.DefaultListableBeanFactory@40b0095d: > defining beans > [org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#0,postgres-ds,org.apache.activemq.xbean.XBeanBrokerService#0,securityLoginService,securityConstraint,securityConstraintMapping,securityHandler,contexts,Server]; > root of factory hierarchy > WARN | destroyApplicationContextOnStop parameter is deprecated, please use > shutdown hooks instead > INFO | > PListStore:/home/wolpert/Downloads/apache-activemq-5.4.2/data/localhost/tmp_storage > started > INFO | Using Persistence Adapter: > JDBCPersistenceAdapter(org.postgresql.ds.PGPoolingDataSource@3302fc5) > INFO | Database adapter driver override recognized for : > [postgresql_native_driver] - adapter: class > org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter > WARN | Could not create JDBC tables; they could already exist. Failure was: > ALTER TABLE ACTIVEMQ_ACKS DROP PRIMARY KEY Message: ERROR: syntax error at or > near "PRIMARY" > Position: 32 SQLState: 42601 Vendor code: 0 > WARN | Failure details: ERROR: syntax error at or near "PRIMARY" > Position: 32 > org.postgresql.util.PSQLException: ERROR: syntax error at or near "PRIMARY" > Position: 32 > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:345) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455) > at $Proxy5.execute(Unknown Source) > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:101) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:272) > at > org.apache.activemq.broker.BrokerService.start(BrokerService.java:485) > at > org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > ... > Database reports the following with its log turned on full. > 2010-12-08 14:35:31 MST LOG: execute : SET SESSION CHARACTERISTICS > AS TRANSACTION ISOLATION LEVEL READ UNCOMMITTED > 2010-12-08 14:35:31 MST LOG: execute S_1: BEGIN > 2010-12-08 14:35:31 MST LOG: execute : SELECT NULL AS TABLE_CAT, > n.nspname AS TABLE_SCHEM, c.relname AS TABLE_NAME, CASE n.nspname ~ '^pg_' > OR n.nspname = 'information_schema' WHEN true THEN CASE WHEN n.nspname = >
[jira] [Commented] (AMQ-2969) Connection pool exhausted in JDBC master-slave when slave tries to acquire lock
[ https://issues.apache.org/jira/browse/AMQ-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266263#comment-17266263 ] Matt Pavlovich commented on AMQ-2969: - [~tbehlau] This issue is quite dated and most likely resolved. Update with a reproducible test case against 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Connection pool exhausted in JDBC master-slave when slave tries to acquire > lock > --- > > Key: AMQ-2969 > URL: https://issues.apache.org/jira/browse/AMQ-2969 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Thomas Behlau >Priority: Major > Fix For: NEEDS_REVIEW > > > Similar to issues AMQ-1972 and AMQ-2296 the connection is not release to the > pool in the TransactDatabaseLocker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2953) Disk limits not observed when memory limits exceeded for non-persistent messaging
[ https://issues.apache.org/jira/browse/AMQ-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266262#comment-17266262 ] Matt Pavlovich commented on AMQ-2953: - This issue is quite dated and most likely resolved. Update with a reproducible test case against 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Disk limits not observed when memory limits exceeded for non-persistent > messaging > - > > Key: AMQ-2953 > URL: https://issues.apache.org/jira/browse/AMQ-2953 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.3.2 >Reporter: Richard Bonneau >Priority: Major > Fix For: NEEDS_REVIEW > > Attachments: activemq-JMX-low-tempUsage-lowstoreUsage-STOMP.xml > > > Using the Kahadb persistence adapter. > When producing non-persistent messages and using the element to > specify memory and disk limits, > it appears that after memory limit is reached that staging incoming messages > to disk continues to happen even > past the specified disk limit. More specifically if limit is > exceeded, we see messages being > stored into files labelled as data-TopicSubscription-.log. However, even > when element specifies a limit on the > disk space to be used, messages continue to be stored there and the limit is > not adhered to. > Attaching the configuration file used for this bug report. I simply used the > producer/consumer programs in the example folder to populate and consume > large number of messages. > Note that with ActiveMQ 5.4, similar behavior except that the location of the > data files is in data\localhost\tmp_storage and the data files are named > db-.log. > We need to have the limit(s) adhered to and then the producer should be held > up until disk or memory is freed up as expected from the description of > handling non-persistent messages. Under the current implementations, the > producer can continue to produce messages until all available disk space is > allocated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2953) Disk limits not observed when memory limits exceeded for non-persistent messaging
[ https://issues.apache.org/jira/browse/AMQ-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2953: Labels: close-pending (was: ) > Disk limits not observed when memory limits exceeded for non-persistent > messaging > - > > Key: AMQ-2953 > URL: https://issues.apache.org/jira/browse/AMQ-2953 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.3.2 >Reporter: Richard Bonneau >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW > > Attachments: activemq-JMX-low-tempUsage-lowstoreUsage-STOMP.xml > > > Using the Kahadb persistence adapter. > When producing non-persistent messages and using the element to > specify memory and disk limits, > it appears that after memory limit is reached that staging incoming messages > to disk continues to happen even > past the specified disk limit. More specifically if limit is > exceeded, we see messages being > stored into files labelled as data-TopicSubscription-.log. However, even > when element specifies a limit on the > disk space to be used, messages continue to be stored there and the limit is > not adhered to. > Attaching the configuration file used for this bug report. I simply used the > producer/consumer programs in the example folder to populate and consume > large number of messages. > Note that with ActiveMQ 5.4, similar behavior except that the location of the > data files is in data\localhost\tmp_storage and the data files are named > db-.log. > We need to have the limit(s) adhered to and then the producer should be held > up until disk or memory is freed up as expected from the description of > handling non-persistent messages. Under the current implementations, the > producer can continue to produce messages until all available disk space is > allocated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2969) Connection pool exhausted in JDBC master-slave when slave tries to acquire lock
[ https://issues.apache.org/jira/browse/AMQ-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2969: Labels: close-pending (was: ) > Connection pool exhausted in JDBC master-slave when slave tries to acquire > lock > --- > > Key: AMQ-2969 > URL: https://issues.apache.org/jira/browse/AMQ-2969 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Thomas Behlau >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW > > > Similar to issues AMQ-1972 and AMQ-2296 the connection is not release to the > pool in the TransactDatabaseLocker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQ-2928) new 5.4.0 activemq sysv init script tries to open the JDWP debug port when run with "stop"
[
https://issues.apache.org/jira/browse/AMQ-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich closed AMQ-2928.
---
local environment variable problem.. closing as non-issue.
> new 5.4.0 activemq sysv init script tries to open the JDWP debug port when
> run with "stop"
> --
>
> Key: AMQ-2928
> URL: https://issues.apache.org/jira/browse/AMQ-2928
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.4.0
>Reporter: Mats Henrikson
>Priority: Minor
>
> With the new ActiveMQ 5.4.0 if you have /etc/default/activemq configured with
> the following line:
> {noformat}
> # Uncomment to enable remote debugging
> ACTIVEMQ_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> {noformat}
> Then when you try to shut down a running ActiveMQ broker instance using the
> init script with the "stop" command, the Java process that attempts to shut
> it down also tries and fails to open the same JDWP port:
> {noformat}
> root@sts-chc-matsh:/# ls -l /etc/init.d/activemq
> lrwxrwxrwx 1 root root 32 2010-09-16 13:10 /etc/init.d/activemq ->
> /usr/local/apache-activemq-5.4.0/bin/activemq*
> root@sts-chc-matsh:/# /etc/init.d/activemq stop
> INFO: Loading '/etc/default/activemq'
> INFO: Using java '/usr/lib/jvm/java-6-sun/bin/java'
> INFO: changing to user 'activemq' to invoke java
> INFO: Waiting at least 30 seconds for regular process termination of pid
> '6764' : ERROR: transport error 202: bind failed: Address already in use
> ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
> JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
> [../../../src/share/back/debugInit.c:690]
> FATAL ERROR in native method: JDWP No transports initialized,
> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
> ..
> INFO: Regular shutdown not successful, sending SIGKILL to process with pid
> '6764'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (AMQ-2928) new 5.4.0 activemq sysv init script tries to open the JDWP debug port when run with "stop"
[
https://issues.apache.org/jira/browse/AMQ-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich resolved AMQ-2928.
-
Resolution: Not A Problem
> new 5.4.0 activemq sysv init script tries to open the JDWP debug port when
> run with "stop"
> --
>
> Key: AMQ-2928
> URL: https://issues.apache.org/jira/browse/AMQ-2928
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.4.0
>Reporter: Mats Henrikson
>Priority: Minor
>
> With the new ActiveMQ 5.4.0 if you have /etc/default/activemq configured with
> the following line:
> {noformat}
> # Uncomment to enable remote debugging
> ACTIVEMQ_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> {noformat}
> Then when you try to shut down a running ActiveMQ broker instance using the
> init script with the "stop" command, the Java process that attempts to shut
> it down also tries and fails to open the same JDWP port:
> {noformat}
> root@sts-chc-matsh:/# ls -l /etc/init.d/activemq
> lrwxrwxrwx 1 root root 32 2010-09-16 13:10 /etc/init.d/activemq ->
> /usr/local/apache-activemq-5.4.0/bin/activemq*
> root@sts-chc-matsh:/# /etc/init.d/activemq stop
> INFO: Loading '/etc/default/activemq'
> INFO: Using java '/usr/lib/jvm/java-6-sun/bin/java'
> INFO: changing to user 'activemq' to invoke java
> INFO: Waiting at least 30 seconds for regular process termination of pid
> '6764' : ERROR: transport error 202: bind failed: Address already in use
> ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
> JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
> [../../../src/share/back/debugInit.c:690]
> FATAL ERROR in native method: JDWP No transports initialized,
> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
> ..
> INFO: Regular shutdown not successful, sending SIGKILL to process with pid
> '6764'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-2766) lost messages using jdbcPersistenceAdapter and mysql
[ https://issues.apache.org/jira/browse/AMQ-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266256#comment-17266256 ] Matt Pavlovich commented on AMQ-2766: - [~javier] this issue is quite dated and most likely resolved in improvements since 5.3.x. Especially in the area of JDBC. Please update this ticket if this is still an issue when using ActiveMQ 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > lost messages using jdbcPersistenceAdapter and mysql > > > Key: AMQ-2766 > URL: https://issues.apache.org/jira/browse/AMQ-2766 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0, 5.3.1, 5.3.2 > Environment: ubuntu >Reporter: Javier Puerto >Priority: Major > > hi, > i was trying durable topics with jdbcPersistenceAdapter and mysql using > JmsDurableTopicTransactionTest class (activemq test sources) and modified > the connection and the method testReceiveRollback adding a reconnect after > the rollback. it should be work fine but it fails and i'm not sure if i'm > doing something wrong or is a bug. > i would appreciate someone can check this test with this little modification > javier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2766) lost messages using jdbcPersistenceAdapter and mysql
[ https://issues.apache.org/jira/browse/AMQ-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2766: Labels: close-pending (was: ) > lost messages using jdbcPersistenceAdapter and mysql > > > Key: AMQ-2766 > URL: https://issues.apache.org/jira/browse/AMQ-2766 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0, 5.3.1, 5.3.2 > Environment: ubuntu >Reporter: Javier Puerto >Priority: Major > Labels: close-pending > > hi, > i was trying durable topics with jdbcPersistenceAdapter and mysql using > JmsDurableTopicTransactionTest class (activemq test sources) and modified > the connection and the method testReceiveRollback adding a reconnect after > the rollback. it should be work fine but it fails and i'm not sure if i'm > doing something wrong or is a bug. > i would appreciate someone can check this test with this little modification > javier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2725) Issues With NetworkConnector and NetworkBridge MBeans
[ https://issues.apache.org/jira/browse/AMQ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266254#comment-17266254 ] Matt Pavlovich commented on AMQ-2725: - stop() on various top-level components should not necessarily unregister from JMX-- networkConnector, transportConnector. Sub-instances should be transient (ie.. networkBridge) > Issues With NetworkConnector and NetworkBridge MBeans > -- > > Key: AMQ-2725 > URL: https://issues.apache.org/jira/browse/AMQ-2725 > Project: ActiveMQ > Issue Type: Bug > Components: JMX >Affects Versions: 5.3.1 > Environment: ActiveMQ 5.3.1 on Windoze XP Pro SP2 >Reporter: Joe Francis >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.17.0 > > > On the JConsole, when you invoke the 'Stop' operation on the > NetworkConnectorView MBean, the corresponding NetworkBridgeView MBean > disappears as expected; however, when you invoke the NetworkConnectorView's > 'Start' operation to restart the bridge, the corresponding NetworkBridgeView > MBean does not reappear. > When you invoke the NetworkBridgeView MBean's Stop operation, the MBean > disappears. So there is no point having a Start operation for this MBean. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2725) Issues With NetworkConnector and NetworkBridge MBeans
[ https://issues.apache.org/jira/browse/AMQ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2725: Fix Version/s: (was: 5.x) 5.17.0 > Issues With NetworkConnector and NetworkBridge MBeans > -- > > Key: AMQ-2725 > URL: https://issues.apache.org/jira/browse/AMQ-2725 > Project: ActiveMQ > Issue Type: Bug > Components: JMX >Affects Versions: 5.3.1 > Environment: ActiveMQ 5.3.1 on Windoze XP Pro SP2 >Reporter: Joe Francis >Priority: Minor > Fix For: 5.17.0 > > > On the JConsole, when you invoke the 'Stop' operation on the > NetworkConnectorView MBean, the corresponding NetworkBridgeView MBean > disappears as expected; however, when you invoke the NetworkConnectorView's > 'Start' operation to restart the bridge, the corresponding NetworkBridgeView > MBean does not reappear. > When you invoke the NetworkBridgeView MBean's Stop operation, the MBean > disappears. So there is no point having a Start operation for this MBean. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (AMQ-2725) Issues With NetworkConnector and NetworkBridge MBeans
[ https://issues.apache.org/jira/browse/AMQ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich reassigned AMQ-2725: --- Assignee: Matt Pavlovich > Issues With NetworkConnector and NetworkBridge MBeans > -- > > Key: AMQ-2725 > URL: https://issues.apache.org/jira/browse/AMQ-2725 > Project: ActiveMQ > Issue Type: Bug > Components: JMX >Affects Versions: 5.3.1 > Environment: ActiveMQ 5.3.1 on Windoze XP Pro SP2 >Reporter: Joe Francis >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.17.0 > > > On the JConsole, when you invoke the 'Stop' operation on the > NetworkConnectorView MBean, the corresponding NetworkBridgeView MBean > disappears as expected; however, when you invoke the NetworkConnectorView's > 'Start' operation to restart the bridge, the corresponding NetworkBridgeView > MBean does not reappear. > When you invoke the NetworkBridgeView MBean's Stop operation, the MBean > disappears. So there is no point having a Start operation for this MBean. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2653) Messages lost when ServerSessionPool.getServerSession() throws a JMSException
[ https://issues.apache.org/jira/browse/AMQ-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2653: Labels: close-pending (was: ) > Messages lost when ServerSessionPool.getServerSession() throws a JMSException > - > > Key: AMQ-2653 > URL: https://issues.apache.org/jira/browse/AMQ-2653 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0 >Reporter: Eugene Rodos >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW > > Attachments: GetServerSessionExceptionTest.java > > > In ActiveMQConnectionConsumer.dispatch() method, if the call to > sessionPool.getServerSession() results in an Exception, the message being > dispatched is never redelivered and is lost forever. In fact, it gets stuck > in the dispatch queue and can result in no new messages at all being > delivered to the consumer if the prefetchSize has been reached! > This JMSException is part of JMS's public API and it seems to me that if it > is thrown, that should not result in a lost message. > I'm attaching a junit test that reproduces the problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2653) Messages lost when ServerSessionPool.getServerSession() throws a JMSException
[ https://issues.apache.org/jira/browse/AMQ-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266253#comment-17266253 ] Matt Pavlovich commented on AMQ-2653: - [~rodos77] this issue is quite dated and most likely resolved in improvements since 5.3.0. Please update this ticket if this is still an issue when using ActiveMQ 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Messages lost when ServerSessionPool.getServerSession() throws a JMSException > - > > Key: AMQ-2653 > URL: https://issues.apache.org/jira/browse/AMQ-2653 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0 >Reporter: Eugene Rodos >Priority: Major > Fix For: NEEDS_REVIEW > > Attachments: GetServerSessionExceptionTest.java > > > In ActiveMQConnectionConsumer.dispatch() method, if the call to > sessionPool.getServerSession() results in an Exception, the message being > dispatched is never redelivered and is lost forever. In fact, it gets stuck > in the dispatch queue and can result in no new messages at all being > delivered to the consumer if the prefetchSize has been reached! > This JMSException is part of JMS's public API and it seems to me that if it > is thrown, that should not result in a lost message. > I'm attaching a junit test that reproduces the problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2543) Network of brokers with durable topics does not recover from network cable unplugging
[ https://issues.apache.org/jira/browse/AMQ-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2543: Labels: close-pending (was: ) > Network of brokers with durable topics does not recover from network cable > unplugging > - > > Key: AMQ-2543 > URL: https://issues.apache.org/jira/browse/AMQ-2543 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.3.0 > Environment: java 1.6.17 > spring 2.5.6 >Reporter: Antti Kallonen >Priority: Major > Labels: close-pending > Fix For: 5.x > > Attachments: ActiveMQBugReport.zip > > > We had a network of brokers configuration like this: C1-B1---B2-C2 where > C means client and B broker and durable topics enabled. when we start the > system, messages get delivered correctly between clients. Even when we shut > down the clients or brokers, messages get delivered correctly. But when I > remove the network plug from broker B1 severing the connection between > brokers, and reconnect the cable, messages are not delivered anymore. Brokers > were set up at store-forward configuration, with static IP:s or multicast > discovery. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2543) Network of brokers with durable topics does not recover from network cable unplugging
[ https://issues.apache.org/jira/browse/AMQ-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266251#comment-17266251 ] Matt Pavlovich commented on AMQ-2543: - [~antti] this issue is quite dated and most likely resolved in improvements since 5.3.0. Please update this ticket if this is still an issue when using ActiveMQ 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Network of brokers with durable topics does not recover from network cable > unplugging > - > > Key: AMQ-2543 > URL: https://issues.apache.org/jira/browse/AMQ-2543 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.3.0 > Environment: java 1.6.17 > spring 2.5.6 >Reporter: Antti Kallonen >Priority: Major > Fix For: 5.x > > Attachments: ActiveMQBugReport.zip > > > We had a network of brokers configuration like this: C1-B1---B2-C2 where > C means client and B broker and durable topics enabled. when we start the > system, messages get delivered correctly between clients. Even when we shut > down the clients or brokers, messages get delivered correctly. But when I > remove the network plug from broker B1 severing the connection between > brokers, and reconnect the cable, messages are not delivered anymore. Brokers > were set up at store-forward configuration, with static IP:s or multicast > discovery. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2399) Add support for reastarting the Broker in BrokerFactoryBean
[ https://issues.apache.org/jira/browse/AMQ-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2399: Labels: close-pending (was: ) > Add support for reastarting the Broker in BrokerFactoryBean > --- > > Key: AMQ-2399 > URL: https://issues.apache.org/jira/browse/AMQ-2399 > Project: ActiveMQ > Issue Type: Sub-task > Components: Connector >Affects Versions: 5.3.0 >Reporter: Mike K. >Priority: Major > Labels: close-pending > > Please add support for restarting the broker when using it in Spring. > Currently in 5.2, if the embedded broker dies then spring will start the > default "localhost" broker (I have no idea how to tell it not to). > Since support was added for restarting an embedded broker, please add support > for it in Spring so it will use the correct broker to produce messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2399) Add support for reastarting the Broker in BrokerFactoryBean
[ https://issues.apache.org/jira/browse/AMQ-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266249#comment-17266249 ] Matt Pavlovich commented on AMQ-2399: - The BrokerService supports a start.. and shutdown.. as long as you have a handle to the same bean, you should be able to start it back up. [~mike.k] this issue is dated and most likely resolved in future releases. Please update this ticket if this is still an issue when using ActiveMQ 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Add support for reastarting the Broker in BrokerFactoryBean > --- > > Key: AMQ-2399 > URL: https://issues.apache.org/jira/browse/AMQ-2399 > Project: ActiveMQ > Issue Type: Sub-task > Components: Connector >Affects Versions: 5.3.0 >Reporter: Mike K. >Priority: Major > > Please add support for restarting the broker when using it in Spring. > Currently in 5.2, if the embedded broker dies then spring will start the > default "localhost" broker (I have no idea how to tell it not to). > Since support was added for restarting an embedded broker, please add support > for it in Spring so it will use the correct broker to produce messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2397) Strange behaviour of Store Percent Usage and associated Memory Usage controls : Abnormal SystemUsage memory limit reached
[ https://issues.apache.org/jira/browse/AMQ-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266248#comment-17266248 ] Matt Pavlovich commented on AMQ-2397: - [~pmouawad] this issue is dated and most likely resolved in future releases. Please update this ticket if this is still an issue when using ActiveMQ 5.16.1. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Strange behaviour of Store Percent Usage and associated Memory Usage > controls : Abnormal SystemUsage memory limit reached > -- > > Key: AMQ-2397 > URL: https://issues.apache.org/jira/browse/AMQ-2397 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.2.0 > Environment: JDK 5 1.5.0_14 / Windows XP / Linux >Reporter: Philippe Mouawad >Priority: Major > Attachments: activemq.xml, activemq.zip, activemq520-bug.pdf > > > I attached the full scenario as a PDF to reproduce the issue. > In the attached configuration notice the following: > - org.apache.activemq.store.amq.AMQPersistenceAdapter is declared as a bean > to allow Memory usage control on store > - Advisory messages are activated > - sendFailIfNoSpace is set to true > - loggingBrokerPlugin is activated > Since I have a listener that consumes messages I don't understand why > although AMQ indicated 0 pending message: > - Store percent used continuously increase > - Memory limit is reached while it was at 0 > See attached files > Philippe > www.ubik-ingenierie.com -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2397) Strange behaviour of Store Percent Usage and associated Memory Usage controls : Abnormal SystemUsage memory limit reached
[ https://issues.apache.org/jira/browse/AMQ-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2397: Labels: close-pending (was: ) > Strange behaviour of Store Percent Usage and associated Memory Usage > controls : Abnormal SystemUsage memory limit reached > -- > > Key: AMQ-2397 > URL: https://issues.apache.org/jira/browse/AMQ-2397 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.2.0 > Environment: JDK 5 1.5.0_14 / Windows XP / Linux >Reporter: Philippe Mouawad >Priority: Major > Labels: close-pending > Attachments: activemq.xml, activemq.zip, activemq520-bug.pdf > > > I attached the full scenario as a PDF to reproduce the issue. > In the attached configuration notice the following: > - org.apache.activemq.store.amq.AMQPersistenceAdapter is declared as a bean > to allow Memory usage control on store > - Advisory messages are activated > - sendFailIfNoSpace is set to true > - loggingBrokerPlugin is activated > Since I have a listener that consumes messages I don't understand why > although AMQ indicated 0 pending message: > - Store percent used continuously increase > - Memory limit is reached while it was at 0 > See attached files > Philippe > www.ubik-ingenierie.com -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2317) Duplicate messages with transacted persistent messages during JDBC Master/Slave failover
[ https://issues.apache.org/jira/browse/AMQ-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2317: Labels: close-pending (was: ) > Duplicate messages with transacted persistent messages during JDBC > Master/Slave failover > > > Key: AMQ-2317 > URL: https://issues.apache.org/jira/browse/AMQ-2317 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0 > Environment: OS: MacOS X 10.5.7 MacBook Core 2 Duo 2 Ghz > DBMS: MySQL 5.0.83 (through macports), SQLServer 2005 (in VMWare), other > suspected but not thouroughly tested (including HSQL) > All observations are against trunk: rev 790957 (2009-07-03 23:07:04 +0700 > (Fri, 03 Jul 2009)) (fuse progress 5.3.0.3 and ActiveMQ 5.2.0 seem to have > the same problem though) >Reporter: Daniel Mueller >Priority: Critical > Labels: close-pending > Attachments: FailoverTransactionalTest.patch > > > There is a race condition somewhere in the transaction/replay code involving > failovers of JDBC only Master/Slave configurations. > Observed problems: > If messages are sent to a master broker in one transaction, and during the > time of the transaction the master fails over to the slave, then the messages > seem to be replayed twice (both database holds duplicates (see query at the > end) and the broker answer with message count containing duplicates). > Severity: > If the clients are connected to the new master and start consuming, the > broker will not deliver dups. The dups will be delivered though, if there is > another failover (a common case for system upgrades). It seems like a single > consumer will not get duplicates, even if it fails over again to new broker, > but if the consumer is restarted, it loses it's state as well, and > subsequently gets the duplicates delivered. > Attached is a testcase that demonstrates the problem. It shows that with a > single producer doing commits after each send, it creates on additional > message in the broker with a duplicate MSGID_SEQ. If everything is committed > in one transaction, then every single message in the transaction is > duplicated (and not only the ones before the failover occurred). > The testcase uses an external MySQL instance though, and needs the DBCP and > the MySQL JDBC connector on the classpath (the pom is patched in the attached > file to resolve that automatically). > Out of the 6 tests, the following almost always fail on my machine: > testProducer_MasterFailoverByShutdown_AtRandomTimes_CommitPerMessage > (expected <6000>, but was <6001>) > testProducer_MasterFailoverByShutdown_AtRandomTimes_OneCommit (expected > <6000>, but was <12000>) > Rarely (3-5% of the cases) this one also fails: > testProducer_MasterFailoverByShutdown_SingleMsgCommit_AfterCommit (expected > <500>, but was <501>) > Other observations made: > 1) The problem seems to be a race condition because while trying to find the > cause through debugging, the problem disapeared when setting a break point in > TransactionInfo.visit(line:100). The race condition is met on my machine > (specs above) basically all the time without interaction (from maven, on the > shell with a build, inside eclipse debugged and normal). > 2) It seems that TransactionBroker.commitTransaction(line:100) is called once > with duplicated synchronizations (2x size). On the other hand > MemoryTransactionStore$Tx(line:109) is called twice with the correct amount > first, and later a doubled amount. > 3) The problem is not reproducible with Kaha, the problem is related to JDBC. > 4) It might be possible to have the testcase fail reliably with one of > Derby/HSQL/H2, but I didn't investigate. > 5) The testcase is not exactly very pretty, but it does show the problem ;) > 6) The attached testcase is a patch against activemq-core. > 7) The tests can be executed directly (in bash) with: > env MAVEN_OPTS="$MAVEN_OPTS -Xmx800M" mvn > -Dtest=org.apache.activemq.transport.failover.FailoverTransactionalTest test > 8) For MySQL the following should work: > SELECT > MSGID_PROD > ,MSGID_SEQ > FROM activemq_msgs > GROUP BY MSGID_PROD,MSGID_SEQ > HAVING ( COUNT(MSGID_SEQ) > 1 ); > 9) if you need the my.cnf for the database, I can attach that as well. > 10) The tables are correctly created as InnoDB > I think that's it... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2317) Duplicate messages with transacted persistent messages during JDBC Master/Slave failover
[ https://issues.apache.org/jira/browse/AMQ-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266245#comment-17266245 ] Matt Pavlovich commented on AMQ-2317: - [~dmueller]This issue is most likely resolved in newer releases. JDBC support has improved greatly, especially up through 5.16.1. If there is still an issue, please retest with 5.16.1 and report back. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > Duplicate messages with transacted persistent messages during JDBC > Master/Slave failover > > > Key: AMQ-2317 > URL: https://issues.apache.org/jira/browse/AMQ-2317 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.0 > Environment: OS: MacOS X 10.5.7 MacBook Core 2 Duo 2 Ghz > DBMS: MySQL 5.0.83 (through macports), SQLServer 2005 (in VMWare), other > suspected but not thouroughly tested (including HSQL) > All observations are against trunk: rev 790957 (2009-07-03 23:07:04 +0700 > (Fri, 03 Jul 2009)) (fuse progress 5.3.0.3 and ActiveMQ 5.2.0 seem to have > the same problem though) >Reporter: Daniel Mueller >Priority: Critical > Attachments: FailoverTransactionalTest.patch > > > There is a race condition somewhere in the transaction/replay code involving > failovers of JDBC only Master/Slave configurations. > Observed problems: > If messages are sent to a master broker in one transaction, and during the > time of the transaction the master fails over to the slave, then the messages > seem to be replayed twice (both database holds duplicates (see query at the > end) and the broker answer with message count containing duplicates). > Severity: > If the clients are connected to the new master and start consuming, the > broker will not deliver dups. The dups will be delivered though, if there is > another failover (a common case for system upgrades). It seems like a single > consumer will not get duplicates, even if it fails over again to new broker, > but if the consumer is restarted, it loses it's state as well, and > subsequently gets the duplicates delivered. > Attached is a testcase that demonstrates the problem. It shows that with a > single producer doing commits after each send, it creates on additional > message in the broker with a duplicate MSGID_SEQ. If everything is committed > in one transaction, then every single message in the transaction is > duplicated (and not only the ones before the failover occurred). > The testcase uses an external MySQL instance though, and needs the DBCP and > the MySQL JDBC connector on the classpath (the pom is patched in the attached > file to resolve that automatically). > Out of the 6 tests, the following almost always fail on my machine: > testProducer_MasterFailoverByShutdown_AtRandomTimes_CommitPerMessage > (expected <6000>, but was <6001>) > testProducer_MasterFailoverByShutdown_AtRandomTimes_OneCommit (expected > <6000>, but was <12000>) > Rarely (3-5% of the cases) this one also fails: > testProducer_MasterFailoverByShutdown_SingleMsgCommit_AfterCommit (expected > <500>, but was <501>) > Other observations made: > 1) The problem seems to be a race condition because while trying to find the > cause through debugging, the problem disapeared when setting a break point in > TransactionInfo.visit(line:100). The race condition is met on my machine > (specs above) basically all the time without interaction (from maven, on the > shell with a build, inside eclipse debugged and normal). > 2) It seems that TransactionBroker.commitTransaction(line:100) is called once > with duplicated synchronizations (2x size). On the other hand > MemoryTransactionStore$Tx(line:109) is called twice with the correct amount > first, and later a doubled amount. > 3) The problem is not reproducible with Kaha, the problem is related to JDBC. > 4) It might be possible to have the testcase fail reliably with one of > Derby/HSQL/H2, but I didn't investigate. > 5) The testcase is not exactly very pretty, but it does show the problem ;) > 6) The attached testcase is a patch against activemq-core. > 7) The tests can be executed directly (in bash) with: > env MAVEN_OPTS="$MAVEN_OPTS -Xmx800M" mvn > -Dtest=org.apache.activemq.transport.failover.FailoverTransactionalTest test > 8) For MySQL the following should work: > SELECT > MSGID_PROD > ,MSGID_SEQ > FROM activemq_msgs > GROUP BY MSGID_PROD,MSGID_SEQ > HAVING ( COUNT(MSGID_SEQ) > 1 ); > 9) if you need the my.cnf for the database, I can attach that as well. > 10) The tables are correctly created as InnoDB > I think that's it... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-2286) NetworkConnector PrefetchSize
[ https://issues.apache.org/jira/browse/AMQ-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-2286: Labels: close-pending (was: ) > NetworkConnector PrefetchSize > - > > Key: AMQ-2286 > URL: https://issues.apache.org/jira/browse/AMQ-2286 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 > Environment: Sun solaris 10 >Reporter: ying >Priority: Major > Labels: close-pending > Fix For: 5.x > > > I have an issue which greatly reduces the quality of service of a network of > activemq brokers. > Here is what I have: > 1. 4 brokers( broker1, broker2, broker3, broker4) in a network by multicast > discovery > 2. i have 2 consumers of QueueA on broker1, 2 consumers of QueueA on broker2, > and consumer queuePrefetch=1, networkConnector prefetchSize=1. Queue is using > RoundRobinDispatchPolicy > 3. I publish to QueueA on broker3 with 100 msgs, 2 consumers on broker1 are > fast and they process fine but 2 consumers on broker2 are stuck. However, > with this config, msgs are still 50 goes to broker1, 50 goes to broker2, and > when consumers on broker2 get stuck, those 50 msgs are stuck on broker2. It > seems the prefetchSize=1 on networkConnector have no effect at all. > what I expect in this case will be that 98 msgs shall go to broker1, and only > 2 msgs stuck on broker2's consumers. I cannot lose a single msg so > ConstantPendingMessageLimit will not help. > Please help. Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-2286) NetworkConnector PrefetchSize
[ https://issues.apache.org/jira/browse/AMQ-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266243#comment-17266243 ] Matt Pavlovich commented on AMQ-2286: - [~yinghe0101]This issue has not been updated for some time. If there is still an issue, please retest with 5.16.1 and report back. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > NetworkConnector PrefetchSize > - > > Key: AMQ-2286 > URL: https://issues.apache.org/jira/browse/AMQ-2286 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 > Environment: Sun solaris 10 >Reporter: ying >Priority: Major > Fix For: 5.x > > > I have an issue which greatly reduces the quality of service of a network of > activemq brokers. > Here is what I have: > 1. 4 brokers( broker1, broker2, broker3, broker4) in a network by multicast > discovery > 2. i have 2 consumers of QueueA on broker1, 2 consumers of QueueA on broker2, > and consumer queuePrefetch=1, networkConnector prefetchSize=1. Queue is using > RoundRobinDispatchPolicy > 3. I publish to QueueA on broker3 with 100 msgs, 2 consumers on broker1 are > fast and they process fine but 2 consumers on broker2 are stuck. However, > with this config, msgs are still 50 goes to broker1, 50 goes to broker2, and > when consumers on broker2 get stuck, those 50 msgs are stuck on broker2. It > seems the prefetchSize=1 on networkConnector have no effect at all. > what I expect in this case will be that 98 msgs shall go to broker1, and only > 2 msgs stuck on broker2's consumers. I cannot lose a single msg so > ConstantPendingMessageLimit will not help. > Please help. Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-1999) XAException: POST COMMIT FAILED (NPE in Pure master/slave setup)
[ https://issues.apache.org/jira/browse/AMQ-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266239#comment-17266239 ] Matt Pavlovich commented on AMQ-1999: - This issue is most likely resolved in newer releases. JDBC features have had a number of fixes-- especially up through 5.16.1. If there is still an issue, please retest with 5.16.1 and report back. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > XAException: POST COMMIT FAILED (NPE in Pure master/slave setup) > > > Key: AMQ-1999 > URL: https://issues.apache.org/jira/browse/AMQ-1999 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 > Environment: Pure master/slave setup with 5.2.0-RC3 > java version "1.6.0_03" > JBoss 4.0.5 GA >Reporter: Hans Bausewein >Assignee: Gary Tully >Priority: Major > Fix For: 5.x > > Attachments: AMQ-1999.patch, activemq.xml, debug.log > > > On the master: > 2008-11-10 18:34:17,001 [44.161.71:41260] WARN XATransaction > - POST COMMIT FAILED: > java.lang.NullPointerException > at > org.apache.activemq.transaction.Transaction.fireAfterCommit(Transaction.java:87) > at > org.apache.activemq.transaction.XATransaction.doPostCommit(XATransaction.java:110) > at > org.apache.activemq.transaction.XATransaction.commit(XATransaction.java:65) > at > org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:170) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.ft.MasterBroker.commitTransaction(MasterBroker.java:285) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:413) > at > org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:305) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179) > at > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143) > at > org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) > at > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:203) > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:185) > at java.lang.Thread.run(Thread.java:619) > 2008-11-10 18:34:17,005 [44.161.71:41260] DEBUG Service > - Error occured while processing sync command: > javax.transaction.xa.XAException: POST COMMIT FAILED > javax.transaction.xa.XAException: POST COMMIT FAILED > at > org.apache.activemq.transaction.XATransaction.doPostCommit(XATransaction.java:115) > at > org.apache.activemq.transaction.XATransaction.commit(XATransaction.java:65) > at > org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:170) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.ft.MasterBroker.commitTransaction(MasterBroker.java:285) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:413) > at > org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:305) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179) > at > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143) > at >
[jira] [Updated] (AMQ-1999) XAException: POST COMMIT FAILED (NPE in Pure master/slave setup)
[ https://issues.apache.org/jira/browse/AMQ-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-1999: Labels: close-pending (was: ) > XAException: POST COMMIT FAILED (NPE in Pure master/slave setup) > > > Key: AMQ-1999 > URL: https://issues.apache.org/jira/browse/AMQ-1999 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 > Environment: Pure master/slave setup with 5.2.0-RC3 > java version "1.6.0_03" > JBoss 4.0.5 GA >Reporter: Hans Bausewein >Assignee: Gary Tully >Priority: Major > Labels: close-pending > Fix For: 5.x > > Attachments: AMQ-1999.patch, activemq.xml, debug.log > > > On the master: > 2008-11-10 18:34:17,001 [44.161.71:41260] WARN XATransaction > - POST COMMIT FAILED: > java.lang.NullPointerException > at > org.apache.activemq.transaction.Transaction.fireAfterCommit(Transaction.java:87) > at > org.apache.activemq.transaction.XATransaction.doPostCommit(XATransaction.java:110) > at > org.apache.activemq.transaction.XATransaction.commit(XATransaction.java:65) > at > org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:170) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.ft.MasterBroker.commitTransaction(MasterBroker.java:285) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:413) > at > org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:305) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179) > at > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143) > at > org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) > at > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:203) > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:185) > at java.lang.Thread.run(Thread.java:619) > 2008-11-10 18:34:17,005 [44.161.71:41260] DEBUG Service > - Error occured while processing sync command: > javax.transaction.xa.XAException: POST COMMIT FAILED > javax.transaction.xa.XAException: POST COMMIT FAILED > at > org.apache.activemq.transaction.XATransaction.doPostCommit(XATransaction.java:115) > at > org.apache.activemq.transaction.XATransaction.commit(XATransaction.java:65) > at > org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:170) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.ft.MasterBroker.commitTransaction(MasterBroker.java:285) > at > org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:101) > at > org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:413) > at > org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:305) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179) > at > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143) > at > org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) > at >
[jira] [Updated] (AMQ-1573) ConduitBridge merges destinations x.a and x.>, resulting in loss of subscription
[ https://issues.apache.org/jira/browse/AMQ-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-1573: Fix Version/s: AGING_TO_DIE > ConduitBridge merges destinations x.a and x.>, resulting in loss of > subscription > > > Key: AMQ-1573 > URL: https://issues.apache.org/jira/browse/AMQ-1573 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Marcus Nilsson >Assignee: Robert Davies >Priority: Major > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > Two brokers A <-> B. > 1. B subscribes to x.a and x.>. > 2. A registers subscription x.a in ConduitBridge > 3. A examines subscription x.> in ConduitBridge: > * A DestinationFilter is created for x.> > * The filter matches the old subscription for x.a > * Consumer B is added as "interested" in x.a > 4. Consumer on B will only receive messages for x.a, but not x.b. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-1573) ConduitBridge merges destinations x.a and x.>, resulting in loss of subscription
[ https://issues.apache.org/jira/browse/AMQ-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-1573: Labels: cl (was: ) > ConduitBridge merges destinations x.a and x.>, resulting in loss of > subscription > > > Key: AMQ-1573 > URL: https://issues.apache.org/jira/browse/AMQ-1573 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Marcus Nilsson >Assignee: Robert Davies >Priority: Major > Labels: cl > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > Two brokers A <-> B. > 1. B subscribes to x.a and x.>. > 2. A registers subscription x.a in ConduitBridge > 3. A examines subscription x.> in ConduitBridge: > * A DestinationFilter is created for x.> > * The filter matches the old subscription for x.a > * Consumer B is added as "interested" in x.a > 4. Consumer on B will only receive messages for x.a, but not x.b. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-1573) ConduitBridge merges destinations x.a and x.>, resulting in loss of subscription
[ https://issues.apache.org/jira/browse/AMQ-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-1573: Labels: close-pending (was: cl) > ConduitBridge merges destinations x.a and x.>, resulting in loss of > subscription > > > Key: AMQ-1573 > URL: https://issues.apache.org/jira/browse/AMQ-1573 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Marcus Nilsson >Assignee: Robert Davies >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > Two brokers A <-> B. > 1. B subscribes to x.a and x.>. > 2. A registers subscription x.a in ConduitBridge > 3. A examines subscription x.> in ConduitBridge: > * A DestinationFilter is created for x.> > * The filter matches the old subscription for x.a > * Consumer B is added as "interested" in x.a > 4. Consumer on B will only receive messages for x.a, but not x.b. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-1573) ConduitBridge merges destinations x.a and x.>, resulting in loss of subscription
[ https://issues.apache.org/jira/browse/AMQ-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266229#comment-17266229 ] Matt Pavlovich commented on AMQ-1573: - This issue is most likely resolved in newer releases. If there is still an issue, please retest with 5.16.1 and report back. NOTE: This JIRA is scheduled to close in 30 days if no update is provided. > ConduitBridge merges destinations x.a and x.>, resulting in loss of > subscription > > > Key: AMQ-1573 > URL: https://issues.apache.org/jira/browse/AMQ-1573 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Marcus Nilsson >Assignee: Robert Davies >Priority: Major > Fix For: NEEDS_REVIEW > > > Two brokers A <-> B. > 1. B subscribes to x.a and x.>. > 2. A registers subscription x.a in ConduitBridge > 3. A examines subscription x.> in ConduitBridge: > * A DestinationFilter is created for x.> > * The filter matches the old subscription for x.a > * Consumer B is added as "interested" in x.a > 4. Consumer on B will only receive messages for x.a, but not x.b. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQ-1350) JDBC master/slave does not work properly with datasources that can reconnect to the database
[ https://issues.apache.org/jira/browse/AMQ-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-1350. --- [~msiegenthaler] indicated issue was resolved with AMQ-1885. > JDBC master/slave does not work properly with datasources that can reconnect > to the database > > > Key: AMQ-1350 > URL: https://issues.apache.org/jira/browse/AMQ-1350 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.2.0 > Environment: Linux x86_64, Sun jdk 1.6, Postgresql 8.2.4, c3p0 or > other pooling datasources >Reporter: Eric Anderson >Priority: Major > Fix For: NEEDS_REVIEW > > Attachments: activemq-master-slave.patch > > > This problem involves the JDBC master/slave configuration when the db server > is restarted, or when the brokers lose their JDBC connections for whatever > reason temporarily, and when a datasource is in use that can re-establish > stale connections prior to providing them to the broker. > The problem lies with the JDBC locking strategy used to determine which > broker is master and which are slaves. Let's say there are two brokers, a > master and a slave, and they've successfully initialized. If you restart the > database server, the slave will throw an exception because it's just caught > an exception while blocked attempting to get the lock. The slave will then > *retry* the process of getting a lock over and over again. Now, since the > database was bounced, the *master* will have lost its lock in the > activemq_lock table. However, with the current 4.x-5.x code, it will never > "know" that it has lost the lock. There is no mechanism to check the lock > state. So it will continue to think that it is the master and will leave all > of its network connectors active. > When the slave tries to acquire the lock now, if the datasource has restored > connections to the now-restarted database server, it will succeed. The slave > will come up as master, and there will be two masters active concurrently. > Both masters should at this point be fully-functional, as both will have > datasources that can talk to the database server once again. > I have tested this with c3p0 and verified that I get two masters after > bouncing the database server. If, at that point, I kill the original slave > broker, the original master still appears to be functioning normally. If, > instead, I kill the original master broker, messages are still delivered via > the original slave (now co-master). It does not seem to matter which broker > the clients connect to - both work. > There is no workaround that I can think of that would function correctly > across multiple database bounces. If a slave's datasource does not have the > functionality to do database reconnects, then, after the first database > server restart, it will never be able to establish a connection to the db > server in order to attempt to acquire the lock. This, combined with the fact > that the JDBC master/slave topology does not have any favored brokers -- all > can be masters or slaves depending on start-up order and the failures that > have occurred over time, means that a datasource that can do reconnects is > required on all brokers. Therefore it would seem that in the JDBC > masters/slave topology a database restart or temporary loss of database > connectivity will always result in multiple masters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-1350) JDBC master/slave does not work properly with datasources that can reconnect to the database
[ https://issues.apache.org/jira/browse/AMQ-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich resolved AMQ-1350. - Resolution: Fixed > JDBC master/slave does not work properly with datasources that can reconnect > to the database > > > Key: AMQ-1350 > URL: https://issues.apache.org/jira/browse/AMQ-1350 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.2.0 > Environment: Linux x86_64, Sun jdk 1.6, Postgresql 8.2.4, c3p0 or > other pooling datasources >Reporter: Eric Anderson >Priority: Major > Fix For: NEEDS_REVIEW > > Attachments: activemq-master-slave.patch > > > This problem involves the JDBC master/slave configuration when the db server > is restarted, or when the brokers lose their JDBC connections for whatever > reason temporarily, and when a datasource is in use that can re-establish > stale connections prior to providing them to the broker. > The problem lies with the JDBC locking strategy used to determine which > broker is master and which are slaves. Let's say there are two brokers, a > master and a slave, and they've successfully initialized. If you restart the > database server, the slave will throw an exception because it's just caught > an exception while blocked attempting to get the lock. The slave will then > *retry* the process of getting a lock over and over again. Now, since the > database was bounced, the *master* will have lost its lock in the > activemq_lock table. However, with the current 4.x-5.x code, it will never > "know" that it has lost the lock. There is no mechanism to check the lock > state. So it will continue to think that it is the master and will leave all > of its network connectors active. > When the slave tries to acquire the lock now, if the datasource has restored > connections to the now-restarted database server, it will succeed. The slave > will come up as master, and there will be two masters active concurrently. > Both masters should at this point be fully-functional, as both will have > datasources that can talk to the database server once again. > I have tested this with c3p0 and verified that I get two masters after > bouncing the database server. If, at that point, I kill the original slave > broker, the original master still appears to be functioning normally. If, > instead, I kill the original master broker, messages are still delivered via > the original slave (now co-master). It does not seem to matter which broker > the clients connect to - both work. > There is no workaround that I can think of that would function correctly > across multiple database bounces. If a slave's datasource does not have the > functionality to do database reconnects, then, after the first database > server restart, it will never be able to establish a connection to the db > server in order to attempt to acquire the lock. This, combined with the fact > that the JDBC master/slave topology does not have any favored brokers -- all > can be masters or slaves depending on start-up order and the failures that > have occurred over time, means that a datasource that can do reconnects is > required on all brokers. Therefore it would seem that in the JDBC > masters/slave topology a database restart or temporary loss of database > connectivity will always result in multiple masters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-8051) FQDN with character "_" fails to start the active mq
[
https://issues.apache.org/jira/browse/AMQ-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich resolved AMQ-8051.
-
Resolution: Not A Problem
> FQDN with character "_" fails to start the active mq
>
>
> Key: AMQ-8051
> URL: https://issues.apache.org/jira/browse/AMQ-8051
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.13.2
>Reporter: rajiv devaraj
>Assignee: Matt Pavlovich
>Priority: Major
>
> Unable to start active mq with fqdn having ("_") character in it . for ex :
> JMX consoles can connect to
> service:jmx:rmi:///jndi/rmi://domainname_1.com:2099/jmxrmi |
> org.apache.activemq.broker.jmx.ManagementContext | JMX connector
>
> Note : /etc/hosts are properly configured and activemq able to launch with
> fqdn without ("_")
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (AMQ-8051) FQDN with character "_" fails to start the active mq
[
https://issues.apache.org/jira/browse/AMQ-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich closed AMQ-8051.
---
Closing this issue due to inactivity. To re-open, please test with 5.16.1 or
newer.
> FQDN with character "_" fails to start the active mq
>
>
> Key: AMQ-8051
> URL: https://issues.apache.org/jira/browse/AMQ-8051
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.13.2
>Reporter: rajiv devaraj
>Assignee: Matt Pavlovich
>Priority: Major
>
> Unable to start active mq with fqdn having ("_") character in it . for ex :
> JMX consoles can connect to
> service:jmx:rmi:///jndi/rmi://domainname_1.com:2099/jmxrmi |
> org.apache.activemq.broker.jmx.ManagementContext | JMX connector
>
> Note : /etc/hosts are properly configured and activemq able to launch with
> fqdn without ("_")
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3069) Add option to mask using the configured password-codec
[ https://issues.apache.org/jira/browse/ARTEMIS-3069?focusedWorklogId=536550=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536550 ] ASF GitHub Bot logged work on ARTEMIS-3069: --- Author: ASF GitHub Bot Created on: 15/Jan/21 16:55 Start Date: 15/Jan/21 16:55 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request #3409: URL: https://github.com/apache/activemq-artemis/pull/3409 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 536550) Remaining Estimate: 0h Time Spent: 10m > Add option to mask using the configured password-codec > -- > > Key: ARTEMIS-3069 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3069 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Artemis documentation describes how to implement and configure a custom codec > class by extending the SensitiveDataCodec class, adding the new class to the > classpath, and configuring a custom-codec element in the broker > configuration; however, there does not seem to be any provision in the > masking utility classes to retrieve and use the custom codec. Instead, the > masking utility is hard-coded to return the DefaultSensitiveStringCodec > bundled with the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-3069) Add option to mask using the configured password-codec
[ https://issues.apache.org/jira/browse/ARTEMIS-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino reassigned ARTEMIS-3069: Assignee: Domenico Francesco Bruscino > Add option to mask using the configured password-codec > -- > > Key: ARTEMIS-3069 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3069 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > > Artemis documentation describes how to implement and configure a custom codec > class by extending the SensitiveDataCodec class, adding the new class to the > classpath, and configuring a custom-codec element in the broker > configuration; however, there does not seem to be any provision in the > masking utility classes to retrieve and use the custom codec. Instead, the > masking utility is hard-coded to return the DefaultSensitiveStringCodec > bundled with the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3069) Add option to mask using the configured password-codec
Domenico Francesco Bruscino created ARTEMIS-3069: Summary: Add option to mask using the configured password-codec Key: ARTEMIS-3069 URL: https://issues.apache.org/jira/browse/ARTEMIS-3069 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Francesco Bruscino Artemis documentation describes how to implement and configure a custom codec class by extending the SensitiveDataCodec class, adding the new class to the classpath, and configuring a custom-codec element in the broker configuration; however, there does not seem to be any provision in the masking utility classes to retrieve and use the custom codec. Instead, the masking utility is hard-coded to return the DefaultSensitiveStringCodec bundled with the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7005) Client OSGI bundle without dependencies
[ https://issues.apache.org/jira/browse/AMQ-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266148#comment-17266148 ] Matt Pavlovich commented on AMQ-7005: - Will come back to this after the 5.17.0 work is done to reduce first-pass of dependencies (leveldb, joda-time, etc) > Client OSGI bundle without dependencies > --- > > Key: AMQ-7005 > URL: https://issues.apache.org/jira/browse/AMQ-7005 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Affects Versions: 5.15.4 >Reporter: Vladimir Konkov >Priority: Major > > Current OSGI megabundle activemq-osgi requires many dependencies: > - spring 4.x (and no 3 or 5) > - blueprint > - commons Lang, Pool, Collections > - Jackson > > And many more, in total 20+ bundles for Karaf 4.2.0 and ActiveMQ 5.15.4 . > It's too much for JMS client module. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch
[
https://issues.apache.org/jira/browse/AMQ-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-7072:
Affects Version/s: 5.16.0
> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.16.0
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B
> spec is out and implemented by both I guess it can be the way to solve that
> issue.
> The most blocking thing is
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
> - which can already not create a mapper if json is empty ;) - but here is
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-6941) Add option to allow anonymous vm://xxx connections
[ https://issues.apache.org/jira/browse/AMQ-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-6941: Affects Version/s: 5.11.4 > Add option to allow anonymous vm://xxx connections > -- > > Key: AMQ-6941 > URL: https://issues.apache.org/jira/browse/AMQ-6941 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.11.4 >Reporter: Quinn Stevenson >Priority: Minor > > When deploying JMS components in the same JVM as an ActiveMQ broker, it would > be really nice to allow vm://broker-name connections to connect without a > username/password. > Either a new plugin could be added, or the Simple Authentication Plugin could > be enhanced. > There is a sample of a plugin that provides the basic functionality in my > Github repository > [https://github.com/hqstevenson/splunk-jms-activemq/tree/master/src/main/java/com/pronoia/splunk/jms/activemq/util] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-6941) Add option to allow anonymous vm://xxx connections
[ https://issues.apache.org/jira/browse/AMQ-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266145#comment-17266145 ] Matt Pavlovich commented on AMQ-6941: - Do anonymous users not work for you? I'm not following the root cause, what's blocking it in ActiveMQ and what approach would solve it. > Add option to allow anonymous vm://xxx connections > -- > > Key: AMQ-6941 > URL: https://issues.apache.org/jira/browse/AMQ-6941 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > When deploying JMS components in the same JVM as an ActiveMQ broker, it would > be really nice to allow vm://broker-name connections to connect without a > username/password. > Either a new plugin could be added, or the Simple Authentication Plugin could > be enhanced. > There is a sample of a plugin that provides the basic functionality in my > Github repository > [https://github.com/hqstevenson/splunk-jms-activemq/tree/master/src/main/java/com/pronoia/splunk/jms/activemq/util] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-6951) Hide embedded jetty version
[
https://issues.apache.org/jira/browse/AMQ-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-6951:
Fix Version/s: 5.17.0
> Hide embedded jetty version
> ---
>
> Key: AMQ-6951
> URL: https://issues.apache.org/jira/browse/AMQ-6951
> Project: ActiveMQ
> Issue Type: New Feature
>Reporter: Marcos Moreno Martin
>Assignee: Matt Pavlovich
>Priority: Major
> Fix For: 5.17.0, 5.15.15, 5.16.2
>
>
> Hi,
> sorry in advance if this is something easy for jetty experts. We need some
> guidance or see if hiding the embedded jetty configuration is possible.
> We have not seen anywhere in the documentation how to hide the embedded jetty
> version. This is marked as a security thread by our penetration testers when
> we are using a web sockets transport on port 80. We have been playing around
> with the configuration file jetty.xml and the parameters, but no success. It
> has been addressed for other projects (see
> https://issues.apache.org/jira/browse/HADOOP-13414)
> So far we have been trying to change the configuration in jetty.xml.
> As far as we know, this should be the configuration for the property:
> {code:java}
>
>
>
>
> {code}
> However, this has no effect in the exposing of the version. We tried further
> and tried with a connection factory, but this also had no effect:
> {code:java}
> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>
>
>
>
>
>
>
>
>class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Are we on the right track, or does it need to be addressed by the codebase of
> ActiveMQ?
> This is how we show the version:
> {code:java}
> #nmap -sV -p80 localhost
> Starting Nmap 7.70 ( https://nmap.org ) at 2018-04-23 18:16 CEST
> Nmap scan report for localhost (127.0.0.1)
> Host is up (0.98s latency).
> PORT STATE SERVICE VERSION
> 80/tcp open http Jetty 9.2.22.v20170606
> Service detection performed. Please report any incorrect results at
> https://nmap.org/submit/ .
> Nmap done: 1 IP address (1 host up) scanned in 11.34 seconds
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-7005) Client OSGI bundle without dependencies
[ https://issues.apache.org/jira/browse/AMQ-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-7005: Affects Version/s: 5.15.4 > Client OSGI bundle without dependencies > --- > > Key: AMQ-7005 > URL: https://issues.apache.org/jira/browse/AMQ-7005 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Affects Versions: 5.15.4 >Reporter: Vladimir Konkov >Priority: Major > > Current OSGI megabundle activemq-osgi requires many dependencies: > - spring 4.x (and no 3 or 5) > - blueprint > - commons Lang, Pool, Collections > - Jackson > > And many more, in total 20+ bundles for Karaf 4.2.0 and ActiveMQ 5.15.4 . > It's too much for JMS client module. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (AMQ-6951) Hide embedded jetty version
[
https://issues.apache.org/jira/browse/AMQ-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich reassigned AMQ-6951:
---
Assignee: Matt Pavlovich
> Hide embedded jetty version
> ---
>
> Key: AMQ-6951
> URL: https://issues.apache.org/jira/browse/AMQ-6951
> Project: ActiveMQ
> Issue Type: New Feature
>Reporter: Marcos Moreno Martin
>Assignee: Matt Pavlovich
>Priority: Major
> Fix For: 5.15.15, 5.16.2
>
>
> Hi,
> sorry in advance if this is something easy for jetty experts. We need some
> guidance or see if hiding the embedded jetty configuration is possible.
> We have not seen anywhere in the documentation how to hide the embedded jetty
> version. This is marked as a security thread by our penetration testers when
> we are using a web sockets transport on port 80. We have been playing around
> with the configuration file jetty.xml and the parameters, but no success. It
> has been addressed for other projects (see
> https://issues.apache.org/jira/browse/HADOOP-13414)
> So far we have been trying to change the configuration in jetty.xml.
> As far as we know, this should be the configuration for the property:
> {code:java}
>
>
>
>
> {code}
> However, this has no effect in the exposing of the version. We tried further
> and tried with a connection factory, but this also had no effect:
> {code:java}
> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>
>
>
>
>
>
>
>
>class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Are we on the right track, or does it need to be addressed by the codebase of
> ActiveMQ?
> This is how we show the version:
> {code:java}
> #nmap -sV -p80 localhost
> Starting Nmap 7.70 ( https://nmap.org ) at 2018-04-23 18:16 CEST
> Nmap scan report for localhost (127.0.0.1)
> Host is up (0.98s latency).
> PORT STATE SERVICE VERSION
> 80/tcp open http Jetty 9.2.22.v20170606
> Service detection performed. Please report any incorrect results at
> https://nmap.org/submit/ .
> Nmap done: 1 IP address (1 host up) scanned in 11.34 seconds
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-8123) Add jaxb-core, istack, ... for runtimeConfigurationPlugin without broker started
[ https://issues.apache.org/jira/browse/AMQ-8123?focusedWorklogId=536540=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536540 ] ASF GitHub Bot logged work on AMQ-8123: --- Author: ASF GitHub Bot Created on: 15/Jan/21 15:47 Start Date: 15/Jan/21 15:47 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request #612: URL: https://github.com/apache/activemq/pull/612 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 536540) Remaining Estimate: 0h Time Spent: 10m > Add jaxb-core, istack, ... for runtimeConfigurationPlugin without broker > started > > > Key: AMQ-8123 > URL: https://issues.apache.org/jira/browse/AMQ-8123 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Plugin >Affects Versions: 5.16.1 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.15.15, 5.16.2 > > Time Spent: 10m > Remaining Estimate: 0h > > In order to work with any JDK version (JDK8, JDK9, JDK11+), and avoid > classloading issue, the runtimeConfigurationPlugin needs jaxb-core and > itstack-commons-runtime in the classloader. This is especially required with > broker start attribute is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-6951) Hide embedded jetty version
[
https://issues.apache.org/jira/browse/AMQ-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266137#comment-17266137
]
Matt Pavlovich commented on AMQ-6951:
-
{noformat}
httpConfiguration.setSendServerVersion(false);
{noformat}
> Hide embedded jetty version
> ---
>
> Key: AMQ-6951
> URL: https://issues.apache.org/jira/browse/AMQ-6951
> Project: ActiveMQ
> Issue Type: New Feature
>Reporter: Marcos Moreno Martin
>Priority: Major
> Fix For: 5.15.15, 5.16.2
>
>
> Hi,
> sorry in advance if this is something easy for jetty experts. We need some
> guidance or see if hiding the embedded jetty configuration is possible.
> We have not seen anywhere in the documentation how to hide the embedded jetty
> version. This is marked as a security thread by our penetration testers when
> we are using a web sockets transport on port 80. We have been playing around
> with the configuration file jetty.xml and the parameters, but no success. It
> has been addressed for other projects (see
> https://issues.apache.org/jira/browse/HADOOP-13414)
> So far we have been trying to change the configuration in jetty.xml.
> As far as we know, this should be the configuration for the property:
> {code:java}
>
>
>
>
> {code}
> However, this has no effect in the exposing of the version. We tried further
> and tried with a connection factory, but this also had no effect:
> {code:java}
> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>
>
>
>
>
>
>
>
>class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Are we on the right track, or does it need to be addressed by the codebase of
> ActiveMQ?
> This is how we show the version:
> {code:java}
> #nmap -sV -p80 localhost
> Starting Nmap 7.70 ( https://nmap.org ) at 2018-04-23 18:16 CEST
> Nmap scan report for localhost (127.0.0.1)
> Host is up (0.98s latency).
> PORT STATE SERVICE VERSION
> 80/tcp open http Jetty 9.2.22.v20170606
> Service detection performed. Please report any incorrect results at
> https://nmap.org/submit/ .
> Nmap done: 1 IP address (1 host up) scanned in 11.34 seconds
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-6951) Hide embedded jetty version
[
https://issues.apache.org/jira/browse/AMQ-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-6951:
Fix Version/s: 5.16.2
5.15.15
> Hide embedded jetty version
> ---
>
> Key: AMQ-6951
> URL: https://issues.apache.org/jira/browse/AMQ-6951
> Project: ActiveMQ
> Issue Type: New Feature
>Reporter: Marcos Moreno Martin
>Priority: Major
> Fix For: 5.15.15, 5.16.2
>
>
> Hi,
> sorry in advance if this is something easy for jetty experts. We need some
> guidance or see if hiding the embedded jetty configuration is possible.
> We have not seen anywhere in the documentation how to hide the embedded jetty
> version. This is marked as a security thread by our penetration testers when
> we are using a web sockets transport on port 80. We have been playing around
> with the configuration file jetty.xml and the parameters, but no success. It
> has been addressed for other projects (see
> https://issues.apache.org/jira/browse/HADOOP-13414)
> So far we have been trying to change the configuration in jetty.xml.
> As far as we know, this should be the configuration for the property:
> {code:java}
>
>
>
>
> {code}
> However, this has no effect in the exposing of the version. We tried further
> and tried with a connection factory, but this also had no effect:
> {code:java}
> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>
>
>
>
>
>
>
>
>class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Are we on the right track, or does it need to be addressed by the codebase of
> ActiveMQ?
> This is how we show the version:
> {code:java}
> #nmap -sV -p80 localhost
> Starting Nmap 7.70 ( https://nmap.org ) at 2018-04-23 18:16 CEST
> Nmap scan report for localhost (127.0.0.1)
> Host is up (0.98s latency).
> PORT STATE SERVICE VERSION
> 80/tcp open http Jetty 9.2.22.v20170606
> Service detection performed. Please report any incorrect results at
> https://nmap.org/submit/ .
> Nmap done: 1 IP address (1 host up) scanned in 11.34 seconds
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (AMQ-6399) Log a warning when starting a networkConnector with static:failover without using maxReconnectAttempts=0
[ https://issues.apache.org/jira/browse/AMQ-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-6399. --- Closing this issue due to inactivity. To re-open, please test with 5.16.1 or newer. > Log a warning when starting a networkConnector with static:failover without > using maxReconnectAttempts=0 > > > Key: AMQ-6399 > URL: https://issues.apache.org/jira/browse/AMQ-6399 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.0.0 >Reporter: Tim Bain >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > > When configuring a networkConnector using the static:failover: transport, > you'll be unable to failover if you don't specify the maxReconnectAttempts=0 > option on the failover transport. > We periodically see users on the mailing list getting tripped up by this, > since it's not intuitive or obvious. One option would be to simply refuse to > start the broker when this happens (since there probably isn't a valid reason > to configure a networkConnector that way), but since that's probably too > draconian, we should instead log a warning that tells the user that this is > probably not what they want so they can fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-6399) Log a warning when starting a networkConnector with static:failover without using maxReconnectAttempts=0
[ https://issues.apache.org/jira/browse/AMQ-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich resolved AMQ-6399. - Resolution: Abandoned > Log a warning when starting a networkConnector with static:failover without > using maxReconnectAttempts=0 > > > Key: AMQ-6399 > URL: https://issues.apache.org/jira/browse/AMQ-6399 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.0.0 >Reporter: Tim Bain >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > > When configuring a networkConnector using the static:failover: transport, > you'll be unable to failover if you don't specify the maxReconnectAttempts=0 > option on the failover transport. > We periodically see users on the mailing list getting tripped up by this, > since it's not intuitive or obvious. One option would be to simply refuse to > start the broker when this happens (since there probably isn't a valid reason > to configure a networkConnector that way), but since that's probably too > draconian, we should instead log a warning that tells the user that this is > probably not what they want so they can fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-6399) Log a warning when starting a networkConnector with static:failover without using maxReconnectAttempts=0
[ https://issues.apache.org/jira/browse/AMQ-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-6399: Fix Version/s: AGING_TO_DIE > Log a warning when starting a networkConnector with static:failover without > using maxReconnectAttempts=0 > > > Key: AMQ-6399 > URL: https://issues.apache.org/jira/browse/AMQ-6399 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.0.0 >Reporter: Tim Bain >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > > When configuring a networkConnector using the static:failover: transport, > you'll be unable to failover if you don't specify the maxReconnectAttempts=0 > option on the failover transport. > We periodically see users on the mailing list getting tripped up by this, > since it's not intuitive or obvious. One option would be to simply refuse to > start the broker when this happens (since there probably isn't a valid reason > to configure a networkConnector that way), but since that's probably too > draconian, we should instead log a warning that tells the user that this is > probably not what they want so they can fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-6660) Deadlock closing a connection due to an exception
[
https://issues.apache.org/jira/browse/AMQ-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich resolved AMQ-6660.
-
Fix Version/s: AGING_TO_DIE
Resolution: Abandoned
> Deadlock closing a connection due to an exception
> -
>
> Key: AMQ-6660
> URL: https://issues.apache.org/jira/browse/AMQ-6660
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.8.0
>Reporter: Dan Groves
>Assignee: Matt Pavlovich
>Priority: Major
> Labels: close-pending
> Fix For: AGING_TO_DIE
>
>
> While recovering from a period of network instability, our application
> deadlocked in ActiveMQ code.
> {noformat}
> Found one Java-level deadlock:
> =
> "ActiveMQ Connection Executor: tcp:///:61616@51026":
> waiting to lock monitor 0x7f60fc0060b8 (object 0x000773f00308, a
> java.lang.Object),
> which is held by "privateJmsInPriority.container-1"
> "privateJmsInPriority.container-1":
> waiting to lock monitor 0x7f610840dbc8 (object 0x000773f99930, a
> org.apache.activemq.ActiveMQConnection),
> which is held by "ActiveMQ Connection Executor: tcp:/// address>:61616@51026"
> Java stack information for the threads listed above:
> ===
> "ActiveMQ Connection Executor: tcp:///:61616@51026":
> at
> org.apache.activemq.SimplePriorityMessageDispatchChannel.close(SimplePriorityMessageDispatchChannel.java:154)
> - waiting to lock <0x000773f00308> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQMessageConsumer.dispose(ActiveMQMessageConsumer.java:800)
> at
> org.apache.activemq.ActiveMQSession.dispose(ActiveMQSession.java:689)
> - locked <0x000773f003d8> (a org.apache.activemq.ActiveMQSession)
> at
> org.apache.activemq.ActiveMQConnection.close(ActiveMQConnection.java:659)
> - locked <0x000773f99930> (a
> org.apache.activemq.ActiveMQConnection)
> at
> org.springframework.jms.connection.SingleConnectionFactory.closeConnection(SingleConnectionFactory.java:456)
> at
> org.springframework.jms.connection.SingleConnectionFactory.resetConnection(SingleConnectionFactory.java:345)
> - locked <0x000773f9a590> (a java.lang.Object)
> at
> org.springframework.jms.connection.CachingConnectionFactory.resetConnection(CachingConnectionFactory.java:207)
> at
> org.springframework.jms.connection.SingleConnectionFactory.onException(SingleConnectionFactory.java:323)
> at
> org.springframework.jms.connection.SingleConnectionFactory$AggregatedExceptionListener.onException(SingleConnectionFactory.java:673)
> - locked <0x000773f9a590> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQConnection$5.run(ActiveMQConnection.java:1976)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "privateJmsInPriority.container-1":
> at
> org.apache.activemq.ActiveMQConnection.getScheduler(ActiveMQConnection.java:2519)
> - waiting to lock <0x000773f99930> (a
> org.apache.activemq.ActiveMQConnection)
> at
> org.apache.activemq.ActiveMQSession.getScheduler(ActiveMQSession.java:2074)
> at
> org.apache.activemq.ActiveMQMessageConsumer.rollback(ActiveMQMessageConsumer.java:1241)
> - locked <0x000773f01030> (a java.util.LinkedList)
> - locked <0x000773f00308> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQMessageConsumer$5.afterRollback(ActiveMQMessageConsumer.java:1032)
> at
> org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:157)
> at
> org.apache.activemq.TransactionContext.commit(TransactionContext.java:332)
> at
> org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:561)
> at sun.reflect.GeneratedMethodAccessor897.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:386)
> at com.sun.proxy.$Proxy49.commit(Unknown Source)
> at
> org.springframework.jms.support.JmsUtils.commitIfNecessary(JmsUtils.java:217)
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.commitIfNecessary(AbstractMessageListenerContainer.java:761)
> at
>
[jira] [Closed] (AMQ-6660) Deadlock closing a connection due to an exception
[
https://issues.apache.org/jira/browse/AMQ-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich closed AMQ-6660.
---
Closing this issue due to inactivity. To re-open, please test with 5.16.1 or
newer.
> Deadlock closing a connection due to an exception
> -
>
> Key: AMQ-6660
> URL: https://issues.apache.org/jira/browse/AMQ-6660
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.8.0
>Reporter: Dan Groves
>Assignee: Matt Pavlovich
>Priority: Major
> Labels: close-pending
> Fix For: AGING_TO_DIE
>
>
> While recovering from a period of network instability, our application
> deadlocked in ActiveMQ code.
> {noformat}
> Found one Java-level deadlock:
> =
> "ActiveMQ Connection Executor: tcp:///:61616@51026":
> waiting to lock monitor 0x7f60fc0060b8 (object 0x000773f00308, a
> java.lang.Object),
> which is held by "privateJmsInPriority.container-1"
> "privateJmsInPriority.container-1":
> waiting to lock monitor 0x7f610840dbc8 (object 0x000773f99930, a
> org.apache.activemq.ActiveMQConnection),
> which is held by "ActiveMQ Connection Executor: tcp:/// address>:61616@51026"
> Java stack information for the threads listed above:
> ===
> "ActiveMQ Connection Executor: tcp:///:61616@51026":
> at
> org.apache.activemq.SimplePriorityMessageDispatchChannel.close(SimplePriorityMessageDispatchChannel.java:154)
> - waiting to lock <0x000773f00308> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQMessageConsumer.dispose(ActiveMQMessageConsumer.java:800)
> at
> org.apache.activemq.ActiveMQSession.dispose(ActiveMQSession.java:689)
> - locked <0x000773f003d8> (a org.apache.activemq.ActiveMQSession)
> at
> org.apache.activemq.ActiveMQConnection.close(ActiveMQConnection.java:659)
> - locked <0x000773f99930> (a
> org.apache.activemq.ActiveMQConnection)
> at
> org.springframework.jms.connection.SingleConnectionFactory.closeConnection(SingleConnectionFactory.java:456)
> at
> org.springframework.jms.connection.SingleConnectionFactory.resetConnection(SingleConnectionFactory.java:345)
> - locked <0x000773f9a590> (a java.lang.Object)
> at
> org.springframework.jms.connection.CachingConnectionFactory.resetConnection(CachingConnectionFactory.java:207)
> at
> org.springframework.jms.connection.SingleConnectionFactory.onException(SingleConnectionFactory.java:323)
> at
> org.springframework.jms.connection.SingleConnectionFactory$AggregatedExceptionListener.onException(SingleConnectionFactory.java:673)
> - locked <0x000773f9a590> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQConnection$5.run(ActiveMQConnection.java:1976)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "privateJmsInPriority.container-1":
> at
> org.apache.activemq.ActiveMQConnection.getScheduler(ActiveMQConnection.java:2519)
> - waiting to lock <0x000773f99930> (a
> org.apache.activemq.ActiveMQConnection)
> at
> org.apache.activemq.ActiveMQSession.getScheduler(ActiveMQSession.java:2074)
> at
> org.apache.activemq.ActiveMQMessageConsumer.rollback(ActiveMQMessageConsumer.java:1241)
> - locked <0x000773f01030> (a java.util.LinkedList)
> - locked <0x000773f00308> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQMessageConsumer$5.afterRollback(ActiveMQMessageConsumer.java:1032)
> at
> org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:157)
> at
> org.apache.activemq.TransactionContext.commit(TransactionContext.java:332)
> at
> org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:561)
> at sun.reflect.GeneratedMethodAccessor897.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:386)
> at com.sun.proxy.$Proxy49.commit(Unknown Source)
> at
> org.springframework.jms.support.JmsUtils.commitIfNecessary(JmsUtils.java:217)
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.commitIfNecessary(AbstractMessageListenerContainer.java:761)
> at
>
[jira] [Closed] (AMQ-762) Message Group based load balancing not well distributed across brokers
[ https://issues.apache.org/jira/browse/AMQ-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-762. -- Closing due to age > Message Group based load balancing not well distributed across brokers > -- > > Key: AMQ-762 > URL: https://issues.apache.org/jira/browse/AMQ-762 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 4.0 > Environment: Active MQ 4.0, Lingo 1.1 >Reporter: Sanjiv Jivan >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > Attachments: ASF.LICENSE.NOT.GRANTED--lingocluster.zip > > > I started 2 servers, each of which have an embedded broker. A shell based > chield sends messages to 30 different message groups (using command "register > " in the samepl app provided. Only 2 mesages are received by > server1, 3 by server2 and 25 by server3. The load balancing distribution is > highly unenen. > As suggested, I also tried setting a low destination queue prefetch value > (consumer.prefetch=1) but the result was the same. > To run sample : > 1. Unzip attached file and run "maven.bat" from the oot directory (Maven 1.0) > 2. Open 3 DOS boxes in the dist\bin folder and run > "startoptimizerPooled.bat", "startOptimizerPooled2.bat" and > "startOptimizerPooled3.bat" in each DOS box respectively. > 3. Step 2 starts a network of 3 servers apps which have an embedded broker. > The Spring configuration files for each of these servers is in the dist\conf > directory. > 4. Open another DOS box in dist\bin and start a test client by running > "startClientShell.bat" > 5. This command driver test client accepts commads in the form > "register " > "close " > and "exit" > NOTE: The command "close " is supposed to close/reset the > message group by issueing a "JMSXGroupSeq" header as described here : > http://www.activemq.org/site/message-groups.html > 6. Try sending several messages to the server by issuing several commands > like "regeister A", "register B", "register C" and so on.. You'll see the > highly uneven distibution of messages. Only one or two messages are received > my 2 servers while the third one receives a majority of the messages. > Please let me know if you have trouble running the sample or replicating the > issue. > Thanks, > Sanjiv -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-762) Message Group based load balancing not well distributed across brokers
[ https://issues.apache.org/jira/browse/AMQ-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266124#comment-17266124 ] Matt Pavlovich commented on AMQ-762: Closing this issue due to inactivity. To re-open, please test with 5.16.1 or newer. > Message Group based load balancing not well distributed across brokers > -- > > Key: AMQ-762 > URL: https://issues.apache.org/jira/browse/AMQ-762 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 4.0 > Environment: Active MQ 4.0, Lingo 1.1 >Reporter: Sanjiv Jivan >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: 5.x > > Attachments: ASF.LICENSE.NOT.GRANTED--lingocluster.zip > > > I started 2 servers, each of which have an embedded broker. A shell based > chield sends messages to 30 different message groups (using command "register > " in the samepl app provided. Only 2 mesages are received by > server1, 3 by server2 and 25 by server3. The load balancing distribution is > highly unenen. > As suggested, I also tried setting a low destination queue prefetch value > (consumer.prefetch=1) but the result was the same. > To run sample : > 1. Unzip attached file and run "maven.bat" from the oot directory (Maven 1.0) > 2. Open 3 DOS boxes in the dist\bin folder and run > "startoptimizerPooled.bat", "startOptimizerPooled2.bat" and > "startOptimizerPooled3.bat" in each DOS box respectively. > 3. Step 2 starts a network of 3 servers apps which have an embedded broker. > The Spring configuration files for each of these servers is in the dist\conf > directory. > 4. Open another DOS box in dist\bin and start a test client by running > "startClientShell.bat" > 5. This command driver test client accepts commads in the form > "register " > "close " > and "exit" > NOTE: The command "close " is supposed to close/reset the > message group by issueing a "JMSXGroupSeq" header as described here : > http://www.activemq.org/site/message-groups.html > 6. Try sending several messages to the server by issuing several commands > like "regeister A", "register B", "register C" and so on.. You'll see the > highly uneven distibution of messages. Only one or two messages are received > my 2 servers while the third one receives a majority of the messages. > Please let me know if you have trouble running the sample or replicating the > issue. > Thanks, > Sanjiv -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-1660. --- Closing for real this time > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-762) Message Group based load balancing not well distributed across brokers
[ https://issues.apache.org/jira/browse/AMQ-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich resolved AMQ-762. Fix Version/s: (was: 5.x) AGING_TO_DIE Resolution: Abandoned > Message Group based load balancing not well distributed across brokers > -- > > Key: AMQ-762 > URL: https://issues.apache.org/jira/browse/AMQ-762 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 4.0 > Environment: Active MQ 4.0, Lingo 1.1 >Reporter: Sanjiv Jivan >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > Attachments: ASF.LICENSE.NOT.GRANTED--lingocluster.zip > > > I started 2 servers, each of which have an embedded broker. A shell based > chield sends messages to 30 different message groups (using command "register > " in the samepl app provided. Only 2 mesages are received by > server1, 3 by server2 and 25 by server3. The load balancing distribution is > highly unenen. > As suggested, I also tried setting a low destination queue prefetch value > (consumer.prefetch=1) but the result was the same. > To run sample : > 1. Unzip attached file and run "maven.bat" from the oot directory (Maven 1.0) > 2. Open 3 DOS boxes in the dist\bin folder and run > "startoptimizerPooled.bat", "startOptimizerPooled2.bat" and > "startOptimizerPooled3.bat" in each DOS box respectively. > 3. Step 2 starts a network of 3 servers apps which have an embedded broker. > The Spring configuration files for each of these servers is in the dist\conf > directory. > 4. Open another DOS box in dist\bin and start a test client by running > "startClientShell.bat" > 5. This command driver test client accepts commads in the form > "register " > "close " > and "exit" > NOTE: The command "close " is supposed to close/reset the > message group by issueing a "JMSXGroupSeq" header as described here : > http://www.activemq.org/site/message-groups.html > 6. Try sending several messages to the server by issuing several commands > like "regeister A", "register B", "register C" and so on.. You'll see the > highly uneven distibution of messages. Only one or two messages are received > my 2 servers while the third one receives a majority of the messages. > Please let me know if you have trouble running the sample or replicating the > issue. > Thanks, > Sanjiv -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich resolved AMQ-1660. - Resolution: Abandoned > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich reopened AMQ-1660: - Doh.. didn't apply correct closing status > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-1660. --- Resolution: Fixed > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-1660: Fix Version/s: NEEDS_REVIEW > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW, AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-1126) The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs
[ https://issues.apache.org/jira/browse/AMQ-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266117#comment-17266117 ] Matt Pavlovich commented on AMQ-1126: - Closing this issue due to inactivity. To re-open, please test with 5.16.1 or newer. > The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs > - > > Key: AMQ-1126 > URL: https://issues.apache.org/jira/browse/AMQ-1126 > Project: ActiveMQ > Issue Type: Bug > Components: JCA Container >Affects Versions: 4.0.1 > Environment: Java 1.4.2_08 > JBoss 4.0.4 > ActiveMQ 4.0.1 >Reporter: John Robinson >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW > > Attachments: amq_reproducer.zip, msg-group-test.zip > > > Integrate AMQ into JBoss using the data source, and resource adapter. Create > an outbound queue and an MDB with a pool size of 100. Dispatch several > messages to the outbound queue, setting the JMSXGroupID property on the > message to be the same value each time. In the MDB's onMessage method print > out the MDBs toString (don't override toString) and you should see something > that looks like: > OutQueueProcessorBean@19a7266 > Observe two things: > a) Many messages are processed in parallel > b) Many different values will occur after the @ in the above message, > denoting that more than on MDB instance is being handed messages. > The correct behavior would be to dispatch messages with the same group id to > the same MDB instance in sequence. This would allow messages from different > groups to be processed in parallel, but messages in any one group would be > processed serially, in the order in which they were placed into the queue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich resolved AMQ-1660. - Resolution: Abandoned > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-1660. --- Closing due to age > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-1660: Fix Version/s: (was: NEEDS_REVIEW) AGING_TO_DIE > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: AGING_TO_DIE > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-1660) Scheduled Failover
[ https://issues.apache.org/jira/browse/AMQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266115#comment-17266115 ] Matt Pavlovich commented on AMQ-1660: - Closing this issue due to inactivity. To re-open, please test with 5.16.1 or newer. > Scheduled Failover > -- > > Key: AMQ-1660 > URL: https://issues.apache.org/jira/browse/AMQ-1660 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1.1, 5.0.0 > Environment: all platforms that support a running standalone broker >Reporter: Rob Bugh >Assignee: Matt Pavlovich >Priority: Major > Labels: close-pending > Fix For: NEEDS_REVIEW > > > I am using a JDBC Master/Slave topology. I'm using Postgres as the db and > noticed that due to the long running transaction of the master holding the > lock on the activemq_lock table my vacuums are not cleaning as many dead > tuples as they could. If you are familiar with postgres then you know that > vacuum can only recover dead tuples up to the point of the oldest > transaction. My activemq database is on the same db server as my production > db. > So I would like to regularly failover the master to the slave to keep the > lock transaction timestamp moving forward in time. > Is there any facility built into activemq that would allow me to schedule a > restart of a broker? For example, it would be nice to have the ability to > specify in the broker.xml a TTL value that would mean run for this much time > then restart yourself (or shutdown). > Rob -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-8123) Add jaxb-core, istack, ... for runtimeConfigurationPlugin without broker started
[ https://issues.apache.org/jira/browse/AMQ-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-8123: -- Summary: Add jaxb-core, istack, ... for runtimeConfigurationPlugin without broker started (was: Add jaxb-core and istack for runtimeConfigurationPlugin without broker started) > Add jaxb-core, istack, ... for runtimeConfigurationPlugin without broker > started > > > Key: AMQ-8123 > URL: https://issues.apache.org/jira/browse/AMQ-8123 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Plugin >Affects Versions: 5.16.1 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.15.15, 5.16.2 > > > In order to work with any JDK version (JDK8, JDK9, JDK11+), and avoid > classloading issue, the runtimeConfigurationPlugin needs jaxb-core and > itstack-commons-runtime in the classloader. This is especially required with > broker start attribute is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-8123) Add jaxb-core and istack for runtimeConfigurationPlugin without broker started
Jean-Baptiste Onofré created AMQ-8123: - Summary: Add jaxb-core and istack for runtimeConfigurationPlugin without broker started Key: AMQ-8123 URL: https://issues.apache.org/jira/browse/AMQ-8123 Project: ActiveMQ Issue Type: Bug Components: Broker, Plugin Affects Versions: 5.16.1 Reporter: Jean-Baptiste Onofré Assignee: Jean-Baptiste Onofré Fix For: 5.17.0, 5.15.15, 5.16.2 In order to work with any JDK version (JDK8, JDK9, JDK11+), and avoid classloading issue, the runtimeConfigurationPlugin needs jaxb-core and itstack-commons-runtime in the classloader. This is especially required with broker start attribute is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3068) Comparator implementation of HierarchicalObjectRepository issue
[
https://issues.apache.org/jira/browse/ARTEMIS-3068?focusedWorklogId=536394=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536394
]
ASF GitHub Bot logged work on ARTEMIS-3068:
---
Author: ASF GitHub Bot
Created on: 15/Jan/21 09:27
Start Date: 15/Jan/21 09:27
Worklog Time Spent: 10m
Work Description: brusdev commented on a change in pull request #3408:
URL: https://github.com/apache/activemq-artemis/pull/3408#discussion_r558117860
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/HierarchicalObjectRepository.java
##
@@ -484,17 +482,10 @@ public int compare(final String o1, final String o2) {
} else if (!o1.contains(singleWord) && o2.contains(singleWord)) {
return -1;
} else if (o1.contains(singleWord) && o2.contains(singleWord)) {
-String[] leftSplits = o1.split(quotedDelimiter);
-String[] rightSplits = o2.split(quotedDelimiter);
-for (int i = 0; i < leftSplits.length; i++) {
- String left = leftSplits[i];
- if (left.equals(singleWord)) {
- if (rightSplits.length < i ||
!rightSplits[i].equals(singleWord)) {
- return -1;
- } else {
- return +1;
- }
- }
+int o1Count = StringUtils.countMatches(o1, singleWord);
+int o2Count = StringUtils.countMatches(o2, singleWord);
+if (o1Count != o2Count) {
+ return o1Count - o2Count;
Review comment:
The MatchComparator should take into account the position the
`singleWord` wild card too, ie `foo.*.too.*` is more specific than `*.too` in a
hierarchical sense.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 536394)
Time Spent: 50m (was: 40m)
> Comparator implementation of HierarchicalObjectRepository issue
> ---
>
> Key: ARTEMIS-3068
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3068
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.13.0, 2.14.0,
> 2.15.0, 2.16.0
>Reporter: Luis Miguel De Bello
>Priority: Major
> Fix For: 2.17.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi, I am having an issue with the MatchComparator implemented in the
> HierarchicalObjectRepository class.
> Let me put an example on what's going on right now:
> I have created a class called DynamicRolesSecuritySettingPlugin implementing
> the interface SecuritySettingPlugin so that I can implement the
> setSecurityRepository method. There, I am adding some roles to the
> HierarchicalRepository based on a certificate. The HierarchicalRepository
> type T is Set. To summarize, the HierarchicalObjectRepository ends up
> having two different strings as key to the internal map (they are added with
> the addMatch method):
> - *.Provider.*.Agent.*.State
> - uswest.Provider.RR.Agent.*.State
> For the string "*.Provider.*.Agent.*.State", i end up setting a Role with
> permissions to publish but not to consume.
> For the string "uswest.Provider.RR.Agent.*.State", i end up setting a Role
> with permissions to consume.
> Now, when I create a consumer for a queue named
> uswest.Provider.RR.Agent.1.State (there is already a queue created with that
> name and with messages on it), I get an error on the consumer saying that I
> don't have the permission 'CONSUME' for queue
> uswest.Provider.RR.Agent.1.State.
> So I went ahead and debugged the code. I ended up in the class
> HierarchicalObjectRepository reading the getMatch method:
> @Override
> public T getMatch(final String match) {
> String modifiedMatch = matchModifier.modify(match);
> T cacheResult = cache.get(modifiedMatch);
> if (cacheResult != null) {
> return cacheResult;
> }
> lock.readLock().lock();
> try {
> T actualMatch;
> Map> possibleMatches =
> getPossibleMatches(modifiedMatch);
> Collection> orderedMatches = sort(possibleMatches);
> actualMatch = merge(orderedMatches);
> T value = actualMatch != null ? actualMatch : defaultmatch;
> if (value != null) {
> cache.put(modifiedMatch, value);
> }
> return value;
> } finally {
> lock.readLock().unlock();
> }
> }
> When I set a breakpoint in
