Markus Blaurock  wrote
> Hallo all,
> 
> we are using a sling-cluster with JSPs, with Jasper in "Development mode".
> 
> We are suffering with the problem of getting more than one cluster node
> to recompile
> a JSP on a change. This leads  sometimes to an unreproducible problem
> with the underlying
> jackrabbit-repository (v1.6.1) because of concurrent writes of the class
> file.
> After this the repository is inconsistent und causes us a lot of trouble.
> 
> Now we thought about a solution of having only one node compile the JSP
> and the others just
> reloading the class, saving time and avoiding the problem from above.
> Sounded like a fine solution with little effort -
> a little tweaking in the jsp-Support of sling and a cluster-event should
> do the trick.
> 
> Now we saw that issue 1038 was fixed, which makes it impossible to
> ignore a change of a JSP-File in the repository
> (before it was possible to just switch off the "development mode").
> This makes our "little tweaking" to a big one.
> 
> Is there a concept for JSP in a cluster-environment which we could follow?
> Any better solution to avoiding unnecessary recompiles in a cluster?
> Probably jackrabbit gets better writing simultanously to the same
> jcr-node, but
> this is a problem we could avoid in the first place...
> 
I'm not sure if this is the best solution, but an easy solution would be
to add a switch to the jsp scripting which simply turns off compilation
and just tries to load the class. I haven't thought about all
implications but I guess this might lead to sync problems as well (for
example if the jsp is not compiled on first access etc.)

The other solution would be to not use the repository for writing the
class files but use the fsclassloader - this one writes classes to the
file system - so each node in the cluster uses its own set of classes.

Carsten
-- 
Carsten Ziegeler
[email protected]

Reply via email to