Hi Juergen, The changes sound good to me. As it's mostly internal, I'd be +1 for you committing them.
The threadtest project is made to facilitate tests like this. Cheers! Eelco On 6/16/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
I've backported the IMarkupLoader change which removes "business" logic e.g. merging markup for inheritance out of MarkupCache into markup loaders. The interface is designed in a way that markup loaders can be chained, the most simple one just using MarkupParser. Another one merging the markup in case of inheritance. In addition I moved getMarkupCache from Application to IMarkupSettings but kept the method (it now delegates) in Application and deprecated it. Beside some increased flexibility in MarkupCache (see jira) I removed the sync lock which protected the hash map from parallel access. Since we are using ConcurrentHashMap for some time already, it should no longer be a reason for the sync block. Removing the sync may improve performance in situations where many markup files must be loaded (not just taken from the cache) (how much is that an issue in real life situations) but it also means that the very same markup might be loaded twice if while the first version is loaded (but not yet in the cache) a 2nd request will load the very same markup again. The code (on my laptop) will throw the 2nd version away and always use the first one. In my opinon that is acceptable, but I didn't want to commit it before I've discussed it. What would be the best test method (e.g. threadtest? a ready made web application and hhtpunit is most likely not the most suitable approach) to stress test these scenarios to make sure that we don't run into any race conditions. I guess this is especially usefull if we agree on putting it into 1.3. Juergen
