Re: Deadlock issue

Hi Daniel,

with this mail I will try to answer some of the interesting points you mentioned:

On Apr 19, 2012, at 11:45 AM, Daniel Dekany wrote:

> Then maybe you share the same
> freemarker.jar file (same full-path) for multiple applications, and
> are also using the deprecated default shared (static) ObjectWrapper
> instance (or some other ObjectWrapper instance which is somehow shared
> between applications).

Yes, I can confirm that in OFBiz we only use the static instance of ObjectWrapper (i.e. BeansWrapper.getDefaultInstance()); we never use "new BeansWrapper()" in OFBiz.
So from what I understand now is that in the VM where OFBiz runs we have *one* object wrapper that is shared by all threads and applications.
I can also confirm that in OFBiz we have *one* freemarker.jar file only that is used by the framework code to render templates (defined in the several OFBiz applications).

> If two applications has the same classes from
> non-shared defining class-loaders (usually, from jar files from
> different directories), and you pass instances of those classes to the
> templates, FreeMarker will constantly believe that the classes were
> reloaded, because it gets classes of the same name which aren't
> equivalent objects. Each application needs to have its own
> ObjectWrapper in this case (see Configuration.setObjectWrapper), which
> is how it's normally done regardless of this issue anyway.
> 
> Let's try a few things instead of just trying to run into a dead-lock:
> 
> When FreeMarker detects a class change, it logs on info-level that
> "Detected a reloaded class [com.example.SomeClass]". For which classes
> does this happening? Do you understand why are those classes
> (apparently) changing?

Some examples of the messages that I see:

Detected a reloaded class [CompanyInfo$_run_closure1]. Clearing BeansWrapper caches.
Detected a reloaded class [CompanyInfo$_run_closure2]. Clearing BeansWrapper caches.
Detected a reloaded class [Breadcrumbs$_run_closure2]. Clearing BeansWrapper caches.
Detected a reloaded class [ContactUs$_run_closure1]. Clearing BeansWrapper caches.
Detected a reloaded class [ShoppingCartReadHelper$_run_closure1]. Clearing BeansWrapper caches.
Detected a reloaded class [ShoppingCartReadHelper$_run_closure2]. Clearing BeansWrapper caches.
Detected a reloaded class [ShoppingCartReadHelper$_run_closure3]. Clearing BeansWrapper caches.
Detected a reloaded class [ShoppingCartReadHelper$_run_closure4]. Clearing BeansWrapper caches.
...

At the moment they don't mke much sense to me; but I am still investigating into this.

> 
> Also, what ObjectWrapper is in use can be checked while the template
> is running with
> freemarker.core.Environment.getCurrentEnvironment().getConfiguration().getObjectWrapper().
> Write a TempalteMethodModel that returns that, print it the result
> into the template, and then you will see if its the same *instance* in
> multiple applications.

Yes, as I mentioned above I am pretty sure that we use *one* instance only (the static instance).
So, if I understand the problem, the deadlock occurs because the following two conditions are met:
a) OFBiz is using *one* instance of BeansWrapper and *one* (?)  instance of ClassBasedModelFactory for all the applications
b) the frequent clearing of caches because they are reloaded (or Freemarker thinks they are); the reason for this is still unknown (I will have to research more)

Kind regards,

Jacopo


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2