<script type="text/javascript">
        $(document).ready(function() {
            //
            // Moves the debug window to the left instead of the right.
            //
            // Needs to use setTimeout so that the wicket-ajax-debug.js
            // script has a chance to create the link
            //
            if(wicketAjaxDebugEnable)
            {
                setTimeout(function() {
                    $("#wicketDebugLink").css('left', '10px');
                }, 1000);
            }
        });
    </script>

• The Web Service Extension needs to point to %WINDIR%\SysWOW64\inetsrv\fcgiext.dll.
• The .php extension on the website also needs to point to %WINDIR%\SysWOW64\inetsrv\fcgiext.dll.
• The fcgiext.ini file must also be located in %WINDIR%\SysWOW64\inetsrv.  Otherwise you will get a 500 error from FastCGI saying it cannot find the configuration file.

Note that the fcgiconfig.js script is only installed in %WINDIR%\system32\inetsrv.  I was able to create a fcgiconfigwow64.js file that points to the correct files.  The script needs to have at least an ini file with the “[Types]” section in the %WINDIR%\SysWOW64\inetsrv directory.  It also needs to be located under %WINDIR%\system32 as it doesn’t support running under Wow64.  You just need to change the following 2 lines near the top of the script.

From:

var g_iniPath       = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\system32\\inetsrv\\fcgiext.ini" );
var g_extensionPath = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\system32\\inetsrv\\fcgiext.dll" );

To:

var g_iniPath       = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\SysWOW64\\inetsrv\\fcgiext.ini" );
var g_extensionPath = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\SysWOW64\\inetsrv\\fcgiext.dll" );

After some searching on Google, the only suggestions that I came across had to do with using the post-set attribute, which gets called after the class has been unmarshalled.  For various reasons, most of which I did not want the domain classes tied to JiBX, I sought out a different solution.

The solution I came up with was to use a set-method for the collection instead of field.  So I replaced field=”fieldName” with set-method=”setFieldName”.  This set method ensures that the bidirectional association is properly defined. 

There is an argument to be made that I should be doing this anyway.  After all, the domain class probably should not let it be up to the caller to ensure the bidirectional association is properly defined, regardless if it is being called from JiBX or some other caller.

However there was one unintentional side affect.  The project is also using Hibernate.  The same domain classes were mapped using lazy associations.  This change to the set method in affect turned off the laziness.  The solution for this was to change the Hibernate mappings to use field access to bypass the set method.

I double checked the sites using Firefox, and even IE 7 from another machine, and the warning did not appear.  I disabled the Smarter Search feature in XMarks and the warning went away.

I have only installed XMarks on IE 8 so I don’t know if it is specific to IE 8 or is a problem with other browsers in general.

Update:  As per Colin below this issue has been fixed with version 1.0.7.  I installed this version and the warning no longer appears.  It is refreshing to have such a quick response.

These programs were fairly small in terms of functionality, but the amount of swap space it was using was around 600-700MB. Here is a summary of our findings (note that some of these details might be different on a Windows system due to differences in memory management):

• A common theme is that most java processes have a big difference between the residual memory and the total virtual memory.
• Java will allocate at a minimum about 200 MB of swap even for the simplest of programs. We tested using a simple program on both a HPUX and a linux server. The best and only documentation I could find about this was at the URL below. The bottom line is that this is probably the behavior of the JVM and out of our control so we just have to deal with it.

  http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/778089cbe0c9814c/5b0dfcea715d9055?lnk=st&q=java+uses+virtual+memory&rnum=20&hl=en#5b0dfcea715d9055It

  It is reserving space for example for threads that you may or may not create. It is awkward to rearrange memory on the fly, so the JVM parcels out the virtual ram for various tables when it first loads.

• The -Xms and -Xmx parameters do affect the java heap but it does not control the total memory footprint. It is only a piece of the total size.
• -Xmx alone can affect the total virtual memory size. Currently the processes have -Xms24m and -Xmx512m. Immediately after starting these programs, we saw the swap allocation jump to 600-700MB. When we changed -Xmx to 24m, it dropped to a little over 200MB.
• In relation to the above, the normal behavior of the garbage collector is to garbage collect only when it needs to free up memory. Having a too high of a -Xmx value could mean that it will never garbage collect, which means it won’t reuse memory. We see this in the Weblogic environment too but in that environment all of the memory usually gets used at some point.
• There is a new tool built into Java 5 and up called jmap that will give you heap information about a java process. This tool would make tuning the heap parms really simple. Unfortunately the process also has to be running using Java 5 so we cannot use it at this time. There is a version for 1.4 but it only works on Solaris.

As per the documentation, Spring’s default behavior will initialize a new ApplicationContext when the EJB object is created. It also states that the BeanFactory (which is the ApplicationContext) is unloaded when the EJB is removed.

One of the first things I checked was ensuring the EJB’s were in fact being removed. They were. At some point I remembered that in a more recent project, we changed the beanFactoryLocator to the ContextSingletonBeanFactoryLocator so that all EJBs use the same context (it also happens we setup the web application to use the same context too). The newer application did not have the memory leak so I decided to implement it here. I also figured that even if it didn’t fix the leak, this method is more efficient since there is no reason to have the context loaded everytime. To implement, I just overloaded the setSessionContext method:

Once implemented the leak went away. I never took the time to dig in and see what the true offender was, but it was found that some of the hibernate SingleTableEntityPersister objects were still present after leak. This could mean that it is Spring not properly cleaning things up or Hibernate itself has the leak.

As info this method was already implemented with our stateless EJB’s, so I could not confirm if the issue existed for AbstractStatelessSessionBean.  However since both abstract classes use the unloadBeanFactory method from AbstractSessionBean, I would figure the issue would present itself — although due to Weblogic pooling the stateless EJB’s, it is probably not as noticable.

Specifics:

• Weblogic 8.1 sp4
• JRockit 1.4.2_13
• Spring 1.2.9
• Hibernate 3.2.5