looks like a wiki page to me if i ever saw one :)
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.
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 protected]>
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 protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora
>> .com
>>
>> This email sent to [email protected]
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/drosenberg%40inquira.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
