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.
