Hi Marlon, Thank you for the message. I have started working on it. I hope to have the first draft ready by today.
Best regards, Siddharth Jain On Tue, Mar 22, 2016 at 1:25 PM, Pierce, Marlon <[email protected]> wrote: > Hi Siddharth, you need to capture this and put it into your GSOC proposal > application: > https://cwiki.apache.org/confluence/display/AIRAVATA/%5BGSoC+Proposal%5D+Apache+Airavata+Monitoring+Module > > > > From: Siddharth Jain <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Friday, March 18, 2016 at 9:06 PM > To: "[email protected]" <[email protected]> > Subject: Summary: Job Monitor Discussion > > Hello all, > > A discussion was held on 3/17/2016 regarding the implementation of a > separate demon service which reads job status from email and sends it out > to a message bus. For more background information about this topic, please > refer: https://issues.apache.org/jira/browse/AIRAVATA-1912. > > > > Following were the contributors to this discussion: > > · Marlon Pierce > > · Shameera Rathnayaka > > · Siddharth Jain > > · Suresh Marru > > > > Summary of discussion, > > > > *Approaches for receiving messages from job executor/HPC* > > 1.) Develop a custom IMAP/SMTP server, which can receive the messages > directly sent by the job executor and place the email on message bus > immediately. > > 2.) Setup a simple IMAP/SMTP server on our network, fetch the messages > from it and place the message on message bus. > > 3.) Use the third-party provider for email-service, connect to the > email service provider periodically, fetch the messages and put it on the > message bus. > > Approach 3 was finalized, because: > > · Maintenance of custom server or a separate server might be a > challenge in future > > · Third-party email service provider take care of the up-time and > any issues with regular email service > > > > *Approaches for putting messages on message bus* > > 1.) Fetch the unread messages from the mail-box and broadcast them as > it is to all the consumer queues bound to exchange. With minimum-invasive > technique have the messages handled with the existing code on the consumer > side. > > 2.) Fetch the unread messages, classify them and accordingly route the > messages to appropriate consumer queue. For classifying and determining > which message is sent to which consumer queue, existing logic from GFAC > module can be reused. > > 3.) Fetch the unread messages, send all of them to a common endpoint, > which in turn will classify them and accordingly route the messages to > appropriate consumer queues. > > Initially approach 1 will be implemented, but the goal is to implement > approach 3 ultimately. > > > > In addition to the above, in general the design has to be such that it can > accommodate consuming messages from different e-mail service providers and > any other protocol (for example UDP) > > > Please feel free to add anything that has been missed out. > > > Best regards, > Siddharth Jain >
