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
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
Yes Eric.. thats exactly I was planning to do; having the external service
interaction before the mail is locally delivered. Spool will act as Queue
in this case and Mailet will do the business logic and external service
call etc.. and once the processing is done, the mail will be available in
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
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
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
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
