[
https://issues.apache.org/jira/browse/CLOUDSTACK-8611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222048#comment-15222048
]
ASF GitHub Bot commented on CLOUDSTACK-8611:
--------------------------------------------
Github user GabrielBrascher commented on the pull request:
https://github.com/apache/cloudstack/pull/1459#issuecomment-204484447
@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
(https://github.com/apache/cloudstack/commits/75b68c68298dab270782be68f8f9f28e551fc5d0/utils/src/main/java/com/cloud/utils/ssh/SshHelper.java)
is located at
"cloudstack/utils/src/main/java/com/cloud/utils/ssh/SshHelper.java". 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/SshHelper.java".
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
(https://github.com/likitha/cloudstack/commits/CLOUDSTACK-8611/utils/src/com/cloud/utils/ssh/SshHelper.java)
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: https://issues.apache.org/jira/browse/CLOUDSTACK-8611
> 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
(v6.3.4#6332)
