Linux, java 8.
We’ve discovered a memory leak that’s been of concern for some time now. By restarting the FC app numerous times I could easily watch the heap size increase until and out of memory error occurred. This will also naturally occur over the course of a few days normal running. (So I schedule a lucee restart every couple of days)
After removing the javaloader in farcrySorPro and converting it to createobject, it’s now seems impossible to cause the out of memory issue.
I also created a OSGI bundle for Tika 1.23 app and changed to using that as well.
I also added the changes from FC 7.4 into my 7.2 around removing the javaloader. (I couldn’t get the 7.4 branch to work for me, a mysql schema issue).
It’s worth noting I didn’t have this issue with CF11 and my fix having that OSGI bundle won’t work for CF.
So, fingers crossed that this is the end of the issue
Can you share the changes you made for FarCry Solr Pro & Tika so we can possibly work them into the plugin? We also have a site having some memory leak issues that we’ve so far been unable to diagnose.
@phillipjrasmuss Is there anything I can do to help get you on to p740 / 7.4? Is that a problem with the MySQL Gateway component, or something in your schema that is incompatible with what’s in p740?
The main idea with 7.4 is removing Java Loader so that Core is Java 11 compatible. Of course removing Java Loader means we needed replacement functionality for dynamically loading JAR files, so we have a convention where placing JAR files in a folder like plugins/myplugin/jars will result in them automatically being added to the Application’s javaSettings.loadPaths array.
@seancoyne You could make use of the above feature in the FarCry SOLR Pro plugin, and then you could just use createObject(“java”, …) directly on the Java package names for the classes you need to instantiate.
Looks like I needed to change 3 files;
cfsolrlib.cfc, configSolrServer.cfc, solrProContentType.cfc
It’s a bit messy as I just commented out the javaloader code (see the github below).
Also you’ll need to install the Tika OSGI bundle;
I added this to the /META-INF/MANIFEST.MF of the tika-app-1.23.jar file:
Bundle-Name: Apache Tika App Bundle
Bundle-SymbolicName: apache-tika-app-bundle
Bundle-Description: Apache Tika App jar converted to an OSGi bundle
Bundle-ManifestVersion: 2
Bundle-Version: 1.23
Then dropped it into the lucee-server/bundles folder.
@seancoyne The reason for OSGI bundle is that Lucee already had a Tika bundle (ver 1.10) in there that was overriding my createobject even if I added the link to the jar. So you might just be able to get away with it in CF.
@phillipjrasmuss Did you also try dropping the non-OSGI version into the “jars” folder in the plugin, or did you only place it in the Lucee lib folder? I’m not sure whether they would be looked up differently but it could be worth a try?
@justincarter No I hadn’t tried that. Mainly because at that stage I hadn’t added the 7.4 changes, I was just working on getting the solr plugin up and running. I’ll give that a go in the next day or so.
@seancoyne I may be missing something here. After removing the javaloader everything works great, and the memory issue has gone.
But…
After a few days (6 in this case) I get (see below).
It looks like when calling this <cfset response = THIS.solrQueryServer.query(thisQuery, methodClass.GET) />
that the THIS.solrQueryServer is not init. I can fix it but just going through the Solr Pro Plugin setting and hitting save. Any suggestions?
I guess I would start by try/catching that line and seeing what this.solrQueryServer contains. The error says it can’t find the method, I’m curious if that variable is being overwritten somewhere by something other than the Java library. The config has a “process” method that runs when you click save which re-inits relevant pieces so that would explain why that fixes it.
I should add, if you’re ultimately unable to track it down, you could try/catch that line, if it fails with that same error, then initialize the library (set the THIS.solrQueryServer variable) then re-run the query. That’s kind of a hack of a workaround but it should work.
@seancoyne Thanks I’ll give that a try and get back to you. I can’t reproduce it out side of my live environment. eg setting the application to expire quickly etc. So definitely a try block will be a good starting place.
I ended up putting a try catch in cfsolrlib.cfc in search() and then resetting the config. seems to work OK. This is in lucee 5.2, I have seen if it looses itself in 5.3 yet.
This is for the GET method… <cftry>
<cfset response = THIS.solrQueryServer.query(thisQuery, methodClass.GET) /> <cfcatch>
<cfset oConfigSolrServer = application.fapi.getContentType(“configSolrServer”) />
<cfset oConfigSolrServer.setupSolrLibrary() />
<cfset oConfigSolrServer.setupSolrDefaults() /> <cflog file="solr" text="Restart required">
<cfset response = THIS.solrQueryServer.query(thisQuery, methodClass.GET) /> </cfcatch> </cftry>
