919 - 926 - 9847

FarCry 6.x tip of the day

I ran into an issue yesterday that I've not seen before.  I was greated with "fuName" doesn't exist in struct (blah,blah,blah) when editing an object in the webtop.  This object had been edited within the last few days, and I know that I had pushed up a new property to that object name "fuName", but it shouldn't have been an issue.  Editing a random object in the same worked fine, but it was just this one object. 

I reinitialized the application, I cleared all my cache.  I restarted the J2EE service, and apache.  I cleared out over cache folder I could find, but nothing worked.  It was until I started breaking everything out line by line from the error trace that it became apparent that the system was seeing a cached version of the object "somewhere".  That somewhere turned out to be dmWizard. 

So, it appears the dmWizard object holds a cached version of what your working on... but I've not really dug into "why".  Regardless, it was a pretty simple fix, but not simple to find.  If you should ever see the same situation as above, just clear out all the entries in dmWizard and you should be good to go!

Odd FarCry 3.1 problem on CF 9

By way of the grapevine, I was hooked up with a client in DC that had upgraded their server from CFMX 7.x to CF 9.x.  There were some issues with built-in functions in the older FarCry code, but that was corrected by the team at Myriad.  The front end was working fine, but the FarCry admin was giving a blank page.

In the past, I've seen this with older versions of Railo and built-in functions clashing, and that was the assumption I went with.  Alas, that turned out to not be it.  However, there were clues in the error logs of the CFadmin.  Essentially, it was going into an odd loop looking for a file called "apps.cfm".  Ahhhh, that file.  It's been a while, but that file controls how the admin finds projects against the URL you're coming in from.

Once I put a call to <cfset stApps['site.local'] = 'farcry_site'>, the FarCry admin started working on my local test.  Rock on! 

It was a fun little adventure for a weekend.  I thought, should anyone else run into this, it'd be nice to document it for future reference.

Gobless you Daemon, and Gobless open source UPDATE

Continuing further down this rabbit hole, it appears that a "webskin" is NOT the same as an "object". Although you can limit the amount of "objects" being cached, there's presently no means to limit the amount of "webskins".

What does that mean?

Basically, object broker is aware of my HTML objects, like my search page. It is NOT keeping track of the various views that object might have, meaning my search page has dynamic variables that changes what's displayed. Since that search page changes based on a set of variables (keyphrase, page number in the result set, etc), it's possible to have more than one webskin cached. In my case, things started going to hell after about 3000 cached pages or 400 megs of memory cache.

As much as I'd like to cache search page results, this particular client isn't going to get that goodness without forking over money for more memory at this point.

It doesn't look like this is high on the priority list for change for Daemon, but I think it'd be beneficial to limit the amount of cached webskins (or size) as well. If I can scrape together enough free time, I'll see if I can pull that off.

FarCry: admin redirect for Railo, and error handler update

So, first item of business. The /farcry/core/webtop folder for FarCry is a real pain to remember, and clients loath having to type that out all the time. To get around this, you're going to need to make the following edits. NOTE: This assumes that you have Apache, rewriting enabled and Railo as your CFML engine. It can be easily adapted to other engines and webservers.

You'll need to open up the webroot/farcryConstructor.cfm file first.


<!--- find this --->
<cfset THIS.webtopURL = "/farcry/core/webtop" />

<!--- change to this --->
<cfset THIS.webtopURL = "/cmsadmin" />

Next, we're going to add an Alias to our web server. You'll need to adjust this if you're using IIS


Alias /cmsadmin "C:\<sitehomes>\<myproject>\farcry\core\webtop"

Our last step is going to be a CFML mapping. In Railo, you visit your http://site/railo-context/admin/web.cfm. Go to the mappings link, and add a resource for /cmsadmin and C:\\\farcry\core\webtop. If it doesn't exist, you'll see a nice red tinge to the box that you entered the path into.

Update your FarCry application, or restart your CFML engine

Bob's your uncle, you should now be able to now browse http://site/cmsadmin and see the FarCry admin!

Second order of business, dealing with the default error handling. It's really great to see what's going when something breaks, it's really BAD for other people to see this in production. It's pretty simple to resolve. The below code will still allow for you to see errors when running test locally, but send all server based errors to email.

Find your webroot/Application.cfc and make the following edit


<!--- find this --->
<cfset super.OnError(argumentCollection=arguments) />

<!--- replace with --->
<cfset var machineName = createObject("java", "java.net.InetAddress").localhost.getHostName() />
        <cfif machinename contains("<server name... use cgi variable to get this>")>
            
            <cfmail from="<valid mail>" to="<valid mail>" subject="ERROR - <sitename>" type="html">
            <cfdump var="#url#">
            <cfdump var="#session#">
            <cfdump var="#arguments#">
            </cfmail>
<!--- send to an error page... need to make this--->
            <cflocation url="/site-error" addtoken="false">
        <cfelse>
            <cfset super.OnError(argumentCollection=arguments) />
        </cfif>    

Gobless you Daemon, and Gobless open source

I've been tracking down a funky memory issue as of late, and it's down to some of the caching being done on one of my FarCry HTML objects. Essentially, the PS Old Gen fills up, and during the course of trying to run a GC on it, one of my four CPU cores just goes AWOL. I'll kill the thread in htop, and the Resin watchdog service will automagically fire back up, and within about 3 minutes we're good to go.

After having something concrete to pass to team Daemon, I'm truly thrilled to have gotten a response back in just a few hours time. Turns out, Daemon has already been working on the objectBroker caching abilities. They now keep a watch on memory use, and automatically start clearing objects out of cache should memory start to go downhill.

I've been watching FusionReactor off and on for the past 3 hours, and I think this fix has nailed the problem. Before, a GC wouldn't bring memory down past 70% or so. Now, it's coming back down to 50%. Combine that with FusionReactor watching for super long running requests, and I think I can now go back to my customer and tell them we can expect no more major slow downs or memory issues. I love open source communities!

If you're looking for this fix, you can find it in both the p610 branch and p600 branch

Railo scope dumper

I'm presently trying to run down a memory (perceived) leak issue on an application that I've hosted for 3 years. In the past 3 months, this app has moved to the FarCry framework from a... less than stellar homebrew solution

At first, I thought it was Lucene shorting out, but I didn't have anything concrete beyond the amount of traffic hitting it. I installed FusionReactor, and although it's very helpful to watch the graphs, it still didn't give all that much accuracy into what was going on. Until...

A heap dump from yesterday revealed that railo.runtime.type.scope.ApplicationImpl had grown to 450 megs for just one site (the one converted recently). After asking around the Railo list, this object appears to be the application scope. Further suggestion was to loop over the keys, and use the built-in sizeOf and countOf functions to see what's going on (yay Railo!).

With some manual dumping of those keys, it appears that the cached HTML object types had grown far beyond expected. Way, far beyond. Ooops. So I cleared the cached objects, and poof, memory was manageable again.

So, on to a handy little file/CFC that will dump out scopes in Railo (I don't think these functions exist in Adobe CF, but I've not tested yet). Much thanks to Gert Franz, Michael Offner, Jay, and Peter Boughton (especially for those key loops Peter!)

First, you need this template. scopeDump.cfm


<!--- instantiate scope object --->
<cfset oGetScopeDetail=createObject("component", "scopeDump")>
<cfoutput>
<form action="" method="post">
<!--- set what scopes you want to dump --->
<select name="scope" id="scope">
    <option value="application">Application</option>
    <option value="session">Session</option>    
    <option value="cgi">CGI</option>
</select>

<input id="submit" name="submit" type="submit" value="GO!">
<cfif structkeyExists(form,"submit")>

<!--- You MUST get the struct to pass into the function --->
    <cfset stScope=oGetScopeDetail.getDetail(structGet(form.scope))>
    <cfif structkeyExists(stScope,'countOf')>
        <p>Count of #form.scope#: #stScope.countOf#</p>
    </cfif>
    <cfif structkeyExists(stScope,'sizeOf')>
        <p>Size of #form.scope#: #stScope.sizeOf#</p>
    </cfif>
<!--- Looping over the returned objects in the structure --->
    <cfif structkeyExists(stScope,'aItems')>
        <table border="1">
            <tr>
                <td>Item</td>
                <td>Count</td>
                <td>Size</td>
            </tr>
            <cfloop from="1" to="#arraylen(stScope.aItems)#" index="i">
                <tr>
                    <td>#stScope.aItems[i].name#</td>
                    <td>#stScope.aItems[i].countOf#</td>
                    <td>#stScope.aItems[i].sizeOf#</td>
                </tr>
            </cfloop>
        </table>
    </cfif>
</cfif>
</form>
</cfoutput>

You'll also need this little CFC, scopeDump.cfc


<cfcomponent displayname="scopeDump" >

    <cffunction name="getDetail" access="remote" returntype="struct">
        <cfargument name="scopeVar" required="yes" type="struct">
        
        <cfset var rStruct=structnew()>
        <cfset rStruct.countOf=numberformat(StructCount(arguments.scopeVar),',')>
        <cfset rStruct.sizeOf=numberformat(SizeOf(arguments.scopeVar),',')>
        <cfset var aItems=arraynew(1)>
        <cfset var stItems=structnew()>
        <cfset var tmp="">
        <cfloop item="CurItem" collection=#arguments.scopeVar#>
            <cfset stItems.name=CurItem>
            <cfif isStruct(arguments.scopeVar[CurItem])>
                <cfset stItems.countOf=numberformat(StructCount(arguments.scopeVar[CurItem]),',')>
            <cfelse>
                <cfset stItems.countOf=0>
            </cfif>
            <cfset stItems.sizeOf=numberformat(SizeOf(arguments.scopeVar[CurItem]),',')>
            <cfset tmp=arrayappend(aItems,structcopy(stItems))>
            <cfset tmp=structclear(stItems)>
        </cfloop>
        <cfset rStruct.aItems=aItems>

        
        <cfreturn rStruct>
    </cffunction>
</cfcomponent>

Facelift (mostly) complete

It's been a long time since I've done a site redesign. I've split off "me" from "business".

Part of this process was moving my blog to a subdomain of my main site. I've thought about making this change for years, but the time has finally come. I really want to be more visible in the hosting/site development sphere, but it's doubtful that those end users really care about my chuck e' cheese experiences ;)

One thing I didn't want to do was lose any traffic (not that I get all that much). So I stumbled around the intertubes for a bit to come up with this


RewriteCond %{REQUEST_URI} (^/blog)($|/)
RewriteRule ^(.*)$ http://matthewwilliams.geodesicgrafx.com$1 [R=301,L]

The above redirects where my blog used to be, geodesicgrafx.com/blog to matthewwilliams.geodesicgrafx.com/blog. In theory, it should change all the search engine links to point to the new address, but there's not much I can do about links out on other pages. Provided I never make a new blog at the old address, it should be fine.

Time to housekeep

It's time to put a new face on the blog and the site. And, to try and get it out there that I'm looking to bring in more hosted customers that like Railo hosting with a small business ;). I'll be switching everything over to a 960gs template just as soon as I get a few projects cleared off my plate.

I also offer custom FarCry solutions, with Social Networking components, e-commerce, blogging, etc. PHP and static sites are welcome as well! I currently host in eastern US, and UK. Signing up through the month of September means no setup fees! You just need to use newfreesetup at checkout time.

I suppose it helps to mention that information can be found at my hosting portal

Been awhile. New FarCry hack for the objectadmin

Under the new 6.x builds of FarCry, and object edit overlay (which is quite handy at times) always pops up on object edit. However, this can be tedious at points. Want to change that behavior? Well, here's one way to do so.

1. Create an edit.cfm for your content type, in this case mdwArticles. In this code have a process form that looks like this (note the return="true"):


<ft:processform action="Save" exit="true" return="true">
<ft:processformobjects typename="mdwArticles" />
</ft:processform>

2. Modify (or make a copy in your project being the better answer) /farcry/core/tags/formtools/processform.cfm:

Add the webskin tag


<cfimport taglib="/farcry/core/tags/webskin" prefix="skin" />

Add a new attribute


<cfparam name="attributes.Return" default="false"><!--- Return to objectadmin --->

After the code block (don't forget the if)


<!--- Return to the objectadmin --->
<cfif structKeyExists(attributes, "Return") AND attributes.return EQ 'true'>
<cfset attributes.exit = true />
<cfset stLocal.onExitProcess = structNew() />
<cfset stLocal.onExitProcess.Type = "Return" />
<cfset stLocal.onExitProcess.Content = "" />
</cfif>

And finally, you need a case to handle the return ()


<cfcase value="Return">
<cfif structKeyExists(stLocal.stOnExit, "Content")>
<skin:onReady>
<cfoutput>

parent.$fc.objectAdminActionDiv.dialog('close');
</cfoutput>
</skin:onReady>
</cfif>
</cfcase>

FarCry 5.2 + Railo 3.1.0.16 + Resin + Apache + MySQL + CentOS - Addendum 1

I had an "Ah HA!" moment when I got home tonight. I copied in my FarCry core folder from my known good Ubuntu Railo/FarCry install over to my CentOS install and still had issues. I tried several iterations of this, and then I had a think. I pulled up the Railo admin on my Ubuntu install, and noticed I had it at .012. And then it hit me... I was actually in a discussion about this with others on the google groups. I thought I had tried it at 3.1.0.016, but I think I did not complete the upgrade step.

So, I copied the .012 install of Railo over to the CentOS box and it worked! Huzzah! So, it appears that .012 remains the most supported version at this point in time. I'm hosting a copy of this file on my site, but please be gentle! I don't want to hear it from my host that ya'll are killing my server. You can grab the file here.

More Entries