JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
task_small.png
CLOSED  Task JPPF-499  -  Simplify client internal code
Posted Apr 17, 2017 - updated Apr 18, 2017
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Task
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Client
  • Resolution
    RESOLVED
  • Priority
    High
  • Targetted for
    icon_milestones.png JPPF 6.0
Issue description
Currently there is too much complexity in the handling of client connections to the drivers and their status. In particular, each JPPFClientConnection implementation holds 2 actual connections, both subclasses of AbstractClientConnectionHandler and each with their status listeners. The main connection status is set either directly or as a combination of the states of the two "sub-connections". In the former case, the sub-connections status becomes inconsistent with that of the main connection.

Overall, this complexity results in many observed problems in the client, especially when running the automated tests: deadlocks, race conditions, failures of the recovery and failover mechanisms.

What we propose is to remove the code that handle the status in the sub-connections (and thus in AbstractClientConnectionHandler) and only keep one source of status and associated events.

Additionally, the abstract class org.jppf.client.balancer.ChannelWrapper, subclassed as ChannelWrapperLocal and ChannelWrapperRemote, holds an executor filed of type ExecutorService defined as a single thread executor in both subclasses. Instead of a separate thread pool for each ChannelWrapper, we should make use of the executor held by the JPPFClient instance, and add proper synchronization if needed.

#2
Comment posted by
 lolo4j
Apr 17, 10:12
trunk revision 4508
#3
Comment posted by
 lolo4j
Apr 18, 06:04
implemented in trunk revision 4510