guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <>
Subject Re: Guacamole 0.9.12 WAN Performance (Ubuntu 14, XDRP)
Date Tue, 06 Jun 2017 17:48:17 GMT
On Tue, Jun 6, 2017 at 9:30 AM, Dogbert <> wrote:
> Hi one more time,
> After upgrading to the latest 0.9.12 I get the following message:
> Exception in thread "Thread-19" java.lang.IllegalStateException: Message will not be
sent because the WebSocket session has been closed
>     at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(
>     at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(
>     at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(
>     at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(
>     at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(
>     at org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$
> using the code I posted in a previous message, which I upgraded to use:
> compile group: 'org.apache.guacamole', name: 'guacamole-common', version: '0.9.10-incubating'
> Which worked before the upgrade. I also tried building guacamole-common from source,
which creates a 0.9.10-incubating jar not

Neither the 0.9.11 nor 0.9.12 releases modified guacamole-common, so
that version number is untouched. As long as the guacamole-client
source you're building is 0.9.12, then you have 0.9.12.

> Any ideas, what could be going wrong? I do have permissions to at least restart guacd
and that has no effect. Could IT have bouched the install? Could installing 0.9.12 over 0.9.9,
caused the issue?

As long as you've verified that it's 0.9.12 that's running, I don't
think that would cause this.

>> Just got back the status from the upgrade, and it still can spike the cpu and the
IT guy sent be back the status of the install, below. Could any of the libs with the status
of 'no' have a negative effect on performance. With this install I am running against a vnc
>> ...
>> libavcodec .......... no
>> libavutil ........... no
>> libswscale .......... no

These libraries are only needed for building guacenc, a utility for
producing video from a Guacamole protocol dump / session recording.
They have no bearing on VNC or any other protocol.

>> libssh2 ............. no
>> libtelnet ........... no

These libraries are only needed if you want SSH and telnet support. If
you're only using VNC, you don't need them, though having libssh2
would allow you to use file transfer via SFTP alongside your VNC

>> ...
>> libvorbis ........... no

This library is only needed for Ogg Vorbis support, which is actually
not currently used by any protocol. It was used in the past, but
lately audio is always streamed as raw PCM. This should probably be
removed from the build ... but it's not the cause of your issues.

>> ...
>> libwebp ............. no

I highly recommend installing libwebp and rebuilding, as it will
improve the experience for anyone using Chrome when the changes to the
screen compress better with WebP (a lossy image codec) than with PNG,
a common situation for complex or photographic images/video. For
browsers lacking WebP support, or if this is not built into Guacamole
at all, JPEG will be used.

I would also recommend checking which version of libjpeg is installed
and, if it's not libjpeg-turbo, installing libjpeg-turbo instead.

>>> So I saw this email and I'm looking into Guacamole again, a while ago I did a
poc(project taken over from offshore) with Guac looking to move to it from novnc. I have seen
CPU spikes, even on my dev box(quad core 8 thread 32GB of RAM), when running a session. My
sessions are running CAD like apps with a 3D model and moving the model can cause a cpu spike.
Right now I'm using version 0.9.9, but I'm getting IT to upgrade me to 0.9.12(Don't have sudo
on my box at this job). Also might be worth noting that my dev box is running Centos 6.7.
 With my application I think I'm running over websockets, but my question is how can I be
sure? My endpoint is running on a Grails app with endpoint code bellow(I have fixed the todo
in another branch). Also When I connect I use a ws:// url. If I run in FireFox I see not network
traffic, but if I run it chrome I see a bunch of get request.

You can expect that there will be spikes of CPU usage when encoding
complex images, such as the 3D modelling you're describing. That's
just the nature of things.

If you're seeing tons of GET requests, that does suggest WebSocket is
not being used.

Do you see any errors in your browser's console?

>>> ...
>>> @ServerEndpoint(value = "/guacamole/websocket", subprotocols = ["guacamole"])
>>> class GuacamoleEndpoint extends GuacamoleWebSocketTunnelEndpoint implements ServletContextListener

Looks good so far.

>>> ...
>>>     @Override
>>>     protected GuacamoleTunnel createTunnel(Session session, EndpointConfig config)
throws GuacamoleException {
>>>         String colorDepth = session.requestParameterMap.colorDepth[0]
>>>         Boolean cursor = Boolean.parseBoolean(session.requestParameterMap.cursor[0])
>>>         Boolean readOnly = Boolean.parseBoolean(session.requestParameterMap.readOnly[0])
>>>         GuacamoleClientInformation info = new GuacamoleClientInformation();
>>>         info.getImageMimetypes().addAll(['image/png',' image/webp','image/jpeg'])

This is not necessarily the cause of your problem, but you will need
to determine whether "image/webp" is actually supported by the browser
in question. Since you didn't build guacamole-server with support for
WebP anyway, it will be ignored, but it's definitely not safe to
arbitrarily assert that WebP is supported without checking. If
Guacamole decides to use WebP due to the nature of the changes being
made to the screen, but the browser does not support WebP, the
connection will either hang (0.9.12 and older) or fail to render that
particular update, resulting in graphical artifacts (current git).

>>> ...
>>>         GuacamoleSocket socket = new ConfiguredGuacamoleSocket(new InetGuacamoleSocket("localhost",
4822), guacamoleConfig, info)
>>>         // Return a new tunnel which uses the connected socket
>>>         return new SimpleGuacamoleTunnel(socket)

Have you verified that this function is being called, and that things
aren't being routed to the HTTP tunnel straight off?

- Mike

View raw message