Hi Ciaran, The issue <http://issues.apache.org/jira/browse/ODE-561> you're referring to aims to limit the total number and/or size of processes in the server's in-memory cache. That work is currently under review and testing, and I expect it to be released anyday now.
As far as the process size (i.e., memory footprint) is concerned, I've a patch in the works that seems to be able to reduce the size of the BPEL objects by as much as 70% under certain circumstances. Note that there's not a whole lot we can do about reducing the size of the WSDL objects, since that is allocated by Axis2. I will create an issue to track that work shortly. As far as the re-deploy issue is concerned, that was resolved a while ago. The patch for the same can be found here<issues.apache.org/jira/browse/ODE-538>. Please give it a shot and let me know how it goes. Regards, Karthick On 3/30/09, Ciaran <ciar...@gmail.com> wrote: > > Hiyah, I've heard good things about your progress on the CBP memory > footprints, the memory usage of the workflows for us is a current concern > and I'm interested in any progress that you've managed to make so far ? > > I hope you don't mind, but because the memory was looking to be an issue to > me, I did a brief investigation into what I might be able to do to improve > things ;) (from what I've heard my improvements weren't a touch on what > you've been looking at!) > > We kept running out of memory during Deploy+Un-deploy cycles, a lot of > memory was being used up by both the ObjectInputStream and by Xerces/DOM. > One simple thing I noticed for us was the cost of Literal Assigns during > re-hydration, the stringToDom seemed to allocate a lot of memory when I > shifted this to the first time the assign was resolved the re-hydration time > was substantially faster, but obviously any errors in the XML weren't caught > at that point. > > The other thing we noted was that memory used by the initial deploy of a > workflow didn't seem to be freed up when an un-deploy occurred (the memory > used by the hydration process was given up, but not the memory used by the > compilation phase.) A v. brief profile suggested that the Process object > may be hanging around, I think one instance was in the 'stack' thats used > within the compiler, but I suspect others. Also for us the _services map > in ODEServer seemed to contain objects referenced by a MultiValueKey which > took a 'namespaced' PortType when it was put into the map, but when the > destroy was trying to remove the service it wasn't using the namespace so it > was never being removed from the map. I haven't yet worked out if thats > just some issue with our WSDL but it seems strange that the ODEServer would > behave differently on a deploy and on an un-deploy... > > I hope these comments help in someway, but I appreciate they're not much > use without a patch or repeatable test-case, so sorry, just not enough time > to do everything I oughta do :( > - cj. >
