On Mon, Jul 11, 2011 at 7:40 PM, Donald Whytock <dwhyt...@gmail.com> wrote: > I don't know if the POP3 and SMTP connections actually have anything > to do with each other, but if the connection locking up is an issue > I'd be inclined to check your flag and force a close after any place > you had to force an open. >
Yeah I only see this option currently on the consumer side (eg POP3/IMAP). If anyone would like to contribute I suggest maybe take a look at the camel-mina component. It has a disconnect option on the consumer side. Its simply named disconnect. Basically you add a new boolean on the endpoint with the option. (incl getter/setter). And then implement the logic in the mail consumer. There is some OnCompletion class/logic where you need to do the disconnect. And then add an unit test as well using this new option. You can read more about contributing here http://camel.apache.org/contributing.html > This may be something similar to what I see in my custom XMPP driver. > If I let it run long enough, it'll think the connection's open but no > IMs ever get through. I think that's the XMPP server discarding the > connection after a while without saying anything, so my driver's > sitting there listening to dead air. I'd wondered when I saw > camel-xmpp why it was recreating connections all the time. Now it > makes unfortunate sense. > > So it probably makes sense for mail connections going in either > direction. At least Gmail is sending you an error code. I could see > some mail server failing/not bothering to do so. > > Don > > On Mon, Jul 11, 2011 at 1:08 PM, Dan Checkoway <dchecko...@gmail.com> wrote: >> Ah, good point! I can't really see anybody wanting to recycle the >> connection in between messages. I think "single" essentially could mean >> what you originally posted about "close.after.poll=true", in that all >> messages picked up during that polling iteration would be processed, and >> delete flags would be updated. I'm just trying to avoid the "poll" >> terminology so that the verbiage will make sense when using SMTP as well as >> POP & IMAP -- unless it makes more sense for the connectionLifeCycle stuff >> only to apply to POP/IMAP but not SMTP (and be documented as such). >> >> What do you think? >> >> Dan >> >> On Mon, Jul 11, 2011 at 12:11 PM, Donald Whytock <dwhyt...@gmail.com> wrote: >> >>> 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 <dchecko...@gmail.com> >>> 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 <claus.ib...@gmail.com> >>> 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 <dchecko...@gmail.com> >>> 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:// >>> >> >>> imap.googlemail.com?username=supp...@mycompany.com&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: cib...@fusesource.com >>> >> Web: http://fusesource.com >>> >> Twitter: davsclaus, fusenews >>> >> Blog: http://davsclaus.blogspot.com/ >>> >> Author of Camel in Action: http://www.manning.com/ibsen/ >>> >> >>> > >>> >> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
