Orphan Message Cleanup Approaches
Hi all.
Recently, I have noticed Scott Roth's mission to resolve issues with Orphaned messages with a lot of focus on prevention, and I envy that level of dedication.
Not wanting to be left out, this has sparked an interest in checking my environments for orphaned messages. Amongst a few different posts on the subject, I came across this post from Suriya Murugan in 2016 that included an interesting class in a Github Gist that seems to be built to do a deep dive into the identification and cleanup of Orphaned Messages.
My question is - is this still considered an appropriate way of cleaning up a namespace's amassed orphaned messages? Other approaches seem to focus heavily on HL7 2.x messages, but a lot of the orphans in my environments are most likely from custom classes that contained the odd steam object without an appropriate %OnDelete classmethod included.
Comments
In this post https://community.intersystems.com/node/539431 from Apr 6, 2023, @Mark.O'Reilly9949 mentions building a custom function to Purge Custom Messages using a Data Lookup table. However, it does delete by message count and not by days, which is something I am not fond of, and I haven't been able to get it to work for our needs either.
Thanks Scott.
I'm also not rushing to delete based on counts, but it's still interesting to review.
I ran the "Complete Ensemble Message Body Report" from Suriya's post's Gist against a namespace and it ran for about 8 hours, which now has me nervous to run the Delete option. Although, to be fair, this is a namespace that has been in operation for about 10 years, so I might start smaller and work my way up.
In my adventures, I broke down our BPL's to see where the Custom Message Classes were leaving the Orphaned messages.
Within BPL's make sure if you use Context Variables none of them are sent to "Instantiate", if you end up not using that context variable it will leave a blank (orphaned) message.
Also pointed out by others was not to have the Response object be anything other than Ens.Response. Any other type would cause an Orphaned message created even if you don't use it.
I also took it upon myself to make sure any context variable (message class) that I defined, I set to "" after using it.
Also pointed out by others was not to have the Response object be anything other than Ens.Response. Any other type would cause an Orphaned message created even if you don't use it.
Is this true even when the response object extends Ens.Response? That's a bit surprising ...
I was sending callresponse objects back to Ens.Response, but ended up removing those since I was not capturing any response from our JDBC Microsoft SQL Stored Procedure calls.
You can't leave the Response blank in the settings on the BP, so while not ideal Ens.Response might be created.
Just my experience. Unless anyone has any other suggestions....
What was the actual class of the response object?
I had a context variable set to Ens.Response, then when I would make my calls to the BO to execute the Stored Procedure on MS SQL, I would set the Response even though I did not expect thing to Ens.Response and my context variable to callresponse.
Then return Ens.Response at the end of the BP. I figured since it was blank it was not needed and would be creating additional Ens.Response objects.
So I removed the callresponse from those calls that I did not expect anything back from like inserts, etc... because if there was a SQL error the status and error would of be sent back to the BO anyway.
The response from the Stored Procedure was not in the form of an object?
Correct. the Response from the Stored Procedure was just a %Status.
Hi:
The reason for counts rather than days was a more granular approach to deleting data with no day information about it i.e. Stream data which would not have a date assigned to it.
Also a lot of custom data ends up in the same table if you don't define a new location for the message data. This would cause an inability to run proper sql against it to clear out the data so a count based approach of where the last message id was required