You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jason Brittain <ja...@olliance.com> on 2000/11/17 01:44:57 UTC
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Hi Remy.
Oops, yes, you're right about this (of course). I misunderstood the use
of the
"started" variable to mean whether or not the background thread was already
started, instead of whether the component's lifecycle had started. Sorry.
BTW: I really like the resources package! I can think of several useful
implementations that I'd like to use, like one for CVS, or one for JavaMail,
or ... lots more.
Remy Maucherat wrote:
>> At the end of this method, we changed the check interval, and then we
>> need to either start or stop the background thread that periodically
>> checks for resource updates. The code in this method handles the
>> following:
>>
>> 1. When the background thread is already running and we should be shutting
>> it down because the new check interval doesn't require a background
>> thread at all.
>> 2. When the thread is supposedly already running, the old check interval
>> didn't require a background thread (really, an illegal state -- and
>> since
>> this code looks basically like my patch below, was this just bad
>> placement
>> of this code?), and the new check interval does require a background
>> thread.. In that case the code at least makes sure that we have
>> a reference to a thread.
>>
>> But, what it doesn't handle is:
>>
>> 3. When the background thread isn't already running, the previous check
>> interval didn't require a background thread, and the new check interval
>> does require a background thread.. It should start one.
>>
>> So, here's the patch I'd suggest:
>>
>> 280a281,284
>> > else {
>> > if ((oldCheckInterval <= 0) && (this.checkInterval > 0))
>> > threadStart();
>> > }
>
>
> The "started" flag indicates that the component has been started. It's
> related to the thread state since the thread cannot be started if the
> started flag is not set to true. The flag is set by the start() and stop()
> method. If the component hasn't been started yet, I don't think it should
> start the thread (or try to stop it).
> Does it make sense (or did I miss something ?) ?
>
> Remy (going back to optimizing the HTTP connector)
>
--
Jason Brittain
Software Engineer, Olliance Inc. http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
Boyd Waters wrote:
>
> [...this un-lurking is getting habit-forming...]
>
> "Craig R. McClanahan" wrote:
>
> > What would you think about using a JNDI DirContext as a representation of the
> > resources available to a web application?
>
> Craig:
>
> I think that the *option* for Catalina to interact with a larger
> namespace is a Good Idea, but my experiments with JNDI implementations
> show these to be rather heavyweight systems.
um, never mind...
Sorry about this, I'm just coming up to speed on the Tomcat/Catalina
architecture. I see that you're using JNDI internally already.
I'm studying the code, trying to figure out where I can patch my RDF
properties storage in...
[...resume lurking mode...]
-- boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
[...this un-lurking is getting habit-forming...]
"Craig R. McClanahan" wrote:
> What would you think about using a JNDI DirContext as a representation of the
> resources available to a web application? The idea would be to use directory
> entry attributes for the commonly used information like "last modified date" and
> "number of bytes in this resource", rather than Java properties. We'd want to
> standardize on attribute names to be used (perhaps starting from the File
> directory context already available with JNDI) so that the rest of the servlet
> container can access them. Obviously, this would be a per-webapp structure, just
> like the naming context for <env-entry> and <resource-entry> things is. In fact
> ... maybe it could even be a subcontext of that very same context ...
Craig:
I think that the *option* for Catalina to interact with a larger
namespace is a Good Idea, but my experiments with JNDI implementations
show these to be rather heavyweight systems.
OK, so a relational database is heavyweight, too... hmm.
I am working on RDF indexes of web content, and am planning a WebDAV
properties store thingy that might use Guha's RDFdb.
OK, I suppose a JNDI thing is the same design pattern. FWIW, I say go
for it...
--boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:
> > > BTW: I really like the resources package! I can think of several useful
> > > implementations that I'd like to use, like one for CVS, or one for
> JavaMail,
> > > or ... lots more.
> >
> > I like the Resources abstraction as well. Before we go whole hog at
> creating new
> > implementations, though, I'd like us to consider one (possibly
> hair-brained)
> > idea.
> >
> > The major purpose for creating the Resources abstraction in the first
> place was
> > to hide the distinctions about *how* resources were accessed from the rest
> of the
> > servlet container. The Resources interface (as extended by Remy to
> support what
> > WebDAV needs) does this, but is not the only way to accomplish it.
> >
> > What would you think about using a JNDI DirContext as a representation of
> the
> > resources available to a web application? The idea would be to use
> directory
> > entry attributes for the commonly used information like "last modified
> date" and
> > "number of bytes in this resource", rather than Java properties. We'd
> want to
> > standardize on attribute names to be used (perhaps starting from the File
> > directory context already available with JNDI) so that the rest of the
> servlet
> > container can access them. Obviously, this would be a per-webapp
> structure, just
> > like the naming context for <env-entry> and <resource-entry> things is.
> In fact
> > ... maybe it could even be a subcontext of that very same context ...
> >
> > What do you think?
>
> Here's what I'll do.
> I'll add an org.apache.naming.resource.FileDirContext class, which will be
> an implementation of javax.naming.DirContext. It will be built by the
> factory.ResourceFactory.
> The Resource will be declared in the web app descriptor as a resource-ref
> element. Additional parameters (path, ...) will be specified there too.
> The factory will actually return an
> org.apache.naming.resource.CacheDirContext which wraps the real DirContext
> to provide transparent caching.
> The resources will be availible through the usual java:/xxxx URL.
>
> Questions :
> - Do we keep the current Resources ?
> - Isn't it a bit late in the release process to do that big change ? I can
> do the FileDirContext and CacheDirContext, and test them with a few
> servlets, no problem, but I'm thinking about rewriting DefaultServlet and
> WebdavServlet (ouch, that hurts ...). Can we do that for 4.1 ?
>
I agree with looking at a change in resources implementation in a 4.1
timeframe. Looking back, I sure didn't make that clear.
In the mean time, let's continue to focus on bug fixes and performance for 4.0.
>
> Remy
Craig
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Posted by Remy Maucherat <re...@apache.org>.
> > BTW: I really like the resources package! I can think of several useful
> > implementations that I'd like to use, like one for CVS, or one for
JavaMail,
> > or ... lots more.
>
> I like the Resources abstraction as well. Before we go whole hog at
creating new
> implementations, though, I'd like us to consider one (possibly
hair-brained)
> idea.
>
> The major purpose for creating the Resources abstraction in the first
place was
> to hide the distinctions about *how* resources were accessed from the rest
of the
> servlet container. The Resources interface (as extended by Remy to
support what
> WebDAV needs) does this, but is not the only way to accomplish it.
>
> What would you think about using a JNDI DirContext as a representation of
the
> resources available to a web application? The idea would be to use
directory
> entry attributes for the commonly used information like "last modified
date" and
> "number of bytes in this resource", rather than Java properties. We'd
want to
> standardize on attribute names to be used (perhaps starting from the File
> directory context already available with JNDI) so that the rest of the
servlet
> container can access them. Obviously, this would be a per-webapp
structure, just
> like the naming context for <env-entry> and <resource-entry> things is.
In fact
> ... maybe it could even be a subcontext of that very same context ...
>
> What do you think?
Here's what I'll do.
I'll add an org.apache.naming.resource.FileDirContext class, which will be
an implementation of javax.naming.DirContext. It will be built by the
factory.ResourceFactory.
The Resource will be declared in the web app descriptor as a resource-ref
element. Additional parameters (path, ...) will be specified there too.
The factory will actually return an
org.apache.naming.resource.CacheDirContext which wraps the real DirContext
to provide transparent caching.
The resources will be availible through the usual java:/xxxx URL.
Questions :
- Do we keep the current Resources ?
- Isn't it a bit late in the release process to do that big change ? I can
do the FileDirContext and CacheDirContext, and test them with a few
servlets, no problem, but I'm thinking about rewriting DefaultServlet and
WebdavServlet (ouch, that hurts ...). Can we do that for 4.1 ?
Remy
Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jason Brittain wrote:
>
> BTW: I really like the resources package! I can think of several useful
> implementations that I'd like to use, like one for CVS, or one for JavaMail,
> or ... lots more.
I like the Resources abstraction as well. Before we go whole hog at creating new
implementations, though, I'd like us to consider one (possibly hair-brained)
idea.
The major purpose for creating the Resources abstraction in the first place was
to hide the distinctions about *how* resources were accessed from the rest of the
servlet container. The Resources interface (as extended by Remy to support what
WebDAV needs) does this, but is not the only way to accomplish it.
What would you think about using a JNDI DirContext as a representation of the
resources available to a web application? The idea would be to use directory
entry attributes for the commonly used information like "last modified date" and
"number of bytes in this resource", rather than Java properties. We'd want to
standardize on attribute names to be used (perhaps starting from the File
directory context already available with JNDI) so that the rest of the servlet
container can access them. Obviously, this would be a per-webapp structure, just
like the naming context for <env-entry> and <resource-entry> things is. In fact
... maybe it could even be a subcontext of that very same context ...
What do you think?
Craig McClanahan