Basic JSP question

[Roedy Green]

If you are writing code for JSP, do you have to take the server down
to change the source code? If not, it would seem you would gradually
fill RAM with classloaders and obsolete versions of code. You would
have to shut down periodically to clear that old just out.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Arne Vajhøj]

If you are writing code for JSP, do you have to take the server down
to change the source code? If not, it would seem you would gradually
fill RAM with classloaders and obsolete versions of code. You would
have to shut down periodically to clear that old just out.

Tomcat can be (and is by default) configured to automatically reload
JSP's when changed.

I would recommend to deploy a war file, because that is the EE way.

My understanding from reading on the internet is that class definitions
does get garbage collected when no longer in use.

Arne

 

[Daniel Pitts]

If you are writing code for JSP, do you have to take the server down
to change the source code? If not, it would seem you would gradually
fill RAM with classloaders and obsolete versions of code. You would
have to shut down periodically to clear that old just out.

Class loaders and classes can be garbage collected.

JSP's themselves tend not to take a lot of memory, but we found that
hot-deploying repeatedly can lead to a memory leak which will result in
OOME: PermGenSpace.

We go with the load-balanced approach, so that taking one server down to
deploy changes will not have an adverse affect on our users.

 

[Daniel Pitts]

Tomcat can be (and is by default) configured to automatically reload
JSP's when changed.

I would recommend to deploy a war file, because that is the EE way.

Where I work, during development, we deploy war files when classes are
changed, but only deploy the JSP's when they are the only things that
change.

The reason for this is our webapps tend to have a heavy start-up time,
and recompiling a JSP takes far less time (by magnitudes)

My understanding from reading on the internet is that class definitions
does get garbage collected when no longer in use.

In theory, yes.

We've had trouble with some apps. I think there is a debate in the EE
world among Hibernate, Sun, and cglib. There is a memory leak when
those three are used together, but switch out any of the components, and
everything seems to work fine.

Like I mentioned in another post, we get around that problem by
disallowing hot-deploys in production.

 

[Roedy Green]

We go with the load-balanced approach, so that taking one server down to
deploy changes will not have an adverse affect on our users.

Since I have only one hardware server box, should I run two copies of
the server on the same box at once, and take one of them down and up
periodically?
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Arved Sandstrom]

Since I have only one hardware server box, should I run two copies of
the server on the same box at once, and take one of them down and up
periodically?

If you had a single server, what kind of disruption would a brief outage
cause? Both from the standpoint of non-availability for a few minutes,
and any state that may exist (i.e. do you anticipate any use of client
sessions?) I would base any decision on those requirements.

If it is important to you to have high availability then you now have
the issue of routing traffic to the UP server while you're doing your
thing with the DOWN server. Using a software approach you'd commonly
have an HTTP server out front, load balancing your two J2EE servers.

In the high availability scenario, finally, you'd also have to take
stateless vs. stateful web apps into account. If stateless you're
already OK. If stateful, and you (more accurately, your users) cannot
tolerate disruption, then you're talking clustering with hot failover.

All depends on what you really want to achieve.

At work we (strictly speaking ops support) have the luxury of announcing
deployment windows, since we don't have to deal with the public or 24/7
requests. For working hours we do have clustering with hot failover,
because _then_ disruption is not acceptable. We also deploy EARs (even
for minor changes), and invariably follow an Undeploy App-Deploy
App-Server Restart cycle.

AHS

 

[Roedy Green]

(i.e. do you anticipate any use of client
sessions?)

No at this point, however people might be downloading large files.

The way things are now, I might update the website during the day
every 15 minutes or so with a file or two, usually with a very minor
change. I wondering, do I have to save these up to avoid taking down
the server or doing something risky.

I often answer a question with a link. I compose the entry, or polish
the entry, upload then post the URL on a newsgroup. This gives the
illusion the answer was there already. I enjoy the imagined
puzzlement of the reader when the entry contains something so
precisely fitting the question. I sometimes get bawled out for my
laziness in answering with canned urls. Since people ask the same
questions over and over, I figure it makes sense to handle the
question once and for all on the website where others may find it
without even having to ask the question. I also like to use the
ability to format my responses with HTML rather than being constrained
to plain text.

It looks like the JSP I won't be able to keep doing that.


--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Daniel Pitts]

No at this point, however people might be downloading large files.

It might make sense to have large files hosted outside of the app
container.

The way things are now, I might update the website during the day
every 15 minutes or so with a file or two, usually with a very minor
change. I wondering, do I have to save these up to avoid taking down
the server or doing something risky.

If they are JSPs, then I say go ahead and copy them in during the day.

If your app itself needs to restart, then save it up.

I often answer a question with a link. I compose the entry, or polish
the entry, upload then post the URL on a newsgroup. This gives the
illusion the answer was there already. I enjoy the imagined
puzzlement of the reader when the entry contains something so
precisely fitting the question. I sometimes get bawled out for my
laziness in answering with canned urls. Since people ask the same
questions over and over, I figure it makes sense to handle the
question once and for all on the website where others may find it
without even having to ask the question. I also like to use the
ability to format my responses with HTML rather than being constrained
to plain text.

It looks like the JSP I won't be able to keep doing that.

JSPs it is fine for the most part, maybe bounce the app every night on a
cron.

 

[Arne Vajhøj]

Where I work, during development, we deploy war files when classes are
changed, but only deploy the JSP's when they are the only things that
change.

The reason for this is our webapps tend to have a heavy start-up time,
and recompiling a JSP takes far less time (by magnitudes)

It will save some time, but is it really significant?

My not about the Java EE way is based on the fact that war deployment
as far as I know is the only portable way of deploying code.

Arne

 

[Arne Vajhøj]

Since I have only one hardware server box, should I run two copies of
the server on the same box at once, and take one of them down and up
periodically?

You could run one Apache HTTPD and two instances of Tomcat,
have Apache HTTPD load balance between the two Tomcats which
will enable you to restart a Tomcat server without users
noticing.

It will obviously not provide redundancy against HW or OS
failure.

And will you run anything where the very short time it takes
to restart Tomcat would be a problem?

Arne

 

[Arne Vajhøj]

It might make sense to have large files hosted outside of the app
container.

Good advice.

Tomcat will use more CPU and be slower serving huge files.

Apache HTTPD is designed to serve files. Tomcat is designed
to do servlets and JSP pages. Two completely different things.

Arne

 

[Lew]

Good advice.

Tomcat will use more CPU and be slower serving huge files.

Apache HTTPD is designed to serve files. Tomcat is designed
to do servlets and JSP pages. Two completely different things.

Fortunately the two play very well together.

I was fortunate to work with Apache Web Server in some depth a few projects
ago. We had it set up to work with Tomcat and as a reverse proxy, enabling
parallel development of development, test and staging environments. The ready
availability project-wide of the three environments, held in check by social
rules rather than deployment barriers, contributed mightily to their
similarity, and thus the applicability of test results. Developers always had
the development environment at hand, and high confidence that it fairly
represented the target environment.

Apache httpd's flexibility and plethora of features blew my mind.

 

[Arved Sandstrom]

It will save some time, but is it really significant?

[ SNIP ]

Are you a developer who is doing it a lot, or is it a test or production
deployment? For the latter, who cares - even for a heavyweight EAR with
all sorts of admin console tweaking it's still only a matter of a few
minutes.

But for a developer it already starts to matter if the deployment of a
full WAR or EAR takes 30 seconds as opposed to 10 seconds. I myself get
ornery if I have to wait half a minute. Some of my colleagues use
hot swap tools (that work quite well) to see class changes in just a few
seconds.

AHS

 

[Daniel Pitts]

It will save some time, but is it really significant?

Yes, 5 minutes versus 3 seconds for testing a minor change. If you have
a lot of tweaking that needs to be done, it can make a huge difference.

Again, this is only in our dev environments, so deploying the "right
way" isn't a necessity. At least not until deploying to UAT and
Production

 

[Roedy Green]

If you are writing code for JSP, do you have to take the server down
to change the source code? If not, it would seem you would gradually
fill RAM with classloaders and obsolete versions of code. You would
have to shut down periodically to clear that old just out.

I had another oh oh moment.

The Java glossary, just a part of my website, is about 3000 html files
and 45 mb. To serve that dynamically will be 3000+ classes and about
90 mb just for the string constants, right?

On the other hand, everything will be in virtual RAM. There is no i/o
needed to generate a page. I should be able to serve pages even faster
than I can serve them statically.

It also means I can update the text for a page, even while its is
being served. Users can't tie up my html pages the way they do now.
It drives me crazy trying to upload since they fail every time I try
to upload a page in the process of being served. Users can still lock
up image files though.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Roedy Green]

On the other hand, everything will be in virtual RAM. There is no i/o
needed to generate a page. I should be able to serve pages even faster
than I can serve them statically.

I forgot that popular static HTML pages are probably served without
I/O too since they would live in disk cache.

I think the bottleneck is downstream of me -- transmitting the page.
This suggests I should ensure my dynamically generated pages get
zipped if the user can handle it.

--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Daniel Pitts]

I forgot that popular static HTML pages are probably served without
I/O too since they would live in disk cache.

I think the bottleneck is downstream of me -- transmitting the page.
This suggests I should ensure my dynamically generated pages get
zipped if the user can handle it.

Or, look into a CDN, although I would bet they aren't cost-effective for
your needs

 

[Roedy Green]

Or, look into a CDN, although I would bet they aren't cost-effective for
your needs

"Short for content delivery network, a network of servers that
delivers a Web page to a user based on the geographic locations of the
user, the origin of the Web page and a content delivery server. A CDN
copies the pages of a Web site to a network of servers that are
dispersed at geographically different locations, caching the contents
of the page. When a user requests a Web page that is part of a CDN,
the CDN will redirect the request from the originating site's server
to a server in the CDN that is closest to the user and deliver the
cached content. The CDN will also communicate with the originating
server to deliver any content that has not been previously cached."

Odd that you should mention that. I just posted one of my student
projects which is a miniature CDN of sorts. See
http://mindprod.com/project/whocanseeme.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"I mean, source code in files; how quaint, how seventies!"
~ Kent Beck (born: 1961 age: 48), evangelist for extreme programming.