MailCore / mailcore2

MailCore 2 provide a simple and asynchronous API to work with e-mail protocols IMAP, POP and SMTP. The API has been redesigned from ground up.
Other
2.6k stars 624 forks source link

Maximum number of concurrent MCOOperation operations? #329

Closed abbood closed 11 years ago

abbood commented 11 years ago

Two things led me to ask this question:

  1. I was dispatching 20 MCOIMAPMessageRenderingOperation requests in a for loop (ie they were all dispatched almost simultaneously), but then not all of the callbacks would execute (ie for each request).. the thing is i wouldn't even get errors.. it's as if the request was never made (out of 20 requests the max complete callbacks were executed was around 16)
  2. I noticed in the sample code you guys would make 10 MCOIMAPMessageRenderingOperation requests at the same time.. anything more than that would be cancelled..

So what is the recommended max concurrent requests we should make.. and is this a bug or expected behavior that some callbacks are never executed?

abhinavguptas commented 11 years ago

You can tweak maximum connections when creating MCOImapSession, here is a code snippet

    MCOIMAPSession *imapSession = [[MCOIMAPSession alloc] init];
    .....
    imapSession.maximumConnections = 2;

Default is 3, but I keep a low value 2, as too many connections sometimes disappoint google servers and IMAP operations start failing.

abbood commented 11 years ago

@abhinavguptas i guess we are talking about two different things.. I'm assuming the imapSession maximumConnections refer to the actual simultaneous networking connections with the Imap server.. I'm referring here to the MailCore level, which ultimately uses the the several imap connection property but behinds the scenes..

dinhvh commented 11 years ago

All operations should be executed. Do you perform every calls from the main thread?

abbood commented 11 years ago

not necessarily.. are you saying that all the calls must be made from the main thread? how come?

dinhvh commented 11 years ago

mailcore2 will make them asynchronous for you.

abbood commented 11 years ago

even if i make them from the main thread.. there are still some operations that never execute their callback.. is there a way to debug this? suppose i have a reference to the MCOIMAPMessageRenderingOperation object that never completed.. what can i do to tell if there is something wrong? put a timeout and fire again?

abbood commented 11 years ago

@dinhviethoa I've been doing some debugging.. I created a table that lists the results of me sending requests and weather i got a response back or not.. see it here

here are some quick conclusions:

  1. i get a non response back in as little as 3 requests
  2. if i send the same amount of requests with the same messages, the same messages will always not be called back
  3. if i send different amount of requests with the same message list, some times the callbacks will execute and sometimes not (ie compare column 5 and 7).. btw the column headers indicate how many render requests where sent

i'm still trying to figure this out.

abbood commented 11 years ago

I think i figured it out.. basically the reason why things were acting all weird was because i had issued the idle command and didn't interrupt it before making the call!!

@dinhviethoa i did this with the old mailcore and it seemed to help me a lot.. so consider this scenario

  1. user signs in
  2. load the first batch of emails (and store into dbase)
  3. issue idle command
  4. do nothing until the user issues a command that requires communication with the imap server (ie load newer emails, mark an email as read etc)
  5. issue idle interrupt command
  6. perform command
  7. issue done command again

and so on.. does this make sense?

dinhvh commented 11 years ago

Sure, you should interrupt idle whenever you want to issue a command. Call -[MCOIMAPIdleOperation interruptIdle] Could you solve your issue?

dinhvh commented 11 years ago

I'm closing this issue. Feel free to re-open if you could not solve your issue.

abbood commented 11 years ago

yeah i'm good thanks! :)