shoal
  1. shoal
  2. SHOAL-89

Improved concurrency for sendMessage

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: 1.1
    • Component/s: GMS
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      89

      Description

      RFE related to fix for shoal issue 88 to change that synchronization
      solution to a more performant pool of OutputPipes (one pipe to be used by one
      thread at any point in time).

        Activity

        Hide
        shreedhar_ganapathy added a comment -

        Transferring to Joe for eval and closure.

        Show
        shreedhar_ganapathy added a comment - Transferring to Joe for eval and closure.
        Hide
        Joe Fialli added a comment -

        there are trade offs for concurrent sendMessage when relying on NIO as the ultimate transport.
        so this RFE was considered and postponed due to these tradeoffs.

        The concurrent processing resulted in not being able to share the same deserialized output stream with
        all send messages. Thus, there is also a space usage and/or multiple desserializations necessary for
        each concurrent send.

        With regular multicast, only one deserialization of the message to be sent was occurring.
        With current implementation, there still is only one.

        With concurrent send, there were not so obvious tradeoffs.
        So this RFE is on hold for now while sorting through the tradeoffs.

        Show
        Joe Fialli added a comment - there are trade offs for concurrent sendMessage when relying on NIO as the ultimate transport. so this RFE was considered and postponed due to these tradeoffs. The concurrent processing resulted in not being able to share the same deserialized output stream with all send messages. Thus, there is also a space usage and/or multiple desserializations necessary for each concurrent send. With regular multicast, only one deserialization of the message to be sent was occurring. With current implementation, there still is only one. With concurrent send, there were not so obvious tradeoffs. So this RFE is on hold for now while sorting through the tradeoffs.

          People

          • Assignee:
            Joe Fialli
            Reporter:
            Joe Fialli
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: