Groovy4, FastStringService, V.206, etc
I noticed in the detailed release notes for V.206 some discussion of Groovy2 vs Groovy4, because apparently at some point in the future Groovy2 may go away and so Groovy4 will be required. There is some info on mitigation, including updating official modules (with its usual issues, IMO) but also updating custom modules. But it looks like the latest collector doesnt force this now, but just supports both Groovy2 and Groovy4. But I want to move on this as soon as I can. So I did some testing on one of my custom groovy configsources and discovered that when I force the script to use Groovy4 (//!/lib-groovy/v4 on the 1st line) I get one of the errors mentioned in the release notes for V.206 ( https://www.logicmonitor.com/release-notes/v-206-release-notes ). Specifically "Unable to load FastStringService". But unlike some of the other known issues, no workaround or example was given. import groovy.json.*; def JsonSlurper jsonSlurper = new JsonSlurper(); def jsonParsed = jsonSlurper.parseText(responseBody) The first 2 lines are fine, so I believe there is nothing to be changed with how I'm importing it. The docs I see for latest groovy still show I'd use groovy.json.jsonSlurper. But the 3rd line in the code throws the "Unable to load FastStringService" error. So I guess I'm just wondering if the community has dealt with this specific issue, or if there is a document that contains a workaround for this case and others. I know LM will be updating their modules, or maybe they already have (I havent looked; their new Modules UI hurts my brain a bit, not looking forward to the old version under settings going away). But updating all our custom code is going to be painful. Somehow I didnt realize this conversion from Groovy2 to Groovy4 was coming, so I'm trying to figure out when that will be a hard line in the sand. But in the meantime, I'm just wondering if anyone has found a way around this issue? Thanks!Oracle jdbc JAR file update
LogicMonitor's collector utilizes an outdated version of the Oracle JDBC jar file. It's essential to upgrade to the most recent version available in the Maven repository to take advantage of new secure database connection types. However, users should note a significant change in behavior with the new jar: while the old version automatically closed abandoned Oracle database connections, the new version does not, potentially leading to an excessive number of open connections. This surge in open connections can overload and crash an Oracle server where connections aren’t limited by user. Therefore, clients must either ensure that customizations explicitly close database connections or adjust their server settings to impose limits on the number of concurrent open connections. All of the newest Logicmonitor datasources properly close connections but some of the older modules did not do this. Logicmonitor has created a module to test for this problem and alert if it occurs. Oracle_Database_MonitorUser will keep track of the number of connections in use by the monitoring user and alert if the number of connections is too high. This update is scheduled for collector 35.400. Make sure this module is installed before upgrading to collect 35.400 and monitor your database connections before rolling this out to general release.
