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 17:08:45 GMT
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 <dwhytock@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 <dcheckoway@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.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