[Users] claws waits forever, freezes grafik on slower networks
clawsmail at pasdzierny.de
clawsmail at pasdzierny.de
Tue Feb 4 23:24:37 UTC 2025
dear Paul,
the log tells me it first tried at 23:15h on the gmx account.
at 23:18 the timeout message was printed.
the debug messages on STDERR/STDOUT unfortunately do not show a
timestamp :|)
At 23:18h it then tries the other server.
Last debug statement comes at 23:18:26.
the log window was opened from the previous try at 23:15h plus ca 3mins
timeout. now the app was not reactive anymore, just the open log window.
I cannot reproduce that behaviour in the office by simply turning off
the network. It behaves that way in trains etc. with weak (small
bandwidth) but generally working networks where e.g. the browser works.
I will try to get more concise log files, screenshots and behavioural
descriptions next time it happens.
regards, Martin.
On Tue, 4 Feb 2025 22:26:02 -0000
Paul <paul at claws-mail.org> wrote:
> On Tue, 4 Feb 2025 20:30:44 +0100
> clawsmail at pasdzierny.de wrote:
>
> > You are probably right. At least when I test it here i my office by
> > simply turning *off* the network the "Get Mail" button comes back
> > :)
> >
> > The situation is actually different on the train with varying
> > network all the time. The log file I sent You was created using
> > such a dynamic and generally weak network.
> >
> > I know from other software development/test situations that real
> > life networks are almost impossible to be simulated, the present all
> > kinds of delays inside the connetion ping pongs etc.
> >
> > Any network api call needs to be implemented non blocking, but i
> > guess you know that quite well ...
> >
> > you see from the log that the pop3 connection logs stops at a
> > specific interaction.
> > - what are the exact parameters of the previous message sent ?
> > - what exact status was it returned with ?
> > - what is the next system call or network api call ?
> > - and what status is it returned with ?
> > - might there be a reason STERR is blocked (temporarily) so that the
> > real debug message is not seen ?
> > - ... etc, you know the drill ;)
> >
> > And why is the GUI system dependent on that at all ?
> >
> > In my own projects I only debug realtime stuff by writing
> > unformatted binary data into circular shared memory buffers and read
> > them by another process. that appears to be a quite safe way to
> > really see whats going on ...
> >
> > greetings, Martin.
>
>
> You replied with a lot of words but didn't actually answer the
> question:
>
> In your screenshot of the log window and debug output, you show that
> dialogue being displayed for the the first connection (gmx), but not
> for the 2nd server. Do you not see a similar dialogue again, for the
> connection to 2nd server? You should.
>
> with regards
>
> Paul
More information about the Users
mailing list