forgot to mention that to deploy clustered I also included additional jar files in the server/deployment/lib folder: jboss-cache.jar, jgroups.jar and jboss-remoting.jar.
So, if Clustering now uses jgroups, does that mean it is not using a lick of ejb under the covers? If our application has no EJBs, do I really need the httpha-invoker then or does jgroups use that ?
You can safely remove httpha if you want. I'd recommend you try out 4.0.2 as there have fixes for http session replication.
In terms of memory leak though, it can cause by the frequent exceptions handling whereas the exceptions can come from your "non-serialzable" objects or from internal ones.
BTW, if your attributes are not serializable, you should not put them into http session.
Thank you for your response!
Alright, I will make all the objects placed on httpSession serializable. Coming from a commercial app server environment, we were spoiled by it's ability to simply igore these objects on the session, not forwarding them to other cluster member nodes.
So, if we are throwing errors in production that might go to the Console, running in Windows 2003 as a Service, and redirecting the "out" and "err" to a file, are we accumulating memory simply because of the console output ? If so is there a way to flush this periodically?
Or, is it that errors thrown up this high into the console have components that get added to some collection and therefore won't get garbage collected ?
Also, not that it should be our first line of defence, but to prevent excessive console messages, is there a way to catch the errors thrown from httpSession Clustering ?