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: Galen Rhodes <email@hidden>
- Date: Sat, 23 Feb 2008 10:02:28 -0500
I rsync to a "staging" folder.
--
Galen Rhodes
email@hidden
http://www.photoyoda.com
http://www.myspace.com/woexpert
On Feb 23, 2008, at 9:55 AM, Mike Schrag wrote:
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
_______________________________________________
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
| References: | |
| | >java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Johan Henselmans <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Archibal Singleton <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: "Mr. Pierre Frisch" <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Archibal Singleton <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Guido Neitzer <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Archibal Singleton <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Guido Neitzer <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: "Mr. Pierre Frisch" <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Galen Rhodes <email@hidden>) |
| | >Re: java heap trouble after 5.4.1 upgrade, opensnoop to the rescue (From: Mike Schrag <email@hidden>) |