@danmurphy I'm not quite following that, but all handler caching does is make the handlers singletons, as opposed to re-created each request. Perhaps check for var scoping issues?

We really dug through that to see if there is anything but couldn’t find the culprit (well, besides the injected Service property).

Yeah, I still don't understand your problem, lol. You say you're getting the same result back from each method, but your running the same code in each method. So... yeah... 🤔

They are passing very different params in both cases.

I'd say it looks like var scoping issues in

myService

or downstream of that

So you’re saying

myService

is being injected as a singleton because handlerCaching is on, which makes the handler a Singleton. Gotcha, good to know.

I wouldn't use the words "injected as a singleton", but yes it's potentially a scope-widening injection if you weren't expecting it

This is the actual entire list function. Does anything stick out for var scoping issues?

component {

	property name='jira' inject='coldbox:setting:jira';

	function init() {
		return this;
	}

	function list( required jql, maxResults = 50 ) {
		cfhttp(
			method   = 'GET',
			url      = 'https://' & jira.hostname & '/rest/api/2/search?jql=' & arguments.jql & '&maxResults=' & arguments.maxResults,
			charset  = 'utf-8',
			username = jira.username,
			password = jira.password,
			result   = 'result'
		) {
			cfhttpparam(
				type  = 'header',
				name  = 'Content-Type',
				value = 'application/json'
			);
		}

		if ( result.statuscode EQ 200 ) {
			var content = deserializeJSON( result.filecontent );
			result.append( { 'total' : content.total } );
			result.append( { 'issues' : content.issues } );
			return result;
		} else {
			return result;
		}
	}
}

result

isn't varred

Does the result need to be vared somehow?

That'st he easiest

Is there a better way then?

Also, you should test the singleton leak detector, even though it wouldn't recognize that CFC as a singleton since it's not annotated.

Yeah, that’s what I meant (the result = ‘local.result’)

Yep, that's the module

Thanks a ton Brad!

The only trick is you have to hit the pages/CFCs/code in question for it to catch the leaks

We have some tests around some of this (I think) so that should work?

That is tricky-- test cases are a great way to hit all the coverage, BUT ... • they need to be integration tests that load the full framework • the leak detector needs to be installed and loaded in the coldbox instance that the tests are running in • your tests need to NOT unload ColdBox at the end

I used to work on an app where pretty much all model CFCs were singletons for performance reasons. We built variables scope leak detection into our testing infrastructure, because devs would forgot to do the var-ing thing and poke themselves in the eye.

Sure enough, adding changing the result parameter to

local.result

makes it all work as expected. Man, good lesson learned. Now to go search for other uses of cfhttp, cfexecute, cfldap, etc. where they just have a return variable and we’re probably not scoping it…

@danmurphy You probably have a var that's null and I need to add a null check to that code

If you have something you’d like to change it to to test out a fix, let me know and I can throw it in there.

@danmurphy What CF engine/version are you using?

Lucee 5.3.9.141

Do you have anything funky like full null support turned on?

We do not.

Ok, I think that was just the Adobe version I was testing on being weird

This happened immediately after a fwreinit and is the same no matter how many pages I visit first before going to the

/leakDetector

url (which sounds like something I could’ve used when we still had babies in diapers).

Yes, I know

Coming up now!

The module is very simply really- there's not even that much code

It did find a legit one though!

EXECUTIONTIME

was another one I already ignore. There was some tag in CF that always created that variable regardles

It isn’t finding the one that started this thread. If I give it the Singleton annotation, it does find that one too.

Yeah, it only introspects • handlers • CFC's with the singleon annotation

(Which I think we tried to fix this issue at one point by marking it not as a Singleton, but that was probably silly of us).

I just pushed a little update to ignore

cfquery

Honestly, the whole Singleton thing still confuses me. 😬 Is there a “talk to me like I’m 5” statement for when objects should be Singletons or not?

Are you asking how singletons are treated or the reason why you'd want them to be treated in that manner?

Why you’d want them to be treated in that manner or not.

Honestly, in many cases it doesn't really matter. If a singleton doesn't actually store any state (variables) that it needs to mutate over time then you could re-create the CFC every time you wanted to use it and it's not like it would behave any different outside of the unnecessary overhead of CFC creation on every use.

So basically, Beans aren’t Singletons for sure. Everything else should be.

And technically the user example isn't even a scope-less instance. single and transient are the most common scopes, but

session

is also a scope you can ask WireBox to store a CFC in automatically

A good test could be to explicitly mark all the things as Singletons if they aren’t already (services, DAOs) and then run this leak detector.

If you had something like this User.cfc

component scope="session" {
}

Then you can just do

currentUser = getinstance( 'user' )

and wirebox will give you the current user for that session, creating it if necessary

We’ve never used scope on a component like that before. Huh.

I have to run-- picking up kids from school time...

No prob. Thanks Brad!

@danmurphy The detection to tell if a variable changed is very simple

oldValue.toString() != scopeValue.toString()

the best thing to do would be to add

property name="allowedFilters";

to the CFC and the leak detector will start ignoring it

You're awesome!