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!
Ubaldo Lazalde Jr
·1 year agoIn case anyone else is still looking for a solution, I stumbled upon it being mentioned in the release notes of v.212. It is fixed in Collector version 36.200 or later, although I haven't tested this yet.
Fix is under "Setting groovy.v4.classloader.enable to true"
https://www.logicmonitor.com/release-notes/ea-collector-36-200
The Issue is listed under the v.212 release notes as a known issue.
https://www.logicmonitor.com/release-notes/v-212-release-notes
Lewis_Beard
OP1 year agoI'm glad I saw this. I'm in the middle of going through our hundreds of custom logicmodules and just got to the point where I'm having to edit the ones that break when forcing to groovy4 and it looks like most of my custom ones are breaking on the parseText bit .... I had totally forgot that I had made this post.
We stopped our collector updates except for required because we were afraid to take any collector updates until we were sure we are good. I guess I need to see what the official optional version is, it may be too late, I may have to update all mine manually.
Do you have a later version of the Agent.Conf, could you post the line that is in there.
I have a collector with only 2 devices I might try setting groovy.v4.classloader.enable to true on Monday, but for whatever reason, collector 36.001 doesnt have the line in there at all, either true or false.
Thanks. I guess Monday or so I'll just try it. Impact will be minimal if just slapping that in there breaks something, and I can rip that line right back out. :)
Ubaldo Lazalde Jr
·1 year agoWe are currently on collector version 37.002 and it's in the agent.conf file as line 841.
The notes mention it being added in version 36.200 and later so it makes sense that you don't see it in version 36.001. I imagine it's set to false by default which is why they explicitly add the line and set it to true.
I tested a couple of custom scripts that use JSONSlurper soon after we upgraded and confirmed it continued to work when forcing groovy4. I still need to check the rest of our scripts but so far so good.
Lewis_Beard
OP1 year agoI found out from my success rep that 37.002 has both v2 and v4 with groovy v2 default, and thats the version I could update to, so I did that today and it worked. Now I have the updates and that classloader item is present and set to true. So now all my faststring problems are fixed, and I was able to test them to make sure they work otherwise as expected.
I was warned that in April 37.003 will be coming as part of the Optional ones, and it will default to v4 groovy but still have both. So now that I've got my weekly update done and I'm on 37.002, I'm unchecking that and only taking required releases until I'm as certain as I can be that official modules, clones of official modules, custom scripts, and advanced netscan scripts (which I dont think I use) and everything groovy4 is updated or etc. I'm almost done.
And then at some point 37.100 will be the doom where only v4 is on the collector. And I think now the EA is up to 37.002 as of today. Now that I'm on 37.002 I'm going to uncheck everything except required updates until the doom comes in via required. :) Then there will be some amount of scramble if I missed anything. Ugh. :)
Thanks for the help.!
Jeremy_Riley
·1 year agoI'm having the same problem. Using general release collector 36.001 on RHEL7 Linux.
LM User
·2 years agoI had similar problems during testing and quickly had to put it on hold awaiting more information from LM. I opened a support case and they promised more.
APIv2/3, UIv3, Groovy2, Meraki, ESX, there are so many things that LM has had strong wording about migrating with little clarity on how it will happen successfully.
LM User
·2 years agoMeant to say APIv1/2 not APIv2/3. No editing possible even for 5 minutes after posted. Bummer.