[closed] Object broker and CF11 issue

Hi All,
Quite often when I do an update application on a FC 7.1.8 the Object Broker doesn’t start up. If you go to the Object Broker Settings page in the admin it’s all 0/0. Doing another restart of the application resolves the problem.
It’s not a critical issue but I was wondering if anyone else has come across this. It seems to only be on CF11.
Cheers Phil

I haven’t see anything like that, I’ll try to check it later today :slight_smile:

I can’t seem to reproduce this issue at the moment…

Can you try updating to 7.1.9? There was a fix to object broker for applications which had underscores in the name, but I think in those scenarios the cache puts and retrievals were always broken, rather than failing after an updateapp.

Otherwise, are there any other things you’re doing that are related to the updateapp that might play a part? Are you restarting the app because of code changes, or some other reason?

No underscores in the application name. I would normally update the app due to code changes but one thing I find with CF, if left running, it starts to run slower over time (ie a couple of months). This is something I’ve noticed from CF9 to CF11 so I sometimes cron a restart in the wee hours every couple of weeks. So it can also happen after a CF restart.

This particular server also tends to restart CF11 very slowly so I suspect my issue might be timing issue. In fact in all reality it’s quicker to reboot the server that restart CF in this instance. But that’s another issue :slight_smile:

Next time I see it happen I’ll take some screen shots and scour the logs for anything. Normally I’m pretty quick to restart the app to get that caching working again :sweat:

So we just put this in on a site, CF11 and FC 7.2.8, and we see all zeros as well (0/1000 or 0/500) or whatever we stated the max to be for that particular content type under “Object Broker Settings”. We are using bObjectBroker="true" objectBrokerMaxObjects="500" in our CFCs.

The webskin tracer is showing all “green” though for all of the webskins that have the cache decorator.

@@cacheStatus: 1 
@@cacheTimeout: 60

But showing all 0 or NA when “Show Webskin Detail” button is clicked next to the “type” under “Object Broker Settings”

We have not restarted CF.

This is our first time doing this so it could be that I am misunderstanding how object brokering works, but we should see some memory filling up correct?

I don’t think the ‘show webskin detail’ has ever worked. I really only use the object broker settings page for seeing the cached objects and the capacity.

FYI when it fails for me after an application start i get this: (doing another restart will generally get it back and running)

I’ve just done a pull request on objectBroker.cfc https://github.com/farcrycore/core/pull/55
This fix’s the issue I’ve had where the object broker fails (see above post). The issue occurs when;

  • I do a ‘Rebuild Site’ from the front end tray
  • Do a ‘Apply Default Resolution’ in the COAPI Overview page
    This occurs on CF11 and Lucee 4.5 so it’s not an engine issue. I’ll keep an eye out for the broker not starting up during application startup but that may be a separate issue.

Phil

The purpose of the flush argument is specifically to clear the objectbroker
cache. That is why Rebuild Site and applying schema changes are passing in
the bFlush argument. Unfortunately, your change would stop that from
working.

A better approach would be to add a function that creates a replacement
objectbroker structure (using the structure defined in configureType as a
guide) with empty aobjects arrays, and calling that in cases where
application.objectbroker already exists.

Blair

Ok, then how about we go back to resetting application.objectbroker on objectbroker.init() and then rebuilding it the same way that is currently in the application.cfc. Then we can remove that code from the application.cfc and just rely on the objectbroker.init() to build or rebuild the application.objectbroker struct. So between the if statement would be:

<cfset application.objectbroker = structNew()>            			
			<!--- This Java object gathers objects that were put in the broker but marked for garbage collection --->
			<cfset application.objectrecycler =  createObject("java", "java.lang.ref.ReferenceQueue") />
			<cfif structKeyExists(application,'stcoapi')>
			<cfloop collection="#application.stcoapi#" item="typename">
			<cfif application.stcoapi[typename].bObjectBroker>
				<cfset configureType(typename=typename, MaxObjects=application.stcoapi[typename].ObjectBrokerMaxObjects) />
			</cfif>
			</cfloop>
			<cfset configureType("config", 100) />
            <cfset configureType("navid", 1) />
            <cfset configureType("catid", 1) />
            <cfset configureType("fuLookup", 10000) />
            </cfif>

I’ve added a structKeyExists(application,'stcoapi') check otherwise the application won’t initially startup.

1 Like

Thanks for tracking down how to reproduce the problem Phil :slight_smile: Happy to merge your final pull request whenever you have time to get to it!

Done :slight_smile:

2 Likes

Woohoo :slight_smile: It’s merged, thanks Phil! I’ll try to wrap up a tagged release next week.