On 4/8/2017 6:42 PM, Mike Thomsen wrote: > I'm running two nodes of SolrCloud in Docker on Windows using Docker > Toolbox. The problem I am having is that Docker Toolbox runs inside of a > VM and so it has an internal network inside the VM that is not accessible > to the Docker Toolbox VM's host OS. If I go to the VM's IP which is > 192.168.99.100, I can load the admin UI and do basic operations that are > written to go against that IP and port (like querying, schema editor, > manually adding documents, etc.) > > However, when I try to run code that uses SolrJ to add documents, it fails > because the ZK configuration has the IPs for the internal Docker network > which is 172.X.Y..Z. If I log into the toolbox VM and run the Java code > from there, it works just fine. From the host OS, doesn't.
SolrCloud and the CloudSolrClient class from SolrJ will have issues if each instance registers with zookeeper using addresses that are not reachable from other Solr instances AND from clients. In situations where there are both external and internal addresses, each SolrCloud node must be configured to register with Zookeeper using the external address or name, and the networking must be set up so clients and other Solr instances can communicate using that address. See the "host" parameter here: https://cwiki.apache.org/confluence/display/solr/Parameter+Reference If you are also translating TCP ports, you probably need to define the hostPort parameter as well as the host parameter. By default, SolrCloud does the best it can to detect the address and port it registers in Zookeeper. When translation is involved or the machine has more than one NIC, that often results in incorrect information in Zookeeper. If you change the registration information for existing nodes in an existing cloud, you may find yourself in a situation where you need to manually edit the zookeeper database to remove information about the incorrect addresses that were registered before. If you can do so, setting up a new cloud from scratch with a fresh ZK ensemble (or a different chroot within the existing ensemble) may be the best plan. Thanks, Shawn
