Great, thanks for the very insightful replies, this info should definitely go into the wicki (David are you gonna let us know when it's there ;-) ). So load balancing i feasible, but it looks like I'll run into a few issues before it's working. I'll try and find the time to tackle these issues. Let's see how it goes.
Again, Great responses - thanks :-) Cheers Tonny On Fri, Apr 17, 2009 at 7:18 PM, Dov Rosenberg <drosenb...@inquira.com>wrote: > The configuration of the JK adaptor is pretty well documented. Attached > is an image that shows the general layout. The key is to set the jvmRoute in > the server.xml. Each Tomcat instance has a different jvmRoute. Those routes > are added to the workers.properties file. > > Server.xml > <!-- You should set jvmRoute to support load-balancing via AJP ie : --> > <Engine name="Standalone" defaultHost="localhost" *jvmRoute*="*worker1* > "> > > I have a document that has more details I can post. > > When you deploy multiple WO apps that share frameworks it is better to > deploy each WAR with the full compliment of stuff with each WAR. For example > our 3 apps share 3 frameworks: MyFoundation.framework, MyModel.framework, > MyComponents.framework. Each WAR file contains its own copy like the > following: > > MyApp1.war > WEB-INF > Library > Frameworks > MyFoundation.framework > MyModel.framework > MyComponents.framework > > MyApp2.war > WEB-INF > Library > Frameworks > MyFoundation.framework > MyModel.framework > MyComponents.framework > > The Tomcat manager application can still be used, but the java service > wrapper will auto restart if the app falls over, captures the System.out, > System.err, etc. Tomcat Manager still shows the stats of the Tomcat > container, java service wrapper is used to launch and keep the apps running. > > To turn off session persistance in Tomcat you need to uncomment an entry in > the $TOMCAT/conf/content.xml. That stops Tomcat from trying to persist the > sessions. > > > Dov > > On 4/17/09 8:51 AM, "David Avendasora" <webobje...@avendasora.com> wrote: > > Dov, > > This is really excellent! Do you mind if I put this up on the Wiki as a > general WebObjects with Servlets informational page? > > With that said, I do have some questions for you about this. See below > > On Apr 17, 2009, at 8:20 AM, Dov Rosenberg wrote: > > We have been deploying our apps out as servlets for a few years now with > many of our larger customers having large numbers of instances. Here is some > things we have learned over that time: > > > > - Deploying as servlets means that you can only have 1 instance per > servlet container. In order to scale you need to deploy multiple servlet > containers. In our case for large servers with plenty of RAM and CPU we may > run 2 or 3 Tomcat servers on the same box all on different ports. We use > the > JK adaptor or other external load balancers to balance across all running > Tomcat instances. > > Can you provide some more detail about how to set this up? Is it similar to > what Andrew Lindesay has documented on the Wiki already? > > > - As long as each WO app being deployed on a single Tomcat server has a > different context name, you can deploy multiple WO apps on a single Tomcat > server. For example, we deploy a management console, a web service app, and > a WO based JSP tag library app in the same servlet container. > > This is exactly the setup I have. I have 3 distinct WO apps running in one > Tomcat 6.0 instance. I run into problems with the classloader trying to load > frameworks that only exist in one project into another. I have to include > all the frameworks used by all three apps in all three otherwise if the one > that loads last doesn't have the frameworks required by one of the previous > apps, it will fail. I'm not sure if it is a problem involving Wonder, or if > it does it for plain WO apps too. > > > - Be aware that all WO apps running in the same servlet container share > the same RAM. On 32bit Windows platforms that typically is around 1.4G. > - Even though Tomcat is multi-threaded, the WO EOF stack is much less > so. It is necessary to scale by adding instances of Tomcat and your app. > Project Wonder has been a big help in minimizing our locking issues in > these > multi threaded environments > - We don’t/can’t use JavaMonitor. We use the Java Service Wrapper ( > http://wrapper.tanukisoftware.org/doc/english/download.jsp) to launch > and monitor our apps. We built a custom page to display the WOStats in our > app. > > So you use this instead of using the Tomcat Manager application? Not that > I've ever gotten it to start and stop individual WO apps anyway. I always > have had to restart the whole container. It's a pain in the butt, but not so > much of one that I've ever tried to figure out why. > > > - We don’t use the WO JSP tags to display WOComponents in JSP pages. > Seems interesting, but never tried it. > - We turned off session persistance in Tomcat. The persisted sessions > are basically unusable and only cause problems when our apps get restarted. > > How do you turn that off. I've never looked for it but it is annoying to > get a bunch of errors at boot. > > > - We rely on Tomcat clustering if we need it. > - You will get errors like: *javax.naming.NameNotFoundException: Name > jdbc is not bound in this Context* when starting up if you do not use a > content.xml and turn off JNDI naming. The app still starts up properly and > runs fine, but it will throw those errors once per connection. I haven’t > bothered to figure out how to use JNDI with our WO apps. Mainly because we > only used a single ObjectStoreCoordinator per instance. > > I get these too, but I never used to. The only thing I can think of that > changed is that I used to define the connections in the context.xml file. I > quit using that file. I don't know if that is what is now causing the error > messages, but the timing seems to be coincidental. > > > - The session time out is set in the WEB-INF/web.xml. The > WOServletAdaptor seems to attach itself to the Tomcat Session such that > they > share the same lifecycle. > > Do you let WOLips auto-generate the web.xml file for you? If so, how do you > manually control this value? Again, I've never tried, but it's been on my > low-priority todo list forever. > > > - The WebObjects classloader is configured in the WEB-INF/web.xml under > the WOCLASSPATH context parameter. It is a separate class loader than the > ones provided by the Tomcat server. We only put the WO related jars (from > the WO runtime and our frameworks and apps) in there. All of the other > dependent jars go in the WEB-INF/lib. We don’t bundle any extra jars inside > our frameworks to avoid duplicates. Tomcat provides jars like log4j, etc > but > we bundle our own so we don’t have any external dependencies. The newer WO > runtime files are delivered as Jars instead of Frameworks – we deploy those > in the WEB-INF/lib but register them in the WEB-INF/web.xml. Our Project > Wonder jars still need to be deployed as Frameworks. > - There is no built in load balancing in the WOServletAdaptor like > there is in the regular WOAdaptors. The machine name stuff is meaningless. > The sessions are sticky based on the JSESSIONID that the Tomcat container > provides > - We deploy our database drivers in the WEB-INF/lib folder of our WARs. > That way we control what drivers are being used. > - The WO apps need to run as expanded WARs in order to resolve the > variables in the WEB-INF/web.xml (i.e. WEBINFROOT). Not sure why, but I > suspect it is because the bootstrapping process needs to see the > environment > directly. WARs are typically expanded in Tomcat by default. Other > containers > such as WebLogic do not expand them by default causing issues. The J2EE > spec > says either way is acceptable but they lean toward not expanding them – > which causes us issues. > - Resource resolution is slightly different between a regular WO app > and a WO app deployed as a servlet. The WOContext is different > (WOServletContext) as well as WORequest, WOResponse. > - The WebObjects servlet is still in the URL i.e. > http://myapp.com/MyStore/WebObjects/store.woa. You can use URL > rewriting to remove it if you want or I think there is some functionality > in > Project Wonder to rename it. > - We found it easier to pass the session id in the URL in most cases. > > Again, this is a great list! Thanks! > > Dave > > > - > > > Hope that helps people. Overall I like deploying WO inside the servlet > containers. Customers are very comfortable with servlet containers and have > a lot less concern than deploying on a proprietary app server engine. There > are some limitations but they are not that bad. It is a whole lot easier > deploying a single WAR than it is sending someone a bunch of files and > hoping they put them in the right place. > > Dov Rosenberg > > > On 4/17/09 6:19 AM, "David Avendasora" <webobje...@avendasora.com> wrote: > > > > > On Apr 17, 2009, at 3:26 AM, Tonny Staunsbrink wrote: > > > >> Hello > >> > >> A recent posting said that "war file deployment just works" (it's > >> not an exact quote, but that how i remember it). > > > > Yeah, I think that was me. I should have said: > > > > Simple, single instance servlet deployments just work. If you create a > > basic app and select the servlet options, you'll get a WAR file you > > can deploy to a servlet container without any additional work. It used > > to be quite a bit of messing around just to get a working servlet build. > > > > When you start talking more advanced things like multiple instances > > and such, I think it is still very much a case of lots of things need > > to be done. My servlet deployments are very simple so I have never > > gone that extra mile. > > > > Dave > > > > > >> > >> I've considered deploying WOA's in servlet containers, but there a > >> few issues i just can't see how they will work > >> if I run deploy an app to a servlet container cluster. > >> > >> 1) The default session store is memory resident, does WOSession hook > >> into whatever session distribution i setup > >> for the containers? > >> > >> 2) The instance number. As far as i can see this property becomes > >> meaningless when running in servlet containers. > >> If the session can be distributed, this may not be an issue, but i > >> not.... > >> > >> Can help me answering these by sharing their experience with this or > >> link me in the right direction (before i go experiment with it)? > >> > >> Cheers > >> Tonny > >> _______________________________________________ > >> Do not post admin requests to the list. They will be ignored. > >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > >> Help/Unsubscribe/Update your Subscription: > >> > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora > >> .com > >> > >> This email sent to webobje...@avendasora.com > > > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > > http://lists.apple.com/mailman/options/webobjects-dev/drosenberg%40inquira.com > > > > This email sent to drosenb...@inquira.com > > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mezz.dk%40gmail.com > > This email sent to mezz...@gmail.com >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
