----- Original Message -----
From: "Pon Umapathy K.S." <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, December 04, 2003 10:18 PM
Subject: RE: Tomcat's ThreadPool and InheritableThreadLocal variables
> >
> > Likely, you can get better advice if you try to explain what problem it
is
> > you are using InheritableThreadLocal for :).
> >
>
> Let me explain what exactly i am trying to acheive.
> We have a web server which runs a suite of applications.There are a large
> number of backend libraries which are used by these different
> applications.The logging done in these libraries will need to go into a
> different log location depending on the calling application(originates
from
> the application invoked from the User Interface).
>
> The library code typically gets a reference to the current Logging context
> by a call
> LoggerIf log=Logger.getCurrentInstance();
>
> The caller would have set the logging context for that thread before
> calling the library code using
> Logger.setCurrentLogInstance(new LoggerImpl("fileName"));
> which sets the value of a InheritableThreadLocal variable to the
specified
> logger instance.
>
> Suppose a request sets the logging context using the thread it is running
> in.After the request is processed,this var is not cleared.So,when a new
> request is processed using the same thread(if the request processing does
> not invlove setting the current logging context),the called backend
> libraries would get the reference to the logging context set by the
previous
> request which was not cleared.
>
> Yes,i know that it's better to pass around the logger references and
> all.But,i would like to see if i can achieve the same results without
having
> to pass around an explicit logger reference every time. :)
>
> Currently,this is what i have planned to do:
>
> I am not allowed to touch the ActionServlet class.So,i wont be able to do
> any preprocessing on a new request by which i can reset the logging
> context.So,this is how i plan to do it:
>
> Have a Logger object in the ActionForm(to be used for that session).
>
> The action class would do something like this for each request:
>
> // See if there is a logger for this session
> LoggerIf log=FormBean.getLogger();
> if(log==null)
> {
> // No.So,create a new one and set the logging context for this thread
> log= Logger.setLogger(new LoggerImpl("fileName"));
> FormBean.setLogger(log);
> }else
> {
> // set the logging context for this thread using the logger created for
> this session
> Logger.setLogger(log);
> }
>
> ...
> ...
>
> // And before returning from the request,clear the logging context for
the
> thread.
> Logger.clearLogger();
> return screenId;
>
> Have to test this out,though.But,it should work.
>
> As an aside,should'nt this behaviour be corrected in tomcat to clear the
> ThreadLocal variables once a request is done(because as i see it,a thread
is
> very much local to the request it is processing)?
>
Actually, with the Ajp13Connector, the thread is there to handle many
request from many users. With the CoyoteConnector2 (in 3.3.2, but pluggable
into 3.3.1), the same user gets multiple requests on the same thread. I
don't really see that it is Tomcat's job to clear application variables that
it knows nothing about.
On the plus side, it should be pretty easy to add in your own custom
Interceptor to do what you want (at least until you decide to move to a
Servlet-API version that gives you more options :). The Tomcat 3.3.x API is
basically Listener based (w/o explicitly subclassing any java.x.*Listener).
Your class needs to extend o.a.t.core.BaseInterceptor, and then overrides
the events it is interested in (in your case, I'm guessing preService and
postService). The getInfo and setInfo methods are also cool for classes
that have access to the Request (so that you can do custom Request attribute
processing).
> > -----Original Message-----
> > From: Bill Barker [mailto:[EMAIL PROTECTED]
> > Sent: Friday, December 05, 2003 11:19 AM
> > To: Tomcat Users List
> > Subject: Re: Tomcat's ThreadPool and InheritableThreadLocal variables
> >
> >
> > Yoav is pretty much right. And, this is pretty much true for Tomcat
4.1.x
> > and Tomcat 5.0.x, since they all use the same threading code.
> >
> > Given the limitations of the 2.2 spec, the easiest is to use Request
> > attributes to pass things along. This works for includes, forwards, and
> > even JSP tags (who can access the Request from the pageContext).
> > It doesn't
> > work if you want to pass them to generic Beans. In this case,
> > you can still
> > use Request attributes, but you must set the attributes on the Beans
> > explictly.
> >
> > Likely, you can get better advice if you try to explain what problem it
is
> > you are using InheritableThreadLocal for :).
> >
> > ----- Original Message -----
> > From: "Pon Umapathy K.S." <[EMAIL PROTECTED]>
> > Newsgroups: gmane.comp.jakarta.tomcat.user
> > Sent: Thursday, December 04, 2003 4:09 AM
> > Subject: Tomcat's ThreadPool and InheritableThreadLocal variables
> >
> >
> > > Hi,
> > > A query regarding InheritableThreadLocal variables in the
> > tomcat context.
> > >
> > > To explain the problem i am facing:
> > > If i am correct,for each request,tomcat uses a thread from it's
> > threadpool
> > > to process the request.
> > > Suppose during one of these requests,i set the value of a
> > > InheritableThreadLocal variable.Once this request is
> > processed,the thread
> > > will be available for use from the ThreadPool.Does tomcat reset
> > the value
> > of
> > > the InheritableThreadLocal variable which was set by the
> > previous request
> > > processing?(it should,ideally). The tomcat version i am using is
> > 3.3.1a.Also
> > > use the struts framework model.
> > >
> > > It seems to me that the InheritableThreadLocal value which was set by
a
> > > previous request on a thread is still retained when that thread
> > is reused
> > > for processing another request.Are there any known issues
> > regarding this?
> > > Would be really helpful if someone can answer this.A bit
> > urgent.Thanks in
> > > advance.
> > >
> > > Regards,
> > > Umapathy
> >
> >
>
>
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
