[
https://issues.apache.org/jira/browse/OOZIE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699457#comment-14699457
]
Jaydeep Vishwakarma commented on OOZIE-2259:
--------------------------------------------
@puru, Thanks for reviewing the code. My Answers are inlined
{quote}
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..
{quote}
CallbackActionService in its current form is attempting to manage the
connection pool and other general parameters governing callback action.
OOZIE-2331 will further decouple the command queue from the action execution
(as some of the external services can be unresponsive, therefore interfering
with other core oozie functions). While WorklfowNotifications are used at the
end of the workflow, this JIRA is essentially adding callback as a primitive
action. With this it is possible for workflow authors to conditionally notify
(based on data or previous outcomes), and also use coord variables and workflow
variables in the arguments. These can potentially enable powerful applications.
{quote}
2 You need to evaluate param/args/url. Lot of user will use variable that need
substitution, like job status.
{quote}
Coord and workflow EL evaluator should be evaluating the params and args
already. JobStatus in this case is moot, as this is an action within a workflow
and is not executed at the beginning / end of an action/workflow.
{quote}
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)
{quote}
I have gone through EventHandlerService. The have specific set of
implementation. I cannot use it as it is. To reuse the code I will have to
create jms utility class, It will have common code, which will be used by
existing and new code. What do you say?
{quote}
4.
<xs:element name="method" type="xs:string" minOccurs="1"
maxOccurs="1"/>
<xs:element name="arg" type="callback:ARG" minOccurs="1"
maxOccurs="unbounded"/>
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.
{quote}
Yes, I agree with you, args should be optional. It is better to be explicit not
assume anything.
Let me know if you still have open question otherwise I will update the patch.
> 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)
