This problem only occurs with MatLab? R2015A.
Currently, we use NoMachine? NX4 to login to our 'login' hosts, and from there, users launch HTCondor jobs which are powered by XPRA.
We haven't had any problems with most of our applications -- we've deployed XPRA cluster wide and all of our researchers use it.
However, with Matlab R2015A, the clipboard icon keeps blinking, although there is apparently nothing in the clipboard that I can see.
When this occurs, the UI becomes unresponsive.
However, when I disable the clipboard, everything works fine.
Unfortunately, disabling the clipboard isn't a solution since people copy and paste into Matlab pretty much all the time.
I was wondering if there was anything I could do about this.
I am including a ZIP file that was generated by the XPRA bug report tool, as well as output logs from the xpra session.
Can you run with clipboard debugging turned on? The clipboard is infamously difficult to get working properly with applications that misbehave (ie: requesting clipboard contents eagerly). See wiki/Clipboard.
It's also very difficult to debug without being able to run the application on my testing environment, which may be difficult to arrange given Matlab's licensing.
xpra matlab -d clipboard on
I just added output from '-d clipboard' from xpra server/client with MatLab? R2015A.
Thanks for your prompt response, I really appreciate it
If it's helpful -- I can give you a trial MatLab? R2015B for Linux and you can use my trial username and license key.
Looking at the logs, I see:
target for CLIPBOARD: 'TARGETS' .. remote selection fetch timed out or empty
process clipboard request, request_id=8, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS .. _filter_targets(())= clipboard raw -> wire: ('ATOM', 32, ()) -> ('atoms', )
And so the server wants to know the "valid targets" (the type of data that it can request) for the clipboard data the client owns (a cut or copy initiated on the client I presume). The client finds NO targets (which is strange, but not invalid AFAICT), and there seems to be a bug in that we then fail to send the empty list and do nothing instead.. The server side clipboard code then spins, times out and tries again. This bug has been present for a very long time!
r12114 should fix this - I will backport it to the older branches in due time if it is correct. @esarmien: can you try the latest beta builds and confirm that this fixes things? (no win32 or OSX builds yet with this change) I am not certain copying will work since there are no targets, but at least this particular bug should be gone.
Also, are there any particular reasons why you still use NX at all? Having nested remote access is always going to be sub-optimal:
Thanks Antoine! The BETA version resolves the problem -- it works!
TBH, we don't *want* to use NoMachine?. Here is how we're situated-- users login to a NoMachine? desktop and from there start primarily graphical applications on our compute cluster. We were having serious problems with NoMachine? NX4 -- users desktops were crashing and along with them, the applications they launched, often kept running for days for computations, as we were simply X Forwarding from the cluster nodes to the dekstop. XPRA has been a huge success for us now that we can basically mitigate NoMachine? desktop crashes, which happen more often than we'd like.
In the future we are def. going to go torwards an total-XPRA solution, but in the meantime, we have this.
Thanks for testing. The fix has been applied to all branches in r12115. (ie: it will be included in 0.16.3 - which also includes some other minor fixes for running matlab)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1139