cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9348) CloudStack Server degrades when a lot of connections on port 8250
Date Thu, 19 May 2016 11:26:12 GMT


ASF GitHub Bot commented on CLOUDSTACK-9348:

GitHub user rhtyd reopened a pull request:

    CLOUDSTACK-9348: NioConnection improvements

    Reopened PR with squashed changes for a re-review and testing after
and sub-sequent PRs got reverted

You can merge this pull request into a Git repository by running:

    $ git pull nio-fixagain-singlepr

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1549
commit 9c7518698d2f4a9fcc6a83fd22dd5b2fc4260232
Author: Rohit Yadav <>
Date:   2016-04-14T18:54:53Z

    CLOUDSTACK-9348: NioConnection improvements
    - Unit test to demonstrate denial of service attack
      The NioConnection uses blocking handlers for various events such as connect,
      accept, read, write. In case a client connects NioServer (used by
      agent mgr to service agents on port 8250) but fails to participate in SSL
      handshake or just sits idle, this would block the main IO/selector loop in
      NioConnection. Such a client could be either malicious or aggresive.
      This unit test demonstrates such a malicious client that can perform a
      denial-of-service attack on NioServer that blocks it to serve any other client.
    - Use non-blocking SSL handshake
      - Uses non-blocking socket config in NioClient and NioServer/NioConnection
      - Scalable connectivity from agents and peer clustered-management server
      - Removes blocking ssl handshake code with a non-blocking code
      - Protects from denial-of-service issues that can degrade mgmt server responsiveness
        due to an aggressive/malicious client
      - Uses separate executor services for handling ssl handshakes
    Signed-off-by: Rohit Yadav <>


> CloudStack Server degrades when a lot of connections on port 8250
> -----------------------------------------------------------------
>                 Key: CLOUDSTACK-9348
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>            Reporter: Rohit Yadav
>            Assignee: Rohit Yadav
>             Fix For: 4.9.0
> An intermittent issue was found with a large CloudStack deployment, where servers could
not keep agents connected on port 8250.
> All connections are handled by accept() in NioConnection:
> A new connection is handled by accept() which does blocking SSL handshake. A good fix
would be to make this non-blocking and handle expensive tasks in separate threads/pool. This
way the main IO loop won't be blocked and can continue to serve other agents/clients.

This message was sent by Atlassian JIRA

View raw message