Mirth Connect
  1. Mirth Connect
  2. MIRTH-2376

Web Service Listener only allows five concurrent client connections

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.3, 3.0.3, 3.1.1, 3.2.2, 3.4.0, 3.3.2
    • Fix Version/s: 3.4.1
    • Component/s: Administrator, Server
    • Labels:
      None
    • Operating System:
      Windows XP

      Description

      A fixed thread pool (five threads) is hard-coded into the receiver. Instead this should be configurable.

        Activity

        Hide
        Nick Rupley added a comment -

        This should have been fixed with MIRTH-3167, but that value of 5 is still hard-coded.

        Show
        Nick Rupley added a comment - This should have been fixed with MIRTH-3167 , but that value of 5 is still hard-coded.
        Hide
        Nick Rupley added a comment -

        Revisions 8056/8057: The Web Service Listener server will now use an executor with a number of pool threads equal to the channel max processing threads, plus a few more to allow for concurrent WSDL/XSD requests. The TCP socket backlog is set to 256 to be in line with what we do for the TCP Listener. In the future a dedicated Max Connections option may be added to the connector (MIRTH-3974).

        Show
        Nick Rupley added a comment - Revisions 8056/8057: The Web Service Listener server will now use an executor with a number of pool threads equal to the channel max processing threads, plus a few more to allow for concurrent WSDL/XSD requests. The TCP socket backlog is set to 256 to be in line with what we do for the TCP Listener. In the future a dedicated Max Connections option may be added to the connector ( MIRTH-3974 ).
        Hide
        Nick Rupley added a comment -

        Attached 3.4.0 group for testing. When you start up the sender channel, you should see 10 messages received by the listener at once, but instead in 3.4.0 you'll only see 5, and then after 10 seconds have elapsed you'll see the remaining 5 process. In 3.4.1 all 10 should be received by the listener immediately.

        Show
        Nick Rupley added a comment - Attached 3.4.0 group for testing. When you start up the sender channel, you should see 10 messages received by the listener at once, but instead in 3.4.0 you'll only see 5, and then after 10 seconds have elapsed you'll see the remaining 5 process. In 3.4.1 all 10 should be received by the listener immediately.
        Hide
        Minh Tran added a comment - - edited

        OS(s) and JRE version: virtual Window 7 with JRE version 1.8.0_91-b14
        Version(s)/Build(s) to reproduce failure: mirthconnect-3.4.0.8000.b1959-windows-x64
        Version(s)/Build(s) to verify fixes: mirthconnect-3.4.1.8057.b139-windows-x64
        How Tested:

        1. Download & import the attached channel group
        2. Deploy channels (Test Web Service Listener & Sender) & Start Sender channel
        3. Monitor Dashboard for number of msgs received/sent on Listener Channel
        4. Verify Listener channel can receive 10 incoming msgs at once
        5. Modify Listener Channel to Max Processing Thread = 8 (from 10)
        6. Redeploy channels
        7. Verify Listener channel can receive 8 incoming msgs at once

        Verified Fixed:
        Before fixes, Listener channel received the most 5 msgs at a time
        With FIXED, Listener channel immediately received 10 incoming msgs or according to the defined Max Processing Thread

        Additional Info: used mirthdb=postgres for this test
        Using Derby would intermittently get Error about duplicate key

        ERROR (com.mirth.connect.donkey.server.channel.Channel:1248): Error processing message in channel Test Web Service Listener (8f605038-3a54-4a76-b7ca-f1ecb1582083).
        com.mirth.connect.donkey.server.channel.ChannelException: com.mirth.connect.donkey.server.data.DonkeyDaoException: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'D_M2_PKEY' defined on 'D_M2'. 
        Show
        Minh Tran added a comment - - edited OS(s) and JRE version: virtual Window 7 with JRE version 1.8.0_91-b14 Version(s)/Build(s) to reproduce failure: mirthconnect-3.4.0.8000.b1959-windows-x64 Version(s)/Build(s) to verify fixes: mirthconnect-3.4.1.8057.b139-windows-x64 How Tested: Download & import the attached channel group Deploy channels (Test Web Service Listener & Sender) & Start Sender channel Monitor Dashboard for number of msgs received/sent on Listener Channel Verify Listener channel can receive 10 incoming msgs at once Modify Listener Channel to Max Processing Thread = 8 (from 10) Redeploy channels Verify Listener channel can receive 8 incoming msgs at once Verified Fixed: Before fixes, Listener channel received the most 5 msgs at a time With FIXED, Listener channel immediately received 10 incoming msgs or according to the defined Max Processing Thread Additional Info: used mirthdb=postgres for this test Using Derby would intermittently get Error about duplicate key ERROR (com.mirth.connect.donkey.server.channel.Channel:1248): Error processing message in channel Test Web Service Listener (8f605038-3a54-4a76-b7ca-f1ecb1582083). com.mirth.connect.donkey.server.channel.ChannelException: com.mirth.connect.donkey.server.data.DonkeyDaoException: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'D_M2_PKEY' defined on 'D_M2'.
        Hide
        Nick Rupley added a comment -

        That error is known for Derby when using multiple processing threads: MIRTH-3871

        Show
        Nick Rupley added a comment - That error is known for Derby when using multiple processing threads: MIRTH-3871
        Hide
        Minh Tran added a comment -

        Successfully verified fixed

        Show
        Minh Tran added a comment - Successfully verified fixed

          People

          • Assignee:
            Nick Rupley
            Reporter:
            Nick Rupley
            Assigned QA:
            Minh Tran
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development