Draft Deployment

Draft Deployment is a feature to prioritize the UPDATE requests over the DEPLOY requests. This feature enables any UPDATE request associated with a DEPLOY request to be processed synchronously within a period of a declared time out value.

The existing architecture, which processes the UPDATEs and DEPLOYs using a single queue - AdMaxRequestQueue, does not handle the expected synchronous behaviour of any UPDATE request even though the queue, AdMaxRequestQueue, can be customized to prioritize the UPDATE requests at JBoss Server. This is because the AdMaxJMSListener which consumes the messages from the queue is not designed to handle any request, UPDATE or DEPLOY if it’s already processing a previous batch (based on the thread limit to process requests in parallel) of requests. This would eventually fail to respond any UPDATE request in the queue bound with a time-out value to expire and return back with an error to HIBU.

The proposed solution is to introduce independent queues, one to process only UPDATEs and the other to process only DEPLOYs. These queues would be implemented to be mutually exclusive, and would process an UPDATE request associated with a previous (successful) DEPLOY request in parallel with any other DEPLOY request.

This design change would reflect at MMS, which would be configured to:
1. Add the new queue, AdMaxUpdateRequestQueue.
2. Incorporate necessary changes to MMS code base to handle IMMSAccountStructure requests to switch between UPDATE and DEPLOY queues based on their type.

At the BidManager:
1. A new version of a listener would be implemented to focus only on the deployments (updates and deploy requests). This would streamline the current deployments from HIBU by processing them separately through another listener, and would exclude them from being part of AdMaxJMSListener, which would be changed to process only a. Refunds, b. External Campaigns, c. Updater Tasks, and d. Migrator Tasks.
2. The new listener - AdMaxDeploymentsListener would further split its responsibilities between a Receptor and a Responder for each queue, Update or Deploy.
3. It would also have a 'heart beat' feature to log its own activity at every declared time interval. The heart beat logs the status, the messages consumed so far by the Receptor, and the messages that were acknowledged by the Responder.
4. The life cycle of the new listener would be managed through cron, similar to the management of the old listener with start and stop scripts, executed at pre-defined time set by the cron.

For an overview of the sequence flow, please click on the following link.
http://kbase.ri.thesearchagency.com/index.php/DraftDeploymentDesignNotes