I should point out that more work is needed before my scenario is
realistic, including off the top of my head:
-- assembling the server from more smaller pieces, such as jetty and
tomcat configurations rather than the giant monolithic server
configuration we have now
-- different classloader structure such as OSGI like classloading where
your classloader includes classes from an essentially arbitrary set of
configurations.
-- versioned binary configurations
I would prefer to establish principles that would let us get to this
rosy future with few obstacles rather than do things that will
definitely conflict and need to be changed.
thanks
david jencks
On Aug 24, 2005, at 6:51 PM, David Jencks wrote:
well, I am not that familiar with what people with large server farms
actually do :-) I was thinking of something like an ISP offering
geronimo hosting: you rent space and a geronimo instance on a box, but
the deployment has to happen on a centralized deployment box. Either
there is one centralized repo/box or the repo is over the network, so
all server parts are available on all servers. In a couple of years,
when we have 10 web containers and 5 ejb containers and 3 jca
containers you will not want to set up the 150 deployment servers
needed for all combinations. Here, clearly you would want the
deployment plan to determine what you end up with, rather than the
particular deployer configuration that happens to be available at the
moment.
In particular I'm thinking the same app would not be deployed on both
jetty and tomcat very often.
thanks
david jencks
On Aug 24, 2005, at 6:55 PM, Aaron Mulder wrote:
To pick one little nit, if you have 1000 Geronimo+Tomcat servers
and 1000 Geronimo+Jetty servers, surely it's in your best interest to
have
a Geronimo+Tomcat binary deployment environment and a Geronimo+Jetty
binary deployment environment. I don't understand why you'd go to
this
much trouble and then make your build server different than your
runtime
server (other than, of course, not having a runtime deployer).
That being the case, wouldn't you be happer to have one version of
the application that you can build on the Jetty build box for all the
Jetty servers and that you can *also* build on the Tomcat build box
for
all the Tomcat servers? No chance that your Jetty copy of the
application
and your Tomcat copy of the application are out of sync?
Aaron
P.S. Is this even a realistic use case? Who is it that has a 2000
node
cluster with 1000 WebLogic boxes and 1000 Websphere boxes all running
the
same application?
On Wed, 24 Aug 2005, David Jencks wrote:
While originally I thought having one schema with customization
elements for our many (currently 2) web containers was a great idea,
I
have changed my mind and think that each web container should have a
separate namespace, although we should try to keep the schemas as
similar as possible. Let me try to explain why.
The basic principle is that the namespace should determine the
builder.
To implement this would require extensive modifications to the
current
builder code, especially the earConfigBuilder. That is kind of a
minor
point :-)
Lets imagine a server farm where 1000 are running jetty and 1000 are
running tomcat, but where for various reasons only binary
configurations can be deployed to the production servers: all
deployment to binary configurations occurs on a separate machine,
then
the binary configurations are sent to the servers and started.
If the namespace determines the builder and web container, then
deploying an app + plan is unambiguous: the builder chugs along, and
whenever if finds a new namespace in the plan it picks the builder
and
tells it to get to work.
If we have something like we have now, where one namespace can apply
to
one of several builders/containers, then we need more information,
such
as a separate deployer configuration, to determine the proper target
and build the right configuration.
So, I'd like to move back to separate but equal schemas/namespaces
for
jetty and tomcat plans.
Comments or objections?
thanks
david jencks
