Maybe not every exchange for "single", since camel-mail will pick up all messages available at a poll. Like, if in your five seconds three messages come in, camel-mail currently would pick up all three. Or would you want that to be an option too...closing and re-opening the folder for each message?
Might want to propogate that down to the message resolution too, in processCommit. ATM, when a message is finished in its routing, camel-mail sets the DELETE flag on the message, which requires making sure the folder's open. It should probably check your option to see if it needs to close the folder there too. Don On Mon, Jul 11, 2011 at 11:30 AM, Dan Checkoway <[email protected]> wrote: > Thanks Claus. > > I think part of the problem is that the connection *is* open...i.e. the > server doesn't disconnect you, it just starts returning errors. > > I think the "disconnect after poll" option would be a valuable addition, but > for those of us who poll very frequently (i.e. my 5-sec poll period) might > extract more value from a "disconnect only if something goes wrong" option. > Because 90% of the time, everything works great. It's only when Google mail > decides it needs a lunch break that I experience problems. :-) > > So I'd vote for both options...here's what I'm proposing (and I'll formalize > it in JIRA if everybody agrees...and I'm a contributor so I can > theoretically work on this): > > *connectionLifeCycle* (default=infinite | single | exception | > duration) > "infinite" (default) - don't ever disconnect unless we find ourselves > disconnected from the server (i.e. as would be the case the first time the > route is run, or if the server drops our connection) > "single" - disconnect after every exchange > "exception" - behaves like "infinite," except it will disconnect whenever an > exception is caught > "duration" - allow connections to remain open for a configurable maximum > amount of time, as configured by the "connectionDuration" property > > *connectionDuration* (number of milliseconds) > amount of time a connection is allowed to remain open, when using > connectionLifeCycle=duration. Connections will be closed (and a new > connection reestablished) if they stay open beyond this amount of time. > > Something like that. Thoughts? Don, does that also work for you? > > Dan > > > On Mon, Jul 11, 2011 at 9:59 AM, Claus Ibsen <[email protected]> wrote: > >> Hi >> >> I think we got logic in place which asks if the connection/mailbox is >> opened before polling. But maybe we can improve the logic there? >> >> We may also consider adding a disconnect option, so you can explicit >> configure it to disconnect after the poll. So if you only poll the >> mailbox every 5th minute or so, it may be nice to disconnect after >> polling. >> >> If you got the time then maybe you can take a look where the code can >> be improved and help with a patch? You can read about contributing >> here (posting it here just in case other people wonder about how to >> contribute) >> http://camel.apache.org/contributing.html >> >> And you are welcome to create a JIRA tickets for this improvement. And >> possible also for the disconnect option if you think it could add >> value. >> >> >> On Sun, Jul 10, 2011 at 11:57 PM, dcheckoway <[email protected]> wrote: >> > I'm using camel-mail to consume mail message via imaps from Google mail. >> The >> > route & processor is set up basically like this: >> > >> > class MyProcessor implements Processor { >> > @Autowired >> > private CamelContext camelContext; >> > >> > @PostConstruct >> > public void initialize() throws Exception { >> > camelContext.addRoutes(new RouteBuilder() { >> > @Override >> > public void configure() { >> > >> > from("imaps:// >> [email protected]&password=...&delete=false&unseen=true&consumer.delay=5000&ignoreUnsupportedCharset=true >> ") >> > .process(MyProcessor.this); >> > } >> > }); >> > } >> > >> > public void process(Exchange exchange) throws Exception { >> > // ...this works fine >> > } >> > } >> > >> > Generally speaking, this works perfectly. But...on occasion, I see this >> > type of exception pop up: >> > >> > WARNING; 10-Jul-2011 21:16:38; tid:9; DefaultPollingConsumerPollStra >> > tegy rollback; Consumer >> > Consumer[imaps:// >> imap.googlemail.com?consumer.delay=5000&delete=false&ignoreUnsupportedCharset=true&password=...&unseen=true&username=support%40mycompany.com >> ] >> > could not poll endpoint: >> > imaps:// >> imap.googlemail.com?consumer.delay=5000&delete=false&ignoreUnsupportedCharset=true&password=...&unseen=true&username=support%40mycompany.com >> > caused by: A663 NO System error (Failure) >> > javax.mail.MessagingException: A742 NO System error (Failure); >> > nested exception is: >> > com.sun.mail.iap.CommandFailedException: A663 NO System error >> > (Failure) >> > at com.sun.mail.imap.IMAPFolder.open(IMAPFolder.java:1004) >> > at >> > org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:106) >> > at >> > >> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:97) >> > at >> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >> > at >> > >> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) >> > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) >> > at >> > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) >> > at >> > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) >> > at >> > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) >> > at >> > >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >> > at >> > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >> > at java.lang.Thread.run(Thread.java:662) >> > Caused by: com.sun.mail.iap.CommandFailedException: A742 NO System error >> > (Failure) >> > at com.sun.mail.iap.Protocol.handleResult(Protocol.java:341) >> > at >> > com.sun.mail.imap.protocol.IMAPProtocol.select(IMAPProtocol.java:655) >> > at com.sun.mail.imap.IMAPFolder.open(IMAPFolder.java:928) >> > ... 11 more >> > >> > At times, this will keep happening iteration after iteration...but the >> > "A742" code (whatever that is) increments itself...by two at a time, it >> > seems. i.e. the next time it happens it'll be A744, then A746, and so >> on. >> > I'm not 100% sure what's happening, but Google mail may be rate limiting >> me >> > or something. Any insight into that particular error would be much >> > appreciated. >> > >> > But what I'm really after is...everything I've read on the web suggests >> that >> > once you see that error from Google, it's best to close the connection >> and >> > reconnect. That, as far as I know, is something I can't easily do using >> > camel-mail. >> > >> > I suspect you'll suggest writing an exception handler that stops the >> route, >> > then restarts the route. But is there anything camel-mail itself can do >> in >> > a more self-maintaining way, short of that sort of a route stop/start? >> i.e. >> > a "reconnectOnException=true|false" property? Or even a >> > "reconnectAfterIterations=nnn" or "maxConnectionLifeSeconds=nnn" property >> > that would force the connection to be closed and reestablished after some >> > number of iterations or seconds. >> > >> > What do you think? >> > >> > >> > ----- >> > Dan Checkoway >> > dcheckoway -at- gmail >> > -- >> > View this message in context: >> http://camel.465427.n5.nabble.com/camel-mail-need-to-force-a-close-reconnect-tp4572997p4572997.html >> > Sent from the Camel - Users mailing list archive at Nabble.com. >> > >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: [email protected] >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> >
