On Mon, Jun 9, 2008 at 1:51 PM, Andy Spitzer <[EMAIL PROTECTED]> 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) > > --Woof! >
This would point to a solution that uses an application container such as J2EE to build such services but that would involve significant re-engineering ( not achievable in the near term ). Such a container would provide for application isolation using classloaders and management facilities and so forth. Ranga -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
