Bug 49521 - Fix ordering issues in setting channelSocket.maxPort
Summary: Fix ordering issues in setting channelSocket.maxPort
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:Coyote (show other bugs)
Version: 5.5.31
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2010-06-29 10:14 UTC by Konstantin Kolinko
Modified: 2010-11-07 00:25 UTC (History)
0 users

2010-06-29_tc6_maxPort.patch (1.28 KB, patch)
2010-06-29 10:20 UTC, Konstantin Kolinko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2010-06-29 10:14:35 UTC
There is a feature in org.apache.jk.server.JkCoyoteHandler implementation of AJP/1.3 protocol: when connector fails to bind to the specified port, it does not fail immediately but will try next available port number.

This was previously discussed in the following threads:

This feature is implemented in the org.apache.jk.common.ChannelSocket and ChannelNioSocket classes and can be controlled by setting channelSocket.maxPort property on a <Connector/>, but there is a bug:

ChannelSocket#setPort(int) resets the value of maxPort, and thus the final configuration is dependent on the order in which the XML attributes were processed.

This concerns only JkCoyoteHandler implementation of the protocol, present in Tomcat 5.5 and 6.0. The new AjpProtocol implementation present in 6.0 and used by default in Tomcat 7.0, as well AjpAprProtocol are not affected.
Comment 1 Konstantin Kolinko 2010-06-29 10:20:40 UTC
Created attachment 25657 [details]

Patch for tc6.0.x
It does the following:
- implements <Connector maxPort=""/> as a synonym for <Connector channelSocket.maxPort=""/>
- implements workaround for this issue, so that the channelSocket.maxPort property, if present, is applied later than the others
Comment 2 Konstantin Kolinko 2010-07-17 19:09:20 UTC
Comment on attachment 25657 [details]

Proposed a different patch for 6.0 and 5.5
Comment 3 Mark Thomas 2010-09-22 11:04:17 UTC
Fixed in 6.0.x and will be included in 6.0.30 onwards.
Comment 4 Konstantin Kolinko 2010-11-07 00:25:37 UTC
Fixed in 5.5.x and will be in 5.5.32 onwards.