logging, TCCL JCL 1.0.5 alpha

["Voytenko, Dmytro" <dv...@reveredata.com>]

Hi,

I'm sorry for repeating the subject if it was discussed already, but I couldn't find an archive search. 

This email is regarding numerous problems with JCL in multi-class-loader environments. This seems to be a rather critical issue. I just got a chance to take a look into changes for JCL 1.0.5 currently in the alpha stage. Unfortunetely, these changes resolve a very small percent of all the problems associated with TCCL. If I understand correctly changes mostly targeted to make sure ClassLoaders are released, thus eliminating memory leaks related to hot deployment. Other issues (arguably more critical) remain unresolved. 

One of the issues I often run into is confusion b/w web application and shared loggers in the servlet container environment (Tomcat). Here's the small description of the situation:
There're two applications: app1 and app2. Both define logging configuration for outputing into different files (logfile1 and logfile2). These two applications use shared library (shared.jar). Classes in app1, app2 and shared.jar use JCL for logging. In this case the sequence is the following:
1) app1 is invoked first (for instance ServletInApp1)
2) code in app1 invokes class/method in the shared library (for instance SharedUtils.getInfo())
3) Log in the shared class (SharedUtils) is initialized using LogFactory for app1
4) At this point, any logs produced by SharedUtils will got to logfile1
5) app2 is invoked
6) code in app2 invokes the same SharedUtils
7) all logs in the SharedUtils still go to logfile1

Such a behaviour is rather confusing and basically jeopardizes any advantages of configuring LogFactory-s for each TCCL. This also brings system into the uncertain state. If app1 is redeployed, it's not clear what will happen to the SharedUtils.log, especially if LogFactory itself will be weak-referenced (as in 1.0.5). 

These all problems could be resolved by simply disabling use of TCCL in the LogFactory. I entered this request in the bug database while ago: http://issues.apache.org/bugzilla/show_bug.cgi?id=36927

This problem seems to be rather critical to me, so I was wondering if you have other plans to resolve these problems, or if you believe the solution described in the bug report is appropriate. If you're persuing other ways to resolve the issue, could you please point me to the documents or bug reports describing them? In either case, do you have information on when the fix could be released?

thanks,
Dimitry E Voytenko



  

- ABOUT REVERE -

Revere provides finance and business professionals with superior data and analytics on companies traded publicly in the U.S. Our approach is based on precise classification and identification of key business relationships. The Revere Complete product suite combines the Revere Research analysis platform and the Revere RealTime market data application. Revere Complete integrates comprehensive financial and market information - real-time quotes, sector and option analytics, charts, news, fundamental data, and sophisticated screening - with unique content derived from Revere's own independent research: 

- The Revere Hierarchy, a patented classification system that provides unmatched detail in specifying a company's business activities and identifying exact competitors

- Revere Relationships, a database mapping a company to its key competitors, customers, suppliers, and strategic partners
 
www.reveredata.com

Re: logging, TCCL JCL 1.0.5 alpha

[Simon Kitching <sk...@apache.org>]

Hi Dimitry,

On Wed, 2005-12-21 at 16:32 -0800, Voytenko, Dmytro wrote:
> Hi,
> 
> I'm sorry for repeating the subject if it was discussed already, but I couldn't find an archive search. 
> 
> This email is regarding numerous problems with JCL in multi-class-loader environments. This seems to be a rather critical issue. I just got a chance to take a look into changes for JCL 1.0.5 currently in the alpha stage. Unfortunetely, these changes resolve a very small percent of all the problems associated with TCCL. If I understand correctly changes mostly targeted to make sure ClassLoaders are released, thus eliminating memory leaks related to hot deployment. Other issues (arguably more critical) remain unresolved. 
> 
[snip]
> Such a behaviour is rather confusing and basically jeopardizes any advantages of configuring LogFactory-s for each TCCL. This also brings system into the uncertain state. If app1 is redeployed, it's not clear what will happen to the SharedUtils.log, especially if LogFactory itself will be weak-referenced (as in 1.0.5). 
> 
> These all problems could be resolved by simply disabling use of TCCL in the LogFactory. I entered this request in the bug database while ago: http://issues.apache.org/bugzilla/show_bug.cgi?id=36927
> 
> This problem seems to be rather critical to me, so I was wondering if you have other plans to resolve these problems, or if you believe the solution described in the bug report is appropriate. If you're persuing other ways to resolve the issue, could you please point me to the documents or bug reports describing them? In either case, do you have information on when the fix could be released?
> 
> thanks,
> Dimitry E Voytenko

There have been a lot of changes since that 1.0.5 alpha branch. It's
better to look at the SVN trunk to see what's happening with JCL.

The next release is likely to be called 1.1, and contain what's
currently in SVN trunk, or very near to it.

With the JCL changes currently in SVN, it is believed that JCL will
correctly handle most cases without the need to disable TCCL loading.
However I agree that there should be some way to completely disable TCCL
loading if necessary, as you describe in your bugzilla entry. I plan to
implement that sometime in early January (assuming that's acceptable to
other JCL developers).

There is definitely interest in getting the JCL 1.1 release out in the
very near future; see the wiki release plan page for example.
Unfortunately no-one has been able to find the time to put the final
touches together but again I hope that I can get that done in January.

If you can help in reviewing code and testing that would be greatly
appreciated.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org