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.
per BZ triage (asantos, ccrouch, loleary, mfoley)
What is the EWS team priority for this bug wrt JON 3.1.2 release?
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.
The default connector is the coyote one so I think there is no reason for a customer to change that.
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.
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.
Increasing the severity of this issue as it prevents use of the default connector in EWS 1.2/2.0 as indicated above.
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.
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.
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?
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.
You can trigger also the error by exchanging the port of 2 connectors.
Doc Text added. @Jean-Frederic Clere, can you please review the Doc Text content?
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. Better: 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.
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.
Mandar, please keep this as known issue.