On Mon, 2008-06-09 at 13:51 -0400, Andy Spitzer wrote: > Woof! > > On Mon, 09 Jun 2008 12:53:14 -0400, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > > Can you quantify that at a system level? Surely most of them are > > sharable pages? > > Don't have a good gantification, but no, most are not sharable due to the > dynamic > nature of Java object loading. It's all heap space. WITHIN the JVM is > where the sharing comes from, not 'tween JVMs. > > Assume 256K per JVM, and it starts to add up fast: > > 1. sipXpage > 2. sipXconfig > 3. symmitron > 4. sipXbridge > 5. sipXivr > > As we add more Java into the mix, placing multiple services into one JVM > becomes more important. More important, I think, than controlling them > seperately. > > One possiblity of fitting this into the current process based structure > is to have "proxy processes" that Process Manager would start/stop, > provision, etc. Those would do whatever Java control is needed to the > main JVM to start/stop services. Those apps would be thin procesesses > (possibly just shell scripts using sockets)
I thing that when we add the more robust process management setup you described in XECS-1423 we will need/want to extend the process definition schema to describe that. -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
