[
https://issues.apache.org/jira/browse/BROOKLYN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251069#comment-14251069
]
Andrew Kennedy edited comment on BROOKLYN-106 at 12/18/14 3:05 AM:
-------------------------------------------------------------------
Looking at this, it does appear that a 32KiB buffer is beaing reached, based on
the size of the STDOUT file and the probable amount of extra data that was
pending. I had a look into the SSHJ code, and discovered that in
{{net.schmizz.sshj.connection.ConnectionImpl}} the following defaults are set:
{noformat}
private long windowSize = 2048 * 1024;
private int maxPacketSize = 32 * 1024;
{noformat}
And, in {{net.schmizz.sshj.connection.channel.AbstractChannel}} they are used
as follows:
{noformat}
lwin = new Window.Local(conn.getWindowSize(), conn.getMaxPacketSize());
{noformat}
This is part of the constructor for all {{Channel}} objects, which is called
during the {{SSHClient#startSession()}} method. If we look at the Brooklyn
{{SshTool#newSessionAction()}} method, which returns a {{SshAction<Session>}},
this calls {{startSession}}, after checking the SSH client is connected and
authenticated, in its {{SshAction#create()}} method. This action is always
performed when connecting using SSH.
I suggest we raise the maximum packet size to 256KiB or even 1MiB to avoid this
issue. We can do that by setting the new value on the {{Connection}} object
stored in the {{SSHClient}} field of the Brooklyn SSH client connection:
{noformat}
checkConnected();
sshClientConnection.ssh.getConnection().setMaxPacketSize(256 * 1024);
session = sshClientConnection.ssh.startSession();
{noformat}
was (Author: andrew.kennedy):
Looking at this, it does appear that a 32KiB buffer is beaing reached, based on
the size of the STDOUT file and the probable amount of extra data that was
pending. I had a look into the SSHJ code, and discovered that in
{{net.schmizz.sshj.connection.ConnectionImpl}} the following defaults are set:
{noformat}
private long windowSize = 2048 * 1024;
private int maxPacketSize = 32 * 1024;
{noformat}
And, in {{net.schmizz.sshj.connection.channel.AbstractChannel}} they are used
as follows:
{noformat}
lwin = new Window.Local(conn.getWindowSize(), conn.getMaxPacketSize());
{noformat}
This is part of the constructor for all {{Channel}} objects, which is called
during the {{SSHClient#startSession()}} method. If we look at the Brooklyn
{{SshTool#newSessionAction()}} method, which returns a {{SshAction<Session>}},
this calls {{startSession}}, after checking the SSH client is connected and
authenticated, in its {{SshAction#create()}} method. This action is always
performed when connecting using SSH.
I suggest we raise the maximum packet size to 256KiB or even 1MiB to avoid this
issue. We can do that by setting the new value on the {{Connection}} object
stored in the {{SSHClient}} field of the Brooklyn SSH client connection:
{{noformat}}
checkConnected();
sshClientConnection.ssh.getConnection().setMaxPacketSize(256 * 1024);
session = sshClientConnection.ssh.startSession();
{{noformat}}
> Tomcat install fails on CentOS: hangs installing java
> -----------------------------------------------------
>
> Key: BROOKLYN-106
> URL: https://issues.apache.org/jira/browse/BROOKLYN-106
> Project: Brooklyn
> Issue Type: Bug
> Affects Versions: 0.7.0-SNAPSHOT
> Reporter: Aled Sage
> Assignee: Aled Sage
> Attachments: debug.log.tgz, jstack.txt, messages.tgz, ssh-stdout.txt
>
>
> When deploying Tomcat to VMware's vcloud-air, to a CentOS 6.4 VM, when
> installing Java it hangs!
> The Brooklyn web-console shows that it is still waiting for a result from the
> ssh command (which executed `sudo -E -n -S -- yum -y --nogpgcheck install
> java-1.7.0-openjdk-devel`).
> However, when logging into the VM I can see that the `yum` command has
> finished, and the /var/log/messages (attached) shows that the install
> completed.
> This fails repeatedly. It used to pass!
> The stdout is at 32040 bytes. The last few lines of the stdout (as shown in
> the web-console) are:
> {noformat}
> Installing : libtasn1-2.3-6.el6_5.x86_64
> 50/56
> Installing : gnutls-2.8.5-14.el6_5.x86_64
> 51/56
> Installing : 1:cups-libs-1.4.2-67.el6.x86_64
> 52/56
> {noformat}
> Could there be some buffer set to 32K, so it's stuck not reading the rest of
> the stdout (but `SshjToolPerformanceTest.testConsecutiveBigStdoutCommands`
> passes)?
> Why else would our ssh command be stuck, not returning?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
