0.9.12 slowing to a crawl over a period of 5 to 10 minutes of use

[Jacob Staub]

Hello,

Thank you for all the good work on Guacamole.

I am having trouble with 0.9.12 slowing to a crawl over a period of 5 to 
10 minutes of use in a reverse proxy application. I upgraded from 0.9.9 
for the ability to screen share but found 0.9.12 so unstable that I 
returned to 0.9.9 which produces solid operation using the same proxy 
settings that were established for 0.9.12. The environment under which 
guacamole operates:


Server = Ubuntu 16.04.2 LTS
Docker = 17.03.1-ce
Docker-compose = 1.13.0
jwilder/nginx-proxy = 1.13.0 
database flavor = postgresql
Connection OS = Windows7

Proxy settings were implemented as described under Chapter 4 
. 
The database of 0.9.12 is an upgrade of the 0.9.9 database if that makes 
any difference.


What I could use is assistance with diagnosing what might cause 
guacamole to bog down over time in 0.9.12. It doesn't seem like 
something related to configuration given 0.9.9 appears to work fine in 
the same environment.


Regards,
Jake

Re: GPU intensive applications in guacamole

[Jacob Staub]

Good evening odonya,

The GPUs should be installed in the remote machine. So long as your 
client can handle things like video from youtube it will be more than 
capable of keeping up with your application.


I'm using guacamole to broadcast CAD workstations that use older Quadro 
2000 cards. So far the performance is good. As with any remote desktop 
scheme there's lag but it's tolerable.


Regards,
Jake

On 5/11/2017 9:04 AM, odonya wrote:

We have a gpu intensive application that we are trying to test if we can use
it with guacamole. This is not a gaming application.
  My question is which machine is supposed to have enhanced GPUs , is it the
client machine which is connecting to guacamole or the remote machine or
actually both machines.



--
View this message in context: 
http://apache-guacamole-incubating-users.2363388.n4.nabble.com/GPU-intensive-applications-in-guacamole-tp955.html
Sent from the Apache Guacamole (incubating) - Users mailing list archive at 
Nabble.com.

0.9.9 on Docker with Reverse Proxy Stable, 0.9.12 on Docker with Reverse Proxy Unstable

[Jacob Staub]

Hello,

Environment:
Docker host OS = Ubuntu Server 16.04.2 LTS
Docker version = 17.03.1-ce
Docker compose version = 1.13.0
jwilder/nginx-proxy  version = 
1.13.0

Reverse proxy settings = jwilder/nginx-proxy default settings
Target connection = Windows 7 RDP
Network environment = LAN (http) & WAN (https)

In the environment above, 0.9.9 performs consistently. Connections are 
made with the Windows 7 RDP target and are held until intentionally ended.


In the environment above, 0.9.12 (and 0.9.11) performs inconsistently. 
Connections are made with the Windows 7 RDP target but last only 
approximately 5 minutes at which point the connection is terminated for 
the following: "ERROR: User is not responding." The attached screen shot 
of the guacd log is an example of the log output. Docker-compose scripts 
that show how each environment is built are also included.


Has anyone else experienced the same behavior? If so, is there a 
workaround available that produces consistent 0.9.12 performance?


Regards,
Jake Staub
version: '3'
services:
  guacamole:
image: 'glyptodon/guacamole:0.9.9'
container_name: 'guacamole_0-9-9'
depends_on:
 - guacd
links:
 - guacd:guacd 
external_links:
 - postgres:postgres
environment:
 - POSTGRES_DATABASE=example_db
 - POSTGRES_USER=example_user
 - POSTGRES_PASSWORD=example_password
 - VIRTUAL_HOST=example.lan,example.com
 - LETSENCRYPT_HOST=example.com
 - LETSENCRYPT_EMAIL=ad...@example.com
restart: 'unless-stopped'
network_mode: "bridge"
  guacd:
image: 'glyptodon/guacd:0.9.9'
container_name: 'guacd_0-9-9'
restart: 'unless-stopped'
network_mode: "bridge"
 
version: '3'
services:
  guacamole:
image: 'glyptodon/guacamole'
container_name: 'guacamole_latest'
depends_on:
 - guacd
links:
 - guacd:guacd 
external_links:
 - postgres:postgres
environment:
 - POSTGRES_DATABASE=example_db
 - POSTGRES_USER=example_user
 - POSTGRES_PASSWORD=example_password
 - VIRTUAL_HOST=example.lan,example.com
 - LETSENCRYPT_HOST=example.com
 - LETSENCRYPT_EMAIL=ad...@example.com
restart: 'unless-stopped'
network_mode: "bridge"
  guacd:
image: 'glyptodon/guacd'
container_name: 'guacd_latest'
restart: 'unless-stopped'
network_mode: "bridge"
 

Docker Guacamole Latest

[Jacob Staub]

Good morning,

I have been working on updating Docker Guacamole from 0.9.9 to 0.9.13. I 
have pulled the latest image for guacamole and guacd. But when I deploy 
Guacamole from the latest images 0.9.11-incubating comes up rather than 
0.9.13-incubating. 0.9.11-incubating, or what is indicated on the login 
page as 0.9.11-incubating, functions normally.


Please confirm the Guacamole version of the latest guacamole images. It 
will help me determine if I'm causing the problem on my end.


Regards,
Jake

Re: Docker Guacamole Latest

[Jacob Staub]

Hello,

Click here <https://hub.docker.com/r/guacamole/guacamole/> for guacamole.

Click here <https://hub.docker.com/r/guacamole/guacd/tags/> for guacd.

Regards,
Jake

On 9/27/2017 11:15 AM, Nick Couchman wrote:

Please let us know how/from where you're pulling the image?

-Nick

On Wed, Sep 27, 2017 at 11:04 AM, Jacob Staub <mailto:jpsta...@gmail.com>> wrote:


Good morning,

I have been working on updating Docker Guacamole from 0.9.9 to
0.9.13. I have pulled the latest image for guacamole and guacd.
But when I deploy Guacamole from the latest images
0.9.11-incubating comes up rather than 0.9.13-incubating.
0.9.11-incubating, or what is indicated on the login page as
0.9.11-incubating, functions normally.

Please confirm the Guacamole version of the latest guacamole
images. It will help me determine if I'm causing the problem on my
end.

Regards,
Jake

Re: Docker Guacamole Latest

[Jacob Staub]

Images are were pulled via the Docker Pull Command listed on each 
corresponding page. Example for guacamole:


docker pull guacamole/guacamole

Using the above command pulls Tag = latest. I would expect "latest" to 
include 0.9.13-incubating but the suggestion is that "latest" does not 
include 0.9.13-incubating.


Regards,
Jake

On 9/27/2017 11:29 AM, Nick Couchman wrote:
On Wed, Sep 27, 2017 at 11:26 AM, Jacob Staub <mailto:jpsta...@gmail.com>> wrote:


Hello,

Click here <https://hub.docker.com/r/guacamole/guacamole/> for
guacamole.

Click here <https://hub.docker.com/r/guacamole/guacd/tags/> for guacd.

Regards,
Jake


If you look at the Tags tab on both of those you'll see the latest is 
0.9.13-incubating, so if you're pulling the latest from there it 
should be 0.9.13-incubating.


How are you pulling it?

-Nick

Re: Docker Guacamole Latest

[Jacob Staub]

See attached for the requested output.

Regards,
Jake

On 9/27/2017 12:27 PM, Mike Jumper wrote:
On Wed, Sep 27, 2017 at 8:34 AM, Jacob Staub <mailto:jpsta...@gmail.com>> wrote:


Images are were pulled via the Docker Pull Command listed on each
corresponding page. Example for guacamole:

docker pull guacamole/guacamole

Using the above command pulls Tag = latest. I would expect
"latest" to include 0.9.13-incubating but the suggestion is that
"latest" does not include 0.9.13-incubating.


Please post the output of:

    docker images guacamole/guacamole

    docker images guacamole/guacd

- Mike

Re: Docker Guacamole Latest

[Jacob Staub]

Thanks for your patience and assistance. The instruction to inspect the 
guacamole containers was the steer I needed.


The problem was traced to an incorrect image identification in the 
docker-compose file used for the deployment.


Incorrect ID: glyptodon/guacamole
Corrected ID: guacamole/guacamole

Since 0.9.10-incubating++ appear under guacamole/guacamole it may be 
worth stripping the same out of glyptodon/guacamole to funnel those like 
me more directly towards the right answer.


Regards,
Jake

On 9/27/2017 4:32 PM, Mike Jumper wrote:
This same issue has been encountered before [1] for an earlier 
version, but there was no problem with the Guacamole images in that 
case, and rechecking now things are still correct. The "latest" tag 
does point to the same image as "0.9.13-incubating", which does 
contain 0.9.13-incubating:


[mjumper@dev-mjumper ~]$ sudo docker images guacamole/guacamole
REPOSITORY                      TAG                 IMAGE ID           
 CREATED             SIZE
docker.io/guacamole/guacamole <http://docker.io/guacamole/guacamole> 
0.9.13-incubating   b602d8daff1b        11 weeks ago  659.7 MB
docker.io/guacamole/guacamole <http://docker.io/guacamole/guacamole> 
latest              b602d8daff1b        11 weeks ago  659.7 MB
docker.io/guacamole/guacamole <http://docker.io/guacamole/guacamole> 
0.9.12-incubating   9af030afb8c8        6 months ago  651.2 MB
docker.io/guacamole/guacamole <http://docker.io/guacamole/guacamole> 
0.9.11-incubating   b08c4f8e69f5        8 months ago  650.4 MB

[mjumper@dev-mjumper ~]$ sudo docker images guacamole/guacd
REPOSITORY                  TAG                 IMAGE ID         
 CREATED             SIZE
docker.io/guacamole/guacd <http://docker.io/guacamole/guacd> 
0.9.13-incubating   ac5de9daf9f3        11 weeks ago  499.2 MB
docker.io/guacamole/guacd <http://docker.io/guacamole/guacd> latest   
           ac5de9daf9f3        11 weeks ago  499.2 MB
docker.io/guacamole/guacd <http://docker.io/guacamole/guacd> 
0.9.12-incubating   8e1536c54985        6 months ago  404.9 MB
docker.io/guacamole/guacd <http://docker.io/guacamole/guacd> 
0.9.11-incubating   940310c23921        8 months ago  404.5 MB

[mjumper@dev-mjumper ~]$

The output from your run of "docker images" matches, so it looks like 
that much is correct on your end, but if you are still seeing 0.9.12 
... you must somehow still be pulling an old copy. The string 
"0.9.12-incubating" is simply not present in these images. They are 
0.9.13.


[mjumper@dev-mjumper ~]$ sudo docker run -it guacamole/guacd
[sudo] password for mjumper:
WARNING: IPv4 forwarding is disabled. Networking will not work.
guacd[1]: INFO:Guacamole proxy daemon (guacd) version 
0.9.13-incubating started

guacd[1]: INFO:Listening on host 0.0.0.0, port 4822

(See attached screenshot for guacamole/guacamole version)

If, after retrying, you still see the wrong version, I suggest using 
"docker inspect" to verify that the image being used matches the image 
ID of 0.9.13-incubating. If it does match, check that your browser 
hasn't simply cached the old version.


- Mike

[1] 
https://lists.apache.org/thread.html/962d0277242c751786615adbc232f6c669fe842a3465a6331ff4e08c@%3Cuser.guacamole.apache.org%3E



On Wed, Sep 27, 2017 at 10:31 AM, Jacob Staub <mailto:jpsta...@gmail.com>> wrote:


See attached for the requested output.

    Regards,
Jake


On 9/27/2017 12:27 PM, Mike Jumper wrote:

On Wed, Sep 27, 2017 at 8:34 AM, Jacob Staub mailto:jpsta...@gmail.com>> wrote:

Images are were pulled via the Docker Pull Command listed on
each corresponding page. Example for guacamole:

docker pull guacamole/guacamole

Using the above command pulls Tag = latest. I would expect
"latest" to include 0.9.13-incubating but the suggestion is
that "latest" does not include 0.9.13-incubating.


Please post the output of:

    docker images guacamole/guacamole

    docker images guacamole/guacd

- Mike

Re: tracking down a tomcat 500 error

[Jacob Staub]

Good morning,

See attached for a docker-compose file that runs Guacamole 0.9.13 
successfully in the following environment:


1. Docker host = Ubuntu 16.04.3 LTS
2. Docker engine = 17.06.2-ce
3. Docker compose = 1.13.0.

A note about the attached docker-compose file:

From what I understand about Docker networking, 'network_mode: 
"bridge"' places docker-compose initiated containers on the default 
bridge network which is handy if you want them to interact with 
containers that were not initiated with docker-compose.


For example, if you use a common database container initiated via 
typical docker command line instructions it would reside on the default 
"bridge" network. To place your Guacamole containers on the bridge 
network such that the common database container is accessible, 
'network_mode: "bridge"' would be used.


Regards,
Jake

On 10/5/2017 2:42 PM, Ryan Underwood wrote:


Anyone have ideas on the below?  I get the same error when guacd is 
running or when it’s not.  I’ve tried it with docker link (deprecated) 
and putting all the containers on a docker network.  No matter what, 
tomcat gives me the connection refused error. I tried it with RDP and 
random other protocols just to see if I could generate a different 
warning.


I can telnet to $GUACD_HOST 4802 from the guacamole server and see the 
guacd error about the protocol in the logs.  I’ve disabled windows 
firewall, disabled antivirus, tried it on public and private networks 
and am just flat out of ideas.


01:42:10.038 [http-nio-8080-exec-1] ERROR 
o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket 
tunnel to guacd failed: java.net.ConnectException: Connection refused 
(Connection refused)


01:42:10.108 [http-nio-8080-exec-7] ERROR 
o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: 
java.net.ConnectException: Connection refused (Connection refused)


Thank you

*From:* Ryan Underwood [mailto:r...@greymarketlabs.com]
*Sent:* Wednesday, October 04, 2017 9:52 PM
*To:* user@guacamole.incubator.apache.org
*Subject:* RE: tracking down a tomcat 500 error

I thought I was there but think I have a problem with guacamole 
connecting to guacd.  From each of the containers I can ping the other 
so the network connectivity within docker _/seems/_ OK.  Here’s what I 
have when I attempt to connect to a connection that I setup through 
the GUI:


01:42:10.038 [http-nio-8080-exec-1] ERROR 
o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket 
tunnel to guacd failed: java.net.ConnectException: Connection refused 
(Connection refused)


01:42:10.108 [http-nio-8080-exec-7] ERROR 
o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: 
java.net.ConnectException: Connection refused (Connection refused)


Any tips on this one?  I saw an error like this in the board history 
but the person said they didn’t have guacd running.  I know it’s 
running but perhaps there’s a connectivity issue…


Thank you

-Ryan

*From:* Ryan Underwood [mailto:r...@greymarketlabs.com]
*Sent:* Wednesday, October 04, 2017 9:43 AM
*To:* user@guacamole.incubator.apache.org 


*Subject:* RE: tracking down a tomcat 500 error

Docker on win10 pro does, and that was a good idea.  I had the 
password environment variable wrong and saw the access denied for the 
user in the mysql logs.  Thanks for the quick responses!


*From:* Mike Jumper [mailto:mike.jum...@guac-dev.org]
*Sent:* Wednesday, October 04, 2017 12:17 AM
*To:* user@guacamole.incubator.apache.org 


*Subject:* Re: tracking down a tomcat 500 error

On Tue, Oct 3, 2017 at 8:42 PM, Ryan Underwood 
mailto:r...@greymarketlabs.com>> wrote:


I am running guacamole via docker on win10 pro. I’m using Mysql,
guacamole and guacd and all appear to be running as intended.  I
get a 500 error when I hit the home page. Localhost access log
shows all the GETs work

Those GETs are probably to static files, and thus aren't hitting the 
component which is failing.


and a PUT failed (172.17.0.1 - - [04/Oct/2017:03:27:52 +]

There shouldn't be a PUT occurring prior to login. What URL is that 
PUT request for?


"POST /guacamole/api/tokens HTTP/1.1" 500 185).  Any ideas where I
should be looking to narrow this down or get more info?

".../api/tokens" is the URL of the REST endpoint used for handling 
authentication. Given the description of your setup, the MySQL portion 
of things is most likely misconfigured (somehow). Once we find the 
proper log, things should clear up.


Catalina error seems to be in non-guacamole classes so not sure
where to go next.

-Ryan

Catalina:

04-Oct-2017 03:13:40.242 SEVERE [http-nio-8080-exec-8]
com.sun.jersey.spi.container.ContainerResponse.logException Mapped
exception to response: 500 (Internal Server Error)

org.apache.guacamole.rest.APIException

at

org.apache.guacamole.rest.RESTExceptionWrapper.i