gtully commented on code in PR #4591:
URL: https://github.com/apache/activemq-artemis/pull/4591#discussion_r1319769650
##########
artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/file/JDBCSequentialFile.java:
##########
@@ -332,13 +409,15 @@ public void close(boolean waitOnSync, boolean block)
throws Exception {
@Override
public void sync() throws IOException {
- final SimpleWaitIOCallback callback = new SimpleWaitIOCallback();
- executor.execute(callback::done);
-
try {
- callback.waitCompletion();
+ // 30 seconds is an eternity here. If there's no response within
SYNC_TIMEOUT milliseconds
+ // nothing better could be done other than onIOError which will
likely shutdown the broker.
+ // If this ever happens the broker will be probably failing in other
places as well
+ // due to the lack of connectivity with the database
+ if (!pendingWrites.await(SYNC_TIMEOUT, TimeUnit.MILLISECONDS)) {
Review Comment:
in a sense, the broker needs to be very tolerant to delays, a db can be very
slow and still work. This is where a non blocking architecture and blocking
work need to coordinate to ensure there is some upper bound on pending work,
that pushed back to the network.
If there is a ha rack behind the jdbc connecton and it is doing work to sync
replicate and then transparently failover, the broker needs to be patient and
wait. messaging client may timeout, but I think the expectaiton is that the
broker stays alive. There can be a configurable upper bound on jdbc io
operations, but I think a hardcoded 30s will cause us trouble. Any value of an
jdbc_io timeout would need to be correlated with the jdbc url.
--
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]
