Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-556

Consolidate thread pools

    XMLWordPrintable

Details

    • Task
    • Resolution: Done
    • Major
    • 2.7
    • None
    • None

    Description

      For JGroups 2.5 we have used numerous instances of ThreadPoolExecutor(s) as we needed them. For instance, STREAMING_STATE_TRANSFER, Multiplexer, TP, and ProtocolStack. Undoubtedly this lead to increased overhead and performance impact that we have not measured. First of all we should stop indiscriminately introducing new thread pools as we go further. Second, we should Investigate possibility to consolidate thread pools so they can be reused by various protocols and components of a channel.

      Attachments

        Issue Links

          relates to

          Feature Request - Feature requests from customers and/or users JGRP-413 Replace separate threads with timer tasks

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Task - Represents a small unit of work that is not end-user facing. JGRP-420 Convert Event.FIND_INITIAL_MBRS to use concurrent stack

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              rhn-engineering-bban Bela Ban
              vblagoje Vladimir Blagojevic (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: