[
https://issues.apache.org/jira/browse/ARTEMIS-3679?focusedWorklogId=728538&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-728538
]
ASF GitHub Bot logged work on ARTEMIS-3679:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 16/Feb/22 21:29
Start Date: 16/Feb/22 21:29
Worklog Time Spent: 10m
Work Description: franz1981 commented on a change in pull request #3950:
URL: https://github.com/apache/activemq-artemis/pull/3950#discussion_r808469313
##########
File path:
artemis-server/src/test/java/org/apache/activemq/artemis/core/server/impl/jdbc/JdbcLeaseLockTest.java
##########
@@ -116,6 +122,22 @@ public void dropLockTable() throws Exception {
jdbcSharedStateManager.close();
}
+ @Test
+ public void shouldStillHeldLockOnTimeZoneChange() {
+
Assume.assumeThat(PropertySQLProvider.Factory.identifyDialect(dbConf.getJdbcDriverClassName()),
CoreMatchers.is(PropertySQLProvider.Factory.SQLDialect.DERBY));
+ TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("-1")));
+ final long expirationMillis = Duration.ofMinutes(30).toMillis();
+ final LeaseLock lock = lock(expirationMillis);
+ Assert.assertTrue("Must acquire the lock!", lock.tryAcquire());
+ TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("+3")));
Review comment:
@fvaleri I still have to decide how to handle testing this :)
But I've decided to use specific UTC get time query per supported DBs
--
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: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 728538)
Time Spent: 1h 20m (was: 1h 10m)
> 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: 1h 20m
> 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)
