On Jul 15, 2014, at 12:34 PM, Paul Dunkler <[email protected]> wrote:
> we are currently facing some deployment problems with WebObjects-Applications > which most probably has the reasons in our (very big) running > WebObjects-Configuration. > While thinking about how we start fixing the problem, i faced the following > question: > > Why is the complete SiteConfiguration of every application and every instance > shared with every application server? I think it's about simplicity in the design. It syncs the SiteConfig.xml as a whole as an independent task. > I just checked the code of JavaMonitor. All default actions like addInstance, > updateInstance and so on are sent to EVERY configured application host. > And i'm wondering if it wouldn't be enough that every application server only > knows about the instances configured to run on itself. This adds complication to the sync process within the concept of the independent task idea. > Like its now the SiteConfiguration can grow very large. A synch-request which > is triggered by the monitor in error cases is then taking a very long time to > compute in the wotaskd which leads to configuration read problems in the > adaptor. That's interesting, never seen that before. How large is your SiteConfig.xml file, in bytes? If you have one large SiteConfig files does it also mean you have one head node? A really fast, simple, error free network really helps. Don't go through your ISP's network drops to communicate with your instance hosts, use a private network switch. Giving JavaMonitor and wotaskd more RAM also helps a lot. > And then another thing. In the default implementation of the GracefulBouncer, > the requests for updating scheduling and so on are only sent to the hosts > which have instances configured for the current application. Why are these > updates not sent to EVERY application server? Not sure if this is right. This information is stored in the siteconfig file which every host gets. If a host does not get an updated siteconfig file, it does do not get the updated schedule. I always treated all my hosts in a site exactly the same, including the head node. I then turned on instances only on those that I needed - on the host of my choosing. I never bothered to only place my application bits on those instance hosts on which I told JavaMonitor to run an instance on. All hosts got all the same bits - including the siteconfig file. Shifting traffic from one host to another, temporarily if a host died, it's easier if all your hosts have all the application installed. If your site configuration is indeed very large it may make sense to split up your site. That whole 'eggs in one basket' thing. If your SiteConfig gets hosed for some reason it can make the entire site behave wonky. Hope this helps. However I'm not sure I said anything you didn't already know. :-) kib "The essence of training is to allow error without consequence." Orson Scott Card Klaus Berkling www.berkling.us | @kiberkli | Photography
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
