[Kde-pim] Proposal for a solution for bug 77862

[Guy Maurel]

Hi!

On Sunday 16 May 2010 15:08:27 Thomas McGuire wrote:
> Hi,
> 
> On Sunday 16 May 2010 11:37:32 Guy Maurel wrote:
> > an anwser to the first part...
> > 
> > On Saturday 15 May 2010 18:56:46 Thomas McGuire wrote:
> > > Hi,
> > > 
> > > > NO! The slave is waiting... but it never got anything, because the
> > > > command bevor was not sent. It was not sent because the IP has
> > > > changed!
> > > 
> > > What I meant: As soon as the connection gets stuck (for example because
> > > the IP address did change), the slave stays in one of the
> > > waitForReadyRead()
> > 
> > or a loose of an IP-address...
> > 
> > > functions. That means the control flow never goes back to the dispatch
> > > loop, so even if KMail sends CMD_DISCONNECT, that command is never
> > > dispatched (or only dispatched after the default timeout, which is too
> > > long)
> > 
> > exact!
> > The problem is, we have not many time to do something. Even if the user
> > don't do anything, the kmail send at least after 60 seconds a
> > CMD_SPECIAL-command. This command do nothing but read the line and we have
> > to wait...
> 
> I see. That is probably the NOOP command ('N'), to keep the connection alive, 
> right?
this ist right...

> > > > > However, all the waitForReadyRead have a timeout parameter. Is that
> > > > > timeout to high? We might just be enable to lower it.
> > > > 
> > > > The timeout value is set by default. To change it, look at the well
> > > > written comment https://bugs.kde.org/show_bug.cgi?id=77862#c48
> > > 
> > > Ok, so the question is: Can we change the timeout manually in the IMAP
> > > KIO slave? Sounds that would solve the bug.
> > 
> > yes, we could!
> > But, what is the winn? We don't know what really happens (only timeout). We
> > don't get information about the line with this way.
> 
> Please try out if setting a timeout works. You can either use something else 
> than responseTimeout() whan calling waitForResponse(), or use setMetaData to 
> set a lower response timeout (with the "ResponseTimeout" key). The metadata is 
> internally used by SlaveBase::responseTimeout().
it doesn't work on this way because the
   void SlaveBase::setMetaData(const QString &key, const QString &value)
use the
    mOutgoingMetaData.insert(key, value);

and the 
   QString SlaveBase::metaData(const QString &key) const
use another variable
   if (mIncomingMetaData.contains(key))

or there is some method to copy the data??

> So setting a lower response timeout, maybe in combination with a 
> cMD_DISCONNECT, for example by using cancelMailCheck() in KMail.
> I have the feeling that a sensible timeout, like 30 seconds, instead of 600 
I tried it direct, as I changed the value of "ResponseTimeout" in the config-file:
   .kde/share/config/kioslaverc
to a very low value (10 seconds).

After waiting about 5-6 minutes I got what I needed. The kio_imap4 goes away.
I think, the time is too long. There must be some other "timeout".
I will look for them.

You had written, my solution was not portable. It was right.
Now I propose a portable solution, tested by some friends:
in the file kmkernel.cpp:

            // kill the kio_imap-process
#ifdef Q_OS_LINUX
            system( killCommand.toAscii());
#endif
#ifdef Q_OS_MACX
            system( killCommand.toAscii());
#endif
#ifdef Q_OS_WIN
#include <direct.h>
            HANDLE hProcess;
            hProcess = OpenProcess( PROCESS_TERMINATE, FALSE, pid );
            if (NULL== hProcess)
            {
              kDebug() << "no such process found";
            }
            TerminateProcess( hProcess, 0 );
            CloseHandle( hProcess );
#endif


-- 
guy
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/