xpra upload file causes UI thread delays

[stdedos]

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.

[Antoine Martin]

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?

[stdedos]

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

[Antoine Martin]

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.

[stdedos]

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!

[Antoine Martin]

You must control ..

Disable remote logging: --remote-logging=no.

[stdedos]

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).

[Antoine Martin]

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.

[stdedos]

Replying to Antoine Martin:

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.

No idea. The server log is complete, minus all-but-first sending logging line.

[stdedos]

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 receiving packet in the whole file, and lots of sending. 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.

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

[stdedos]

I just uploaded a 20mb file ... nothing like that happened.

Let's just ignore this for now.