On Apr 20, 2009, at 3:45 PM, Tonny Staunsbrink wrote:
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 ;-) ).
Ahg. I knew there was something on my todo list not getting done!
Dave
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
