tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [PATCH] Parallel deployment
Date Mon, 08 Nov 2010 15:46:55 GMT
On 08/11/2010 15:40, Remy Maucherat wrote:
> On Mon, 2010-11-08 at 14:31 +0000, Mark Thomas wrote:
>> We might be able to avoid that be limiting the version to just integers.
>> I think that is reasonable but would like to hear some feedback from others.
>>
>> That does raise the issue of whether to convert the provided version to
>> a (zero padded) string and continue with String compares or to convert
>> the version parsed from the session ID to an int. Performance is the
>> thing that worries me but I might be over-thinking this. Some
>> micro-benchmarks are probably called for.
> 
> Ah, it seems this bad feature is spawning ugly hacks :( Why is it a good
> idea to append one-more-thing to the session id ? Already with the JVM
> route it is costly, and has spawned a ton of bugs (updates not being
> made when switching to a new node, etc etc).
> 
> Isn't it better to have the mapper simply query the existing managers if
> multiple versions exist ?
> 
> The algorithm:
> - if the Context has old versions active, the mapper will query the
> managers to find the right Context
> - of match, then you know the context
> - otherwise it belongs to the latest version
> - if no old versions of a context, no manager lookups, so no cost

I did consider that approach but rejected it for a couple of reasons:
- Mapper needs to be manager aware - it isn't currently
- Performance

Now the clean-up is in place and we can focus on the actual changes I'll
probably go back and take another look at this option. It is almost
certain I didn't fully explore all the possible ways of doing this.

> I don't agree with adding a version number/id to the session id, or
> changing its format, this will create legacy issues, as we can see right
> now.

An understandable concern.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message