[Gnustep-nonfsf-bugs] [bug #55222] [Pantomime] Default timeout too small and makes connection impossible

[Yavor Doganov]

URL:
  <https://savannah.nongnu.org/bugs/?55222>

                 Summary: [Pantomime] Default timeout too small and makes
connection impossible
                 Project: GNUstep Non-FSF
            Submitted by: yavor
            Submitted on: Thu 13 Dec 2018 10:50:18 PM EET
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Pantomime & GNUMail 1.3.0

It appears that GNUMail is the only MUA in Debian that cannot connect reliably
to my IMAP server.  In most cases a dialog is displayed that the connection
timed out.  Sometimes (rarely) it connects but if I switch to another folder
it throws me out quickly.  The server is a Pentium III box with 256 MB RAM,
running Dovecot/2.2.27 on Debian GNU/Linux (stretch).  I am attempting
connections from another (more powerful) machine on the local network.  Worth
mentioning that my inbox has ~50K messages.

All other MUAs I've tried (Wanderlust, Gnus, Mutt, Evolution, Balsa, Claws
Mail, plus some more obscure ones) connect flawlessly even though I have to
wait for a few minutes.  Waiting is perfectly acceptable for me given the
above constraints, cutting me out is not.  Increasing the timeout as in the
attached patch fixes the problem, although GNUMail's UI freezes for long
periods when switching accounts and/or folders.  Often the UI freeze is
accompanied with heavy load (on the client machine) and lots of repeated
output on the console, like:

read_unsinged_int: EOF
2018-12-13 21:57:21.028 GNUMail[30636:30636] stringWithData - iconv fallback,
charset: cp1251

AFAIU this is when reading the cache and is not related to the connection and
the timeout issue. 

I'm not sure as I'm not familiar with the relevant RFCs, but I think that
there should be no timeout -- the client should continue attempting connection
until the server timeouts or until the user cancels the operation.  At least
this is the behavior with all the other MUAs I've tried.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 13 Dec 2018 10:50:18 PM EET  Name: increase-timeout.patch  Size:
499B   By: yavor

<http://savannah.nongnu.org/bugs/download.php?file_id=45647>

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?55222>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/