falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Balu Vellanki (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FALCON-327) Simplify message passing framework
Date Thu, 07 Aug 2014 17:44:12 GMT

    [ https://issues.apache.org/jira/browse/FALCON-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14089510#comment-14089510

Balu Vellanki commented on FALCON-327:

I cloned falcon from https://github.com/apache/incubator-falcon and then started reviewing
patchs for https://issues.apache.org/jira/browse/FALCON-327. I applied patch for JIRA 484,
485, 486, 487, 488, 492. 

- Looking at comments, 484 and 485 seem like they have been reviewed.
- The merge does not happen in a clean manner for OozieCoordinatorBuilder.java. 
- Cant find class EntityInstanceMessage at line 686,687 in file OozieProcessWorkflowBuilderTest
it has been removed from source in patch FALCON-485-v3.patch and has not been added back.

I did go through the code changes even though I could not build the cloned source after applying
the patch. I do not see anything specific that needs fixing. Looking at code helped me understand
the message passing framework.

> 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
>            Assignee: 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
> * 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

View raw message