Bug 56657 - Parallel deployment. If sessionid belongs to the latest version of webapp, use the latest version.
Parallel deployment. If sessionid belongs to the latest version of webapp, us...
Product: Tomcat 7
Classification: Unclassified
Component: Catalina
PC All
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
Depends on:
  Show dependency tree
Reported: 2014-06-22 16:25 UTC by Konstantin Kolinko
Modified: 2014-06-22 22:25 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2014-06-22 16:25:15 UTC
In 8.0.9, 7.0.54: [1]
Reviewing the loop that finds correct web application version by a sessionid.

Looking at [1], there shall be a "break;" after line 921.

This matters in the following rare scenario:
1. There are several versions of the same web application that are deployed in parallel.
2. The same sessionid is valid both for the latest version and for some older one.
3. Expected result: map request to the latest version of the webapp.
Actual result: the latest version will be skipped and the request will be mapped to an older version.

[1] http://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_9/java/org/apache/catalina/connector/CoyoteAdapter.java?view=markup#l916
Comment 1 Konstantin Kolinko 2014-06-22 16:39:55 UTC
Fixed by r1604605 r1604607 and will be in 7.0.55, 8.0.10 onwards.

Tomcat 6 is not affected, it does not implement parallel deployment.
Comment 2 Konstantin Kolinko 2014-06-22 22:15:21 UTC
Additional minor issue in the same place.

There is no check that on the second mapping loop the "version" was applied to the same path as on the first loop.

If there is the following configuration:

Consider that a request for "bar#0" comes in. It performs a remapping loop to select the "0" version. Consider that bar#0 is paused and third remapping loop is required.

If both "bar#0" and "bar#1" are undeployed before remapping, the version variable remains "0", but it is being applied to a different path. So it may select ROOT#0 instead of expected ROOT#latest.

Given the complexity of configuration to observe this, it is kind of a theoretical issue.
Comment 3 Konstantin Kolinko 2014-06-22 22:25:35 UTC
(In reply to Konstantin Kolinko from comment #2)

Fixed by r1604661 r1604662 and will be in 7.0.55, 8.0.10 onwards.