[
https://issues.apache.org/jira/browse/ARTEMIS-3679?focusedWorklogId=728855&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-728855
]
ASF GitHub Bot logged work on ARTEMIS-3679:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 17/Feb/22 11:06
Start Date: 17/Feb/22 11:06
Worklog Time Spent: 10m
Work Description: fvaleri commented on a change in pull request #3950:
URL: https://github.com/apache/activemq-artemis/pull/3950#discussion_r808930127
##########
File path: artemis-jdbc-store/src/main/resources/journal-sql.properties
##########
@@ -75,14 +76,15 @@ create-file-table.mysql=CREATE TABLE %s(ID BIGINT NOT NULL
AUTO_INCREMENT, FILEN
append-to-file.mysql=SELECT DATA, ID FROM %s WHERE ID=? FOR UPDATE
create-journal-table.mysql=CREATE TABLE %s(id BIGINT,recordType
SMALLINT,compactCount SMALLINT,txId BIGINT,userRecordType SMALLINT,variableSize
INTEGER,record LONGBLOB,txDataSize INTEGER,txData LONGBLOB,txCheckNoRecords
INTEGER,seq BIGINT) ENGINE=InnoDB
copy-file-record-by-id.mysql=UPDATE %1$s, (SELECT DATA AS FROM_DATA FROM %1$s
WHERE id=?) SELECT_COPY SET DATA=FROM_DATA WHERE id=?
+current-timestamp.mysql=SELECT UTC_TIMESTAMP(6)
# 4 GiB
max-blob-size.mysql=4294967296
table-names-case.mysql=lower
# Oracle SQL statements
create-file-table.oracle=CREATE TABLE %s(ID NUMBER(19) GENERATED BY DEFAULT ON
NULL AS IDENTITY, FILENAME VARCHAR(255), EXTENSION VARCHAR(10), DATA BLOB,
PRIMARY KEY(ID))
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType
NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType
NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData
BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
-
+current-timestamp.oracle=SELECT SYSTIMESTAMP AT TIME ZONE 'UTC' FROM DUAL
Review comment:
Given the different behaviors and way to express these queries, I would
say we should test them on all databases setting a system TZ different from UTC.
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/jdbc/JdbcLeaseLock.java
##########
@@ -147,14 +148,13 @@ private long dbCurrentTimeMillis(Connection connection)
throws SQLException {
try (ResultSet resultSet = currentDateTime.executeQuery()) {
resultSet.next();
final long endTime = stripMilliseconds(System.currentTimeMillis());
- final Timestamp currentTimestamp = resultSet.getTimestamp(1);
- final long currentTime = currentTimestamp.getTime();
- final long currentTimeMillis = stripMilliseconds(currentTime);
- if (currentTimeMillis < startTime) {
- LOGGER.warnf("[%s] %s query currentTimestamp = %s on database
should happen AFTER %s on broker", lockName, holderId, currentTimestamp, new
Timestamp(startTime));
+ final long currentTime = resultSet.getTimestamp(1,
Calendar.getInstance(TimeZone.getTimeZone("UTC"))).getTime();
+ final long currentTimeNoMillis = stripMilliseconds(currentTime);
+ if (currentTimeNoMillis < startTime) {
Review comment:
Shouldn't this method be called something like
verifyAndGetDatabaseCurrentTimestamp to better reflect the internal logic?
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/jdbc/JdbcLeaseLock.java
##########
@@ -114,14 +115,14 @@ private String readableLockStatus() {
final boolean autoCommit = connection.getAutoCommit();
connection.setAutoCommit(false);
try (PreparedStatement preparedStatement =
connection.prepareStatement(this.isLocked)) {
+ final long currentTimestamp = dbCurrentTimeMillis(connection);
Review comment:
I guess in dbCurrentTimeMillis() we should select the current UTC
timestamp query based on the database type (e.g. `current-timestamp.mssql`) and
fall back to `current-timestamp` with an appropriate warning if the database is
unknown.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 728855)
Time Spent: 1.5h (was: 1h 20m)
> Brokers with JDBC shared-store shutdown after daylight saving fall back
> -----------------------------------------------------------------------
>
> Key: ARTEMIS-3679
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3679
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.20.0
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> This is what happened on a two brokers JDBC shared-store setup after daylight
> savings change. This also causes the backup shutdown with the same critical
> IO error.
> {code:java}
> 2021-10-31 01:58:44,002 WARN
> [org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLock] [LIVE]
> d5b17659-c4f6-4847-bfb2-6c5f209a0fb9 query currentTimestamp = 2021-10-31
> 01:58:43.999927 on database should happen AFTER 2021-10-31 01:58:44.0 on
> broker 2021-10-31 02:59:00,217 WARN [org.apache.activemq.artemis.core.server]
> AMQ222010: Critical IO Error, shutting down the server. file=NULL,
> message=Lost NodeManager lock: java.io.IOException: lost lock at
> org.apache.activemq.artemis.core.server.impl.SharedStoreLiveActivation.lambda$registerActiveLockListener$0(SharedStoreLiveActivation.java:123)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.NodeManager.lambda$notifyLostLock$0(NodeManager.java:143)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> java.base/java.lang.Iterable.forEach(Iterable.java:75) [java.base:] at
> org.apache.activemq.artemis.core.server.NodeManager.notifyLostLock(NodeManager.java:141)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.notifyLostLock(JdbcNodeManager.java:154)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock.run(ActiveMQScheduledLeaseLock.java:114)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForExecutor(ActiveMQScheduledComponent.java:313)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.lambda$bookedRunForScheduler$2(ActiveMQScheduledComponent.java:320)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:] at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012]
> {code}
> The reason seems related to the TIMESTAMP field used on
> HOLDER_EXPIRATION_TIME: given that it doesn't contains any time zone
> information, if it compares against TIMESTAMP WITH TIME ZONE values ie
> CURRENT_TIMESTAMP query results, they won't work as expected.
> In addition, CURRENT_TIMESTAMP values, while converted into the Java world,
> reports UTC time values, while TIMESTAMP ones are adjusted depending by the
> actual time zone (sensitive to day saving time adjustment as well!).
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
