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.
> 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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
