[
https://issues.apache.org/jira/browse/CAMEL-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324902#comment-17324902
]
Manuel Shenavai edited comment on CAMEL-10914 at 4/19/21, 9:30 AM:
-------------------------------------------------------------------
Even this change is quite old, we just experience some problems with it. So I
hope this is the right place to ask a question related to this change.
Setup:
Route1 - CXFConsumer with endpoint address /test is already running
Route2 - Gets started with CXFConsumer with same endpoint /test
The expected behavior: Route2 startup fails (endpoint already registered on
address). Route1 keeps running.
Expected error on Route2 (endpoint already registered on address):
[https://github.com/apache/cxf/blob/master/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/SoapBindingFactory.java#L918]
Due to the change in this ticket, server.destroy() will be called after failed
startup:
[https://github.com/tadayosi/camel/commit/6d31d169dc17138ed02ad1164a4b2209729677fc#diff-174b6ca7cb178d3dc464aa9355d148d95fc0a3ad3f7edb60f0293fac988d3e05R100]
And it will eventually unregister the route:
[https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/ServerImpl.java#L191]
Observed behavior:
After failed startup of Route2, Route1 is not registered anymore (HTTP 404
when trying to call /test). I could not reproduce this with embedded Jetty, but
we experience this with tomcat on production.
Do you have any suggestion how this could be reproduced in a test using tomcat?
Is there a simple way to replace jetty with tomcat?
was (Author: mash-sap):
Even this change is quite old, we just experience some problems with it. So I
hope this is the right place to ask a question related to this change.
Setup:
Route1 - CXFConsumer with endpoint address /test is already running
Route2 - Gets started with CXFConsumer with same endpoint /test
The expected behavior: Route2 startup fails (endpoint already registered on
address). Route1 keeps running.
Expected error on Route2 (endpoint already registered on address):
[https://github.com/apache/cxf/blob/master/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/SoapBindingFactory.java#L918]
Due to the change in this ticket, server.destroy() will be called after failed
startup:
[https://github.com/tadayosi/camel/commit/6d31d169dc17138ed02ad1164a4b2209729677fc#diff-174b6ca7cb178d3dc464aa9355d148d95fc0a3ad3f7edb60f0293fac988d3e05R100]
And it will eventually unregister the route:
[https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/ServerImpl.java#L191]
Observed behavior:
After failed startup of Route2, Route1 is not registered anymore (HTTP 404
when trying to call /test). I could not reproduce this with embedded Jetty, but
we experience this with tomcat on production.
Do you have any suggestion how this could be reproduced in a test using tomcat?
> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -------------------------------------------------------------
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
> Affects Versions: 2.18.2
> Reporter: Tadayoshi Sato
> Assignee: Tadayoshi Sato
> Priority: Major
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which
> are never used.
> To reproduce the issue, extract the attached reproducer
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
