James Server
  1. James Server
  2. JAMES-283

James should use default backLog value when creating a ServerSocket

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.2.0
    • Component/s: James Core
    • Labels:
      None

      Description

      We have a test where we send 100 messages simultaneously. James does not handle this well. With a standard setup 40-70 messages are NOT handled. After tweaking the config file (allocating more threads and connections) still 10-30 messages are not picked up.

      We discovered that James specifies a very tight 'backLog' value when creating a ServerSocket. This happens in org.apache.james.core.AbstractJamesService.initialize() on line 302:

      ServerSocket serverSocket = factory.createServerSocket(port, 5, bindTo);

      (Sorry no time to do a proper diff)

      We suppose that eventually a java.net.ServerSocket is created with this value. According to the javadoc of ServerSocket, the default value is 50. This can be specified by setting the backLog parameter to 0. See http://java.sun.com/j2se/1.4.2/docs/api/java/net/ServerSocket.html

      We changed the above line in AbstractJamesService to

      ServerSocket serverSocket = factory.createServerSocket(port, 0, bindTo);

      With this fix all 100 messages are accepted (on Windows 2000 Server).

      We advise that James uses the default value for the backLog parameter. If there is a special reason why the default value should be 5, please make it a parameter we can specify in the config file.

      Thanks

      Hes.

      1. backlog-patch.txt
        2 kB
        Noel J. Bergman

        Activity

        Hes Siemelink created issue -
        Hide
        Noel J. Bergman added a comment -

        I agree that a change should be made, but am reluctant to change the backlog value at this late date without putting the release through testing again. There is a certain amount of platform dependency to this issue. For example, linux systems that use SYN_COOKIES to guard against a syn flood attack will not see this problem.

        However, I have modified the code to allow a <connectionBacklog> element, which currently defaults to the internal value of 5, and would be willing to vote for that change to go into the 2.2.0 release, since it does not change the default behavior.

        Please review the attached patch ASAP, and let us know if it resolves your problem. You'll want to an add <connectionBacklog> element to your <smtpserver> configuration.

        Show
        Noel J. Bergman added a comment - I agree that a change should be made, but am reluctant to change the backlog value at this late date without putting the release through testing again. There is a certain amount of platform dependency to this issue. For example, linux systems that use SYN_COOKIES to guard against a syn flood attack will not see this problem. However, I have modified the code to allow a <connectionBacklog> element, which currently defaults to the internal value of 5, and would be willing to vote for that change to go into the 2.2.0 release, since it does not change the default behavior. Please review the attached patch ASAP, and let us know if it resolves your problem. You'll want to an add <connectionBacklog> element to your <smtpserver> configuration.
        Hide
        Noel J. Bergman added a comment -

        Patch to add configurable connection backlog.

        Show
        Noel J. Bergman added a comment - Patch to add configurable connection backlog.
        Noel J. Bergman made changes -
        Field Original Value New Value
        Attachment backlog-patch.txt [ 14496 ]
        Hide
        Hes Siemelink added a comment -

        Noel, thanks for the rapid response & fix.

        I agree that the default value should not be changed for the upcoming release.

        I'm afraid the first opportunity that I can test the patch is Tuesday.

        Show
        Hes Siemelink added a comment - Noel, thanks for the rapid response & fix. I agree that the default value should not be changed for the upcoming release. I'm afraid the first opportunity that I can test the patch is Tuesday.
        Hide
        Hes Siemelink added a comment -

        Seems to work fine!

        Will this patch be included in the 2.2.0 release?

        Show
        Hes Siemelink added a comment - Seems to work fine! Will this patch be included in the 2.2.0 release?
        Hide
        Noel J. Bergman added a comment -

        Patch is included in the DB-TEST build, and will be in the RC4 build.

        Show
        Noel J. Bergman added a comment - Patch is included in the DB-TEST build, and will be in the RC4 build.
        Noel J. Bergman made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.2.0RC4 [ 10720 ]
        Resolution Fixed [ 1 ]
        Noel J. Bergman made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Noel J. Bergman [ noel ]
        Mark Thomas made changes -
        Workflow jira [ 31424 ] Default workflow, editable Closed status [ 12565813 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12565813 ] jira [ 12581223 ]

          People

          • Assignee:
            Noel J. Bergman
            Reporter:
            Hes Siemelink
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development