clipboard hitting maximum requests per second limit

[totaam]

Issue migrated from trac ticket # 877

component: server | priority: critical | resolution: fixed

2015-06-02 04:26:26: jiang.qian created the issue

---

Xpra 0.15 from apt repository, running on Ubuntu 14.04 on both server and client (server 32 bit, client 64 bit). Copying from one forwarded app window to another one resulting in clipboard crashing.

Debugging message on server side log shows

2015-06-01 05:24:49,027 clipboard disabled: more than 10 clipboard requests per second!

I am running a clipboard manager called parcellite on the client side, but the bug is not present in 0.14.28, which works fine with parcellite after the earlier bug I reported in ticket #703 is resolved.

[totaam]

2015-06-02 06:29:20: antoine changed owner from antoine to jiang.qian

[totaam]

2015-06-02 06:29:20: antoine commented

---

There were NO changes whatsoever in the clipboard code between 0.14 and 0.15.
Do you have sound enabled? (this did change)

It is possible that we are now handling clipboard requests faster than before, and therefore hitting the limit sooner. r9566 raises the default limit to 20 per second. I will backport to 0.15, until then you can raise the limit yourself with:

XPRA_CLIPBOARD_LIMIT=20 xpra start ...

Note: running a clipboard manager is always going to be a problem, these tools just really mess up the way the X11 clipboard was designed. Handling the clipboard is hard enough as it is, dealing with the somewhat broken behaviour from these tools is never going to be a high priority for us... sorry.

[totaam]

2015-06-02 18:55:42: jiang.qian commented

---

I do have sound enabled.

I understand clipboard manager is a problem, so I understand that this may not be fixed completely. However, perhaps higher limit, perhaps even 40 or 50, may be helpful.

Is the limit set to prevent loops? If so, as you commented on the bug I filed for ticket #703, if there is indeed a true loop, the clipboard grow out of control and the limit will be hit very quickly however high the limit is. If there is no true loop, then the higher limit is more tolerant of normal behaviors.

Thanks for looking into this

[totaam]

2015-06-02 19:01:18: antoine commented

---

I do have sound enabled.
[[BR]]
That explains it I think: I believe sound was acting as a rate-limiter for your clipboard requests until now by adding extra latency.
[[BR]]

If there is no true loop, then the higher limit is more tolerant of normal behaviors
[[BR]]
Unfortunately, that's not the case: you often just end up just crashing or making xpra so slow it becomes unusable.
I think #812 may help here.

[totaam]

2015-06-03 03:58:45: jiang.qian commented

---

I understand your point better now. I think being able to adjust the limit myself via XPRA_CLIPBOARD_LIMIT is a great idea, because I can then adjust the value myself without having to bother the developers, particularly since I run a clipboard manager, a non-standard setup

I did not know that the option existed! Should I change the variable on the client or the server side? Is there some documentation, either in the manpage or on the website, about this? I could add something on the appropriate place once I find out how to do this, and by trial and error find a good limit for XPRA_CLIPBOARD_LIMIT.

[totaam]

2015-06-03 05:41:08: antoine commented

---

I have added more information on the Clipboard page (look under "Notes and Tuning"), feel free to suggest more edits.

I think we can close this ticket?

[totaam]

2015-06-03 06:51:23: jiang.qian set resolution to fixed

[totaam]

2015-06-03 06:51:23: jiang.qian commented

---

Sure. I'm too busy right now to check it (since I'm running a production system, I have to downgrade to 0.14 branch). I will check it after things calm down a bit on my end. At worst, I'll reopen the ticket if it turns out this is not the cause of the problem. Thank you again for helping!

[totaam]

2015-06-05 10:00:23: antoine commented

---

Could be related to #883.

[totaam]

2015-06-05 19:18:02: antoine commented

---

Applied to the v0.15.x branch in 9591.