dxATAlert table grown too big

[cj]

Hi All,

Action tracker process loads dxATAlert table in memory and because it has grown too big, the process's memory utilisation is very high. What is the best way to tackle this?

Can dxATAlert be persisted to HDB? 

Any help would be greatly appreciated.

[davidcrossey · Accepted solution]

Hi cj,

Alerts will be persisted to the HDB at end-of-day (EOD) in the standard AT workflow. For this to happen, you need to close out alerts via the Action Tracker.

When EOD runs on your ds_actiontracker (AT) process, the closed alerts will be persisted to disk. You can wait to EOD, or optionally call dxATEOD[.z.D] on the AT process after alerts have been closed.

More info on end of day here

Kind regards,

David

[cj]

Thanks a lot David for the quick response.

I think my HDB is corrupt, when I try to access dxATAlert on action tracker HDB, it gives a "type" error? Can this be related with the Kx version where syms were updated to String instead of symbols? Or does it mean that because nothing has ever been EODed successfully so far, so there is nothing in the HDB at all? 

Also, tried to close one item from AT dashboard and manually triggered dxATEOD1[.z.d], this resulted in removing that item from the dashboard but following error occurred on the action tracker process.

ERROR. ### (3317156): Failed to connect to :hostname:port for HDB reload ### "access"

Any idea why would this be occurring? 

[davidcrossey]

Hi cj,

1. For this you will need to check the AT HDB directory on disk to find out if it exists; if it does then you should run some checks to determine if source of the type
2. You would need to check the process log of the AT to see which HDB's it's tried to reload. In some misconfigurations it's possible that an HDB outside of the AT workflow is being picked up and the AT is trying to connect to that permissioned HDB to reload (which it doesn't have access to)

Hope the above helps your initial investigation 🤞🏻