Changing CVS Username and Password in an Eclipse Project

I'm posting this for my future reference since I could find any reference to changing a saved CVS username and password for an already created Eclipse project.  This post has nothing to changing CVS credentials on a CVS server.  I needed to do this because I had commits to make to an open source project however the project I originally setup was using the anonymous read only access.

1. You need to set a new connection string for the CVS repository you want to access by using the CVS Repository view.

Goto the "Window" menu -> "Show View" -> "Other" -> find "CVS" section and expand -> "CVS Repositories"

2. Next setup the new connection string for your repository

Click on the mini icon of this view (a cylinder with the word "CVS" and a "+" sign) -> Add your new CVS repository

3. Associate the new repository (could be the same repository with different login credentials) with your project

Right click on the project in the "Navigator" -> select "Properties" -> in the properties tree select "CVS" -> hit the "Change Sharing..." button -> select your new repository and "OK" -> hit "Apply" back on the properties page

I hope this helps somebody in the future.

Fixing a Mysterious Memory Leak on ColdFusion 8

Last year I noticed a strange problem while developing the Mach-II Dashboard on an Adobe CF8 based application.   If I reloaded my entire Mach-II application through an URL argument which called the bootstrapper loadFramework() method everything was fine.  However, if I reloaded my application via the Dashboard I would see a slow memory leak of 30MB of Java heap space per reload.  Suffice it to say that in normal development, you can reload an application many times every day.  Thus this was very bad.  I do remind you that my application is fairly large (200-250MB of heap space to load up).

The only difference between the two methods of reloading was the bootstrapper method instantiated a Mach-II AppLoader CFC and replaced the current one in the application scope.  The dashboard on the other hand would reload the application by reusing the current AppLoader and calling an method on it.  I was able to replicate the memory leak using the bootstrapper by calling the same method that the Dashboard was using instead instantiating a new AppLoader CFC.

I immediately tried to replicate this memory leak on OpenBD and Railo test beds however I did not observe any memory leaks.  So the problem only existed on CF8 and probably CF7 based on another blog post posted by the great development team at Dave Ramsey.  To be fair, I personally haven't tested on CF9 but have heard reports of this from another Mach-II user.

Basically, it appears that CF8 holds on to a strong reference of some type of object in memory and is never released  from the heap for reuse.  I checked a lot stuff in our code base for accidental circular references or something strange like that, but I was unable to figure out the problem.  I even devised a stripped down application based on the Mach-II skeleton and nothing else. This was attempt #1 where I spent about four hours.  Frustrated, I went to bed.

It took a couple of months of just ignoring the problem for me to release all the frustration that I have had about this issue.  Plus, I was out of ideas even after discussing this Kurt Wiersma and Matt Woodward.  So on attempt #2, I decided that I needed to use some more high powered tools available to me.  So I fired up VisualVM which is bundled with Java 6 these days (before it was separate download).  VisualVM allows you to get detailed information about Java applications that are running in a JVM (local or remote) such as monitoring memory consumption, profile applications and take/display heap or thread dumps.  Since ColdFusion runs on Java, this is perfect tool to figure out the problem.

I'll spare you my frustrations, but about four hours in I was able to see that CF8 was holding on to a strong reference to the MachII.framework.AppLoader component which does have a circular reference to another AppLoader when Mach-II modules are in use.  However, my frustrations were not of what was the problem, but how to fix the issue.  So I Googled and Googled for blog posts and after a while I came upon this post (thanks Dave Ramsey guys - great blog name):

ColdFusion 7 Memory Leak (via Web Monkeys With Laser Beams)

So, what the hell?  If I leave off a "output" attribute on a <cffunction> there could be a memory leak?  That seems like a totally stupid bug.  So I did a code base search of Mach-II for missing "output" attributes on <cffunction> tags.  I knew there were a few because CF doesn't treat the "output" attribute like a true boolean.

1. output="true" - output everything
2. output="false - suppresses all output
3. no output attribute defined-  suppresses all output except if you have something wrapped in a <cfoutput> tag

Option number three is used in a couple of places because it is actually quite usual.  Now, this "feature" of the "output" is not documented, but is known to I guess a more advanced CFML programmers.  So I added in cfoutput="true" for all the places in all the places where we had left off the "output" attribute.  I thought I would worry about whitespace suppression later if this work.  So, restarted my instance of Tomcat and did a few reloads of my application via the Dashboard.  I took a heap space dump before I started to get a baseline and did a few more snapshots after a few reloads to see what was happening.

I think after seeing the first results I yelled some expletive along the lines of Holy Cow!  This small change was like a tourniquet on the memory leak.  It was now down to 6MB memory leak per reload.  So I knew there was something else up.  A quick search of ColdSpring showed a ton of missing "output" attributes on <cffunction> tags.  A RegEx replace of those was quickly performed.

After restarting my Tomcat instance, I repeated my analysis process of heap dumps and reloading of my application.  Viola! The memory leak was gone.  Literally, the JVM would recover all the memory -- down the almost 1kb of heap space after a full GCC was requested (which is why I wrote a "request garbage collection" feature in the Dashboard that night).

Summary: Leaving off the "output" attribute of <cffunction> tags can cause memory leaks in certain situations on CF7 and CF8 (even with CHF 3 installed which supposedly fixes memory leak issues with CFCs and memory scopes).

Solution: Never leaver off the "output" attribute!

Cases in the wild: I'm sure everything had a few of these in their code base.

I can't confirm how CF9 handles this stuff since aren't running that on any of our applications at work, but I suspect the same problem exists.  So if anybody wants check, feel free to comment.

----

Update: March 6, 2010

Because I have been asked this a few times.  The CF8 server I was running my tests against was 8.01 with CHF3 installed.

I have filed a ticket for this issue with Adobe as ColdFusion Bug 82362.

Mach-II 1.9 Milestone 1 (mach-ii.com)

Mach-II 1.9

Hot on the heels of the Mach-II 1.8 "Simplicity" final release, Team Mach-II is proud to announce the availability of Milestone 1 (M1) of the 1.9 "Integrity" release.

As we've mentioned a few times before, starting with Mach-II 1.9 we are moving to milestone releases in order to get fully completed features in your hands as soon as possible. This helps us better organize and complete the development tasks involved with the release, and our users can help us by testing the new features as they're completed instead of waiting for the full final release, or potentially having numerous partially completed features in nightly builds.

Mach-II 1.9 is code-named "Integrity" because one of the main focal points of this release is adding validation capabilities to the framework. An integral part of validation is internationalization, so i18n is another big piece of Mach-II 1.9. We've made great progress on these features and they'll be available in future milestone releases. You can read about some of our plans for i18n features on the Mach-II wiki.

In keeping with our smaller, faster release cycle, we started with some low-hanging fruit for Mach-II 1.9 M1, including:

• Boostrapper "loading page" option - #195


• Add 'prepend' attribute to the view-page command - #420


• Improvements to the logging package
  
  
  
  • Use for M2 logger output when on Open BD - #439
  
  
  • Allow for MachIILogger use IP list to show debugging output - #329
  
  
  
  


• Improvements to the HtmlHelperProperty
  
  
  
  • Add support for nested "inline" JS in asset packages - #469
  
  
  • Add option to add JS before HTML body in HtmlHelperProperty - #230
  
  
  
  


• Miscellaneous improvements
  
  
  
  • Add ability to use a module event as default event - #382
  
  
  • Add helper methods to ViewContext and BaseComponent for environment related functionality - #467
  
  
  
  

Grab the Mach-II 1.9 M1 zip now and help us by starting to incorporate new Mach-II features into your development cycle right when they're available.

As for our plans for future 1.9 milestone releases, we're a completely open book. You can read about all the milestone plans on our roadmap, and please let us know if you have feedback on any of the great features we have planned for 1.9. And we can't wait to start sharing our plans for 2.0.

As always, thanks for your support of Mach-II! Our users and community are what make Mach-II great, so we truly appreciate everything you do for Mach-II.

All I can say is that the entire team is excited. We're already working towards milestone 2. Get it now.

Was joint custody a mistake? (Salon.com)

When Simon was 3, he used to call the time after the lights were out and before he fell asleep "the talking dark"; it was one of those pitch-perfect childhood phrases coined to describe an experience not found in grown-up parlance. In the talking dark, Simon talked himself to sleep. In the talking dark, bad guys were defeated, weather was commented upon, stuffed ducks waddled into ponds. He also got two of everything that year: two bedrooms, two sets of toys, two different jammie rotations. Dad's house and Mom's house were very separate places in his consciousness, a firewall built between them so thick that once, when he was with his dad and ran into me on the street, he introduced us to each other. "Mommy, this is Daddy. Daddy, Mommy." But he had one talking dark. One consciousness to inhabit and one narrative machine with which to invent stories out of the tracks of his days.

via salon.com

Although I was much older than Simon at the time, I am a child of divorce as well. I too drifted between two households. During that time, I very much felt like I was living two separate but equally important characters in my two families. Still, I existed in my own world between the two and those lines are gradually blurring over the past years. From all of this, I had a good chuckle at the distilling down of Simon's consciousness to the causal "introduction" of his parents on the street described above. The rest of the article is rather funny as well so I encourage you read the whole thing.

The Bloom Box (60 Minutes) - Absolutely Fascinating

via cbsnews.com

Cleaner energy? No power grid? This "fuel cell" could make a difference. Only time will tell.

Why I'm Proud To Be A Dirty GNU Hippy (GoingWare)

By earning my bread through writing software, I made a pact with the Devil. In seventeen years spent working as a software engineer, I have been required to sign a non-disclosure agreement by everyone I have ever worked for. I have never been allowed to write Free Software. All but a tiny bit of the source code I have written in seventeen years of hard labor is now kept a jealously guarded trade secret by those who paid me to write it. Many of those companies are now long out of business, yet I could still be sued or even imprisoned should I release any of the source code I wrote for them.

via goingware.com

So true and probably why there are a lot of people trying to figure out how open source can pay the bills. I'd be one of those as I like sharing my work, but if only it would pay my mortgage.

Open CFML Advisory Committee -- Resignation Letter

Since my involvement in the Open CFML Advisory Committee is public knowledge, here is my resignation letter I shared with my colleagues on the committee.

Dear Colleagues,

My personal commitments  and professional endeavors have changed a lot since I joined the committee in May of 2009.  The demands on my time have increased in the past year and it has become increasingly difficult for me to contribute sufficiently to the CFML specification process. After much thought and internal debate, I have decided to tender my resignation from the Open CFML Advisory Committee.  I have enjoyed working with all of you this past year, and I appreciate everything I have learned from the process. I wish everyone the best going forward with creating a CFML specification.

Best,
Peter J. Farrell

 

Edit July 24th, 2010:

I had some additional thoughts to add now that the Open CFML Advisory Committee has disbanded.