#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: |
Attachments (1)
Change History (14)
comment:1 follow-up: 2 Changed 12 months ago by
Status: | new → assigned |
---|---|
Summary: | xpra upload file on the main thread → xpra upload file causes UI thread delays |
comment:2 Changed 11 months ago by
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 11 months ago by
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.
comment:4 Changed 11 months ago by
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 follow-up: 6 Changed 11 months ago by
You must control ..
Disable remote logging: --remote-logging=no
.
comment:6 Changed 11 months ago by
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 11 months ago by
Attachment: | redact-uniq-xpra-2668-display-0-timestamp.log added |
---|
comment:7 follow-up: 8 Changed 11 months ago by
Owner: | changed from Antoine Martin to stdedos |
---|---|
Status: | assigned → new |
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 follow-up: 9 Changed 11 months ago by
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 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.
comment:9 Changed 11 months ago by
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 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.
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
comment:10 Changed 11 months ago by
Milestone: | 4.0 → 4.1 |
---|
comment:11 Changed 10 months ago by
I just uploaded a 20mb file ... nothing like that happened.
Let's just ignore this for now.
comment:12 Changed 5 months ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
comment:13 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2668
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:
And this is what I see:
But maybe somehow we're slowing down the
parse
thread instead and causing knock on effects?