Is it possible that you need to do r25486 (from #2617) also for file uploading?
I uploaded a 4mb file over the internet; and the shadow server freezing "matches approximately" the time it would take to upload said file.
No UI thread polling waited ... message though on client output.
That's odd, we don't use the main thread for handling file transfer packets. To be absolutely certain of this, I changed the code in r25744 to also log the thread handling the packet when xpra is started with:
XPRA_LOG_PACKET_TYPE=1 xpra ..
And this is what I see:
sending ack-file-chunk (thread=<Thread(format, started daemon 140228485605120)>) receiving send-file-chunk (thread=<Thread(parse, started daemon 140228383725312)>)
But maybe somehow we're slowing down the parse thread instead and causing knock on effects?
Replying to Antoine Martin:
To be absolutely certain of this, I changed the code in r25744 to also log the thread handling the packet when xpra is started with:
Server or client?
Server is Xenial (I know backports are not a good idea, I could try to apply manually), and Client has no beta builds posted
Server or client?
Both.
Server is Xenial (I know backports are not a good idea, I could try to apply manually),
Applying by hand should be trivial. This will not be backported at present because it is not a bug fix or an important feature.
and Client has no beta builds posted
There are now.
You must control 2020-03-24 15:22:44,572 sending logging (thread=<Thread(format, started daemon 16768)>) messages!. You are spamming client-logging every millisecond!
You must control ..
Disable remote logging: --remote-logging=no.
Replying to Antoine Martin:
You must control ..
Disable remote logging:
--remote-logging=no.
Isn't it better to handle it in-code? :/
I added a big file to upload; it uploaded 2.9mb / ~90mb file.
I could normally enter gibberish on my X11 lock screen, so I guess the delay was unrelated (but concurrent) to the file upload.
However: Server output (attached) contains a lot of send-file-chunk but no ack-file-chunk. Due to the above issue, client's output is impossible to save / work with (Windows terminal limitations).
Isn't it better to handle it in-code? :/
No. No special case. This is a debugging tool, if you see optional packets you're not interested in, toggle the feature off. ie: audio, clipboard, etc..
I added a big file to upload; it uploaded 2.9mb / ~90mb file.
I only see a single receiving packet in the whole file, and lots of sending. How can that be?
I'm getting a mix of both.
Replying to Antoine Martin:
I added a big file to upload; it uploaded 2.9mb / ~90mb file.
I only see a single
receivingpacket in the whole file, and lots ofsending. How can that be? I'm getting a mix of both.
No idea. The server log is complete, minus all-but-first sending logging line.
Replying to stdedos:
Replying to Antoine Martin:
I added a big file to upload; it uploaded 2.9mb / ~90mb file.
I only see a single
receivingpacket in the whole file, and lots ofsending. How can that be? I'm getting a mix of both.No idea. The server log is complete, minus all-but-first
sending loggingline.
I have a small idea why there might not be any receiving-logging:
u@h:/usr/lib/python3/dist-packages/xpra$ grep -TrinIF 'def call_handler():' u@h:/usr/lib/python3/dist-packages/xpra$
I forgot to backport r25744 to my server
I just uploaded a 20mb file ... nothing like that happened.
Let's just ignore this for now.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2668