On 22/10/2010 14:15, Leon Rosenberg wrote:
> Well the primary resource I see as a problem is heap. I have one
> customer who runs his tomcats with 12gb heap and another with 8. Both
> do that on 16 gb machines. They couldn't increase without resizing the
> machines.
> The heap is really used and no
On 10/22/2010 7:39 AM, Mark Thomas wrote:
On 22/10/2010 06:27, Tim Funk wrote:
(1) Since we already have
- effectiveMajorVersion
- effectiveMinorVersion
Is Context.version a "good name" to use? Since the name version is also
used by the servlet spec? Would "revision" be a less confusing name? (
On 10/21/2010 08:52 PM, Mark Thomas wrote:
- decide once we can see the patch without the clean-up if it is safe
for 7.0.x or needs to be held back for 7.1.x
If it doesn't break things or existing users configs,
I have no problem of having it in 7.0.
Adding 7.1 to the list would just confuse f
On Fri, Oct 22, 2010 at 3:04 PM, Mark Thomas wrote:
> On 22/10/2010 13:28, Leon Rosenberg wrote:
>> Hello,
>>
>> I was playing around with zero downtime releases since 2003 and I
> This isn't zero downtime. Tomcat already does that and has done for
> quite a while. This handles the case where sess
On 22/10/2010 13:28, Leon Rosenberg wrote:
> Hello,
>
> I was playing around with zero downtime releases since 2003 and I
This isn't zero downtime. Tomcat already does that and has done for
quite a while. This handles the case where sessions from version n can't
migrate to version n+1 - e.g. to an
A bit of opinion from my side:
On 22.10.2010 14:28, Leon Rosenberg wrote:
1. ressources - for the time you have both versions in parallel you'll
have double resources need, double amount of db connections, double
amount of memory etc.
This means that the hosting has to sized accordingly, but hos
Hello,
I was playing around with zero downtime releases since 2003 and I
think there are some pitfalls in your approach I dont see yet solved.
I'm taking as premise that you are targeting 'larger' sites, meaning
loadbalancers, 4++ servers etc. Small sites don't really need this
feature imho (the d
On 22/10/2010 06:55, Rainer Jung wrote:
> On 22.10.2010 13:39, Mark Thomas wrote:
>> On 22/10/2010 06:27, Tim Funk wrote:
>>> (1) Since we already have
>>> - effectiveMajorVersion
>>> - effectiveMinorVersion
>>>
>>> Is Context.version a "good name" to use? Since the name version is also
>>> used by
On 22.10.2010 13:39, Mark Thomas wrote:
On 22/10/2010 06:27, Tim Funk wrote:
(1) Since we already have
- effectiveMajorVersion
- effectiveMinorVersion
Is Context.version a "good name" to use? Since the name version is also
used by the servlet spec? Would "revision" be a less confusing name? (Or
On 22/10/2010 06:27, Tim Funk wrote:
> (1) Since we already have
> - effectiveMajorVersion
> - effectiveMinorVersion
>
> Is Context.version a "good name" to use? Since the name version is also
> used by the servlet spec? Would "revision" be a less confusing name? (Or
> webappRevision).
Good point
Cool. Some notes ...
(1) Since we already have
- effectiveMajorVersion
- effectiveMinorVersion
Is Context.version a "good name" to use? Since the name version is also
used by the servlet spec? Would "revision" be a less confusing name? (Or
webappRevision).
(2)
[I thought of this as a side ef
On 21.10.2010 23:11, Mark Thomas wrote:
On 21/10/2010 14:51, Sylvain Laurent wrote:
Though I can see how this can be done for a standalone tomcat instance, how do
you plan to do with clustered sessions ? Should the old version of the
application wait for all sessions in the cluster to expire ?
On 21.10.2010 20:52, Mark Thomas wrote:
All,
As most of you are probably aware I work for SpringSource and
SpringSource has an application server product - tc Server - that is
heavily based on Apache Tomcat. When talking to prospective clients
about tc Server, one of the things we often hear is
On 21/10/2010 14:51, Sylvain Laurent wrote:
> Though I can see how this can be done for a standalone tomcat instance, how
> do you plan to do with clustered sessions ? Should the old version of the
> application wait for all sessions in the cluster to expire ?
TBD. I haven't looked at this at al
I discovered this feature a while ago in Weblogic and I found this interesting.
But as I always had classloader leaks, I had to restart the JVM anyway so that
it defeated the purpose of the feature and I gave up dreaming of zero-downtime
deployments.
Now with tomcat memory leak protection featur
15 matches
Mail list logo
