Want to make Homesite+ the viewer used by IE's "view source"? Edit the following registry key to be the path to Homesite and you're all set! HKEY_LOCAL_MACHINESoftwareMicrosoftInternet ExplorerView Source EditorEditor Name(Default)

As a result of the CFMX/Commonspot upgrade I blogged a few days ago, I've been troubleshooting some CFMX crashing problems along with "java.lang.OutOfMemoryError" errors and have been tuning the JVM settings for the servers. Along the way I ended up doing a good bit of research on JVM settings and what the differences are between the Heap Size and the MaxPermSize. It's fairly well documented on various blogs and discussion lists that both the JVM Heap Size and MaxPermSize are important when dealing with "out of memory" errors in CFMX, but I've never really completely understood what these setting or their values mean. First off, what is the JVM Heap? The heap is memory that's been allocated to store Java classes and objects. The JVM heap is split up into several areas and newer/older objects are shuffled between the sections based on their age and use. The shuffling of object occurs during Garbage Collection, a process which also discards objects which are no longer used. Depending on system settings, garbage collection runs now and then, cleaning up objects and shuffling them around. More great information on Garbage collection in CFMX can be found on Brandon Purcell's blog and in Sun's tuning article on garbage collection (via Tom Link). About heap size - it's generally a good idea to set the JVM's max heap size to at least 512, and no matter what the max is, the initial heap size should be set to the same value. Making these settings the same value prevents the JVM from frequently re-sizing the heap as it grows, something that can trigger frequent garbage collections and can degrade performance. So when does it make sense to increase the JVM heap to a value larger than 512? Generally, no-one cares about this value till they start to get java.lang.OutOfMemoryError messages, and perhaps that's why you are reading this. If the JVM heap size is set too small, the server's memory slowly fills up and eventually an object is created and there's no more room in memory for it. This becomes the proverbial straw that breaks the camel's back and will cause your server to crash. Inversely, if you set the value too high, alot of junk objects build up in the heap and garbage collection can take a long time cleaning it up. This can cause a serious degradation in performance. Again, I'll point at Brandon Purcell's blog for more help in finding the right size for the heap, though it also work to just adjust the heap size and watch the server for errors or performance problems. That's a description of the heap, but what about this other setting set with -XX:MaxPermSize? Turns out this sets the size for something called the "Permanent Generation". A good definition for the Permanent Generation is found in the Sun article Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine:

The permanent generation is used to hold reflective of the VM itself such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations. Generally, sizing of this generation can be ignored because the default size is adequate. However, programs that load many classes may need a larger permanent generation.

So the permanent generation contains information about the objects in the heap. Ah-ha! Now we can start to understand how these two numbers are related to each other. The heap stores the objects, and the permanent generation keeps track of information about the objects. Consequently, the more objects there are in the heap, the more information there is to be tracked about them, and the larger the permanent generation needs to be. Another quote from Sun's documentation comes in handy here:

For most applications the permanent generation is not relevant to garbage collector performance. However, some applications dynamically generate and load many classes. For instance, some implementations of JSP(TM) pages do this. If necessary, the maximum permanent generation size can be increased with MaxPermSize.

This also applies to compiled ColdFusion class files. If there are alot of class files in /coldfusionmx/wwwroot/WEB-INF/cfclasses/, then you'll likely need to increase the MaxPermSize setting. Following this logic, if you have an application server with a large number of small class files, you are likely to need a larger MaxPermSize than if you have a server consisting of a small number of large class files. Note: Instructions on increasing the MaxPermSize are found in this ColdFusion MX: Tips for performance and scalability Technote. As it turns out in my recent Commonspot/CFMX upgrade, the new codebase must have generated more classes, or at least had more information generated by those class files. Even though the heap size was still large enough after the upgrade, I had to change the MaxPermSize from 128 to 256 to make the java.lang.OutOfMemoryError plaguing the site go away. Hopefully this explanation will come in handy for others tuning their memory settings! Added 4:14PM 5.28.04 Note: Important tidbit I forgot to add into this post initially - The MaxPermSize is in addition to the Heap, so if you add both of the numbers together you'll get the total size Jrun/CF should consume before blowing up.

Significant parts of Conyers Ga are being evacuated due to a huge fire at the Biolab chemical plant and distribution center located there. An area of at least a mile around the plant has been evacuated, and reports indicate that the plume of smoke can be seen from as far away as Atlanta (45 miles away). I-20 has been closed in both directions by the plant and I've seen reports of the fire on both CNN Headline News and Fox News Channel. So far no-one has been reported injured aside from some smoke inhalation injuries. This news is of particular interest because I did ColdFusion programming work for Biolab for the better part of 2002, including working on some warehouse management portions of their ERP system. I'm still good friends with most of the folks I worked with there and I hope that everything will turn out ok for the company and its employees.

Ran into an unusual problem last week while upgrading Commonspot 3.2 SP2 to a 3.2 SP4 and CFMX 6.0 to CFMX 6.1. Thought I'd drop it into the ole blog in case someone else runs into this problem. After the upgrade everything seemed fine except replication. Having dealt with a number of replication problems in the past I wasn't totally shocked by this, but the error wasn't one I'd seen before. In the application.log file, I uncovered the following: "Error","jrpp-47","05/19/04","10:29:38","CommonSpot","CFID, CFTOKEN contains invalid characters. This exception is caused by either broken links, or security attacks. The invalid id is 370db970662a6471%2D9D91146A%2D96A6%2DEFAB%2DDC215EC73B22393D The specific sequence of files included or processed is: /xxx/xxx/commonspot/sync/sync-process-requests.cfm" After decoding the URLFormatting of the string, I found that the invalid CFTOKEN being passed was 370db970662a6471-9D91146A-96A6-EFAB-DC215EC73B22393D. It's pretty apparent that this is a UUID with some sort of rouge data appended to the front of it. The reason that this might throw a ColdFusion error is somewhat documented in the following forum post by Christian Cantrell. From the looks of it, anytime ColdFusion gets a CFTOKEN or CFID value in a format that it doesn't expect, it blows up. In this specific case, it may have been because the CFTOKEN contained lowercase text, or perhaps because the format of the string was unexpected. Either way, it made CF break. So I knew why ColdFusion blew chunks, and just had to wait for Paperthin to get back to me on why Commonspot might have passed this CFTOKEN value during replication. Side note: For those who've not dealt with Commonspot's content replication before, it's essentially a process where an authoring server "replicates" approved content to one or more "target" content servers. There are a few choices on how to have Commonspot move the data, including FTP and HTTP (CFFTP and CFHTTP). The content to be replicated is zipped up and transferred to the target server, then unpacked and distributed to it's location in the database or file system. Back to the problem - I finally heard back from Paperthin about the root case of this issue. Turns out that Commonspot tracks CFTOKEN/CFID pairs within the replication process so that the repeated requests between the authoring server and target server(s) don't startup a buncha phantom sessions. Somewhere along the way, their tracking of the CFTOKEN got munged and the replication process started feeding the invalid value to the target server. This halted replication in it's tracks. Paperthin sent over a couple of patches to solve the problem, and I also ended up turning off the "Use UUID CFTOKEN" option in CFMX's admin. One of those two things fixed the problem, though I am uncertain which it was. Hopefully this little tidbit of information will help out someone else in the future...

As blogged in a few other locations, a new CF resource is out here in the form of Tim Buntel's Blackstone Blog. For those who have been living under a rock, Blackstone os the codename for the next verison of ColdFusion. As demonstrated at the WorldWide User Group meeting last week, some of the expected featureset may include a new PDF generating CFDOCUMENT tag, a Flash attribute for CFFORM, and possibly (gasp) sourceless deployment of ColdFusion applications.

Google's Gmail makes hit number two for a very successful marketing tactic. It's not a new tactic, but it's been proven particularly effective for the search giant. Google's created so much buzz surrounding Gmail that people are willing to give their left arm for an account. But why? Gmail is just webmail right? I mean, it has alot of storage, that nice. But it's still just webmail. So why are people going crazy to get an account? Because you aren't allowed to have one! Yes, you might be the best geek around, have all the latest gadgets, but the sing-song voice in your head is chanting like kids on playground "Neah-nee-neah-nee-neah-neah you can't have an account!". So you want an account! You have a cell phone that takes pictures in the dark, a laptop that can connect to the internet from the south pole, and can track your GPS location within one yard - BUT YOU CAN'T HAVE AN ACCOUNT! But wait, there's more. How to frustrate a self declared metrosexual (technosexual?) even more? Give out a handful of accounts to one of the most vocal communities around - Bloggers. Now everywhere you turn, bloggers are posting about Gmail. Gmail this and gmail that, but you still can't have an account! But I mentioned that this is hit number two. Though the shine's worn off a little, Google's Orkut has followed the same path. You can't join Orkut unless you know someone else who's already a member. And the timing could be better! Google's pending IPO promises to be a huge event, and don't expect the announcements to stop coming. The carrot and stick approach has worked well so far. Expect to hear more of this before they offer up any stock.

Last year this event included 184 User Groups from all over the world with a combined attendance of more than 7500 individuals! The local San Diego MMUG is also planning on joining us for the event, and I'm extending to invitation to a few other groups in San Diego as well. Hopefully we will get a great turnout, this event has the potential to attract almost as many as the March Mingle did a few months ago when 150 people showed up. On a related topic, I've heard a little grumbling from other CFUG managers about the content of the Worldwide User Group meeting last year. MMUGs want more tools presented, CFUGs want more ColdFusion presented, Director User Groups want more Director... The fact is that the meeting's topics will certainly vary again this year and include Dreamweaver, Flash, Contribute, Flex, as well as ColdFusion. My hope is that this meeting will serve as a mixer for those technologies, allowing everyone to see something new from technologies they may not use every day. Of course, they are probably going to also learn something new about products they do use. The key in satisfying your User Group is simply to tell them upfront. "Warning! You are going to learn cool new things about products you may not use!" I'm excited to see what's in store for the next product cycles! I think User Group members will be too! On another slightly related topic. I've made a few changes to the SDCFUG website to reflect the secured nature of our meeting location. I was very disappointed to get an email after the most recent presentation from someone who'd arrived a little late and was locked out of the building. I've added a new map, directions, and phone numbers to call in case you are locked out when you arrive. We also have some new good news on the meeting location. I found out today that due to our host, Booz Allen Hamilton, is willing to supply us with food during some of our larger meetings. This is great news, and very much appreciated! We also now have access to the parking structure next to the building!

As many may have seen on various postings and email lists, Gestaltech (Guy Rish's company) and R337 Consulting (Matt's Liotta's company) have formed a partnership called RichPallette and from that partnership are developing a new ColdFusion IDE based the popular Eclipse IDE called He3. Some of the planned highlights include built in support for Fusebox4 and Mach-II, expression builders, and support for debugging and CFC development. Knowing both Matt and Guy's participation in the Blue Dragon community, though not formally announced, the tools will undoubtedly also include tight support for New Atlanta's Blue Dragon as well as Macromedia's ColdFusion. Price points for a final product haven't been disclosed yet, but it definitely promises to be a strong competitor and perhaps even a replacement for aging but much loved ColdFusion Studio/Homesite+. Word on the street is that the beta for He3 will start at the CFUN-04 conference with all attendees receiving a beta CD. Interested? Email info at richpalette dot com to get updates and information about the IDE.

Last night we had a great turnout for our May SDCFUG meeting! We had a triple threat of speakers including Sean Corfield on Mach-II, Mike Hamilton on RoboHelp, and Silke Fleisher on RoboDemo. The audience contained alot of regulars, but a quick poll indicated that about half of the attendees were first timers - always a good sign for a growing group! We also had several people travel from out of town including Mike Brunt and Patrick Quinn from Webapper in the LA area and Rob Brooks-Bilson and a co-worker from Amkor all the way from Phoenix Arizona! I had a few worries considering that we had 3 speakers and only a couple of hours of time. It actually turned out perfectly with both Robo Presentations taking about half and hour and Sean's Mach-II talk taking just about an hour. I was also worried that some attendees would show up just for one of the three topics and be bored or uninterested in the others. This worry was also unfounded as everyone in attendance seemed to enjoy all the presentations, asking alot of questions as they went along and most taking notes throughout the meeting.

Haven't posted in more than a week, partly due to a friend being in town and spending a good amount of time at the beach and at the Coachella Music Festival. If you ever get the opportunity to attend, I very highly recommend Coachella. It's totally restored my faith in the industry's ability to create good music and shun manufactured pop stars. Located near Palm Springs CA in the high desert, both days were packed with people (50,000 - 60,000 according to an MTV.com writeup), hot as a mofo, and totally worth it! There were 5 stages with so much good music that I found myself wandering from one stage to the next attempting to catch a taste of all the acts I wanted to see. The complete setlist is on the Coachella site, of which I was able to see only a small percentage including DJ Peretz (Perry Ferrell), Death Cab for Cutie, Heiroglyphics, Pixies, Radiohead, Sage Francis, Dizzee Rascal, 2 many DJ's, Crystal Method, Atmosphere, Basement Jaxx, Antibalas Afrobeat Orchestra, and Danger Mouse. Unfortunately, I missed a few acts I would have liked to have seen including The Cure and Beck. I also had the unfortunate experience of having my eardrums pummeled by angry political spoken word from Saul Williams. If you have the chance, don't miss Coachella in 2005!