Closed Bug 269609 Opened 20 years ago Closed 20 years ago

multiple mail servers should be accessed in parallel

Categories

(MailNews Core :: Networking, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 267361

People

(Reporter: eyalroz1, Assigned: sspitzer)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041104
Build Identifier: 

When several mail servers are using global inbox, and the user presses 'get
messages', the get operations are performed in sequence: the first server is
contacted, messages are d/led, then the second server is contacted etc. This
should happen in parallel, not in sequence, to reduce the delay.

I believe this also happens if the accounts use different folders and the user
selects 'get all new messages' from the get messages button dropdown, but I'm
not sure.

I'm thinking the parallelness could either mean multiple threads (difficult; I
know that many parts of the code are not thread-safe) or a single thread which
does select() or poll(), and cycles through the servers reading new blocks of
data, to avoid timeouts with any of them.

Reproducible: Always
Steps to Reproduce:
Currently, the download operation grabs a lock on the folder when it starts, and
releases it when the whole download is finished. If we tried to make it more
modular and grab the lock around each message, the problem is that we need to
write a complete message into the inbox before we can start writing the next
message, obviously. And we'd need to deal with a failure to get the lock in the
middle of a pop3 download, which would be rather painful...
Whiteboard: DUPEME
Oh, but we could do something else. We could parallelize even further: separate
the download from the addition into the folder. The downloads begin in parallel,
to some temporary buffer (in memory or on disk) and as the download of message
completes, a lock is obtained on the folder (while downloading continues to the
temp buffer), the message is added to the folder from the temp buffer, and the
lock is released.
sure, but that would still involve reworking the download code in somewhat
painful ways, especially the way the db is created, and the way filters are
applied - I'm not saying we shouldn't do it, but it's not trivial...
Maybe there should be a 'fixing this is hard' keyword, then... :-)

Plus, if fixing this means reworking the filter application code, maybe it's
time to also do this:

https://bugzilla.mozilla.org/show_bug.cgi?id=257979#c6

(wink wink, nudge nudge).
similiar is TB Bug 267361

*** This bug has been marked as a duplicate of 267361 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
Cleanup *dupeme* whiteboard flag from bugs that are marked as Resolved Duplicate!
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.