Re: Multiple instances of WOA's deployed as WAR's
Re: Multiple instances of WOA's deployed as WAR's
- Subject: Re: Multiple instances of WOA's deployed as WAR's
- From: Dov Rosenberg <email@hidden>
- Date: Fri, 17 Apr 2009 13:18:24 -0400
- Thread-topic: Multiple instances of WOA's deployed as WAR's
Title: Re: Multiple instances of WOA's deployed as WAR's
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" <email@hidden> 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" <email@hidden> 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 (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> .com
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
Attachment:
multiinstanceWO.png
Description: PNG image
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden