cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: ServletConfig.getRealPath
Date Wed, 23 Jan 2002 10:44:24 GMT
Berin Loritsch wrote:
> Sylvain Wallez wrote:
> > Stefano Mazzocchi wrote:
> >
> > <snip/>
> >
> >>
> >> HSQL should be considered a library used by the cocoon 'samples' and the
> >> files should be removed from /WEB-INF/ since it seems that Cocoon makes
> >> use of HSQL internally (which is NOT and will never be the case!)
> >>
> > ... and if you use a clustered server, you're likely to use some more
> > heavyweight database ;
> If the db files could be automagically moved to the work directory, that
> would be more correct.
> BTW, the hsql.Server "role" should be something more generic, and the HSQL
> be an implementation of that more generic role.
> >> For logging, I think that Cocoon should not attempt to provide
> >> centralization of logging, it's not its concern.
> >> This is why I'd like to have the ability to log into the servlet
> >> container directly: if they provide transparent clustering they will
> >> very likely provide transparent log centralization (probably
> >> asynchronously for better system performance).
> >>
> > There's the ServletTargetFactory that logs to the servlet container. It
> > is declared in logkit.xconf and was used up to recently to log all
> > errors to the engine's log.
> There is also the issue with the servlet's log implementation.  Almost all
> ServletContext.log() calls are blocking (causing major performance issues),
> and there is no distinction of priority or category.
> Cocoon uses a logging package--so that "concern" is not directly handled
> by Cocoon.  Also, that logging package can store the logging information
> in a database, or on a remote machine.  That way all logging information
> is centralized.  We need to fix the AsyncLogTargetFactory so that it
> actually works--when that is done, the Cocoon logs will be using that.
> This should speed up the logging facilities tremendously.

Agreed on this and agreed on the fact that Servlet API weren't designed
for this kind of use so they don't provide log priority and category
(even if I proposed it a while back, but was rejected)

But the fact that ServletContext.log() are blocking is only an
implementation detail.

> > About clustering, we have a component that I think won't work in
> > clustered environment : the FragmentExtractor/Generator. It grabs on the
> > fly parts of a document and keeps them in memory for servicing by
> > requests that follow the current one. In a clustered environment, it is
> > very likely that those requests are served by another computer in the
> > cluster, and thus the extracted fragments won't be found.
> >
> > As solution could be to store these fragments in the servlet session :
> > clustered engines either use a single computer for a session or
> > communicate session data between computers.
> Or you configure your clustering implementation to use server affinity.
> That means that a particular user is talking with one server all the time--
> and if a new session is created, that new session can go to any server
> in the cluster.  Server affinity also reduces the amount of information
> that has to be passed to all the servers in the cluster.
> Clustering environments is one of the reasons why storing large amounts of
> information in a Session object is frowned upon.  Server affinity does alleviate
> those issues.

Yes, exactly.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message