Bug 803093 - [Tomcat Plugin] Changing an existing connector type results in new connector type not being discovered
[Tomcat Plugin] Changing an existing connector type results in new connector ...
Product: JBoss Enterprise Web Server 2
Classification: JBoss
Component: JON Plugin (Show other bugs)
All All
unspecified Severity high
: ---
: ---
Assigned To: Jean-frederic Clere
Jan Stefl
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-03-13 19:14 EDT by Larry O'Leary
Modified: 2016-12-05 11:37 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
In JBoss Enterprise Web Server, when an existing Tomcat connector was changed by modifying Tomcat's <filename>server.xml</filename> file, JBoss Operations Network (JON) did not discover the new connector. The old connector remains in the inventory and is invalid. This is a known issue in JBoss Enterprise Web Server 3.0. As a workaround for this issue, remove the old connector resource from the JBoss Operations Network (JON) inventory and force service discovery to discover the new connector.
Story Points: ---
Clone Of:
Last Closed: 2014-02-14 08:47:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 81653 None None None Never

  None (edit)
Description Larry O'Leary 2012-03-13 19:14:35 EDT
Essentially, if you have an existing Tomcat Connector, say jk-8009, in inventory and alter the Tomcat server.xml to change the connector from, let's say jk to ajp, the result is the new AJP connector is never discovered and the old JK connector remains unavailable/invalid.

This appears to be a direct result of the discovery process finding the new AJP connector but because its host/port are the same as the existing JK connector, the assumption is that the connectors are the same (i.e. mapped to an existing resource in inventory).

If you manually remove the old JK connector from inventory, the new AJP connector is properly discovered and imported into inventory when the next service discovery occurs.
Comment 1 Mike Foley 2012-03-19 12:19:00 EDT
per BZ triage (asantos, ccrouch, loleary, mfoley)
Comment 2 mark yarborough 2012-11-20 16:23:03 EST
What is the EWS team priority for this bug wrt JON 3.1.2 release?
Comment 3 Jean-frederic Clere 2012-11-21 02:51:42 EST
In EWS we strongly advice not to use the old connector, the old connector is an old code in tomcat 5.5.x. In EWS 2.0 we don't deliver tomcat5.
For me that is the last bug to fix.
Comment 4 Jean-frederic Clere 2012-11-21 03:26:16 EST
The default connector is the coyote one so I think there is no reason for a customer to change that.
Comment 5 Larry O'Leary 2012-11-21 09:58:19 EST
Your comments would indicate that this is extremely urgent then. The issue is not that the old connector does not work. This issue is that when a customer attempts to use the "new" connector, it can not be monitored or managed if they stopped using the "old" connector. i.e., if this bug is not fixed, they CAN NOT use the "new" connector.
Comment 6 Larry O'Leary 2012-11-27 17:25:41 EST
As the description explains, this affects all connectors on the same port. So, if changing port 8009 from one connector type to another when an upgrade is performed, the result will be that the old connector will no longer be managed/monitored and the new connector can not be discovered (managed/monitored).

To illustrate:

* User is running EWS 1.0.2 with Tomcat 5 using jk connector type on port 8009
* User upgrades to EWS 1.0.2 or EWS 2.0 with Tomcat 6 and changes the jk connector to ajp running on port 8009.
* ON Tomcat plug-in will reflect that the jk connector is DOWN due to its connector type not matching what is actually deployed in Tomcat (ajp).
* ON Tomcat plug-in will attempt service discovery to find the new AJP connector but because the plug-in creates a resource key based on host name and port to identify a connector, the new AJP connector ends up with a key of localhost_8009.
* The newly discovered resource is ignored because we already have a resource with resource key of localhost_8009 (the old jk connector which is no longer being used).

This situation is not limited to upgrade only. If a user is using Tomcat 6 and has installed the JK connector and later decides to replace it with the AJP connector, the same problem exists.

And, to ensure it is not missed, the WORKAROUND is to simply remove the old JK connector resource from inventory and force service discovery to discover the new AJP connector.

This issue was originally reported in EWS plug-in pack for JBoss ON 3.0 and keeps getting deferred. I suggest we either fix this in the 3.1 or 3.2 release.
Comment 8 Larry O'Leary 2013-02-20 22:56:14 EST
Increasing the severity of this issue as it prevents use of the default connector in EWS 1.2/2.0 as indicated above.
Comment 10 Jean-frederic Clere 2013-04-19 09:02:09 EDT
EWS 1.0.x comes with APR so the org.apache.jk.server.JkCoyoteHandler won't be used except the APR (native) modules are broken.
Comment 11 Larry O'Leary 2013-04-19 10:10:05 EDT
I am not certain what you are trying to say here but just in case it is not clear.

Install Tomcat 5... use it... put it in JBoss ON inventory... Upgrade to Tomcat 6... switch to APR... Tomcat connector is broken in JBoss ON and the APR connector can not be discovered... 

This is due to the resource key for the discovered non-native and native connectors ending up being the exact same. Meaning that the native connector gets discovered but because it uses the same key as a resource already in inventory, it is ignored.
Comment 12 Jean-frederic Clere 2013-04-19 10:16:35 EDT
Are you suggesting to change the way the resource keys (for the connectors) are generated?
I added a new connector in server.xml and restart the tomcat it doesn't appair is that normal?
Comment 13 Larry O'Leary 2013-04-19 10:32:00 EDT
A connector is a service so will only be discovered and imported into inventory after service discovery scan. By default, this happens at agent startup and once every 24 hours. 

However, if you have done that and if the new connector has the same port as the existing connector, then you most likely have run into this bug.

I am not sure what the best way to fix this would be. Changing the way the resource key is generated for connectors would be how to fix it but it must support backwards compatibility. In other words, at the point of such a change, the plug-in would have to upgrade all existing connector's resource keys to match the new, more unique name.
Comment 14 Jean-frederic Clere 2013-05-08 06:02:03 EDT
You can trigger also the error by exchanging the port of 2 connectors.
Comment 15 Mandar Joshi 2013-06-14 02:37:26 EDT
Doc Text added.

@Jean-Frederic Clere,  can you please review the Doc Text content?
Comment 16 Jean-frederic Clere 2013-06-14 04:58:47 EDT
Cause: When existing Tomcat connector is changed by modifying the Tomcatsever.xml file, the new connector is not discovered and the old connector is also not valid.


Cause: When existing Tomcat connector is changed by modifying the Tomcat sever.xml file, JBoss Operations Network doesn't discover the new connector and the old connector is kept in the inventory and it is not valid.
Comment 18 Larry O'Leary 2014-02-14 09:47:11 EST
Re-opening... This is still critical and we require a fix.

Without this, Tomcat 6/7 are broken when managing from JBoss ON if you had previously managed Tomcat 5/6.
Comment 31 Jean-frederic Clere 2014-07-09 07:34:41 EDT
Mandar, please keep this as known issue.

Note You need to log in before you can comment on or make changes to this bug.