You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by dcheckoway <dc...@gmail.com> on 2011/07/10 23:57:35 UTC
camel-mail - need to force a close/reconnect
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.
Re: camel-mail - need to force a close/reconnect
Posted by Donald Whytock <dw...@gmail.com>.
Seconded. Forced disconnects/reconnects might clear up a lockup
problem I've been having from time to time with my ISP's POP3 server,
and I'm polling every 15 seconds.
close.after.poll=true?
Don
On Mon, Jul 11, 2011 at 9:59 AM, Claus Ibsen <cl...@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 <dc...@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/
>
Re: camel-mail - need to force a close/reconnect
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jul 11, 2011 at 7:40 PM, Donald Whytock <dw...@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 <dc...@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 <dw...@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 <dc...@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 <cl...@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 <dc...@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/
>>> >>
>>> >
>>>
>>
>
--
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/
Re: camel-mail - need to force a close/reconnect
Posted by Donald Whytock <dw...@gmail.com>.
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.
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 <dc...@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 <dw...@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 <dc...@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 <cl...@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 <dc...@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/
>> >>
>> >
>>
>
Re: camel-mail - need to force a close/reconnect
Posted by Dan Checkoway <dc...@gmail.com>.
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 <dw...@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 <dc...@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 <cl...@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 <dc...@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/
> >>
> >
>
Re: camel-mail - need to force a close/reconnect
Posted by Donald Whytock <dw...@gmail.com>.
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 <dc...@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 <cl...@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 <dc...@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/
>>
>
Re: camel-mail - need to force a close/reconnect
Posted by Dan Checkoway <dc...@gmail.com>.
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 <cl...@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 <dc...@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/
>
Re: camel-mail - need to force a close/reconnect
Posted by Claus Ibsen <cl...@gmail.com>.
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 <dc...@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/