JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
enhancement_small.png
CLOSED  Enhancement JPPF-425  -  Improvements to the (custom) load-balancer APIs
Posted Dec 19, 2015 - updated Mar 14, 2016
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Enhancement
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Customization
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 5.2
Issue description
To instantiate a load-balancer, the API currently relies on the copy() method in the Bundler and LoadBalancingProfile interfaces. It doesn't make sense since the JPPFBundlerProvider interface already provides methods to create a Bundler and a LoadBalancingProfile. Consequently, I propose to deprecate the copy() methods in v5.2 and remove them altogether in v6.0, update the server and client code to create new bundlers from the declared providers and update the documentation accordingly.

Also, context-aware load-balancers are not documented, we should remedy. We should also provide access to more information in the JPPFContext for context-aware load-balancers, for instance:
  • whether this is a client-side or server-side context/load-balancer, like with isInClient() and isInServer() methods
  • access to the JPPFClient from the JPPFContextClient instance. For this we should take care of possible classloading issues, since JPPFClient and JPPFContextClient are not in the classpath of the server.

#3
Comment posted by
 lolo4j
Mar 01, 21:39
removal of copy() methods in trunk revision 3994
#4
Comment posted by
 lolo4j
Mar 14, 08:35
Implemented in trunk revision 3998