tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Whitmore" <>
Subject prediction; context problems
Date Wed, 03 May 2006 06:41:36 GMT
Hi people, Sriram, Remy, Costin,

Thanks Sriram for the +1 on this!   As you guys have read, I think something is up in the
the area of Context information; specifiers, parsing, and storage of current deployment state.

I've previously been talking about determinism as one of the problems, but I don't find much
indication that people get what I'm pointing out or are thinking about this at the 'concept'

I'm going to some effort here to clarify this, and communicate these areas.

I would therefore expect competent people to discuss Issues, not "issues". And please Costin,
before you write too much about 'can't parse rant', perhaps try finding the Enter key on your
own keyboard.  :-)


My understanding of the new Context/ Deployment design, is that deployed Context Specifiers
are located in /conf/[engine]/[host].  My further understanding is,  that either Tomcat or
the User can create these;  tomcat from a variety of original sources.

Based on this I'd like to make a couple of predictions;   re:  erroneous behaviours.

1)  Tomcat will be unable to know reliably when a Source context-specifier has been deleted,
in order to delete the resultant Deployed context record.

2)  Tomcat does not have enough information to know whether a given Deployed context-specifier
is owned by Tomcat or the User.

Apparently there may already be reports of #1.

Number #2 is likely to lead to to Tomcat auto-scrubbing deployed apps in the /webapps folder
when a context specifier is manually edited, whether these are owned by tomcat or not.


Now, for a recommended solution.

1)  never mix Ownership of anything.
2)  store the list of  Deployed Context specifiers, away from the user /conf directory;
        - storage in  /working  would be suitable.
        - keep ownership of this entirely to TC; then we will always know what is going on.
3)  sub-folder and named files structure for deployed Master Contexts is unnecessary.
        - it's complex & unnecessary, toss it entirely.
        - store as XML file instead.
        - all Context elements flat within the head; no need to structure/ nest or context

4)  bring back Context.ContextPath attribute, currently non-functional
        - current implementation disregards in most cases (!)
        - determine simple identification of Context Path from deployed/ context sources
            - aka.  use the Context Path if it's spec'd
            - otherwise,  use the default

5)  fix recognition of Contexts by DocBase,  currently broken
        - this will fix Contexts explicitly specified in  'server.xml', from also being deployed
        duplicates under default settings.


Anyway, hopefully this a good explanation of the issues, and helpful to the Tomcat developers
and contributors in identifying what's wrong here.

I'm aware there are some Clustering issues, driving the current design, but don't know exactly
what these are. My proposed solution delivers Determinism, and from a replication perspective,
providing solid reliability for Context info would certainly simplify clustering this information.

Obviously, I've already put 8 - 10 hours of thought into this. But, more importantly, I've
seen such 'unreliable' designs before, know what a reliable one is, and can tell the symptoms
& difference pretty much instantly.

As always, the proof is in the pudding;  everything I'm raising & reporting is there,
the Context stuff can exhibit ranges of undesirable behaviour (due to lack of determinism),
the Context Path stuff is almost completely broken, etc. If this *wasn't* the case I'd be
full of shit, but it is, so let's look at moving forward;  will those Clustering requirements
interact well with the proposed solution, what other future goals are desirable, etc.

Let me know what you think,

Connector Systems Ltd

thomasw   'at'   connectorsystems   'dot'    co    'dot'   nz

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message