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-8611) CS waits indefinitely for CheckS2SVpnConnectionsCommand to return
Date Fri, 01 Apr 2016 17:40:25 GMT


ASF GitHub Bot commented on CLOUDSTACK-8611:

Github user GabrielBrascher commented on the pull request:
    @DaanHoogland thanks for the hint, but the problem is not related to line ending.
    The problem is that there are two (2) different SshHelper classes in the ACS history.
Although the content is the same, they were moved.
    The master SshHelper (
is located at "cloudstack/utils/src/main/java/com/cloud/utils/ssh/". The file
that I got to edit is the predecessor of the master SshHelper and is located at "cloudstack/utils/src/com/cloud/utils/ssh/".
    I am not sure about how to proceed.
    On the one hand, by keeping this PR as it is, it will preserve the history of all commits
of this (SshHelper) class (
and the path will remain as the master; on the other hand, if I add these changes in the SshHelper
at the current master, it will appear that I made all the changes in this class.

> CS waits indefinitely for CheckS2SVpnConnectionsCommand to return
> -----------------------------------------------------------------
>                 Key: CLOUDSTACK-8611
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>            Reporter: Likitha Shetty
>            Assignee: Suresh Kumar Anaparti
>             Fix For: 4.6.1
> On one instance, CS began to execute CheckS2SVpnConnectionsCommand command on a router
but the command result was never returned to the MS. If a command never returns, then 'DirectAgent'
thread executing this command is blocked indefinitely and cannot pick up any other request.
> Now since this command is designed to execute in sequence on a host and is run regularly,
every execution of that command thereafter on that particular host ended up picking up a DirectAgent
thread and waiting for the previous execution to complete. And hence overtime, the host ended
up using and blocking all 'DirectAgent' threads indefinitely.

This message was sent by Atlassian JIRA

View raw message