modcluster
[1.3.x] MODCLUSTER-824 Improve handling of overlapping aliases in APP commands
Can we please validate the removal behavior? Just to make sure there isn't a side-effect that we are missing.
Before the patch, two virtual hosts with overlapping aliases are created. When REMOVE-APP is sent to the overlapping alias, only one of the hosts gets removed. (That does no affect the case when the remove command is sent with /* path, then both get removed.)
With this PR, only one virtual hosts is present because in case of an overlap, the two get merged. Then the removal removes the only host as expected.
Alright, so it seems we have come to a conclusion that replace is the correct action (instead of the proposed merge). I'll fix this PR once I fix the upstream.
Alright, so it seems we have come to a conclusion that replace is the correct action (instead of the proposed merge). I'll fix this PR once I fix the upstream.
Or maybe not. In case of following configuration of tomcat
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Alias>default.example.com</Alias>
</Host>
<Host name="testing" appBase="webapps-example"
unpackWARs="true" autoDeploy="true">
<Alias>default.example.com</Alias>
</Host>
the merge seems the right way...
in server.xml:
+++
<Host name="A" appBase="Aapps" unpackWARs="true" autoDeploy="true">
<Alias>B</Alias>
</Host>
<Host name="B" appBase="Bapps" unpackWARs="true" autoDeploy="true">
<Alias>C</Alias>
</Host>
+++
deploy demo-1.0.war in HostA... you have in mod_proxy_cluster Alias a, b. deploy test.war in HostB... you have in mod_proxy_cluster Alias a, b, c . The above looks wrong demo-1.0 was never for c and test was never for a.
undeploy test.war in HostB.... you still have Alias a, b, c ... so c still has demo-1.0 which is wrong.
in server.xml:
+++ <Host name="A" appBase="Aapps" unpackWARs="true" autoDeploy="true"> <Alias>B</Alias> </Host> <Host name="B" appBase="Bapps" unpackWARs="true" autoDeploy="true"> <Alias>C</Alias> </Host> +++deploy demo-1.0.war in HostA... you have in mod_proxy_cluster Alias a, b. deploy test.war in HostB... you have in mod_proxy_cluster Alias a, b, c . The above looks wrong demo-1.0 was never for c and test was never for a.
undeploy test.war in HostB.... you still have Alias a, b, c ... so c still has demo-1.0 which is wrong.
Right, so we have multiple levels at which both the current state and the proposed fix are not working. :smile: I'll mark this as draft, we should think it through first.
Right, so we have multiple levels at which both the current state and the proposed fix are not working. 😄 I'll mark this as draft, we should think it through first.
A partial fix went into upstream/main, so just make sure we don't forget to fix there too. 👍🏼
Another funny thing:
<Host name="A" appBase="Aapps" unpackWARs="true" autoDeploy="true">
<Alias>B</Alias>
</Host>
<Host name="B" appBase="Bapps" unpackWARs="true" autoDeploy="true">
<Alias>A</Alias>
</Host>
deploy demo-1.0 in Aapps, then in Bapps, wait and later undeploy demo-1.0 in Aapps, the VirtualHost is gone :-(
I don't see how to handle this "configuration error"...
<Host name="A" appBase="Aapps" unpackWARs="true" autoDeploy="true">
<Alias>B</Alias>
</Host>
<Host name="A" appBase="Bapps" unpackWARs="true" autoDeploy="true">
<Alias>A</Alias>
</Host>
gives an error in tomcat, as expected.
gives an error in tomcat, as expected.
Hm, but it gives an error due to name=A conflict, but having alias/name conflict is not problem. So this should be fixed in the java part as well.
Although thinking about it, maybe this is something to fix in tomcat directly, isn't it?