Cargo, Tomcat, and Email Server Error On Startup Using spring.mail.* Properties

120 views
Skip to first unread message

Jeff Jensen

unread,
Jun 24, 2017, 4:29:57 PM6/24/17
to codehau...@googlegroups.com
Hi, I have been unable to diagnose what causes this problem and am looking for any assistance/suggestions to resolve it.

I'm using Cargo (1.6.3 the current latest release) to start a WAR in Tomcat for acceptance tests.  The app uses external services such as LDAP, Database, and sends emails.  I run the build/acceptance tests with Maven, and it starts the external services before running the Cargo plugins.  The problem is with the email service.

The problem is at WAR deploy, something is connecting to the email server, encounters a problem, and then causes a shutdown.  The error says "Port number N ... is in use", but nothing is running on that port.  I think it is a different error but not sure what (unless Cargo/Tomcat is attempting to start a service listening on that port!).

The error occurs no matter what the port number is.

However, when removing the two email properties used with Spring Boot and provided to Cargo for setting in the Tomcat environment, the problem goes away:
  spring.mail.host=localhost
  spring.mail.port=15025
(of course, that makes the app use the production-configured values so not a solution!)

What is using those values somehow, Cargo or Tomcat?


When starting Tomcat with Cargo (running mvn install), this is what the problem looks like from the logs:

1. Log shows email server starting:

[INFO] Starting SubEtha SMTP mail server...
[INFO] SMTP server *:15025 starting
[INFO] Started SubEtha SMTP mail server
[INFO] Waiting for command from client
[INFO] SMTP server *:15025 started

2. Log shows Tomcat starting and deploying the war:
[INFO] [talledLocalContainer] Tomcat 8.x starting...
[INFO] [stalledLocalDeployer] Deploying [C:\Users\jjensen\.m2\repository\research\cargo\maven\plugin\email\issue\empty-war\1.0.0-SNAPSHOT\empty-war-1.0.0-SNAPSHOT.war] to [D:\devroot\research\cargo-maven-plugin\email-server-issue\acceptance-test\target\cargo\configurations\tomcat8x\webapps]...

3. Log shows connecting to the email server at app startup, encountering some error, and then stops:

[DEBUG] [talledLocalContainer]  Socket Socket[addr=localhost/127.0.0.1,port=15025,localport=52310] for port 15025 managed to connect
[DEBUG] [talledLocalContainer]  Socket Socket[addr=localhost/127.0.0.1,port=15025,localport=52310] for port 15025 shutdown
[DEBUG] [talledLocalContainer]  Socket Socket[addr=localhost/127.0.0.1,port=15025,localport=52310] for port 15025 closed
[WARNING] [talledLocalContainer] org.codehaus.cargo.container.ContainerException: Port number 15025 (defined with the property spring.mail.port) is in use. Please free it on the system or set it to a different port in the container configuration.
[ERROR] Starting container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@54d8c20d] failed, now stopping container
[INFO] [talledLocalContainer] Tomcat 8.x is stopping...


When starting Tomcat without Cargo, the problem does not occur.  To do so, I manually run the email server with the Maven goal to start it (mvn com.btmatthews.maven.plugins:emailserver-maven-plugin:run -Demail.daemon=false), so both situations use the same pom config, then mvn install (or verify) the tests as usual.


What causes Cargo to issue a connect at start?  I don't know what is connecting because the WAR is empty and it's not completely started yet anyway.  Is Cargo doing it, or having Tomcat do something?

What is the conflict internal to Cargo with Spring - with using the "spring.mail.[host|port]" properties?

Are there config changes I can make to work around this?


I made a small reproducer and pushed to github:

To reproduce, run "mvn install" in empty-war dir and then in acceptance-test dir.

S. Ali Tokmen

unread,
Jun 25, 2017, 6:30:07 AM6/25/17
to codehau...@googlegroups.com

Hi Jeff

Since its version 1.4.0 (April 2013), Cargo indeed checks whether any of the ports in its properties are in use before starting the container - This allows unexpected issues later on.

In your case, unfortunately, this causes an issue: your file acceptanceTest.properties contains both the port number for the e-mail service (not started by Cargo) and the Tomcat server (started by Cargo); and hence Cargo throws an error saying "hey, the spring.mail.port is in use!".

You can easily fix this issue by having two properties file: One for the Cargo container, the other for the mail service. We could also imagine changing the Cargo checker so that it checks only for port numbers starting with cargo. as prefix.

Let us know if this helps

S. Ali Tokmen
http://ali.tokmen.com/
http://contact.ali.tokmen.com/
--
You received this message because you are subscribed to the Google Groups "Codehaus Cargo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-carg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/CAKumxByRiQhKv8219N%2BwJEgDYqdNOWGMAHzNODqNQ0MtKCfKmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jeff Jensen

unread,
Jun 25, 2017, 11:52:33 AM6/25/17
to codehau...@googlegroups.com
Thank you for explaining!

It is a good feature, and one I didn't expect (and it explains why the other 3 services do not have the problem - their port numbers are in the URLs).  

Since this is a Cargo feature, I suggest adding an info log message providing context before checking, something like "Cargo checking for defined ports already in use".  This kind of message would have let me know what was doing it and that it is deliberate vs a true conflict.

If you want to tweak the feature as you mentioned, I suggest adding a config property something like "cargo.ports.check.all" to have it verify all ports or only the cargo.* ports, default to true.

Yes, splitting into two files would work.  The reason I use only one properties file is because cargo.servlet.port is needed by Cargo as well as the port for the tests' URL, so simply defining it in one place.

In the meantime, I worked around the issue by not setting the port and relying on a production configured value.

Thank you again for your quick reply.


To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-cargo+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Codehaus Cargo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-cargo+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/d34d32b7-43d7-f2e5-7118-08c158e53212%40alishomepage.com.

S. Ali Tokmen

unread,
Jun 25, 2017, 2:37:16 PM6/25/17
to codehau...@googlegroups.com

Hi Jeff

I'm glad a workaround can be applied for your case!

I meanwhile created an improvement so that only the properties starting with cargo. are taken into account for the port checks (see https://codehaus-cargo.atlassian.net/browse/CARGO-1438 for details).

If you wish to try you can use the version 1.6.4-SNAPSHOT by following the instructions on https://codehaus-cargo.github.io/cargo/Maven2+Plugin+Installation.html#Maven2PluginInstallation-snapshots.

Enjoy the weekend

To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-carg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/CAKumxBw2nLt8KtTLfSwAayL6Od0kpamg0tVVzkrOeiRAb1FsWg%40mail.gmail.com.

Jeff Jensen

unread,
Jun 25, 2017, 4:24:02 PM6/25/17
to codehau...@googlegroups.com
:-)  Very nice!  1.6.4-SNAPSHOT works great, does not shutdown on a port setting not starting with cargo.

Thank you very much.


--
You received this message because you are subscribed to the Google Groups "Codehaus Cargo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-cargo+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages