xpra icon
Bug tracker and wiki

Opened 2 weeks ago

Last modified 26 hours ago

#2668 new defect

xpra upload file causes UI thread delays

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 4.1
Component: client Version: 3.0.x
Keywords: Cc:

Description

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.

Attachments (1)

redact-uniq-xpra-2668-display-0-timestamp.log (82.6 KB) - added by stdedos 2 weeks ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 2 weeks ago by Antoine Martin

Status: newassigned
Summary: xpra upload file on the main threadxpra upload file causes UI thread delays

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?

comment:2 in reply to:  1 Changed 2 weeks ago by 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

comment:3 Changed 2 weeks ago by 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.

Last edited 2 weeks ago by Antoine Martin (previous) (diff)

comment:4 Changed 2 weeks ago by 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!

comment:5 Changed 2 weeks ago by Antoine Martin

You must control ..

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

comment:6 in reply to:  5 Changed 2 weeks ago by 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).

Changed 2 weeks ago by stdedos

comment:7 Changed 2 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

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.

comment:8 in reply to:  7 ; Changed 2 weeks ago by 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.

comment:9 in reply to:  8 Changed 2 weeks ago by 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

Last edited 2 weeks ago by stdedos (previous) (diff)

comment:10 Changed 26 hours ago by Antoine Martin

Milestone: 4.04.1
Note: See TracTickets for help on using tickets.