[pmmail-list] PMMail mystery process pegs CPU

[Dean Boulding]

I have experienced hangs when fetching mail which appear to be due to TCP/IP 
problems, not PMMail.  I often have wondered, in my ignorant state, if there 
couldn't be some way of hitting a CANCEL button and stopping the fetch, so 
that I could wait and retry.  Exiting PMMail and restarting works, but is 
inelegant.

Apologies if this has been discussed earlier.

Dean


On Mon, 03 Sep 2001 15:20:01 -0400 (EDT), quaero@myrealbox.com wrote:

>On Sun, 02 Sep 2001 17:26:23 -0300, PMMail OS/2 Support wrote:
>
>>On Fri, 31 Aug 2001 10:15:13 -0400 (EDT), quaero@myrealbox.com wrote:
>>
>>>I've tried all of the interim versions between 2.20.2010 through the
>>>latest 2.20.2370 but have always been struck by the same CPU bug.  The
>>>bug manifests as described below:
>>
>>Nick, I'm writing this to you on the list rather than directly
>>because I am unable to send to your email address. My mail server
>>refuses to send to your domain, it appears.
>
>I'm sorry - it would appear that your server has relegated this domain
>to the spammers' list.  I will look into an alternative provider. 
>Thanks for letting me know.
>
>>We are trying to find the source of this problem. Until we do,
>>naturally I recommend using the "official" release version,
>>v2.20.2010. The later releases are betas and if they are causing
>>problems on your system you should stop using them.
>
>Thank you, Trevor, for your prompt acknowledgment and reassurance that
>the bug is being investigated.  That this bug has been present for
>quite a while and yet has escaped scrutiny is somewhat unnerving - for
>a while I thought I had a problem with my Warp.  Only after I'd
>reinstalled Warp and found that the bug remained inspired me to write
>to the list.
>
>Interestingly, since my last post to the list, PMMail/2 has run for
>slightly more than a day before being killed - again, this shows that
>the "lockup" doesn't happen at a consistent rate but only when certain
>conditions are met.  However, it's certain that this is just a matter
>of "when" and that PMMail/2 may run for a few hours or a few days here.
>
>From the POV of a non-expert, may I suggest again that there could be a
>problem with PMMail/2 being stuck in a loop if some kind of a conflict
>is created by the auto-retrieval routine?  I would also like to suggest
>the following improvement:
>
>The max value of "Check For New Mail Every XXX Seconds" be changed to
>hours instead.  I find this particular feature of MR/2 Ice to be very
>sensible.  I should think that most users with multiple accounts do not
>need all of their accounts to be checked within every hour.  Having a
>max value of 24 hours (1 day) would give a most useful and reasonable
>margin for users to determine the time period between auto-retrieval. 
>In any case, if a user have 6 accounts and all check for mail within
>the hour, a bottleneck in bandwidth (especially if other online
>activities are running) would surely occur when mail volume gets heavy,
>which is not unusual given the the traffic of certain mailing lists.  I
>therefore urge the development team to consider amending this function
>of PMMail/2.
>
>I would value your thoughts on improving this feature.
>
>Thanks and regards,
>
>Nick
>
>- pmmail-list - The PMMail Discussion List ---------------------------
>To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com with the first 
>line of the message body being...
>UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com
>
>


Dean Boulding
Jakarta, Indonesia

- pmmail-list - The PMMail Discussion List ---------------------------
To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com with the first 
line of the message body being...
UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com