2020-12-09 11:04 阅读 0

Dynamically-assigned IP addresses for cloud instances require changes to app client bootstrapping for remote RMI-IIOP access

GF 3.2 will support clouds with both statically and dynamically (DHCP) assigned IP addresses. This has an impact on supporting app clients that access EJBs remotely and to IIOP FOLB.

First, a couple of points about the ORB:

  • The ORB normally caches and re-uses TCP/IP connections aggressively, and holds TCP connections open for a long time.
  • Stateful EJBs have their current state on a single instance, and for efficiency we normally want each request to go to the same instance. o When a failure occurs, IIOP failover causes all EJBs that were accessed from the failed instance to failover to the same instance ("Sticky failover").

Typically a cloud-based cluster will have a load balancer at a well-known address for handling HTTP traffic. The instances in the cloud may or may not be accessible over the public internet (if not, the load balancer sits in some kind of DMZ so at least an address on the LB is publicly accessible). We have the following possible scenarios:

1. Only the LB is publicly accessible. 2. LB and instances are publicly accessible, static cluster. 3. LB and instances are publicly accessible, dynamic cluster.

Case 1 is discussed in RFE 16480.

Case 2 is probably no different than supporting IIOP FOLB in GF 3.1, so it needs no further discussion.

Case 3 is interesting, because it creates a bootstrapping problem. Currently IIOP FOLB assumes that there are at least 2 fixed addresses of instances in the cluster which can be used to bootstrap into full FOLB operation. This is not the case for the dynamic cluster, where an app client may find that all of the instance addresses have been re-assigned every time it attempt to contact the cluster. The only available fixed, known address in this case is that of the load balancer (which itself may will use DNS tricks to make more than one IP address available, both for load balancing and high availability). So IIOP FOLB must make use of the LB address in this case.

While perhaps a suitable LB might be persuaded to support some sort of request that gives the client ORB the information that it needs, I think Tim's suggestion of a small web listener is a better idea. Here something in each GF 3.2 instance is listing to a URL like


which would respond to a GET request with a list of instance addresses in the cluster (and perhaps other information?). This might be formatted using JSON for convenient processing.

It's not clear whether security is required here. If it is, it would add significant complexity and require integration with the Java SE security facilities for managing a password or certificate.

I'm not sure how best to implement this in GF; I'm sure someone familiar with the web programming side of things could point out how to implement this rather easily.

These issues are also summarized at the Dynamic IP address concerns page.

Affected Versions



  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

5条回答 默认 最新

  • weixin_39603217 weixin_39603217 2020-12-09 11:04
    • Issue Imported From: https://github.com/javaee/glassfish/issues/16481
    • Original Issue Raised By:
    • Original Issue Assigned To:
    点赞 评论 复制链接分享
  • weixin_39603217 weixin_39603217 2020-12-09 11:04

    Commented Was assigned to hvilekar

    点赞 评论 复制链接分享
  • weixin_39603217 weixin_39603217 2020-12-09 11:04

    Commented This issue was imported from java.net JIRA GLASSFISH-16481

    点赞 评论 复制链接分享
  • weixin_39603217 weixin_39603217 2020-12-09 11:04

    Commented Reported by kcavanaugh

    点赞 评论 复制链接分享
  • weixin_39778106 weixin_39778106 2020-12-09 11:04

    This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment

    点赞 评论 复制链接分享