Ensure that all data store auto-configurations have consistent default connection behaviour

[wilkinsona]

This was raised as part of a discussion on Twitter. The specific example given is Mongo which connects to localhost when it's on the classpath and Couchbase which doesn't connect to anything until your configure at least one bootstrap host.

There may well be good reasons for the apparent inconsistency, but it appears to be causing some confusion. It would be nice to align the behaviour across data stores if we can. If there are good reasons not to do that, it would be nice to see if we can somehow make the varying behaviour less surprising.

[abelsromero]

The confusion for us came because of two reasons
One, we have been using Couchbase without issues, and when we migrated to MongoDB we had to exclude the autoconfigurer. That felt odd.

Two, how the Autoconfiguration starts and logs the MongoClient behauviour...

1. if MongoClient is in the classpath and no configuration is present, it attempts to connect a localhost instance.
2. If connection fails, it does not propagate the error, so the context starts and the app is working fine.
3. However, the error is logged into the logs just after the "success"message. See attachment.
   mongoclient-springboot-autcoonfigurer-error.txt

Note: whe use a logback logging configuration importing springs defaults

    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

Imho, all Autoconfigurators for components depend on some mid-complex configuration should check for properties. Simple things or when a default config is a common thing like Gson or Jackson are fine that they only check for Beans.

Btw, the reason why we have a custom connector and do not expose a MongoClient to the Spring context is because we have a multitennacy platform that manages several connections at once. We load the configurations from a config-service and then initialize all our MongoClients inside a custom bean. That bean is the exposed, but not the clients.

[wilkinsona]

Here's the error from the attachment:

2017-12-12 12:58:38.732  INFO [multitenancy-server,,,] 9520 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 9040 (http)
2017-12-12 12:58:38.741  INFO [multitenancy-server,,,] 9520 --- [           main] c.e.e.m.MultitenancyServerApplication    : Started MultitenancyServerApplication in 12.765 seconds (JVM running for 13.878)
2017-12-12 12:58:38.826  INFO [multitenancy-server,,,] 9520 --- [localhost:27017] org.mongodb.driver.cluster               : Exception in monitor thread while connecting to server localhost:27017
com.mongodb.MongoSocketOpenException: Exception opening socket
                at com.mongodb.connection.SocketStream.open(SocketStream.java:62)
                at com.mongodb.connection.InternalStreamConnection.open(InternalStreamConnection.java:107)
                at com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:111)
                at java.lang.Thread.run(Thread.java:748) 
Caused by: java.net.ConnectException: Connection refused: connect
                at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
                at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
                at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
                at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
                at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
                at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
                at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
                at java.net.Socket.connect(Socket.java:589)
                at com.mongodb.connection.SocketStreamHelper.initialize(SocketStreamHelper.java:59)
                at com.mongodb.connection.SocketStream.open(SocketStream.java:57)
                ... 3 common frames omitted

[wilkinsona]

IMO, the main problem with the current situation is the inconsistency in behaviour across the different data stores for which auto-configuration is provided. The current behaviour when dependencies are available but no configuration is provided is described in the following table:

Store	Result
JDBC	Can't determine the driver class and fails to start.
Cassandra	Tries to connect to localhost and fails to start.
Couchbase	Auto-configuration backs off and application starts.
Elasticsearch	Auto-configuration backs off and application starts.
Mongo	Application starts but logs a ConnectException. Any calls to Mongo fail.
Redis	Application starts cleanly. Any calls to Redis fail.
Solr	Application starts cleanly. Any calls to Solr fail.

These results were gathered from deliberately minimal applications that didn't attempt to autowire or use any components that may or may not have been auto-configured.

@mbhave made a good point about a knock-on effect of this inconsistency with respect to actuator and the health endpoint. The health responses are shown in the following table:

Store	Health
Couchbase	Up
Elasticsearch	Up
Mongo	Down
Redis	Down
Solr	Down

The difference in health responses is determined by the auto-configuration either backing off or "successfully" configuring beans that can't actually communicate with the data store.

[philwebb]

Wondering if this should be in the backlog?

[wilkinsona]

It'd be nice to tackle it in 2.1 if we can.