[jira] [Commented] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656280#comment-16656280
]
ASF subversion and git services commented on AMQ-6780:
--
Commit dc36c19c811dcaab07c27d6f2a0dcdd90f856d3f in activemq's branch
refs/heads/master from [~j...@nanthrax.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=dc36c19 ]
[AMQ-6780] This closes #311
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656279#comment-16656279
]
ASF subversion and git services commented on AMQ-6780:
--
Commit 46f8deeb67623e095622debac18f53d736cb3bcc in activemq's branch
refs/heads/master from [~j...@nanthrax.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=46f8dee ]
[AMQ-6780] Add PostgreSQL version JDBC driver name in jdbc store services
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved AMQ-6780.
---
Resolution: Fixed
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656283#comment-16656283
]
ASF subversion and git services commented on AMQ-6780:
--
Commit ab41382b0e1627ab1a76b1a9f802810281ed955f in activemq's branch
refs/heads/activemq-5.15.x from [~j...@nanthrax.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ab41382 ]
[AMQ-6780] Add PostgreSQL version JDBC driver name in jdbc store services
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656281#comment-16656281
]
ASF GitHub Bot commented on AMQ-6780:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq/pull/311
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656255#comment-16656255
]
ASF GitHub Bot commented on AMQ-6780:
-
GitHub user jbonofre opened a pull request:
https://github.com/apache/activemq/pull/311
[AMQ-6780] Add PostgreSQL version JDBC driver name in jdbc store services
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbonofre/activemq AMQ-6780
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq/pull/311.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #311
commit 46f8deeb67623e095622debac18f53d736cb3bcc
Author: Jean-Baptiste Onofré
Date: 2018-10-19T04:11:14Z
[AMQ-6780] Add PostgreSQL version JDBC driver name in jdbc store services
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-6780:
--
Labels: postgresql (was: )
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-6780:
--
Component/s: JDBC
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: postgresql
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-6780) New Postgres JDBC-Driver not recognized
[
https://issues.apache.org/jira/browse/AMQ-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-6780:
--
Fix Version/s: 5.15.7
5.16.0
> New Postgres JDBC-Driver not recognized
> ---
>
> Key: AMQ-6780
> URL: https://issues.apache.org/jira/browse/AMQ-6780
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.0
>Reporter: Ch.Krauss
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0, 5.15.7
>
> Attachments: postgresql_jdbc_driver
>
>
> After our switch of the postgres-jdbc-driver from version 9.4-1201 to 42.1.3
> the JDBCPersistenceAdapter does not recognize postgres any more.
> The log:
> {code:title=new driver}
> 2017-07-31 19:35:52,733 [INFO ] 259-949-060 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override not found for :
> [postgresql_jdbc_driver]. Will use default implementation.
> 2017-07-31 19:35:52,765 [WARN ] 259-949-060 [DefaultJDBCAdapter :
> executeStatement] - Could not create JDBC tables; they could already exist.
> Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
> VARCHAR(250) NOT NULL, MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION
> BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: ERROR: type "blob" does not
> exist
> Position: 147 SQLState: 42704 Vendor code: 0
> {code}
> {code:title=old driver}
> 2017-07-31 19:37:21,021 [INFO ] 11b-e48-c83 [JDBCPersistenceAdapter :
> loadAdapter] - Database adapter driver override recognized for :
> [postgresql_native_driver] - adapter: class
> org.apache.activemq.store.jdbc.adapter.PostgresqlJDBCAdapter
> {code}
> The cause is the change of the name from "postgres_native_driver" to
> "postgres_jdbc_driver" (getDriverName() now returns "PostgreSQL JDBC
> Driver"). The PostgresqlJDBCAdapter uses the name to find the class.
> Our workaround is to add a file "postgres_jdbc_driver" to
> "META-INF/services/org/apache/activemq/store/jdbc" in the
> "activemq-jdbc-store-5.15.0.jar".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2137) Console retry message is broken
[
https://issues.apache.org/jira/browse/ARTEMIS-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656225#comment-16656225
]
ASF GitHub Bot commented on ARTEMIS-2137:
-
GitHub user shailendra14k opened a pull request:
https://github.com/apache/activemq-artemis/pull/2382
[ARTEMIS-2137]Console retry message is broken
Jira:- https://issues.apache.org/jira/browse/ARTEMIS-2137
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shailendra14k/activemq-artemis ARTEMIS-2137
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2382.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2382
commit 09b9dd327db1371b004533bb2726044a99f5b3be
Author: Shailendra Kumar Singh
Date: 2018-10-19T02:48:03Z
[ARTEMIS-2137]Console retry message is broken
> Console retry message is broken
> ---
>
> Key: ARTEMIS-2137
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2137
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.3
>Reporter: Shailendra Kumar singh
>Priority: Major
> Attachments: retry_messages.png
>
>
> Console retry message is broken, it throws below exception
> {code:java}
> [Core] Operation retryMessage(java.lang.String) failed due to:
> java.lang.IllegalArgumentException : No operation
> retryMessage(java.lang.String) on MBean
> org.apache.activemq.artemis:address="ExpiryQueue",broker="0.0.0.0",component=addresses,queue="ExpiryQueue",routing-type="anycast",subcomponent=queues
> exists. Known signatures: (long)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-2137) Console retry message is broken
Shailendra Kumar singh created ARTEMIS-2137:
---
Summary: Console retry message is broken
Key: ARTEMIS-2137
URL: https://issues.apache.org/jira/browse/ARTEMIS-2137
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Web Console
Affects Versions: 2.6.3
Reporter: Shailendra Kumar singh
Attachments: retry_messages.png
Console retry message is broken, it throws below exception
{code:java}
[Core] Operation retryMessage(java.lang.String) failed due to:
java.lang.IllegalArgumentException : No operation
retryMessage(java.lang.String) on MBean
org.apache.activemq.artemis:address="ExpiryQueue",broker="0.0.0.0",component=addresses,queue="ExpiryQueue",routing-type="anycast",subcomponent=queues
exists. Known signatures: (long)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655983#comment-16655983
]
Jeff Genender commented on AMQ-7080:
[~gtully] I don't think there is a risk to the partial write because the
metadata is written after the free list in his patch. So assuming a partial
write occurred to the freelist, in theory the metadata write wouldn't hold the
same fingerprint, and a full index read would be required anyways. Correct?
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Priority: Major
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655976#comment-16655976 ] ASF subversion and git services commented on ARTEMIS-2136: -- Commit 024db5bd3c1656d265daf60c9e3a362d53b9088b in activemq-artemis's branch refs/heads/2.6.x from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=024db5b ] ARTEMIS-2136 synchronize copy constructor A synchronization block was missed during the AMQP refactoring. This could impact use-cases involving diverts, cluster bridges, and multiple concurrent consumers. (cherry picked from commit 175d77a5b78023a44c9ce140e39ea282fe9da7c9) > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655972#comment-16655972 ] ASF GitHub Bot commented on ARTEMIS-2136: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2381 I ran the PR build locally and everything was good. > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655971#comment-16655971 ] ASF GitHub Bot commented on ARTEMIS-2136: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2381 > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655970#comment-16655970 ] ASF subversion and git services commented on ARTEMIS-2136: -- Commit 175d77a5b78023a44c9ce140e39ea282fe9da7c9 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=175d77a ] ARTEMIS-2136 synchronize copy constructor A synchronization block was missed during the AMQP refactoring. This could impact use-cases involving diverts, cluster bridges, and multiple concurrent consumers. > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-2136: Fix Version/s: 2.7.0 > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655949#comment-16655949 ] ASF GitHub Bot commented on ARTEMIS-2136: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/2381 ARTEMIS-2136 synchronize copy constructor A synchronization block was missed during the AMQP refactoring. This could impact use-cases involving diverts, cluster bridges, and multiple concurrent consumers. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2136 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2381.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2381 commit 175d77a5b78023a44c9ce140e39ea282fe9da7c9 Author: Clebert Suconic Date: 2018-10-18T21:18:45Z ARTEMIS-2136 synchronize copy constructor A synchronization block was missed during the AMQP refactoring. This could impact use-cases involving diverts, cluster bridges, and multiple concurrent consumers. > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655930#comment-16655930 ] ASF GitHub Bot commented on ARTEMIS-2136: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2380 @clebertsuconic, will do. Thanks! > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655929#comment-16655929 ] ASF GitHub Bot commented on ARTEMIS-2136: - Github user clebertsuconic closed the pull request at: https://github.com/apache/activemq-artemis/pull/2380 > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655928#comment-16655928 ] ASF GitHub Bot commented on ARTEMIS-2136: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2380 @jbertram can you take over? I will close my PR. > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655915#comment-16655915 ] ASF GitHub Bot commented on ARTEMIS-2136: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2380 The test for this was a complex application. I still don't have a testcase for this.. I may come up with something next week. > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
[ https://issues.apache.org/jira/browse/ARTEMIS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655914#comment-16655914 ] ASF GitHub Bot commented on ARTEMIS-2136: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2380 ARTEMIS-2136 Adding synchronization on Copy Constructor I missed this synchronization block during the AMQP Refactoring This could have issues on Diverts Or Clustering bridges. You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-2136 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2380.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2380 commit 45e152644069ffcf10034aca997fabeda005ff04 Author: Clebert Suconic Date: 2018-10-18T21:18:45Z ARTEMIS-2136 Adding synchronization on Copy Constructor I missed this synchronization block during the AMQP Refactoring This could have issues on Diverts Or Clustering bridges. > Lack of synchronization on CoreMessage.copy may cause issues > > > Key: ARTEMIS-2136 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2136) Lack of synchronization on CoreMessage.copy may cause issues
clebert suconic created ARTEMIS-2136: Summary: Lack of synchronization on CoreMessage.copy may cause issues Key: ARTEMIS-2136 URL: https://issues.apache.org/jira/browse/ARTEMIS-2136 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.6.3 Reporter: clebert suconic Assignee: clebert suconic Fix For: 2.6.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655866#comment-16655866
]
Gary Tully commented on AMQ-7080:
-
the freelist format is not so lenient.
the writes can be already complete if async.
i think you need a contents checksum in case of a partial write. the read needs
to be verified. the checksum could be computed on the inmem sequencesset to
keep it fast
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Priority: Major
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655840#comment-16655840
]
Alan Protasio commented on AMQ-7080:
Hi [~gtully],
Thank you very much for the feedback... :D:D:D
{quote}you may be able to do this without any change to the stored metadata
format or free list format by repurposing the freePageSize long to be the
freePageCheckSum.
That long can hold the checksum of the serialised sequence set, if it is set,
load the freepage data and if the checksum matches all is good. If not, replay
In that way it may be possible to be backward compatible or auto migratable.
{quote}
I was looking at the code here... creating a new field in the metadata is
backward compatible anyway.. right?
[https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/page/PageFile.java#L591]
https://github.com/apache/activemq/blob/master/activemq-jms-pool/src/main/java/org/apache/activemq/jms/pool/IntrospectionSupport.java#L34
So... We read the properties from the file to Map and them apply to the right
prop of the object... so if the new prop is not there it will only leave the
default value
The PAGE_FILE_HEADER_SIZE is bigger than we need exactly for that i believe...
We can crate new props and be backward compatible...
{quote}This won't be free, every writeBatch call will take the additional hit
of serialising both the freeList and the metadata, but it may be worth it for
large index files.
{quote}
Agree!
{quote}it is not sufficient to do this when the checkPointLatch is non null b/c
it may be that there are no pending writes at that time. Or maybe that is a
risk worth taking.
{quote}
If there is no pending writes means that the the index file didn't change... no?
{quote}Always generate the checksum and update the metadata if the checksum is
different and only write the freeList when a flush/checkpoint has been set.
{quote}
I didn't want to calculate the Hash on every checkpoint... I was thinking to
create a new field freePageTxId and simply increment it every time db.free is
written.
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Priority: Major
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655819#comment-16655819
]
Gary Tully commented on AMQ-7080:
-
you may be able to do this without any change to the stored metadata format or
free list format by repurposing the freePageSize long to be the
freePageCheckSum.
That long can hold the checksum of the serialised sequence set, if it is set,
load the freepage data and if the checksum matches all is good. If not, replay
In that way it may be possible to be backward compatible or auto migratable.
This won't be free, every writeBatch call will take the additional hit of
serialising both the freeList and the metadata, but it may be worth it for
large index files.
it is not sufficient to do this when the checkPointLatch is non null b/c it may
be that there are no pending writes at that time. Or maybe that is a risk worth
taking.
Always generate the checksum and update the metadata if the checksum is
different and only write the freeList when a flush/checkpoint has been set.
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Priority: Major
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655811#comment-16655811
]
Jeff Genender commented on AMQ-7080:
This looks good to me. My comments are the fingerprint shouldn't be a random
due to potential clashes. I would use a time in millis or use a time based
UUID. Anything that has an excellent chance of being unique.
[~cshannon], you made some good comments about ACTIVEMQ_KILL_MAXSECONDS which
can be an issue. Luckily that setting is an easy changeable parameter.
However, what's your's and [~gtully] thoughts on removing that from the
'activemq stop', letting it stop normally, and perhaps create a new invoker,
call it 'activemq force-stop', which could use the ACTIVEMQ_KILL_MAXSECONDS
parameter? It seems to me that its been a long while since I have actually
seen ActiveMQ "hang" on its own and slow shut downs have been the consequence
of it doing its thing. Any thoughts/opinions on this? I would be happy to do
it if you guys find value in this.
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Priority: Major
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655742#comment-16655742 ] Alan Protasio commented on AMQ-6590: Thanks! Just created a new Jira for that: https://issues.apache.org/jira/browse/AMQ-7080 > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
Alan Protasio created AMQ-7080:
--
Summary: Keep track of free pages - Update db.free file during
checkpoints
Key: AMQ-7080
URL: https://issues.apache.org/jira/browse/AMQ-7080
Project: ActiveMQ
Issue Type: Improvement
Components: KahaDB
Affects Versions: 5.15.6
Reporter: Alan Protasio
In a event of an unclean shutdown, Activemq loses the information about the
free pages in the index. In order to recover this information, ActiveMQ read
the whole index during shutdown searching for free pages and then save the
db.free file. This operation can take a long time, making the failover slower.
(during the shutdown, activemq will still hold the lock).
>From http://activemq.apache.org/shared-file-system-master-slave.html
{quote}"If you have a SAN or shared file system it can be used to provide high
availability such that if a broker is killed, another broker can take over
immediately."
{quote}
Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
seconds, any following shutdown will be unclean. This broker will stay in this
state unless the index is deleted (this state means that every failover will
take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time to 5
minutes, you fail over can take more than 5 minutes).
In order to prevent ActiveMQ reading the whole index file to search for free
pages, we can keep track of those on every Checkpoint. In order to do that we
need to be sure that db.data and db.free are in sync. To achieve that we can
have a attribute in the db.free page that is referenced by the db.data.
So during the checkpoint we have:
1 - Save db.free and give a freePageUniqueId
2 - Save this freePageUniqueId in the db.data (metadata)
In a crash, we can see if the db.data has the same freePageUniqueId as the
db.free. If this is the case we can safely use the free page information
contained in the db.free
Now, the only way to read the whole index file again is IF the crash happens
btw step 1 and 2 (what is very unlikely).
The drawback of this implementation is that we will have to save db.free during
the checkpoint, what can possibly increase the checkpoint time.
Is also important to note that we CAN (and should) have stale data in db.free
as it is referencing stale db.data:
Imagine the timeline:
T0 -> P1, P2 and P3 are free.
T1 -> Checkpoint
T2 -> P1 got occupied.
T3 -> Crash
In the current scenario after the Pagefile#load the P1 will be free and then
the replay will mark P1 as occupied or will occupied another page (now that the
recovery of free pages is done on shutdown)
This change only make sure that db.data and db.free are in sync and showing the
reality in T1 (checkpoint), If they are in sync we can trust the db.free.
This is a really fast draft of what i'm suggesting... If you guys agree, i can
create the proper patch after:
[https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655547#comment-16655547 ] Christopher L. Shannon commented on AMQ-6590: - I'm good with the checkpoint but want to see what [~gtully] thinks as he brought up some concerns about checkpointing the free list. As Jeff said we can continue the conversation against the PR in a new jira. > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655537#comment-16655537 ] Alan Protasio commented on AMQ-6590: [~cshannon] What about saving the free pages in the check point? Do you think that make sense? I was talking other guys and the only concern seems to be that we will increase the Checkpoint timings (as we are writing one more file) > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655503#comment-16655503 ] Christopher L. Shannon commented on AMQ-6590: - The ACTIVEMQ_KILL_MAXSECONDS actually occurred to me as well a bit after I responded to this. I use a custom start up script but still have something similar where if the broker hangs it will be killed which obviously breaks in this case. So that case needs to be handled. > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-7079) Using abortSlowAckConsumerStrategy aborts slow consumer even though it has disconnected
[
https://issues.apache.org/jira/browse/AMQ-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-7079.
-
Resolution: Fixed
Assignee: Gary Tully
Fix Version/s: 5.16.0
> Using abortSlowAckConsumerStrategy aborts slow consumer even though it has
> disconnected
> ---
>
> Key: AMQ-7079
> URL: https://issues.apache.org/jira/browse/AMQ-7079
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Simon Lundstrom
>Assignee: Gary Tully
>Priority: Minor
> Fix For: 5.16.0
>
>
> When testing AMQ-7077 I noticed that if an consumer gets tagged as
> slowConsumer and then the consumer disconnects ActiveMQ will abort the slow
> consumer (even though it already has disconnected).
>
> Somewhere in between of 13:09:10 and 13:09:42 the consumer disconnects.
> {code:java}
> 2018-10-18 13:09:10,735 | INFO | sub:
> ID:kaka.it.su.se-51120-1539860894594-1:1:1:1 is no longer slow |
> org.apache.activemq.broker.region.policy.AbortSlowAckConsumerStrategy |
> ActiveMQ Broker[localhost] Scheduler
> 2018-10-18 13:09:42,836 | INFO | aborting slow consumer:
> ID:kaka.it.su.se-51120-1539860894594-1:1:1:1 for
> destination:queue://su.it.linfra.simlu |
> org.apache.activemq.broker.region.policy.AbortSlowConsumerStrategy | ActiveMQ
> Broker[localh
> {code}
> Configuration:
> {code:xml}
> […]
>
>
> maxTimeSinceLastAck="3000" />
>
>
> […]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6421) AbortSlowAckConsumerStrategy does not produce SlowConsumer advisory message
[ https://issues.apache.org/jira/browse/AMQ-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655462#comment-16655462 ] ASF subversion and git services commented on AMQ-6421: -- Commit 9dd751149f7489f99d430d3f1240f2bfa2e70c69 in activemq's branch refs/heads/master from gtully [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9dd7511 ] AMQ-7079 AMQ-7077 AMQ-6421 - check for consumers that have been destroyed > AbortSlowAckConsumerStrategy does not produce SlowConsumer advisory message > --- > > Key: AMQ-6421 > URL: https://issues.apache.org/jira/browse/AMQ-6421 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.14.0 >Reporter: Matt Pavlovich >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > The AbortSlowAckConsumerStrategy should throw an advisory when applicable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7079) Using abortSlowAckConsumerStrategy aborts slow consumer even though it has disconnected
[
https://issues.apache.org/jira/browse/AMQ-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655460#comment-16655460
]
ASF subversion and git services commented on AMQ-7079:
--
Commit 9dd751149f7489f99d430d3f1240f2bfa2e70c69 in activemq's branch
refs/heads/master from gtully
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9dd7511 ]
AMQ-7079 AMQ-7077 AMQ-6421 - check for consumers that have been destroyed
> Using abortSlowAckConsumerStrategy aborts slow consumer even though it has
> disconnected
> ---
>
> Key: AMQ-7079
> URL: https://issues.apache.org/jira/browse/AMQ-7079
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Simon Lundstrom
>Priority: Minor
>
> When testing AMQ-7077 I noticed that if an consumer gets tagged as
> slowConsumer and then the consumer disconnects ActiveMQ will abort the slow
> consumer (even though it already has disconnected).
>
> Somewhere in between of 13:09:10 and 13:09:42 the consumer disconnects.
> {code:java}
> 2018-10-18 13:09:10,735 | INFO | sub:
> ID:kaka.it.su.se-51120-1539860894594-1:1:1:1 is no longer slow |
> org.apache.activemq.broker.region.policy.AbortSlowAckConsumerStrategy |
> ActiveMQ Broker[localhost] Scheduler
> 2018-10-18 13:09:42,836 | INFO | aborting slow consumer:
> ID:kaka.it.su.se-51120-1539860894594-1:1:1:1 for
> destination:queue://su.it.linfra.simlu |
> org.apache.activemq.broker.region.policy.AbortSlowConsumerStrategy | ActiveMQ
> Broker[localh
> {code}
> Configuration:
> {code:xml}
> […]
>
>
> maxTimeSinceLastAck="3000" />
>
>
> […]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7077) Queue subscriber view slowConsumer flag set in error
[ https://issues.apache.org/jira/browse/AMQ-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655461#comment-16655461 ] ASF subversion and git services commented on AMQ-7077: -- Commit 9dd751149f7489f99d430d3f1240f2bfa2e70c69 in activemq's branch refs/heads/master from gtully [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9dd7511 ] AMQ-7079 AMQ-7077 AMQ-6421 - check for consumers that have been destroyed > Queue subscriber view slowConsumer flag set in error > > > Key: AMQ-7077 > URL: https://issues.apache.org/jira/browse/AMQ-7077 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > For queue subscribers, the broker dispatches prefetch num messages and stops. > The subscription is considered full. > There is currently logic in PrefetchSubscription that flags the consumer as > slow on the success full dispatch of the last message in a prefetch batch. > this flag remains set till there are more messages to dispatch, which happens > on the first ack. > The consumer is considered slow, till it acks (which seems wrong) and in the > case that there are no more message to dispatch, it remains slow. > > Interestingly, there are some tests for this functionality that only validate > topics in error. > > From my investigation, it seems that for queue consumers, it is really only > possible to gauge slowness due to the frequency of acks, which is what the > AbortAckSlowConsumerPolicy does. > It makes sense that that code flags a consumer as slow once it is detected as > such. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655414#comment-16655414 ] Jeff Genender commented on AMQ-6590: Also, add a unit test. The unit test can show a normal checkpoint, and you can also exercise the failure by force calling brokerService.getPersistenceAdapter().checkpoint() and then changing the db.data or db.free fingerprint with some file I/O using the File object, then restarting and testing that it did a full recovery. Should be straight forward. Open a new Jira on this :) > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655260#comment-16655260 ] Alan Protasio commented on AMQ-6590: Yep... Or we can change the fingerprint for freePageTxId or something like that and be a single increment (freePageTxId++) on every time i save db.free > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655236#comment-16655236 ] Jeff Genender commented on AMQ-6590: One more small comment, I would change from using Random as the fingerprint and perhaps use a time stamp or something. The Random could potentially have a clash and possibly could have a collision which would cause corruption. Perhaps use a Time function or time based UUID as your finger print. Since this will not be doing 2 checkpoints in under a millisecond, I think that would be the safest. > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4, 5.16.0, 5.15.7 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7079) Using abortSlowAckConsumerStrategy aborts slow consumer even though it has disconnected
Simon Lundstrom created AMQ-7079:
Summary: Using abortSlowAckConsumerStrategy aborts slow consumer
even though it has disconnected
Key: AMQ-7079
URL: https://issues.apache.org/jira/browse/AMQ-7079
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Reporter: Simon Lundstrom
When testing AMQ-7077 I noticed that if an consumer gets tagged as slowConsumer
and then the consumer disconnects ActiveMQ will abort the slow consumer (even
though it already has disconnected).
Somewhere in between of 13:09:10 and 13:09:42 the consumer disconnects.
{code:java}
2018-10-18 13:09:10,735 | INFO | sub:
ID:kaka.it.su.se-51120-1539860894594-1:1:1:1 is no longer slow |
org.apache.activemq.broker.region.policy.AbortSlowAckConsumerStrategy |
ActiveMQ Broker[localhost] Scheduler
2018-10-18 13:09:42,836 | INFO | aborting slow consumer:
ID:kaka.it.su.se-51120-1539860894594-1:1:1:1 for
destination:queue://su.it.linfra.simlu |
org.apache.activemq.broker.region.policy.AbortSlowConsumerStrategy | ActiveMQ
Broker[localh
{code}
Configuration:
{code:xml}
[…]
[…]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
