Maximum number of Xvnc sessions

[Rafael Guimaraes]

Hi DRC,

In past versions of TurboVNC (unfortunatelly I can't be precise with this info, but I think that I am talking about versions from 2015 or 2016), I was able to create up to 100 XVnc sessions on the same computer. In fact, at that moment, I haved hacked the vncserver script to allow the creation of up to 200 sessions (changed the way ports are assigned). Although I have never reached this 200 session limit, I have seen more than 100 sessions on a single server and everything went fine.

However, with the current TurboVNC version (as a matter of fact, it happened with version 2.2), I was not able to create more than around 50 or 60 sessions. Is there a hard-coded limit for the number of sessions or any other kind of limit?

If needed, I can try to create lots of sessions and copy and paste the error I get from vncserver while trying to create a session. I didn't do it because it happened on a production server and, at the moment, I was worried on trying to solve the problem (users were not able to create new Xvnc sessions) and forgot to copy the error message (my fault, I admit!).

In fact, it seems that the problem was with a limit on the display number (something around 70). At least, that's what I think, since there were several /tmp/.X11-lock/X?? files that existed although the respective display was not in use. After removing those (unused) files, I was able to create more sessions...

Any information about this limit?

Best regards,

Rafael Guimarães

[DRC]

There is no such limit in TurboVNC. If such a limit exists, it is apparently being imposed by the operating system somehow. Not sure what would have changed in 2.2 to cause the maximum number of sessions to decrease. It might have had something to do with upgrading the Xorg code base to 1.19.x. It would be a useful data point to see whether the ‘-listen tcp’ option has any effect. That option used to be the default, but it is not anymore.

--
You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_-%2BT4Oxk6H-xdt82APPaqqB8A5Hot-d237hZGvATshsng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Rafael Guimaraes]

I am currently using the -listen tcp, since users are allowed to export display to the TurboVNC session. So, the problem happens with -listen tcp on...

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/613DF5A5-72A8-4A70-B9D2-FE988593264B%40virtualgl.org.

[DRC]

So it goes away if you don’t use ‘-listen tcp’?

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8826CZrqxCfuSdmsSvZ9xvr4%3DVVwCmS%2B5fx9jke3-5ag%40mail.gmail.com.

[Rafael Guimaraes]

I haven't tested it without -listen tcp... It's a must in our environment, so I don't know the behavior without It...

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/DCFFC243-898D-409F-B63D-01C49EB115BD%40virtualgl.org.

[DRC]

Further information:

Our vncserver script (and the vncserver script for other Xvnc
implementations, such as TigerVNC) has a hard-coded limit of 99
sessions, mainly because:

(a) All VNC viewers expect Display :{n} to map to TCP port 5900+{n} on
the server, and

(b) Starting with VNC display :100, the RFB ports would start
interfering with X11 TCP ports (6000-), and the HTTP ports would start
interfering with RFB ports (5900-).

Technically the only RFB ports registered with IANA are 5900 and 5800,
so Xvnc solutions are already stomping on ports that aren't registered
to RFB. However, those ports are registered to somewhat esoteric
applications that probably wouldn't be used on a VNC server, so thus far
it hasn't been a problem. If people need more than 99 TurboVNC
sessions, then the best solution would probably be for vncserver to pick
an unused TCP port for the 100th and subsequent sessions and require
that viewers connect to those sessions using {host}::{port} rather than
{host}:{display_number}. Thus far, no one has requested more than 99
sessions in the nearly 15 years that TurboVNC has existed, but I'm just
putting all of this out there in case someone does have a need for it.
With the TurboVNC Session Manager, which will be introduced this year in
TurboVNC 3.0, it would even be possible for the viewer to automatically
connect to the port that the server automatically assigns.


As to the issue at hand:

I tried to reproduce it with TurboVNC 2.2 on RHEL 7 and wasn't able to.
I've got 99 sessions, and a glitch ain't one. I started them all with
-listen tcp and the HTTP daemon activated, and I verified that I can run
xdpyinfo and glxinfo against all 99 sessions. I also started them
asynchronously, to simulate multiple users banging away on the server
simultaneously. I confirmed that, with the aforementioned settings,
TurboVNC 2.2 is occupying the same TCP ports that TurboVNC 2.1 occupied:

- IPv4 and IPv6 ports 6000+{n} for the X11 connection
- IPv4 port 5900+{n} for the RFB connection (this would change to IPv6
if -ipv6 is passed to the server)
- IPv4 port 5800+{n} for the HTTP connection (this would also change to
IPv6 if -ipv6 is passed to the server)

I also tried with -ipv6 and got the same result. I am happy to re-test
this on your Linux distribution of choice. Question: did anything else
change other than the TurboVNC version? I could see, for instance, a
different window manager creating some sort of resource exhaustion that
didn't exist previously. Other straws to grasp at, based on looking at
the TurboVNC change log:

- TurboVNC 2.2 introduced a software GLX extension, which may be causing
some sort of resource exhaustion (although I tested with it enabled
above.) If you are using VirtualGL, then you can safely start the
server with -extension GLX to disable the software GLX extension, in
case that is causing the problem.

- TurboVNC 2.2 enabled multi-threaded Tight encoding by default.
Although you shouldn't be running into a thread limit because of that,
stranger things have happened. You can revert to the TurboVNC 2.1.x
behavior by passing -nomt to the server. I seriously doubt this is the
cause, since those threads aren't actually created until a viewer connects.

Other than that, the upgrade to xorg-xserver 1.19.6 was the only other
major change to the server, but without the ability to reproduce the
problem or any further information on it (error messages?), I'm clueless.

On 1/12/19 7:44 PM, Rafael Guimaraes wrote:
> I haven't tested it without -listen tcp... It's a must in our
> environment, so I don't know the behavior without It...
>
> Em sáb, 12 de jan de 2019 17:23, DRC <d...@virtualgl.org

> <mailto:d...@virtualgl.org> escreveu:

>
> So it goes away if you don’t use ‘-listen tcp’?
>
> On Jan 7, 2019, at 8:23 PM, Rafael Guimaraes <rgu...@gmail.com

> <mailto:rgu...@gmail.com>> wrote:
>
>> I am currently using the -listen tcp, since users are allowed to
>> export display to the TurboVNC session. So, the problem happens
>> with -listen tcp on...
>>
>> Em sex, 4 de jan de 2019 às 05:43, DRC <d...@virtualgl.org

>> <mailto:d...@virtualgl.org>> escreveu:

>>
>> There is no such limit in TurboVNC. If such a limit exists, it
>> is apparently being imposed by the operating system somehow.
>> Not sure what would have changed in 2.2 to cause the maximum
>> number of sessions to decrease. It might have had something to
>> do with upgrading the Xorg code base to 1.19.x. It would be a
>> useful data point to see whether the ‘-listen tcp’ option has
>> any effect. That option used to be the default, but it is not
>> anymore.
>>
>> On Jan 3, 2019, at 2:20 PM, Rafael Guimaraes <rgu...@gmail.com

>>> <mailto:turbovnc-deve...@googlegroups.com>.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_-%2BT4Oxk6H-xdt82APPaqqB8A5Hot-d237hZGvATshsng%40mail.gmail.com

>>> <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_-%2BT4Oxk6H-xdt82APPaqqB8A5Hot-d237hZGvATshsng%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "TurboVNC Developer Discussion" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to
>> turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-deve...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/turbovnc-devel/613DF5A5-72A8-4A70-B9D2-FE988593264B%40virtualgl.org
>> <https://groups.google.com/d/msgid/turbovnc-devel/613DF5A5-72A8-4A70-B9D2-FE988593264B%40virtualgl.org?utm_medium=email&utm_source=footer>.

>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "TurboVNC Developer Discussion" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-deve...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8826CZrqxCfuSdmsSvZ9xvr4%3DVVwCmS%2B5fx9jke3-5ag%40mail.gmail.com
>> <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8826CZrqxCfuSdmsSvZ9xvr4%3DVVwCmS%2B5fx9jke3-5ag%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC Developer Discussion" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to turbovnc-deve...@googlegroups.com

> <mailto:turbovnc-deve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/turbovnc-devel/DCFFC243-898D-409F-B63D-01C49EB115BD%40virtualgl.org
> <https://groups.google.com/d/msgid/turbovnc-devel/DCFFC243-898D-409F-B63D-01C49EB115BD%40virtualgl.org?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC Developer Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to turbovnc-deve...@googlegroups.com

> <mailto:turbovnc-deve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8iBJDrEy5Wk0Cq6nevdiSbfU1H_D2iRrwZn7okbs%2BudQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8iBJDrEy5Wk0Cq6nevdiSbfU1H_D2iRrwZn7okbs%2BudQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Rafael Guimaraes]

Hi DRC,

It just happened again and now I collected some additional information.
When I try to create a new session, I get the following error:

Warning: server08:1 is taken because of /tmp/.X11-unix/X1
Remove this file if there is no X server server08:1

Warning: server08:24 is taken because of /tmp/.X11-unix/X24
Remove this file if there is no X server server:24

WARNING: The first attempt to start Xvnc failed, possibly because the vncserver
script was not able to figure out an appropriate X11 font path for this system
or because the font path you specified with the -fp argument was not valid.
Attempting to restart Xvnc using the X Font Server (xfs) ...
Could not start Xvnc.

TurboVNC Server (Xvnc) 64-bit v2.1.90 (build 20180522)
Copyright (C) 1999-2018 The VirtualGL Project and many others (see README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC

25/02/2019 10:53:25 Using auth configuration file /etc/turbovncserver-security.conf
25/02/2019 10:53:25 Enabled authentication method 'otp'
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE)
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
TurboVNC Server (Xvnc) 64-bit v2.1.90 (build 20180522)
Copyright (C) 1999-2018 The VirtualGL Project and many others (see README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC

25/02/2019 10:53:26 Using auth configuration file /etc/turbovncserver-security.conf
25/02/2019 10:53:26 Enabled authentication method 'otp'
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE)
Fatal server error:

(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)

Then I looked at the running Xvnc sessions:

server08:root:[/root]# ps -ef |grep Xvnc |grep -v grep |wc -l
67

All sessions are created with the same parameters (except for the geometry, that may change a bit from session to session). Here is one of the sessions's ps:

user1       895     1  0 Jan29 ?        00:02:02 /opt/TurboVNC/bin/Xvnc :3 -desktop TurboVNC: server08:3 (user1) -auth /u/user1/.Xauthority -geometry 1240x870 -depth 24 -rfbwait 120000 -securitytypes otp -rfbport 5903 -fp catalogue:/etc/X11/fontpath.d -deferupdate 1 -listen tcp

Getting which displays are in use by these Xvnc sessions:

server08:root:[/root]# ps -ef |grep Xvnc |grep -v grep |grep -v sed |sed 's/.*Xvnc :\([0-9]*\) -desktop .*/\1/' |sort -n
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
21
22
23
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
68
69
70
71
72

How many Xvnc sessions:

---> ps -ef |grep Xvnc |grep -v grep |grep -v sed |sed 's/.*Xvnc :\([0-9]*\) -desktop .*/\1/' |sort -n |wc -l
67

Removed Xvnc lock files that had no equivalent Xvnc session:

server08:root:[/tmp/.X11-unix]
---> rm X1 X19 X20 X24 X67

Then I was able to create a new session, but the created session does not run the window manager correctly (gnome). The window remains black and, only when I manually kill a couple of existing sessions, this new session's Gnome finishes starting correctly. It seems the be paused at some point and it just continues when another session is killed. Really odd behavior.

Best regards,

Rafael

To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/d3ec1e65-a5b0-f76d-6c6f-8c3305c423ef%40virtualgl.org.

[DRC]

The leftover files in /tmp/.X11-unix/ would be indicative of a session failing to shut down properly.  You should be able to run '/opt/TurboVNC/bin/vncserver -kill :1' and '/opt/TurboVNC/bin/vncserver -kill :24' to get rid of those files, but the question remains: why aren't those sessions shutting down properly?

Note also:  the files in /tmp/.X11-unix/ are not lock files.  Those files are the Unix domain socket files that are used for inter-process communication between X11 clients (applications) and various X server instances, including instances of the TurboVNC X server.  The lock files are /tmp/.X1-lock, /tmp/.X2-lock, etc.  The TurboVNC Server will not start on Display :{n} if either /tmp/.X11-unix/X{n} or /tmp/.X{n}-lock exists.  When you run '/opt/TurboVNC/bin/vncserver -kill :{n}' and the Xvnc process for that display has already terminated, then the vncserver script will remove the corresponding lock file and Unix domain socket file.

I'm afraid that there is little I can do without the ability to reproduce the problem, and given all of the known issues with GNOME, it's entirely possible that the black screen issue you observed is just another one of those.  If you can diagnose why the sessions are failing to shut down properly and thus failing to clean up their lock and socket files, then that would give me something to work with.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_819aaeOK-Sk_Npz_GOtqwO21SbwsEK_aQL%3DxDajjVZig%40mail.gmail.com.

[Rafael Guimaraes]

Would you recommend me switching from Gnome to any other particular window manager?

I have another environment here with IceWM where I have no such problems. But in this case, I would like to provide Gnome or something similar? Maybe Mate? Or do you have better experience with any other window manager?

Best regards,

Rafael Guimarães

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/e178213d-fc34-406d-a071-9561abec472f%40virtualgl.org.

[DRC]

MATE is my recommended window manager for systemd systems.

On 2/25/19 11:52 AM, Rafael Guimaraes wrote:
> Would you recommend me switching from Gnome to any other particular
> window manager?
> I have another environment here with IceWM where I have no such
> problems. But in this case, I would like to provide Gnome or something
> similar? Maybe Mate? Or do you have better experience with any other
> window manager?
>
> Best regards,
>
> Rafael Guimarães
>
>
> Em seg, 25 de fev de 2019 às 14:06, DRC <d...@virtualgl.org

> <mailto:d...@virtualgl.org>> escreveu:

>
> The leftover files in /tmp/.X11-unix/ would be indicative of a
> session failing to shut down properly.  You should be able to run
> '/opt/TurboVNC/bin/vncserver -kill :1' and
> '/opt/TurboVNC/bin/vncserver -kill :24' to get rid of those files,
> but the question remains: why aren't those sessions shutting down
> properly?
>
> Note also:  the files in /tmp/.X11-unix/ are not lock files.  Those
> files are the Unix domain socket files that are used for
> inter-process communication between X11 clients (applications) and
> various X server instances, including instances of the TurboVNC X
> server.  The lock files are /tmp/.X1-lock, /tmp/.X2-lock, etc.  The
> TurboVNC Server will not start on Display :{n} if either
> /tmp/.X11-unix/X{n} or /tmp/.X{n}-lock exists.  When you run
> '/opt/TurboVNC/bin/vncserver -kill :{n}' and the Xvnc process for
> that display has already terminated, then the vncserver script will
> remove the corresponding lock file and Unix domain socket file.
>
> I'm afraid that there is little I can do without the ability to
> reproduce the problem, and given all of the known issues with GNOME,
> it's entirely possible that the black screen issue you observed is
> just another one of those.  If you can diagnose why the sessions are
> failing to shut down properly and thus failing to clean up their
> lock and socket files, then that would give me something to work with.
>
> On 2/25/19 8:42 AM, Rafael Guimaraes wrote:

>> *Hi DRC,

>>
>> It just happened again and now I collected some additional
>> information.

>> When I try to create a new session, I get the following error:*

>> *Then I looked at the running Xvnc sessions:*

>>
>> server08:root:[/root]# ps -ef |grep Xvnc |grep -v grep |wc -l
>> 67
>>

>> *All sessions are created with the same parameters (except for the

>> geometry, that may change a bit from session to session). Here is

>> one of the sessions's ps:*

>>
>> user1       895     1  0 Jan29 ?        00:02:02
>> /opt/TurboVNC/bin/Xvnc :3 -desktop TurboVNC: server08:3 (user1)
>> -auth /u/user1/.Xauthority -geometry 1240x870 -depth 24 -rfbwait
>> 120000 -securitytypes otp -rfbport 5903 -fp
>> catalogue:/etc/X11/fontpath.d -deferupdate 1 -listen tcp
>>

>> *Getting which displays are in use by these Xvnc sessions:*
>> *
>> *

>> *
>> *
>> *How many Xvnc sessions:*

>>
>> ---> ps -ef |grep Xvnc |grep -v grep |grep -v sed |sed 's/.*Xvnc
>> :\([0-9]*\) -desktop .*/\1/' |sort -n |wc -l
>> 67
>>

>> *Removed Xvnc lock files that had no equivalent Xvnc session:*

>>
>> server08:root:[/tmp/.X11-unix]
>> ---> rm X1 X19 X20 X24 X67
>>

>> *Then I was able to create a new session, but the created session

>> does not run the window manager correctly (gnome). The window
>> remains black and, only when I manually kill a couple of existing
>> sessions, this new session's Gnome finishes starting correctly. It
>> seems the be paused at some point and it just continues when
>> another session is killed. Really odd behavior.

>> *
>> *
>> *
>> *Best regards,*
>> *
>> *
>> *Rafael*

>>
>>
>>
>>
>>
>> Em sex, 8 de fev de 2019 às 01:41, DRC <d...@virtualgl.org

>> <mailto:d...@virtualgl.org>> escreveu:

>> > <mailto:d...@virtualgl.org <mailto:d...@virtualgl.org>> escreveu:

>> >
>> >     So it goes away if you don’t use ‘-listen tcp’?
>> >
>> >     On Jan 7, 2019, at 8:23 PM, Rafael Guimaraes
>> <rgu...@gmail.com <mailto:rgu...@gmail.com>

>> >     <mailto:rgu...@gmail.com <mailto:rgu...@gmail.com>>> wrote:
>> >
>> >>     I am currently using the -listen tcp, since users are
>> allowed to
>> >>     export display to the TurboVNC session. So, the problem
>> happens
>> >>     with -listen tcp on...
>> >>
>> >>     Em sex, 4 de jan de 2019 às 05:43, DRC
>> <d...@virtualgl.org <mailto:d...@virtualgl.org>

>> >>     <mailto:d...@virtualgl.org <mailto:d...@virtualgl.org>>>

>> escreveu:
>> >>
>> >>         There is no such limit in TurboVNC. If such a limit
>> exists, it
>> >>         is apparently being imposed by the operating system
>> somehow.
>> >>         Not sure what would have changed in 2.2 to cause
>> the maximum
>> >>         number of sessions to decrease. It might have had
>> something to
>> >>         do with upgrading the Xorg code base to 1.19.x. It
>> would be a
>> >>         useful data point to see whether the ‘-listen tcp’
>> option has
>> >>         any effect. That option used to be the default, but
>> it is not
>> >>         anymore.
>> >>
>> >>         On Jan 3, 2019, at 2:20 PM, Rafael Guimaraes
>> <rgu...@gmail.com <mailto:rgu...@gmail.com>

>> >>         <mailto:rgu...@gmail.com

>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>
>> >>>       
>>  <mailto:turbovnc-deve...@googlegroups.com
>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>>.

>> >>>         To view this discussion on the web visit
>> >>>       
>>  https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_-%2BT4Oxk6H-xdt82APPaqqB8A5Hot-d237hZGvATshsng%40mail.gmail.com
>> >>>       
>>  <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_-%2BT4Oxk6H-xdt82APPaqqB8A5Hot-d237hZGvATshsng%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> >>>         For more options, visit
>> https://groups.google.com/d/optout.
>> >>
>> >>         --
>> >>         You received this message because you are
>> subscribed to the
>> >>         Google Groups "TurboVNC Developer Discussion" group.
>> >>         To unsubscribe from this group and stop receiving
>> emails from
>> >>         it, send an email to
>> >>         turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>
>> >>         <mailto:turbovnc-deve...@googlegroups.com
>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>>.

>> >>         To view this discussion on the web visit
>> >>       
>>  https://groups.google.com/d/msgid/turbovnc-devel/613DF5A5-72A8-4A70-B9D2-FE988593264B%40virtualgl.org
>> >>       
>>  <https://groups.google.com/d/msgid/turbovnc-devel/613DF5A5-72A8-4A70-B9D2-FE988593264B%40virtualgl.org?utm_medium=email&utm_source=footer>.
>> >>         For more options, visit
>> https://groups.google.com/d/optout.
>> >>
>> >>     --
>> >>     You received this message because you are subscribed to
>> the Google
>> >>     Groups "TurboVNC Developer Discussion" group.
>> >>     To unsubscribe from this group and stop receiving
>> emails from it,
>> >>     send an email to
>> turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>
>> >>     <mailto:turbovnc-deve...@googlegroups.com
>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>>.

>> >>     To view this discussion on the web visit
>> >>   
>>  https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8826CZrqxCfuSdmsSvZ9xvr4%3DVVwCmS%2B5fx9jke3-5ag%40mail.gmail.com
>> >>   
>>  <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8826CZrqxCfuSdmsSvZ9xvr4%3DVVwCmS%2B5fx9jke3-5ag%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> >>     For more options, visit https://groups.google.com/d/optout.
>> >
>> >     --
>> >     You received this message because you are subscribed to
>> the Google
>> >     Groups "TurboVNC Developer Discussion" group.
>> >     To unsubscribe from this group and stop receiving emails
>> from it,
>> >     send an email to
>> turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>
>> >     <mailto:turbovnc-deve...@googlegroups.com
>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>>.

>> >     To view this discussion on the web visit
>> >   
>>  https://groups.google.com/d/msgid/turbovnc-devel/DCFFC243-898D-409F-B63D-01C49EB115BD%40virtualgl.org
>> >   
>>  <https://groups.google.com/d/msgid/turbovnc-devel/DCFFC243-898D-409F-B63D-01C49EB115BD%40virtualgl.org?utm_medium=email&utm_source=footer>.
>> >     For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to the
>> Google
>> > Groups "TurboVNC Developer Discussion" group.
>> > To unsubscribe from this group and stop receiving emails
>> from it, send
>> > an email to turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>
>> > <mailto:turbovnc-deve...@googlegroups.com
>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>>.

>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8iBJDrEy5Wk0Cq6nevdiSbfU1H_D2iRrwZn7okbs%2BudQ%40mail.gmail.com
>> >
>> <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_8iBJDrEy5Wk0Cq6nevdiSbfU1H_D2iRrwZn7okbs%2BudQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "TurboVNC Developer Discussion" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to
>> turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-devel%2Bunsu...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/turbovnc-devel/d3ec1e65-a5b0-f76d-6c6f-8c3305c423ef%40virtualgl.org.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "TurboVNC Developer Discussion" group.
>> To unsubscribe from this group and stop receiving emails from it,

>> send an email to turbovnc-deve...@googlegroups.com

>> <mailto:turbovnc-deve...@googlegroups.com>.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_819aaeOK-Sk_Npz_GOtqwO21SbwsEK_aQL%3DxDajjVZig%40mail.gmail.com
>> <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_819aaeOK-Sk_Npz_GOtqwO21SbwsEK_aQL%3DxDajjVZig%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC Developer Discussion" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to turbovnc-deve...@googlegroups.com
> <mailto:turbovnc-deve...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/turbovnc-devel/e178213d-fc34-406d-a071-9561abec472f%40virtualgl.org
> <https://groups.google.com/d/msgid/turbovnc-devel/e178213d-fc34-406d-a071-9561abec472f%40virtualgl.org?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC Developer Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to turbovnc-deve...@googlegroups.com
> <mailto:turbovnc-deve...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4__53jKYJQUkt6DKRqWR_kyqWQ%2B%2BR8yRceq5YvgQmFB%2B2A%40mail.gmail.com
> <https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4__53jKYJQUkt6DKRqWR_kyqWQ%2B%2BR8yRceq5YvgQmFB%2B2A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[DRC]

Also, I would strongly recommend upgrading the server to 2.2.1. 2.1.90
is 2.2 beta, which means it has bugs, and one of those bugs might be
what is causing premature termination of the server instances. 2.2 beta
was no longer supported after 2.2 was released (how could it be
supported? All of the bug fixes went into 2.2.)

On 2/25/19 11:52 AM, Rafael Guimaraes wrote:

[Rafael Guimaraes]

I have just upgraded my environment to 2.2.1 and I will monitor my servers to see what happens. Meanwhile, when I tried to use the Java Client, I had problems with some dead keys for accents (^ ' ~). This is something that is really common in portuguese, so it is important for us... I have checked the previous versions of the Java Client that used here and I verified that in each one of them I have applied the patch described in https://github.com/TurboVNC/turbovnc/issues/30.

I thought that maybe this was solved in this version, but it doesn't seem to be. So I applied the patch and it voilà! Accents working again! Is there any problem in merging this to the standard code?

That's the patch I applied to CConn.java (sorry for some many useless comments, they make my life easier since I can easily identify where the patch begins and ends just by looking at the code :)).

Best regards,

Rafael Guimarães

1809,1816d1808

< //
< // Patched by Rafael Guimaraes
< // (https://github.com/TurboVNC/turbovnc/issues/30)
< //
<     boolean fakePress = false;
< //
< // End of Patch
< //
1855,1886d1846
< //
< // Patched by Rafael Guimaraes
< // (https://github.com/TurboVNC/turbovnc/issues/30)
< //
<         if (VncViewer.isX11()) {
<           // Attempt to work around
<           // https://bugs.openjdk.java.net/browse/JDK-8016255
<           switch (keycode) {
<           case KeyEvent.VK_DEAD_ABOVEDOT:
<           case KeyEvent.VK_DEAD_ABOVERING:
<           case KeyEvent.VK_DEAD_ACUTE:
<           case KeyEvent.VK_DEAD_BREVE:
<           case KeyEvent.VK_DEAD_CARON:
<           case KeyEvent.VK_DEAD_CEDILLA:
<           case KeyEvent.VK_DEAD_CIRCUMFLEX:
<           case KeyEvent.VK_DEAD_DIAERESIS:
<           case KeyEvent.VK_DEAD_DOUBLEACUTE:
<           case KeyEvent.VK_DEAD_GRAVE:
<           case KeyEvent.VK_DEAD_IOTA:
<           case KeyEvent.VK_DEAD_MACRON:
<           case KeyEvent.VK_DEAD_OGONEK:
<           case KeyEvent.VK_DEAD_SEMIVOICED_SOUND:
<           case KeyEvent.VK_DEAD_TILDE:
<           case KeyEvent.VK_DEAD_VOICED_SOUND:
<             fakePress = nextKeyFakePress = true;
<             break;
<           default:
<             fakePress = nextKeyFakePress;
<             nextKeyFakePress = false;
<           }
<         }
<         if (!fakePress) {
1892d1851
<         }
1895d1853
<       if (!fakePress) {
1901,1904d1858
<       }
< //
< // End of Patch
< //
2273,2284c2227
< //
< // Patched by Rafael Guimaraes
< // (https://github.com/TurboVNC/turbovnc/issues/30)
< //
< //    pressedKeys.put(keycode, keysym);
<     if (fakePress && !down)
<       writeKeyEvent(keysym, true);
<     else
<       pressedKeys.put(keycode, keysym);
< //
< // End of Patch
< //
---
>     pressedKeys.put(hashedKey, keysym);
2483,2490d2425
< //
< // Patched by Rafael Guimaraes
< // (https://github.com/TurboVNC/turbovnc/issues/30)
< //
<   boolean nextKeyFakePress;
< //
< // End of Patch
< //

--
You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/f77664d1-304d-0afd-fcb5-3a98755789ea%40virtualgl.org.

[DRC]

On 3/12/19 3:27 PM, Rafael Guimaraes wrote:
> I have just upgraded my environment to 2.2.1 and I will monitor my
> servers to see what happens. Meanwhile, when I tried to use the Java
> Client, I had problems with some dead keys for accents (^ ' ~). This is
> something that is really common in portuguese, so it is important for
> us... I have checked the previous versions of the Java Client that used
> here and I verified that in each one of them I have applied the patch
> described in https://github.com/TurboVNC/turbovnc/issues/30.
>
> I thought that maybe this was solved in this version, but it doesn't
> seem to be. So I applied the patch and it voilà! Accents working again!
> Is there any problem in merging this to the standard code?

Yes, the problem with merging it is described in the comment in which I
posted the aforementioned patch, but I'll reiterate the overall situation:

- Java under Linux only sends a release event, not a press event, for
the dead key. I thought it might be possible to fake a press event
whenever I get a release event for a dead key, but ...

- Java under Linux only sends a release event for the modified
(accented) character resulting from a dead key, not the unmodified
character (and, IIRC, not the dead key itself either.) I need to know
the actual keys that were pressed, because that is what I have to send
to the server, but it's impossible to divine that information from what
Java gives me.

If the patch works on Portugese keyboards, it's only by pure luck. On
other types of international keyboards-- specifically those that require
Shift or AltGr in order to activate a dead key-- the patch will only
generally work if the user releases Shift/AltGr prior to releasing the
dead key. This is really a Java bug:
https://bugs.openjdk.java.net/browse/JDK-8016255, which I note has not
yet been fixed after nearly six years. If you really want to solve this
the right way in TurboVNC, then I encourage your organization to fund
this feature:

https://github.com/TurboVNC/turbovnc/issues/108

because otherwise, there is not much I can do about it.