Asynchronous operations with Hangfire

[LeonardoDaga]

I've setup a simple .netcore 3.1 web application, based on Ubuntu 16.04 Server with Mysql 8.0.25 and Hangfire 1.7.30 for scheduled activities. I'm actually struggling in understanding how scheduling activities should be made. In the actual version of the SW, I've created up to 8 asynchronous scheduled tasks managed by Hangfire, all of them structured as follow:

public static async Task ScheduledTaskAsync_UpdateTransferList()
{
    await TaskScheduling.UpdateTransferList(SavedAppServices);
}

All these scheduling activities query the mysql DB, that's why I've made them asynchronous. One of these 8 services is quite frequent (Cron.Minutely()) and takes few seconds to be executed. I'm wondering if I'm doing something wrong, because I see in the app log many consecutive messages like:

  dbug: Hangfire.Server.RecurringJobScheduler[0]
        1000 recurring job(s) processed by scheduler.

sometimes for a total of 9000-10000 recurring jobs processed. Furthermore, after moving from Mysql 5.7.3 to 8.0.25, I've noticed a sharp increase of mysql binlogs (up to 6Gb generated in two days), all of them because of multiple logs like this (generated at the same second):

  # at 9683673
  #220617  5:25:45 server id 1  end_log_pos 9683704 CRC32 0x08936f4a      Xid = 25774476
  COMMIT/*!*/;
  # at 9683704
  #220617  5:25:45 server id 1  end_log_pos 9683783 CRC32 0xdd8b5fe2      Anonymous_GTID  last_committed=26277    sequence_number=26278   rbr_only=yes  original_committed_timestamp=1655443545028260    immediate_commit_timestamp=1655443545028260     transaction_length=332
  /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
  # original_commit_timestamp=1655443545028260 (2022-06-17 05:25:45.028260 UTC)
  # immediate_commit_timestamp=1655443545028260 (2022-06-17 05:25:45.028260 UTC)
  /*!80001 SET @@session.original_commit_timestamp=1655443545028260*//*!*/;
  /*!80014 SET @@session.original_server_version=80025*//*!*/;
  /*!80014 SET @@session.immediate_server_version=80025*//*!*/;
  SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
  # at 9683783
  #220617  5:25:45 server id 1  end_log_pos 9683862 CRC32 0x8b83c028      Query   thread_id=110   exec_time=0     error_code=0
  SET TIMESTAMP=1655443545/*!*/;
  BEGIN
  /*!*/;
  # at 9683862
  #220617  5:25:45 server id 1  end_log_pos 9683940 CRC32 0x29c7f191      Table_map: `Hangfire`.`Hangfire.DistributedLock` mapped to number 92
  # at 9683940
  #220617  5:25:45 server id 1  end_log_pos 9684005 CRC32 0x6f8c7b99      Delete_rows: table id 92 flags: STMT_END_F

To be noted that the Hangfire Dashboard panel signals no issues and I know that I could simply deactivate binlog generation, but I would like to understand if I'm doing something wrong with Hangfire/Mysql and how I can make everything work without a so huge waste of diskspace due to binlog generation.

[odinserj]

Unfortunately it's not possible by Hangfire to signal about all the issues down the stack, so the absence of warnings doesn't mean that everything is fine. Databases are very complex techs and it's very difficult to implement a reliable "success" metric, because any mistake in the code will compromise it.

You can also ask this question in the GitHub repository of the MySql storage package you are using (the best way is to look on NuGet.org where its repository is located), since it's a community-based storage.