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 08:20:01 -0400
- Thread-topic: Multiple instances of WOA's deployed as WAR's
Title: Re: Multiple instances of WOA's deployed as WAR's
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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
_______________________________________________
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