When received, the mail is kind-of "queued" in the mailet container [1].
We also have specific queues for the RemoteDelivery case, but in that
case, the dequeing is not managed by the mailet lifecycle.

Wherever you plan to have an external queuing system (JMS or whatever),
you need to take care on the communication between the mailet (a custom
one you will have to write) and the system you are calling. Timeout and
worth, infinite socket, can put your james server down.

When you say, "if I have an email in Inbox", you must realize that at
that time, the whole processing by the mailet container is already done.
You just have to configure so that your mailet in called before the mail
is delivered locally.

[1] http://james.apache.org/server/3/feature-mailetcontainer.html

On 08/04/2014 12:05 PM, Mahesh Sivarama Pillai wrote:
> Thanks Eric. A queuing system definitely makes sense here. I am trying
> to understand bit more on the design considerations while using James.
> Spool itself is a queue. If I have enough storage space and the SLA
> expectation for processing the email is within a reasonable amount of
> time say 5 seconds, Can I have this functionality as part of the main
> processor itself ? Means, if I have an email in Inbox, that means the
> cloud service have been called for that email. Otherwise I can see the
> email in the error folder or something like that.. What are your thoughts ?
> 
> Thanks
> Mahesh
> 
> 
> On Sun, Aug 3, 2014 at 1:43 PM, Eric Charles <e...@apache.org
> <mailto:e...@apache.org>> wrote:
> 
>     You have to implement your self the queing system, a bit like the
>     RemoteDelivery mailet.
> 
>     Having an abstraction for this feature would be indeed cool.
> 
>     On 07/25/2014 04:59 PM, Mahesh Sivarama Pillai wrote:
>     > Thanks Ozgur. We are planning to have a it forwarded it to an ESB
>     which has
>     > the queuing and other features in the next phase. If I implement the
>     > feature in the mailtet without a Queue, the messages will be
>     available in
>     > the spool and will move to the inbox only when the webservice call is
>     > completed. Yes, Spool directory will get piled up depending on the
>     > performance of the Mailet and the number of spool threads
>     configured. Do
>     > you see any other issue in this short term approach.
>     >
>     > If you don't mind, can you please share how you configured James
>     to handle
>     > the errors/timeout etc in the WebService call ? Like moving to the
>     error
>     > directory and reprocessing later etc ? What are the James related
>     design
>     > considerations and best practices that you followed ?
>     >
>     > Thanks
>     > Mahesh
>     >
>     >
>     > On Fri, Jul 25, 2014 at 1:09 AM, Özgür EROĞLU
>     <oeroglu.c...@gmail.com <mailto:oeroglu.c...@gmail.com>>
>     > wrote:
>     >
>     >> On 07/13/2014 11:16 PM, Mahesh Sivarama Pillai wrote:
>     >> Hi,
>     >>
>     >> It would be better to put mail  or its reference (if you use a db or
>     >> filesystem to save messages temporarily) to a message queue and
>     then at the
>     >> service side implement a consumer to get messages for processing.
>     This way
>     >> you will eliminate the constraint to have 7/24 alive service. We
>     did smt.
>     >> similar in a project by writing a mailet to forward messages to web
>     >> services.
>     >>
>     >> Ozgur Eroglu
>     >>
>     >>
>     >>  Hi,
>     >>>
>     >>>   I am planning to use James Server for a Mail-to-Cloud use
>     case. Here is
>     >>> what I am planning to do.
>     >>>
>     >>>   1. Receive email redirected from the Corporate Email Server to
>     James
>     >>> (100K
>     >>> emails per day)
>     >>>   2. Do some validation/filter etc on the received email
>     >>>   3. Call the cloud web service with the email content and
>     simultaneously,
>     >>> upload the attachment(max size may be ~15 mb) in the mail to
>     another file
>     >>> storage cloud.
>     >>>
>     >>>   I am planning to implement a Mailet for implementing this use
>     case. My
>     >>> questions are;
>     >>>
>     >>>   1. What are all the design considerations that I should be
>     looking at
>     >>> while implementing this ?
>     >>>   2. I may want to retry the emails which failed during the cloud
>     >>> interaction. How can I do this ?
>     >>>   3. Is anyone implemented a similar use case and can you please
>     share
>     >>> your
>     >>> experiences ?
>     >>>
>     >>>   I want to use 2.3.2 because it is the stable version as 3.0 is
>     still in
>     >>> Beta and I cannot convince my company to use a software which is
>     in beta
>     >>> version.
>     >>>
>     >>>
>     >>>   Highly appreciate your thoughts and inputs on these.
>     >>>
>     >>>   Thanks
>     >>>   Mahesh
>     >>>
>     >>>
>     >>
>     >> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
>     <mailto:server-user-unsubscr...@james.apache.org>
>     >> For additional commands, e-mail:
>     server-user-h...@james.apache.org
>     <mailto:server-user-h...@james.apache.org>
>     >>
>     >>
>     >
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org

Reply via email to