Major issues after upgrading from 5.6 to 5.8

I did an upgrade from traccar 5.6 to 5.8 and the server suddenly stopped sending "received" response.

Logs before the upgrade:

2023-08-12 00:00:00  INFO: [Ud8bb79a0: protocol < XXX.XXX.XXX.XXX] Incoming HEX
2023-08-12 00:00:00  INFO: [Ud8bb79a0: protocol > XXX.XXX.XXX.XXX] Server Response

Now I only have

2023-08-12 16:45:57  INFO: [U8300552d: protocol < XXX.XXX.XXX.XXX] Incoming HEX
2023-08-12 16:45:57  INFO: [U8300552d: protocol < YYY.YYY.YYY.YYY] Incoming HEX
2023-08-12 16:45:57  INFO: [U8300552d: protocol < ZZZ.ZZZ.ZZZ.ZZZ] Incoming HEX

Because of that the devices are sending non stop the same data over and over again.

Any idea why this is and how to fix it?

Are you sure you're not omitting any information from the logs?

No errors in the logs, all positions are accepted by the server and logged into the DB.
Because the devices don't receive the server response, they are sending the same data endlessly and as a result the database is growing with 1200% compared to before the upgrade.
Traccar server has been restarted multiple times after the upgrade...

I will provide the initial logs in few moments.

Have you tried configuring "server.instantAcknowledgement" parameter?

It seems to be working, I need to do more testing.

Is omitting this parameter for 5.8 causing the server to stop sending a response? As opposed to 5.6 where this parameter was not needed?

It delays the response until the message is processed, but it seems like it doesn't work well in your case. Possibly because you use UDP protocol.

Yes probably, because UDP doesn't acknowledge packets have been received. Well, thank you for coming up with this explanation so quickly!

Now, good luck to me trying to clear 6GB of identical data.

Further checking the logs, it seems that traccar did send response on some occasions but there are a lot of incoming packets without a response. All devices have the same configuration.

Is this "random" behavior normal? I would expect that the server will either send or not send a response....

It is expected. Probably when you had a gap between messages and all of them got processed, it sent the response.

Hello, I've done some research and applied the recommendations mentioned in various threads, but I'm still experiencing issues with this device model CALAMP LMU.

Even after applying the suggestions, the device sent the first report but after that, nothing changes. It always stays "Online" but does not update its position or timestamp. I have tested the configuration using both UDP and TCP.

Below is the log:

2025-05-01 10:00:48  INFO: [Ub76427fa: calamp < 10.0.9.145] 8305463118204201010102000d6812715c6812715d0b00d101d63e9cce000006dc000007b900030a200002ffa508091d001e1e1000000032d300000dd00000000005c7d14c000012a80000000000000000000000000000006d017200f40005c3a100000126000001260000001d0000000000000000
2025-05-01 10:00:48  INFO: [Ub76427fa: calamp > 10.0.9.145] 0201000d020000000000
2025-05-01 10:03:36  INFO: [Ub76427fa: calamp < 10.0.6.146] 8305463119468601010102008f68127b1868127b190affe4acd652ca200000000000000008013b0b200002ffbb0f081d001e1e10000000353300000ea00000000012548e010000000a00000000000000000000000000000083017200f8002b2e8900001086000010860000001d0000000000000000
2025-05-01 10:03:36  INFO: [Ub76427fa: calamp > 10.0.6.146] 0201008f020000000000
2025-05-01 10:04:46  INFO: [Ub76427fa: calamp < 10.0.9.145] 8305463118204201010102000d6812715c6812715d0b00d101d63e9cce000006dc000007b900030a200002ffa508091d001e1e1000000032d300000dd00000000005c7d14c000012a80000000000000000000000000000006d017200f40005c3a100000126000001260000001d0000000000000000
2025-05-01 10:04:46  INFO: [Ub76427fa: calamp > 10.0.9.145] 0201000d020000000000
2025-05-01 10:07:45  INFO: [Ub76427fa: calamp < 10.0.6.146] 8305463119468601010102008f68127b1868127b190affe4acd652ca200000000000000008013b0b200002ffbb0f081d001e1e10000000353300000ea00000000012548e010000000a00000000000000000000000000000083017200f8002b2e8900001086000010860000001d0000000000000000
2025-05-01 10:07:45  INFO: [Ub76427fa: calamp > 10.0.6.146] 0201008f020000000000
2025-05-01 10:08:46  INFO: [Ub76427fa: calamp < 10.0.9.145] 8305463118204201010102000d6812715c6812715d0b00d101d63e9cce000006dc000007b900030a200002ffa508091d001e1e1000000032d300000dd00000000005c7d14c000012a80000000000000000000000000000006d017200f40005c3a100000126000001260000001d0000000000000000
2025-05-01 10:08:46  INFO: [Ub76427fa: calamp > 10.0.9.145] 0201000d020000000000
2025-05-01 10:12:45  INFO: [Ub76427fa: calamp < 10.0.6.146] 8305463119468601010102008f68127b1868127b190affe4acd652ca200000000000000008013b0b200002ffbb0f081d001e1e10000000353300000ea00000000012548e010000000a00000000000000000000000000000083017200f8002b2e8900001086000010860000001d0000000000000000
2025-05-01 10:12:45  INFO: [Ub76427fa: calamp > 10.0.6.146] 0201008f020000000000

Server configuration:

<entry key='filter.future'>86400</entry>
<entry key='event.ignoreDuplicateAlerts'>true</entry>
<entry key='filter.maxSpeed'>600</entry>
<entry key='osmand.timeout'>900</entry>
<entry key='server.instantAcknowledgement'>true</entry>
<entry key='logger.rotate'>true</entry>
<entry key='logger.rotate.interval'>hour</entry>
<entry key='logger.level'>info</entry>