You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dejan Krsmanovic <de...@gmail.com> on 2007/05/28 15:43:31 UTC
Web application receives request parameters sent to another application
on Tomcat 6
We have two applications running on the same Tomcat instance. These two
applications are used by completely different people and one of them has
much higher traffic than another one.
Recently we have upgraded to Tomcat 6.10 and start experiencing strange
behavior. After a lot of debugging, we have noticed that the first
application sometimes receives request parameters sent to second
application. Parameters are mixed-up, that is, request.getParameterMap()
returns parameters from both applications. This is not happening all the
time (probably because one of these applications is used rarely), but we
had this situation several times a day.
After some time we have decided to return back to Tomcat 5.5.x and the
problems stopped.
What can be reason for such problems? Is it possible that Tomcat re-uses
some objects internally without clearing them up?
Regards,
Dejan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Web application receives request parameters sent to another application
on Tomcat 6
Posted by Dejan Krsmanovic <de...@gmail.com>.
Rashmi Rubdi wrote:
> It is hard to tell what could be the problem without knowing full
> details of how the 2 projects Host, Context etc are configured.
>
> Are they at the ROOT context, or other Context?
No, they are on different contexts (not ROOT).
>
> Are they on a virtual host or all of them on localhost?
Both applications are on localhost. Virtual hosts are not used.
>
> Is crossContext set to true or false?
crossContext attribute is not set, thus I assume it should be false by
default.
>
> relevant sections of server.xml , Context xml files will be useful.
>
Server.xml has default values (we didn't changed it). Both applications
have their own context.xml files specified. There is nothing special in
it; reloadable is set to false and both applications have data source
defined as resource.
Just to mention - one of these two applications is accessed by users
with browsers only while second application is accessed by both browsers
and hand held devices (Pocket PCs). The devices use .Net application
which sends POST request with data in one large String. When servlet on
the second application receives request from device, it sometimes
contains additional request parameters that are not sent by device. We
have discovered that these parameter names are used in the second
application, that is parameters from both applications are somehow
mixed-up. We suspect that problem arises when both applications are used
at the same time, but we could not verify it (we have just analyzed log
files).
As I said, we had this problem on Tomcat 6.10 only. Tomcat 5.5.x works
fine with the same context configuration.
Regards,
Dejan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Web application receives request parameters sent to another application on Tomcat 6
Posted by Rashmi Rubdi <ra...@gmail.com>.
On 5/28/07, Dejan Krsmanovic <de...@gmail.com> wrote:
> We have two applications running on the same Tomcat instance. These two
> applications are used by completely different people and one of them has
> much higher traffic than another one.
> Recently we have upgraded to Tomcat 6.10 and start experiencing strange
> behavior. After a lot of debugging, we have noticed that the first
> application sometimes receives request parameters sent to second
> application. Parameters are mixed-up, that is, request.getParameterMap()
> returns parameters from both applications. This is not happening all the
> time (probably because one of these applications is used rarely), but we
> had this situation several times a day.
> After some time we have decided to return back to Tomcat 5.5.x and the
> problems stopped.
>
> What can be reason for such problems? Is it possible that Tomcat re-uses
> some objects internally without clearing them up?
It is hard to tell what could be the problem without knowing full
details of how the 2 projects Host, Context etc are configured.
Are they at the ROOT context, or other Context?
Are they on a virtual host or all of them on localhost?
Is crossContext set to true or false?
relevant sections of server.xml , Context xml files will be useful.
> Regards,
> Dejan
-Regards
Rashmi
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Web application receives request parameters sent to another application
on Tomcat 6
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
What connector are you using? ie, how does the <Connector> element look
in server.xml?
Filip
Dejan Krsmanovic wrote:
> We have two applications running on the same Tomcat instance. These two
> applications are used by completely different people and one of them has
> much higher traffic than another one.
> Recently we have upgraded to Tomcat 6.10 and start experiencing strange
> behavior. After a lot of debugging, we have noticed that the first
> application sometimes receives request parameters sent to second
> application. Parameters are mixed-up, that is, request.getParameterMap()
> returns parameters from both applications. This is not happening all the
> time (probably because one of these applications is used rarely), but we
> had this situation several times a day.
> After some time we have decided to return back to Tomcat 5.5.x and the
> problems stopped.
>
> What can be reason for such problems? Is it possible that Tomcat re-uses
> some objects internally without clearing them up?
>
> Regards,
> Dejan
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Comet: Unsufficiently synchronized recycling decisions
Posted by "Reich, Matthias" <ma...@siemens.com>.
Hi,
as mentioned in my contribution to topic 'Web application receives
request parameters sent to another application on Tomcat 6', I sometimes
get non-recycled Request objects in a BEGIN event.
A non-recycled request object appeared in a BEGIN event if the previous
request processed by the same request processor was answered
asynchronously directly after the BEGIN event.
In such a situation my Servlet sometimes did not get an END event, i.e.
the CoyoteAdapter was not triggered again and therefore could not
recycle the Request object.
Nevertheless, the request processor was recycled, i.e. readded to the
processor pool.
As the processor was recycled, the cometEvent.close() must have happened
*after* CoyoteAdapter had made the decision not to recycle
Request/Response, but *before* Http11AprProtocol had made the decision
to recycle the processor.
To verify this, I modified the methods Http11AprProcessor.event and
Http11AprProcessor.process.
I replaced every occurrence of:
recycle();
within these methods with the following lines:
org.apache.catalina.connector.Request req =
(org.apache.catalina.connector.Request) request.getNote(1);
org.apache.catalina.connector.Response res =
(org.apache.catalina.connector.Response) response.getNote(1);
req.recycle( );
res.recycle( );
recycle();
I know that this is a hack and must be solved in a better way (and also
for the NIOConnector), but with these modifications I enforced a single
decision point for recycling of Request/Response *and* the processor.
When running Tomcat with these modifications, my Servlet no longer
received non-recycled Request objects.
Regards,
Matthias
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Web application receives request parameters sent to another application on Tomcat 6
Posted by "Reich, Matthias" <ma...@siemens.com>.
With some additional logging I found out that my problem is most
probably not related to the mixed request parameters.
It is a problem of synchronizing the decisions of whether to recycle
Request/Response objects and whether to recycle the processor.
I'll send more details in another mail with topic 'Comet: Unsufficiently
synchronized recycling decisions'.
Regards,
Matthias
> -----Original Message-----
> From: Reich, Matthias
> Sent: Tuesday, May 29, 2007 10:54 AM
> To: 'Tomcat Users List'
> Subject: RE: Web application receives request parameters sent
> to another application on Tomcat 6
>
> Hi,
>
> I am experiencing a behavior that may be related to the
> mentioned problem.
>
> My Servlet uses the Comet interfaces of Tomcat 6.
> For debugging purposes, when my Servlet receives a BEGIN
> event, it stores a request counter in an atttribute of the
> HttpServletRequest object.
> (This is done to see in the logs to which request a
> subsequent READ, END or ERROR event is related.)
>
> Before setting the attribute, the servlet checks whether the
> attribute is already set:
>
> if (event.getEventType() == CometEvent.EventType.BEGIN)
> {
> HttpServletRequest request = event.getHttpServletRequest( );
> Long index = (Long) request.getAttribute(INDEX_ATTRIBUTE);
> if (index == null)
> {
> index = nextRequestIndex();
> request.setAttribute(INDEX_ATTRIBUTE, index);
> requestCount++;
> }
> else
> {
> myLogger.warn("Found old request attribute ("
> + index + ") in BEGIN event!");
> }
> ...
>
> When running tests where several requests are processed at
> the same time, I occasionally see the log message appear.
>
> It looks as if sometimes recycling of a request object is not
> yet completed when the object is already reused for a new request.
> I cannot tell if a similar behavior occurs in my tests also
> for request parameters because my tests don't pay much
> attention on the parameters.
>
> The 'old attributes' problem occurs as well with the APR
> connector as with the NIO connector, and I guess that also
> the 'wrong request parameters' problem only occurs with these
> two connectors, as they are prepared to handle Comet requests
> and therefore have a modified request processing (compared to
> the Http11Processor) also for 'regular' servlet requests.
>
> What connector are you using with Tomcat 6?
>
> If it is the APR connector (i.e. if you have the tcnative-1
> library in your library path), you could try if the problem
> disappears when you switch to the Http11Protocol.
>
>
> Matthias
>
>
> > -----Original Message-----
> > From: Dejan Krsmanovic [mailto:dejan.krsmanovic@gmail.com]
> > Sent: Tuesday, May 29, 2007 8:13 AM
> > To: Tomcat Users List
> > Subject: Re: Web application receives request parameters sent
> > to another application on Tomcat 6
> >
> > I am aware of that. We are printing request parameters inside
> > Servlet's
> > doPost method.
> >
> > Dejan
> >
> > Len Popp wrote:
> > > It is possible that Tomcat resuses request objects. I'm
> not sure it
> > > does, but it might. For that reason, you're only allowed
> to use the
> > > request object in your servlet's doGet or doPost method, you can't
> > > stash it somewhere (e.g. in the HttpSession) and access it later.
> > > (This is mentioned in the servlet spec.) Of course I don't know if
> > > that's your problem, it's just something that came to mind.
> >
> >
> >
> ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Comet: Unsufficiently synchronized recycling decisions
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
The explanation is enough, thank you for the detailed info.
yes, having two different flags can make life difficult for us, I will
look into it.
Filip
Reich, Matthias wrote:
> Filip,
>
> thank you for the response.
>
> The issue is fairly simple:
>
> At some point in time (t1) the CoyoteAdapter.service (or the
> CoyoteAdapter.event) method calls request.isComet().
> If the CometEvent has not been closed at (t1), this method returns true
> and request and response are not recycled.
>
> At a later point in time (t2), after returning from the call to the
> CoyoteAdapter, the Http11AprProcessor.process (or
> Http11AprProcessor.event) method checks the comet flag. If the flag is
> false at (t2), the processor will be recycled.
>
> In almost all cases the comet flag is still true at (t2) if
> request.isComet() had returned true at (t1).
>
> However, especially in heavy load situations, another thread may be
> scheduled between (t1) and (t2) and call event.close() . In such a
> situation, the comet falg will be false at (t2) and the processor is
> recycled while request and response are not recycled. The processor will
> then process the next request with non-recycled request/response
> objects.
>
> My quick and dirty fix calls the recycle methods of request and response
> whenever the recycle method of the processor is called, regardless if
> request and response had been recycled before or not.
>
>
> It is not that easy to provide a simple example app that produces such a
> behaviour reliably.
> I can see that it happens in my application which runs an embedded
> Tomcat and a whole bunch of additional threads when the system is under
> load, but it does not happen in a simple test situation.
>
>
> Regards,
> Matthias
>
>
>
>
>
>> -----Original Message-----
>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>> Sent: Wednesday, June 13, 2007 8:09 PM
>> To: Tomcat Users List
>> Subject: Re: Comet: Unsufficiently synchronized recycling decisions
>>
>> Reich, Matthias wrote:
>>
>>> Hello,
>>>
>>> I did not get any response on my post from 2 weeks ago.
>>>
>>> Even if non-recycling of request/response objects happens only
>>> sporadically and only in webapps where asynchronous
>>>
>> responses may happen
>>
>>> before the event processing has finished, it is definitively a bug.
>>>
>>> Should I report it as a bug to receive any reaction?
>>>
>>>
>> a bug would help only if it has an example app, or enough
>> info to help
>> us truly understand the issue.
>> personally, I haven't had enough time to look through it to truly
>> understand it, cause I believe the fix would probably be
>> easier than the
>> one described below
>>
>> Filip
>>
>>
>>> Regards,
>>> Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Reich, Matthias
>>>> Sent: Wednesday, May 30, 2007 2:04 PM
>>>> To: 'Tomcat Users List'
>>>> Subject: Comet: Unsufficiently synchronized recycling decisions
>>>>
>>>> Hi,
>>>>
>>>> as mentioned in my contribution to topic 'Web application
>>>> receives request parameters sent to another application on
>>>> Tomcat 6', I sometimes get non-recycled Request objects in a
>>>> BEGIN event.
>>>>
>>>> A non-recycled request object appeared in a BEGIN event if
>>>> the previous request processed by the same request processor
>>>> was answered asynchronously directly after the BEGIN event.
>>>>
>>>> In such a situation my Servlet sometimes did not get an END
>>>> event, i.e. the CoyoteAdapter was not triggered again and
>>>> therefore could not recycle the Request object.
>>>> Nevertheless, the request processor was recycled, i.e.
>>>> readded to the processor pool.
>>>>
>>>> As the processor was recycled, the cometEvent.close() must
>>>> have happened *after* CoyoteAdapter had made the decision not
>>>> to recycle Request/Response, but *before* Http11AprProtocol
>>>> had made the decision to recycle the processor.
>>>>
>>>> To verify this, I modified the methods
>>>> Http11AprProcessor.event and Http11AprProcessor.process.
>>>>
>>>> I replaced every occurrence of:
>>>>
>>>> recycle();
>>>>
>>>> within these methods with the following lines:
>>>>
>>>> org.apache.catalina.connector.Request req =
>>>> (org.apache.catalina.connector.Request) request.getNote(1);
>>>> org.apache.catalina.connector.Response res =
>>>> (org.apache.catalina.connector.Response) response.getNote(1);
>>>> req.recycle( );
>>>> res.recycle( );
>>>> recycle();
>>>>
>>>> I know that this is a hack and must be solved in a better way
>>>> (and also for the NIOConnector), but with these modifications
>>>> I enforced a single decision point for recycling of
>>>> Request/Response *and* the processor.
>>>>
>>>> When running Tomcat with these modifications, my Servlet no
>>>> longer received non-recycled Request objects.
>>>>
>>>>
>>>> Regards,
>>>> Matthias
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Comet: Unsufficiently synchronized recycling decisions
Posted by "Reich, Matthias" <ma...@siemens.com>.
Filip,
thank you for the response.
The issue is fairly simple:
At some point in time (t1) the CoyoteAdapter.service (or the
CoyoteAdapter.event) method calls request.isComet().
If the CometEvent has not been closed at (t1), this method returns true
and request and response are not recycled.
At a later point in time (t2), after returning from the call to the
CoyoteAdapter, the Http11AprProcessor.process (or
Http11AprProcessor.event) method checks the comet flag. If the flag is
false at (t2), the processor will be recycled.
In almost all cases the comet flag is still true at (t2) if
request.isComet() had returned true at (t1).
However, especially in heavy load situations, another thread may be
scheduled between (t1) and (t2) and call event.close() . In such a
situation, the comet falg will be false at (t2) and the processor is
recycled while request and response are not recycled. The processor will
then process the next request with non-recycled request/response
objects.
My quick and dirty fix calls the recycle methods of request and response
whenever the recycle method of the processor is called, regardless if
request and response had been recycled before or not.
It is not that easy to provide a simple example app that produces such a
behaviour reliably.
I can see that it happens in my application which runs an embedded
Tomcat and a whole bunch of additional threads when the system is under
load, but it does not happen in a simple test situation.
Regards,
Matthias
> -----Original Message-----
> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
> Sent: Wednesday, June 13, 2007 8:09 PM
> To: Tomcat Users List
> Subject: Re: Comet: Unsufficiently synchronized recycling decisions
>
> Reich, Matthias wrote:
> > Hello,
> >
> > I did not get any response on my post from 2 weeks ago.
> >
> > Even if non-recycling of request/response objects happens only
> > sporadically and only in webapps where asynchronous
> responses may happen
> > before the event processing has finished, it is definitively a bug.
> >
> > Should I report it as a bug to receive any reaction?
> >
> a bug would help only if it has an example app, or enough
> info to help
> us truly understand the issue.
> personally, I haven't had enough time to look through it to truly
> understand it, cause I believe the fix would probably be
> easier than the
> one described below
>
> Filip
>
> > Regards,
> > Matthias
> >
> >
> >> -----Original Message-----
> >> From: Reich, Matthias
> >> Sent: Wednesday, May 30, 2007 2:04 PM
> >> To: 'Tomcat Users List'
> >> Subject: Comet: Unsufficiently synchronized recycling decisions
> >>
> >> Hi,
> >>
> >> as mentioned in my contribution to topic 'Web application
> >> receives request parameters sent to another application on
> >> Tomcat 6', I sometimes get non-recycled Request objects in a
> >> BEGIN event.
> >>
> >> A non-recycled request object appeared in a BEGIN event if
> >> the previous request processed by the same request processor
> >> was answered asynchronously directly after the BEGIN event.
> >>
> >> In such a situation my Servlet sometimes did not get an END
> >> event, i.e. the CoyoteAdapter was not triggered again and
> >> therefore could not recycle the Request object.
> >> Nevertheless, the request processor was recycled, i.e.
> >> readded to the processor pool.
> >>
> >> As the processor was recycled, the cometEvent.close() must
> >> have happened *after* CoyoteAdapter had made the decision not
> >> to recycle Request/Response, but *before* Http11AprProtocol
> >> had made the decision to recycle the processor.
> >>
> >> To verify this, I modified the methods
> >> Http11AprProcessor.event and Http11AprProcessor.process.
> >>
> >> I replaced every occurrence of:
> >>
> >> recycle();
> >>
> >> within these methods with the following lines:
> >>
> >> org.apache.catalina.connector.Request req =
> >> (org.apache.catalina.connector.Request) request.getNote(1);
> >> org.apache.catalina.connector.Response res =
> >> (org.apache.catalina.connector.Response) response.getNote(1);
> >> req.recycle( );
> >> res.recycle( );
> >> recycle();
> >>
> >> I know that this is a hack and must be solved in a better way
> >> (and also for the NIOConnector), but with these modifications
> >> I enforced a single decision point for recycling of
> >> Request/Response *and* the processor.
> >>
> >> When running Tomcat with these modifications, my Servlet no
> >> longer received non-recycled Request objects.
> >>
> >>
> >> Regards,
> >> Matthias
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Comet: Unsufficiently synchronized recycling decisions
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Reich, Matthias wrote:
> Hello,
>
> I did not get any response on my post from 2 weeks ago.
>
> Even if non-recycling of request/response objects happens only
> sporadically and only in webapps where asynchronous responses may happen
> before the event processing has finished, it is definitively a bug.
>
> Should I report it as a bug to receive any reaction?
>
a bug would help only if it has an example app, or enough info to help
us truly understand the issue.
personally, I haven't had enough time to look through it to truly
understand it, cause I believe the fix would probably be easier than the
one described below
Filip
> Regards,
> Matthias
>
>
>> -----Original Message-----
>> From: Reich, Matthias
>> Sent: Wednesday, May 30, 2007 2:04 PM
>> To: 'Tomcat Users List'
>> Subject: Comet: Unsufficiently synchronized recycling decisions
>>
>> Hi,
>>
>> as mentioned in my contribution to topic 'Web application
>> receives request parameters sent to another application on
>> Tomcat 6', I sometimes get non-recycled Request objects in a
>> BEGIN event.
>>
>> A non-recycled request object appeared in a BEGIN event if
>> the previous request processed by the same request processor
>> was answered asynchronously directly after the BEGIN event.
>>
>> In such a situation my Servlet sometimes did not get an END
>> event, i.e. the CoyoteAdapter was not triggered again and
>> therefore could not recycle the Request object.
>> Nevertheless, the request processor was recycled, i.e.
>> readded to the processor pool.
>>
>> As the processor was recycled, the cometEvent.close() must
>> have happened *after* CoyoteAdapter had made the decision not
>> to recycle Request/Response, but *before* Http11AprProtocol
>> had made the decision to recycle the processor.
>>
>> To verify this, I modified the methods
>> Http11AprProcessor.event and Http11AprProcessor.process.
>>
>> I replaced every occurrence of:
>>
>> recycle();
>>
>> within these methods with the following lines:
>>
>> org.apache.catalina.connector.Request req =
>> (org.apache.catalina.connector.Request) request.getNote(1);
>> org.apache.catalina.connector.Response res =
>> (org.apache.catalina.connector.Response) response.getNote(1);
>> req.recycle( );
>> res.recycle( );
>> recycle();
>>
>> I know that this is a hack and must be solved in a better way
>> (and also for the NIOConnector), but with these modifications
>> I enforced a single decision point for recycling of
>> Request/Response *and* the processor.
>>
>> When running Tomcat with these modifications, my Servlet no
>> longer received non-recycled Request objects.
>>
>>
>> Regards,
>> Matthias
>>
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Comet: Unsufficiently synchronized recycling decisions
Posted by "Reich, Matthias" <ma...@siemens.com>.
Hello,
I did not get any response on my post from 2 weeks ago.
Even if non-recycling of request/response objects happens only
sporadically and only in webapps where asynchronous responses may happen
before the event processing has finished, it is definitively a bug.
Should I report it as a bug to receive any reaction?
Regards,
Matthias
> -----Original Message-----
> From: Reich, Matthias
> Sent: Wednesday, May 30, 2007 2:04 PM
> To: 'Tomcat Users List'
> Subject: Comet: Unsufficiently synchronized recycling decisions
>
> Hi,
>
> as mentioned in my contribution to topic 'Web application
> receives request parameters sent to another application on
> Tomcat 6', I sometimes get non-recycled Request objects in a
> BEGIN event.
>
> A non-recycled request object appeared in a BEGIN event if
> the previous request processed by the same request processor
> was answered asynchronously directly after the BEGIN event.
>
> In such a situation my Servlet sometimes did not get an END
> event, i.e. the CoyoteAdapter was not triggered again and
> therefore could not recycle the Request object.
> Nevertheless, the request processor was recycled, i.e.
> readded to the processor pool.
>
> As the processor was recycled, the cometEvent.close() must
> have happened *after* CoyoteAdapter had made the decision not
> to recycle Request/Response, but *before* Http11AprProtocol
> had made the decision to recycle the processor.
>
> To verify this, I modified the methods
> Http11AprProcessor.event and Http11AprProcessor.process.
>
> I replaced every occurrence of:
>
> recycle();
>
> within these methods with the following lines:
>
> org.apache.catalina.connector.Request req =
> (org.apache.catalina.connector.Request) request.getNote(1);
> org.apache.catalina.connector.Response res =
> (org.apache.catalina.connector.Response) response.getNote(1);
> req.recycle( );
> res.recycle( );
> recycle();
>
> I know that this is a hack and must be solved in a better way
> (and also for the NIOConnector), but with these modifications
> I enforced a single decision point for recycling of
> Request/Response *and* the processor.
>
> When running Tomcat with these modifications, my Servlet no
> longer received non-recycled Request objects.
>
>
> Regards,
> Matthias
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Web application receives request parameters sent to another application on Tomcat 6
Posted by "Reich, Matthias" <ma...@siemens.com>.
Hi,
I am experiencing a behavior that may be related to the mentioned
problem.
My Servlet uses the Comet interfaces of Tomcat 6.
For debugging purposes, when my Servlet receives a BEGIN event, it
stores a request counter in an atttribute of the HttpServletRequest
object.
(This is done to see in the logs to which request a subsequent READ, END
or ERROR event is related.)
Before setting the attribute, the servlet checks whether the attribute
is already set:
if (event.getEventType() == CometEvent.EventType.BEGIN)
{
HttpServletRequest request = event.getHttpServletRequest( );
Long index = (Long) request.getAttribute(INDEX_ATTRIBUTE);
if (index == null)
{
index = nextRequestIndex();
request.setAttribute(INDEX_ATTRIBUTE, index);
requestCount++;
}
else
{
myLogger.warn("Found old request attribute ("
+ index + ") in BEGIN event!");
}
...
When running tests where several requests are processed at the same
time, I occasionally see the log message appear.
It looks as if sometimes recycling of a request object is not yet
completed when the object is already reused for a new request.
I cannot tell if a similar behavior occurs in my tests also for request
parameters because my tests don't pay much attention on the parameters.
The 'old attributes' problem occurs as well with the APR connector as
with the NIO connector, and I guess that also the 'wrong request
parameters' problem only occurs with these two connectors, as they are
prepared to handle Comet requests and therefore have a modified request
processing (compared to the Http11Processor) also for 'regular' servlet
requests.
What connector are you using with Tomcat 6?
If it is the APR connector (i.e. if you have the tcnative-1 library in
your library path), you could try if the problem disappears when you
switch to the Http11Protocol.
Matthias
> -----Original Message-----
> From: Dejan Krsmanovic [mailto:dejan.krsmanovic@gmail.com]
> Sent: Tuesday, May 29, 2007 8:13 AM
> To: Tomcat Users List
> Subject: Re: Web application receives request parameters sent
> to another application on Tomcat 6
>
> I am aware of that. We are printing request parameters inside
> Servlet's
> doPost method.
>
> Dejan
>
> Len Popp wrote:
> > It is possible that Tomcat resuses request objects. I'm not sure it
> > does, but it might. For that reason, you're only allowed to use the
> > request object in your servlet's doGet or doPost method, you can't
> > stash it somewhere (e.g. in the HttpSession) and access it later.
> > (This is mentioned in the servlet spec.) Of course I don't know if
> > that's your problem, it's just something that came to mind.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Web application receives request parameters sent to another application
on Tomcat 6
Posted by Dejan Krsmanovic <de...@gmail.com>.
I am aware of that. We are printing request parameters inside Servlet's
doPost method.
Dejan
Len Popp wrote:
> It is possible that Tomcat resuses request objects. I'm not sure it
> does, but it might. For that reason, you're only allowed to use the
> request object in your servlet's doGet or doPost method, you can't
> stash it somewhere (e.g. in the HttpSession) and access it later.
> (This is mentioned in the servlet spec.) Of course I don't know if
> that's your problem, it's just something that came to mind.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Web application receives request parameters sent to another application on Tomcat 6
Posted by Len Popp <le...@gmail.com>.
It is possible that Tomcat resuses request objects. I'm not sure it
does, but it might. For that reason, you're only allowed to use the
request object in your servlet's doGet or doPost method, you can't
stash it somewhere (e.g. in the HttpSession) and access it later.
(This is mentioned in the servlet spec.) Of course I don't know if
that's your problem, it's just something that came to mind.
--
Len
On 5/28/07, Dejan Krsmanovic <de...@gmail.com> wrote:
> We have two applications running on the same Tomcat instance. These two
> applications are used by completely different people and one of them has
> much higher traffic than another one.
> Recently we have upgraded to Tomcat 6.10 and start experiencing strange
> behavior. After a lot of debugging, we have noticed that the first
> application sometimes receives request parameters sent to second
> application. Parameters are mixed-up, that is, request.getParameterMap()
> returns parameters from both applications. This is not happening all the
> time (probably because one of these applications is used rarely), but we
> had this situation several times a day.
> After some time we have decided to return back to Tomcat 5.5.x and the
> problems stopped.
>
> What can be reason for such problems? Is it possible that Tomcat re-uses
> some objects internally without clearing them up?
>
> Regards,
> Dejan
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org