xpra icon
Bug tracker and wiki

Opened 7 months ago

Closed 4 weeks ago

#2668 closed defect (needinfo)

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 7 months ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 months 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 7 months 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 7 months 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 7 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 7 months 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 7 months ago by Antoine Martin

You must control ..

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

comment:6 in reply to:  5 Changed 7 months 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 7 months ago by stdedos

comment:7 Changed 7 months 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 7 months 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 7 months 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 7 months ago by stdedos (previous) (diff)

comment:10 Changed 7 months ago by Antoine Martin

Milestone: 4.04.1

comment:11 Changed 6 months ago by stdedos

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

Let's just ignore this for now.

comment:12 Changed 4 weeks ago by Antoine Martin

Resolution: needinfo
Status: newclosed
Note: See TracTickets for help on using tickets.