Bill,
> > 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.
In some ways,you are right.But,looking at it this way.
When it's said that each request is processed in a *new* thread,it is
reasonable to expect that thread-specific language constructs will be
handled.In this case,a new thread would mean new copies of ThreadLocal and
InheritableThreadLocal variables.
If this new thread is created in a customized manner(in this case,alloted
from a ThreadPool),I would say that the behaviour of the new Thread should
be modelled on the language defined lines.
It would be good if this is atleast documented somewhere. :)
>
>
> ----- 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
> > >
> > >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
