hello all,
this is a following up to the email sent before.
i spend a bit more time in investigating the problem and found the
following.
consider the following: tile is initialized using the
org.apache.tiles.definition.UrlDefinitionsFactory.
now, when a request receives and the tiles container is instructed to render
a specific tiles definition, the following happens (the interessing parts):
1. invoke 'Definition getDefinition(String name, TilesRequestContext
tilesContext)' of UrlDefinitionFactory.
2. from there invoke 'Definitions getDefinitions()' of
UrlDefinitionFactory.
3. if the instance attribute 'definitions' is null, from there invoke
'Definitions readDefinitions()' of UrlDefinitionFactory.
within the third call the configuration is actually parsed and the
beans/instances/what ever defined within the configuration file(s) ar
created.
unfortunatelly the UrlDefinitionFactory does not synchronize the call to the
'Definitions readDefinitions()' method. the result is, if there are
multiple request received by the servlet container at once and there has no
other request been received so long, we get into classical multi
threading problematics where each thread is bothering the others and the
process of creating the definitions list crashs.
i think this is where's the rub.
can anyone confirm this?
greez,
dirk
----- Original Message -----
From: "Schaefer, Dirk Alexander" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 27, 2007 12:32 PM
Subject: Re: tiles2 crashes (digester)
dear antonio,
first of all, thx a lot for your answer. but i do not agree with your
explanations. for sure tiles relies on the fact that the configuration is
getting loaded during start up but in fact it is not realy getting loaded
until the first request has been received. even not using the default
servlet/listener/... that are part of the tiles release. the only thing
that is getting done - as far as i can see - is reading in the
configuration but not parsing it.
i took a look through the code and i did not see any synchronized work
inside it ragarding the initialization of the framework at start. in
generall the work done by the tiles configurere explained in the initial
email is more or less exactly the same as the work done by, e.g. the
TileListener, which is used by both, the TilesFilter and TilesServlet
which are explained to be use to initialize tiles at the tile
documentation.
therefore, in my opinion it is not a failure in using/initializing tiles
but in tiles it self. this gets even more harden if you consider the fact
that the hole initialization work in my case is done within the servlet
container startup process, too. just like it is done by using the tiles
default implementation of its listener/servlet/filter.
if i got it right, creating the real beans/instances/what ever from the
configuration file(s) is not done before the first tile definition is
requested/told to render. therefore i think tiles should care about
synchronizing this work, not the application using tiles.
please correct me if i'm wrong.
greez,
dirk
----- Original Message -----
From: "Antonio Petrelli" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 27, 2007 10:10 AM
Subject: Re: tiles2 crashes (digester)
Hi Dirk,
Your example is really pretty complicated :-)
Seriously, Tiles relies on the fact that the configuration is read at
startup only once. This is done by using the listener, the filter or
the servlet.
For some strange reason, I think that your Spring integration does not
load on startup, so I guess it is a bug in Spring, or in your code.
What I mean is that Tiles is not responsible for a misuse of the
startup procedure.
For example, I think that the container creation and its assignment to
TilesAccess should be done in a synchronized block.
Ciao
Antonio
2007/8/19, Schaefer, Dirk Alexander <[EMAIL PROTECTED]>:
hi all,
i'm new to tiles2 and currently trying hard to get it working within my
spring enabled web application.
actually almost the hole thing is working proper with one exception.
tiles2 crashes while it reads the definitions from the
definitionsFile(s) i told it to read from within the following
circumstances:
1. start the tomcat servlet container.
2. no request sent to tomcat since startup.
3. sending multiple request using a web application test application
simultaneously.
if i do this, a realy big number of exceptions occurre inside of tomcat.
investigating those exceptions i figured out, that there is a problem
when the definitions are getting read from the xml string held inside
tiles. as far as i can see, those definitions are then getting read
using digester. as i can see, reading the definitions is neither
synchronized nor is it using independent instances (thread bounded) of
the class it is using for this purpose.
the result is, that the different threads are messing with each other
and the process of loading the definitions crashs.
if i use it the following way, everything works proper:
1. start the tomcat servlet container.
2. send one single request to it at least.
3. send as many request simultanously as the server can handle.
interessting, isn't it?
---------------------------------------------------
how i use tiles2:
i do not use any of tiles' servlets, listeners, ... i initialize tiles
the programmatical way by using the spring framework's TilesConfigurer
introduced in its version 2.1 m4. in general it is first setting up
servlet initial parameters that are defining the several factory,
preparer, ... implementations to use by tiles.
after that it initializes the tiles framework the following way:
public void afterPropertiesSet() throws TilesException {
TilesContainer container =
createTilesContainer(this.servletContext);
TilesAccess.setContainer(this.servletContext, container);
}
protected TilesContainer createTilesContainer(ServletContext context)
throws TilesException {
ServletContextAdapter adaptedContext = new ServletContextAdapter(new
DelegatingServletConfig());
TilesContainerFactory factory =
TilesContainerFactory.getFactory(adaptedContext);
return factory.createContainer(adaptedContext);
}
where afterPropertiesSet() is the method which needs to be invoked in
order to initialize tiles. DelegatingServletConfig is a simple inner
class of TilesConfigurer which makes the configurer's settings according
to the factory/preparer/... implementations to use by tiles available as
initial servlet property settings.
can anyone confirm that this is a bug within tiles2 or is it just me,
who's using tiles the wrong way?
thx a lot, greez,
dirk
