That's where I get very confused.  It says the default action is "error".
>From the text you quoted, that would imply that the default reaction to an
exception in the mailet would mean it would not requeue it.  But that WAS my
configuration, and it continually requeued it.  So I'm confused.  

Just for completeness of my understanding of this, what would the
configuration be if I DID want to requeue and start over. 

I don't know the details of the all the flows.  All I know is when I throw
an exception, I'm in an infinite loop by default.  Coding it to the default
of "error" doesn't seem like it's going to make any difference.  

It appears to me that either the default is not "error" or the documentation
of "error" that says it won't re-queue is in error.

Maybe I'm at the wrong level of discussion.  When the exception occurs, my
mailet exits.  The mailet is the last thing in the processor.  So 'ending'
the processor and 'continuing' the processor when this is the last step
would basically be the same thing, right?  It still comes back to whether or
not the message gets left on the spool and starts over.

Can you clarify this for me?

Thanks.

Jerry

-----Original Message-----
From: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 22, 2006 3:01 AM
To: James Users List
Subject: Re: Mail List Mailet Infinite Loop on db failure

onMailetException="error" sends the message to the error processor, which
(in the default config.xml) stores the message in <repositoryPath>
file://var/mail/error/</repositoryPath> and ghosts it (will stop). This is
what you may want.

If you code onMailetException="ignore" the message will ignore the exception
and continue in the current processor.

Vincenzo



JWM wrote:

>Thanks for the wiki info.  I read over it.  It doesn't completely explain
>what the default [onMailetException="error"] does.  But I can assume that
>the philosophy of "error" is to just re-queue the message and start over.
>Is that correct?  At least that is what it appears to be doing for me now.
>If so, I assume that if I say "ignore", the email message will simply
>terminate and NOT be re-queued, which is what I want. Have I got it
correct?
>
>I don't have any stack traces.  In the mailet log, it is happily processing
>through the mail list, then there is an exception saying it can't get
>connection to mySQL.  Then the maillist starts over just like it was a
brand
>new note.  It starts sending to the list again and the same exception
>occurs, etc. etc. until I delete the message from the spool.  The
connection
>problem with mySQL is an issue.  But the biggest concern is to tame this
>infinite loop that results from it or any other possible error.  Once
that's
>done, I'll figure out the mySQL connection problem.
>
>Thanks.
>
>Jerry
>
>-----Original Message-----
>From: Stefano Bagnara [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, March 21, 2006 4:33 AM
>To: James Users List
>Subject: Re: Mail List Mailet Infinite Loop on db failure
>
>JWM wrote:
>  
>
>>What do I need to do either in the mailet code or in the configuration
>>    
>>
>file
>  
>
>>to ensure any failure (with the db or anything else) on this mailet forces
>>    
>>
>a
>  
>
>>complete termination of this mail message and guaranteed no restart?
>>    
>>
>
>Have you any stacktrace of the problem?
>
>Depending on the problem this could help:
>http://wiki.apache.org/james/HandlingExceptions
>
>Stefano
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to