camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Checkoway <dchecko...@gmail.com>
Subject Re: camel-mail - need to force a close/reconnect
Date Mon, 11 Jul 2011 15:30:41 GMT
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.ibsen@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 <dcheckoway@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=support@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message