1

SnappyData v.0.5

In our AWS SnappyData instance, we have the following attributes:

  1. public IP: 52.x.x.x (exposed to the Internet)
  2. private/internal IP: 172.x.x.x (exposed only inside AWS)
  3. private/internal Name: ip-172-x-x-x.us-west-2.compute.internal (exposed only inside AWS)

To connect with JDBC from my Windows client, I use a JDBC URL like this:

jdbc:snappydata://52.x.x.x:1527/

The sequence of events the connection makes is:

  1. JDBC client connects into AWS and reaches the Locator at 172.x.x.x:1527
  2. Locator finds the Server running at 172.x.x.x:somePort
  3. Locator sends the internal host name back to the Windows Client
  4. Windows JDBC Client tries to connect to this:

ip-172-x-x-x.us-west-2.compute.internal

The JDBC connection fails because only the 52.x.x.x IP address is really publicly available to the Internet.

To remedy, I had to change my Windows hosts file, adding a mapping of:

52.x.x.x         ip-172-x-x-x.us-west-2.compute.internal

Please advise on a better way, so my clients don't need to hack their 'hosts' files.

Jason
  • 2,006
  • 3
  • 21
  • 36

1 Answers1

1

You can set the "prefer-netserver-ipaddress" property on servers to force sending the IP addresses back to clients e.g. -prefer-netserver-ipaddress=... or -J-Dgemfirexd.prefer-netserver-ipaddress=... on command-line (see details here)

The default is to convert to host names because in most scenarios it is the IP address that does the job of catering to both internal IP and external (i.e. if looked up from inside the subnet then it resolves to internal IP address but from outside it resolves to external IP address).

Sumedh
  • 383
  • 2
  • 7