[
https://issues.apache.org/jira/browse/FALCON-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918092#comment-13918092
]
Shaik Idris Ali commented on FALCON-327:
----------------------------------------
Make sense to clean this up, also the workflow template has number of
arguments, which can be parameterised as well.
JMS seems ok so far. I would prefer to crate a Message Entity class (containing
args) and float this across different modules.
> Simplify message passing framework
> ----------------------------------
>
> Key: FALCON-327
> URL: https://issues.apache.org/jira/browse/FALCON-327
> Project: Falcon
> Issue Type: Improvement
> Components: messaging
> Affects Versions: 0.5
> Reporter: Venkatesh Seetharam
> Labels: messaging
>
> Issues with the current implementation:
> * hard to evolve the schema
> If I need to add one attribute, requires change in various places
> * Too many enum classes for the same variable
> Confuses the heck out of me. Some small, some caps
> * FalconPostProcessing gets args, parses the args into CLI and converts 'em
> back into args repeatedly
> Too much redundant processing
> * Timestamp should be long as opposed to a String - minor?
> I need to compare dates and thought long is easier instead of constructing
> expensive SimpleDateFormats
> * Hard dependency on JMS.
> Suggest the following:
> * Have the payload in a Map serialized as JSON
> - wonder how to pass this from oozie
> * Have one central Enum class for the keys in the payload
> * Each class now depends on this Enum and takes what it needs from the Map
> We also could rethink about the current messaging which falcon relies on (had
> started a discuss thread but did not get any response):
> * Continue to use JMS
> * Switch to FS Polling
> * Use both
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
