Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
I already heard about the CORDYS_LOG table in the database from several customers. Most of the time in a negative way after the database administration guy (or gal) concludes tables are too big when a valid question was raised during your daily scrum session (mostly years from now when it’s indeed too late!): What is the status of our database tables; do they perform well, do they require indexing, and are tables in overflow mode? Time to dive into a logging table which has a split in settings over time. A split? Yes, on my latest AppWorks environments I see an empty table by default as customers with an ‘older’ version of the platform have an overflowed table after years…What is the working of this table and what is saved into it! Let have a look and…
Let get right into it…
Well, it’s a database table! So, let’s have HeidiSQL ready with a valid connection. I have a clean AppWorks 22.3 up and running with a supported Postgres DB. What is the status of our table?
SELECT * from cordys_log;…Looks empty to me!? Interesting as my current project (AWP 20.4) also started clean, but we saw a data overflow in the exact same table without changing anything after a while (on a multi-dev environment!). So, what is the difference here? Let’s check the manual on the term “CORDYS_LOG” with only 1 result in a tiny “forgotten” section in the administration guide of the platform with the name “Viewing log messages using the Log Viewer”!
Aha!…It looks like our split-flag is finally found in the properties of the ‘Logging’ service group at ‘System’ level with the helpful name “Enable Composite Application Logging”!? 😕
It’s unmarked (by default) at my environment; let’s mark it, save it, and just reboot the entire system/VM. After a coffee-break, we’re back with a second view on that table in HeidiSQL:
SELECT counter, priority, category, thread, message from cordys_log ORDER BY timestamp desc;…Yes, our first set of results:
Nice, but where are these entries coming from? and…Can we truncate the table of its data without any consequence?
Truncate the table
An answer on the last question is easy…Yes we can truncate it with TRUNCATE TABLE cordys_log;. Removing only specific items (like only data from last year), you can do something like this:
DELETE FROM cordys_log WHERE timestamp <= '2021-12-31' AND TIMESTAMP >= '2021-01-01';
BRO-TIP…Always check the size of the table before cleaning and double-check what data is cleaned. Does it need a backup? Or is the data that big that it triggers a performance issue? As always…Ask your questions!
Well, for me an easy and efficient task…next!
The database log settings
What is the input on the entries in our table? A valid question! For the answer, we dive first into our set of results (in CSV-format). Have a look at the ‘thread’ column where you see the FullQualifiedName of the entry passing by. It looks like it’s all happening on service level! Let’s have a look at the ‘monitor@appworks’ (in my case) service container properties. Go to the ‘Log Settings’ where you see a secret flag ‘Publish to Database’.
Unmark this option and restart the ‘TomEE’ instance on your environment. I truncated our table after each try and after 5 service containers (all in the ‘system’ space), I see indeed the database entries being less and less. So, mission accomplished!
I currently only executing it all in the ‘system’ organization of the platform, but keep in mind that the service containers in your own organization use the same database publication setting (by default enabled!).
Nice…learned something again today! “DONE”. The conclusion?…If you don’t want any database logging overflow of data, unmark the option in the ‘system’ organization for the ‘Logging’ service group! In later versions of the platform I see this is disabled by default, but I still see environments passing by where the option is enabled. Enabling it is not the problem but be aware what is saved with each service container and decide to clean it or backup it. That’s it for this week. I see you all in a next AppWorks Tips topic…next week.
Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?
