[jira] [Comment Edited] (OOZIE-2259) Create a callback action

["Purshotam Shah (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OOZIE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694180#comment-14694180 ] 

Purshotam Shah edited comment on OOZIE-2259 at 8/12/15 9:15 PM:
----------------------------------------------------------------

Few comments
1. CallBackActionService logic looks, with limit thread. I think that this might impact SLA.
Why not use use command queue. We already have WorkflowNotificationXCommand which take care of notifying to external web-services.
It take care of proxy setting, retry logic etc..

2 You need to evaluate param/args/url. Lot of user will use variable that need substitution, like job status.

3. For jms callback, can you check if you can use EventHandlerService (which has it own queue"oozie.service.EventHandlerService.event.queue"). 
In that case we can avoid lot of duplicate codes. 
We have even plan to persisting jms queue incase of restart (https://issues.apache.org/jira/browse/OOZIE-1293)

4.
{code}
            <xs:element name="method" type="xs:string" minOccurs="1" maxOccurs="1"/>
            <xs:element name="arg" type="callback:ARG" minOccurs="1" maxOccurs="unbounded"/>
{code}
Can method and args be optional? I guess most of people will try to use http get call to notify there webservice about job progress. Which doesn't need any arg.
http get should be default method.



was (Author: puru):
Few comments
# CallBackActionService logic looks, with limit thread. I think that this might impact SLA.
Why not use use command queue. We already have WorkflowNotificationXCommand which take care of notifying to external web-services.
It take care of proxy setting, retry logic etc..

# You need to evaluate param/args/url. Lot of user will use variable that need substitution, like job status.

# For jms callback, can you check if you can use EventHandlerService (which has it own queue"oozie.service.EventHandlerService.event.queue"). 
In that case we can avoid lot of duplicate codes. 
We have even plan to persisting jms queue incase of restart (https://issues.apache.org/jira/browse/OOZIE-1293)

#
{code}
            <xs:element name="method" type="xs:string" minOccurs="1" maxOccurs="1"/>
            <xs:element name="arg" type="callback:ARG" minOccurs="1" maxOccurs="unbounded"/>
{code}
Can method and args be optional? I guess most of people will try to use http get call to notify there webservice about job progress. Which doesn't need any arg.
http get should be default method.


> Create a callback action 
> -------------------------
>
>                 Key: OOZIE-2259
>                 URL: https://issues.apache.org/jira/browse/OOZIE-2259
>             Project: Oozie
>          Issue Type: New Feature
>          Components: action
>            Reporter: Jaydeep Vishwakarma
>            Assignee: Jaydeep Vishwakarma
>         Attachments: OOZIE-2259-v1.patch, OOZIE-2259-v3.patch, OOZIE-2259-v4.patch, OOZIE-2259-v5.patch
>
>
> Need an action to send notification to external server by oozie. We should be able to do multiple types of callback, Currently I know jms and http call. It should suppose to have capability to call diffrent types of methods along with n number of arguments. 
> The sample workflow with callback action 
> {code:xml}
> <workflow-app name="[WF-DEF-NAME]" xmlns="uri:oozie:workflow:0.3">
> ...
> <action name="[NODE-NAME]">
> <callback>
> 	<host>[HOST]</host>
> 	<method>[METHOD]</command>
> 	<arg>
> 		<key>[KEY]</key><value>[VALUE]</value>
> 	<arg>
>             ...
> </action>
> ...
> </callback>
> ...
> </workflow-app>
> {code}
> HOST : by the host system can figure out if it is http or jms callback action. System will send the notification to that host.
> METHOD : it can be POST/GET/QUEUE/TOPIC



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)