[Platemail-developer] Re: whatzzup

[David S. <ds...@in...>]

Neil Campbell wrote:
> [ CC ing back onto the devel list]
> 
> On Wednesday 30 March 2005 03:28, you wrote:
> 
>>Neil Campbell wrote:
>>[snip]
>>
>>
>>>Not really - the issue of limiting connections is all understood, the
>>>question was more one of what to do when you find you've run out.  As I
>>>understood it, the better way was to open a connection for each mail box,
>>>so you don't have to keep SELECTing to move around, but your comments
>>>above seem to discourage this course of action.  If I do open a
>>>connection for each, the question is how to recover sensibly when I try
>>>to open the 5th one, if Courier has annoyingly stopped me from having
>>>more than 4.
>>
>>On the contrary, I quite strongly suggested that your should maintain
>>separate connections for each mailbox, precisely because SELECT is so
>>expensive.  You can move about with SELECT, but you shouldn't if it's
>>avoidable.
> 
> 
> Ahh, then I am confused.  I thought you'd suggested that Outlook's folly was 
> its use of separate connections?  Perhaps I've misunderstood.
> 

The stupid thing with outlook is that it chooses the worst of all 
possible worlds.  It opens a large number of connections, thus placing a 
high load on the server, but then doesn't actually use them concurrently 
when downloading mail.  That saves on bandwidth for modem users 
(probably a small audience given Outlook's commercial base).  The only 
advantage of doing this is that it allows the IMAP server to ping the 
client with new messages, though even that's fairly daft given that 
normally only one mailbox is likely to be updated (inbox).

> 
>>Assuming Courier at least picks up the phone it would probably issue a
>>NO response to the client's opening volly.  Actually that's rubbish,
>>since NO is a context sensitive response that has formally defined
>>meanings.  For example NO to a LOGIN means bad password, and NO to a
>>CAPABILITY (normally the first command run on establishing a connection)
>>is undefined.
> 
> 
>>It would seem the only valid thing Courier could do is not pick up the
>>phone, so to speak, but that's into questionable territory (it could be
>>valid for the client to take this for the server going down) --
>>certainly it's outside the scope of the RFC.  You could try to recover
>>using a SELECT in an existing connection, but then you're writing the
>>client wrt to a specific server and that's just not a good idea.
>>Certainly having the client code around this would fall into the
>>catagory of "heroic measures".
> 
> 
> Yes, this is the problem.  Courier refuses to accept any further connections 
> at all (the way I eventually worked out what was happening was to open a load 
> of telnet sessions, the 5th of which got refused).  Coding around it at the 
> client end would be pretty awkward for me, I think, as I don't have direct 
> control over how many connections Javamail will use.  The ultimate result, as 
> far as I can tell, is that if there are 5 folders, I will never be able to 
> see the 5th one as there will be a connection for each of the others.
> 
> 
>>What happens when you use telnet?  Or you use Thunderbird against this
>>mailhost?  Does thunderbird handle it?
> 
> 
> Telnet just has the connection refused.  The problem was documented on a 
> Courier mailing list when someone was trying to use Thunderbird against a 
> similarly configured Courier server, because Thunderbird defaults to using 5 
> concurrent connections.  I couldn't reproduce the problem with Thunderbird 
> though, so perhaps more recent ones handle it better.
> 
> 

Did you try a larger number of connections through thunderbird?  10, 20? 
  If you have the energy you could look through the thunderbird source 
and see if it still uses this number of connections.

It seems odd, since the client should be reactive I think.  Having a 
present number of connections is half-baked; too few and you're going to 
be unresponsive because you'll be redoing SELECTs, too many and you're 
going to hit the same problem and thus need to dynamically accept this.

Actually, what you could do is this:

conn = openNewConnection(host, port)
if(!conn) {
   // connection refused, take heroic measures
   reuseConn = pickExistingConnection(connections, FEWEST_MESSAGES)
   response = send(reuseConn, NOOP)
   if(response == "OK" || "NO" || "BAD") {
     // host is still there, not real failure
     conn = reuseConn;
   }
}

I'm wary of assuming a connection refusal means resource limiting; I 
can't think of other failure reasons that would cause it but it's a bit 
of generalisation.

Of course this is all probably hidden inside Javamail so it's probably 
not an option.  Do you actually have any flexibility about this at all?

Someone else has had this problem:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0204&L=javamail-interest&F=&S=&P=74

however, infuriatingly, I couldn't find any replies to it.

This does sound like it's a problem in Javamail's domain, so perhaps you 
  should ask a question on the javamail list?

>>>>Why on earth would anyone want a vi plugin?  Lot of crazies out there.
>>>
>>>You could put one into emacs to improve it, for a start.
>>
>>Emacs already has a vi emulation mode, which I imagine has been in there
>>since the days we first drew breath.  Bring on the pain.
> 
> 
> Finally, a feature worth using :-)

God, you're not one of _them_ are you?  I thought you spent all your 
time in the world of bimbo interfaces like eclipse.

Cheers,
dgs.
-- 
David Stocks
Institute of Perception, Action and Behaviour
School of Informatics, University of Edinburgh
+44 (0)131 651 3436