DbTrackingModule - not synchronized well under pressure

[szygie]

Hello,
I found out that if I process more then one file (~10) at a time using As2DirectoryPollingModule updates made by DbTrackingModule get out of order for couple of records (like 1 or 2)

For example (please note ~40ms difference)

11:15:11.649 [Thread-1015] DEBUG org.openas2.processor.msgtracking.DbTrackingModule -- Tracking record successfully persisted to database: {state_msg=Message sent. Message MDN success response received., is_resend=N, receiver_id=TEST_PARTNER_B, file_name=fileNameToBeSend.txt, resend_count=0, mdn_response=Le message a ete envoye parTEST_PARTNER_A le Thu, 04 Apr 2026 13:15:11 CEST avec comme sujet ( File fileNameToBeSend.txt sent from TEST_PARTNER_A to TEST_PARTNER_B ) a ete recu. 
, sender_id=TEST_PARTNER_A, content_transfer_encoding=null, content_type=application/XML, sent_file_name=fileNameToBeSend.txt, mdn_id=<PROAS2-02042026131511-8488@TEST_PARTNER_B_TEST_PARTNER_A>, prior_msg_id=null, signature_algorithm=SHA1, mdn_mode=SYNC, encryption_algorithm=3DES, state=msg_sent_mdn_received_ok, msg_id=<OPENAS2-20260402111511+0000OPENAS2--427-TEST_PARTNER_A_TEST_PARTNER_B_fileNameToBeSend.txt>, compression=null, direction=SEND, status=verifying_mdn}


11:15:11.686 [Thread-1014] DEBUG org.openas2.processor.msgtracking.DbTrackingModule -- Tracking record successfully persisted to database: {state_msg=Message sending started, is_resend=N, receiver_id=TEST_PARTNER_B, file_name=fileNameToBeSend.txt, resend_count=0, sender_id=TEST_PARTNER_A, content_transfer_encoding=null, content_type=application/XML, sent_file_name=fileNameToBeSend.txt, prior_msg_id=null, signature_algorithm=SHA1, mdn_mode=SYNC, encryption_algorithm=3DES, state=msg_send_start, msg_id=<OPENAS2-20260402111511+0000OPENAS2--427-TEST_PARTNER_A_TEST_PARTNER_B_fileNameToBeSend.txt>, compression=null, direction=SEND, status=sending_msg}

Steps to reproduce:
place into /data/toAny/ ~10 files dedicated for one partner.

Observe results. 1 or 2 out of 10 would have Status = sending_msg, State=msg_send_start, MDN_RESPONSE= not null value(actual message from MDN), STATE_MSG = Message sending started.

Thanks in advance!

[uhurusurfa]

At this moment this is not unexpected.

The rason is that the DB persistence transaction is spawned into a new thread so that the processing of a new message in the poller directory can be started sooner instead of waiting for the database transaction to complete.

Unfortunately, the operating system does not guarantee the order of processing the threads and this is why it sometimes gets out of order under high volume.

In the upcoming release 5.0 the messages will be pushed into a queue and the database handler will run in a separate thread and retrieve messages in the order they were put into the queue and that should solve this issue.