Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue
Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue
- Subject: Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue
- From: Mike Schrag <email@hidden>
- Date: Sat, 23 Feb 2008 09:55:46 -0500
A warning here -- If you're rsyncing, presumably you're replacing your
application in-place. Java caches jar indexing when the jar loads,
which means that if you replace jars while the app is running you can
cause really strange problems during the time between replacing the
jar and restarting the process if it tries to load a new class during
that time. Just be aware that this is a risky operation to perform on
a production server. The better technique is to upload into a second
folder (versioned), repoint your instances to run from that folder,
and then restart your instances. This way you're never mucking with
the live app. This approach also allows for rollbacks, which is very
nice.
ms
On Feb 23, 2008, at 9:25 AM, Galen Rhodes wrote:
And if you use rsync to transfer to the server then the time to
upload updates is even shorter.
--
Galen Rhodes
email@hidden
On Feb 22, 2008, at 6:28 PM, Mr. Pierre Frisch wrote:
I disagree on this one. Embedding frameworks enables you to be
independent of the version of WebObjects installed on the target
machine. Considering the cost of disk drive (<1$/Gb) 10Mb is a
negligible it is save you debug time. Even the upload time is very
small if you tar your application before uploading.
Pierre
--
Pierre Frisch
email@hidden
On Feb 22, 2008, at 14:38, Guido Neitzer wrote:
On 22.02.2008, at 15:06, Archibal Singleton wrote:
We're talking about embedding the jars version of the System
Frameworks right? I was under the impression that this was "just"
of matter setting some configuration in WOLips/Ant
That's what I was talking about. I don't know why I should embed
the WebObjects (aka System) frameworks in my application. I have
to test and develop against the same frameworks as production is
running on so I need either the same versions on the two
environments or I need to embed the stuff I tested on.
But why should I deploy the same frameworks that normally don't
change in a long time (Remember the last 5.3 update?) on ANY
deploy for every application. If you have ten different
applications running on a machine, you have them at least ten
times (plus old version backups) on the machine without any benefit.
I can understand embedding the frameworks you work on or that are
not in a normal install, but I'd hate adding more than 10MB for
every application in every deploy. That would add around 70 meg to
every deploy. Even embedding the other stuff would push the size
to unreasonable values (because of ERJars and some stuff for
PayPal integration).
For my own projects I embed everything as deployments are quite
seldom and there are normally changes to all frameworks - and it's
only one big application.
I thought it would be a good idea for WO version isolation (ie to
make sure the the app is running with the WO version of WO it was
developed with/for) and enable running apps that use different
versions of WO.
Yes, it might be useful for that. But see the downsides above.
And there is no problem embedding "legacy" frameworks.
cug
--
Real-World WebObjects class at the Big Nerd Ranch
March 2008, Frankfurt, Germany
http://www.bignerdranch.com/classes/webobjects.shtml
_______________________________________________
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
_______________________________________________
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