You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Alejandro Abdelnur (JIRA)" <ji...@apache.org> on 2013/03/13 21:02:13 UTC
[jira] [Commented] (OOZIE-1209) Event generation and handling for
workflow and coordinator
[ https://issues.apache.org/jira/browse/OOZIE-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601566#comment-13601566 ]
Alejandro Abdelnur commented on OOZIE-1209:
-------------------------------------------
from my email after the meetup:
* SLA and status events should be handled in the exact same way.
* All entities (BLD/COORD/WF * job/action) status changes should be capable of generating events
* A server configuration should allow disabling event generation for certain entity types (ie WF action)
* XCommands should publish events thru an EventService, the signature of the publishEvent() method should take the EntityManager instance in context of the XCommand (even if the current implementation that not use it). It would be the publishEvent() the one filtering out events for entities that are not to be published doing a NOP for them.
* The EventService should store the received events in a concurrent queue
* The EventService should register a runnable (running every 5 secs) in the SchedulerService that drains the queue, and creates a PublishEventsXCommand with all the drained events from the queue. Each batch of events would have a batch ID.
* The PublishEventsXCommand would use an pluggable EventPublisher for which there could be different implementations: DBWriter, JMSPublisher, EmailSender
* The PublishEventsXCommand, once the EventPublisher completes, it should ACK the EventService with the batch ID (to allow clean up of any persistency the EventService may have)
Note that with this proposal, we don't have to have a different threadpool and workers, we just leverage the CommandQueue (because it has throttling capabilities built in event commands will be capped). The CommandQueue size and threadpool has to be increased as needed (rather than duplicating all this logic).
The first impl of the EventService would be in-memory, later we can add either a DB or edit-log based one.
Furthermore, i would be inclined to move the SLAEvents servlet to the monitoring system.
> Event generation and handling for workflow and coordinator
> ----------------------------------------------------------
>
> Key: OOZIE-1209
> URL: https://issues.apache.org/jira/browse/OOZIE-1209
> Project: Oozie
> Issue Type: Sub-task
> Affects Versions: trunk
> Reporter: Mona Chitnis
> Assignee: Mona Chitnis
> Fix For: trunk
>
> Attachments: ConceptualDiagram.png, JobNotificationsClassDiagram-draft.jpg
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Oozie will publish notifications for the different types of jobs - workflows and coordinators, for monitoring purposes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira