The first question is whether we need to move recipe to server side or not, no matter which webpage we use (JSP or HTML5). As far as I understand, it is best to keep it on client side. Yes? If we choose HTML5, one way is to use JAVA applet in HTML5.
On 3/12/15, 9:31 AM, "Siva Thumma" <[email protected]> wrote: >+1. > >> On 12-Mar-2015, at 8:58 pm, Arpit Gupta <[email protected]> wrote: >> >> Are people not moving away from JSP's? I know all UI's in Hadoop moved >>away from JSP recently to html 5 >>https://issues.apache.org/jira/browse/HADOOP-10563 >> >> -- >> Arpit Gupta >> Hortonworks Inc. >> http://hortonworks.com/ >> >> On Mar 12, 2015, at 8:13 AM, Ying Zheng >><[email protected]<mailto:[email protected]>> wrote: >> >> Sort of, but not a completely new server. We don't need to write a new >>server. As long as we have Tomcat installed and running, we just need to >>copy front end JSP files to a folder under tomcat. In this way, we >>separate front end and back end. >> >> On Mar 12, 2015 7:39 AM, Srikanth Sundarrajan >><[email protected]<mailto:[email protected]>> wrote: >> Are you suggesting a completely new server for cooking recipe? >> >> Sent from my iPhone >> >> On 12-Mar-2015, at 8:03 pm, "Ying Zheng" >><[email protected]<mailto:[email protected]>> wrote: >> >> Perhaps I don't understand your question. JSP is one way to generate >>webpages. Why does it need to run in Falcon server? It can be isolated >>from Falcon server, and developed and run in Apache Tomcat server. >> >> Thanks, >> Ying >> >> On Mar 12, 2015 12:53 AM, Srikanth Sundarrajan >><[email protected]<mailto:[email protected]>> wrote: >> Hi Ying, >> JSP would still run in Falcon server JVM, so not sure if that is any >>different from implementing this natively inside the falcon server. >> >> Regards >> Srikanth Sundarrajan >> >> ---------------------------------------- >> Subject: Re: [DISCUSS]: Moving recipe cooking to server >> From: [email protected]<mailto:[email protected]> >> To: [email protected]<mailto:[email protected]> >> Date: Thu, 12 Mar 2015 07:43:28 +0000 >> >> Hi Sowmya, Srikanth, Venkatesh and Venkat, >> >> As far as I understand, recipe helps the user generate the process >>entity >> xml and it looks best to keep it a client side logic, as what you did >> before. The current question is how to run recipe logic on DR UI. To >>avoid >> repeating all the recipe logic in JS, one choice you can consider is >>JSP. >> JSP can be supported by Apache Tomcat server. If you package the recipe >> code into JAR, it can be reused in JSP. JS and CSS can also be included >>in >> the JSP page. >> >> Cheers, >> Ying >> >> >> On 3/11/15, 11:51 PM, "Srikanth Sundarrajan" >><[email protected]<mailto:[email protected]>> wrote: >> >> Thanks Sowmya for capturing the discussion and also initiating this >> conversation to drive consensus around the design. I am inclined towards >> Approach 2. >> >> Regards >> Srikanth Sundarrajan >> >> ---------------------------------------- >> Subject: [DISCUSS]: Moving recipe cooking to server >> From: [email protected]<mailto:[email protected]> >> To: [email protected]<mailto:[email protected]> >> Date: Thu, 12 Mar 2015 05:17:16 +0000 >> >> I had a discussion with Srikanth, Venkatesh and Venkat regarding making >> recipe processing server side concept. I am sending out the summary of >> the meeting and opening it for further discussion. >> >> Today Recipe cooking is a client side logic. Recipe also supports >> extensions i.e. user can cook his/her own custom recipes. >> Decision to make it client side logic was for the following reasons >> >> * Keep it isolated from falcon server >> >> * As custom recipe cooking is supported, user recipes can introduce >> security vulnerabilities and also can bring down the falcon server >> >> Today, falcon provides HDFS DR recipe out of the box. There is a plan >> to add UI support for DR in Falcon. >> Rest API support cannot be added for recipe as it is client side >> processing. >> If the UI is pure java script[JS] then all the recipe cooking logic has >> to be repeated in JS. This is not a feasible solution - if more recipes >> are added say DR for hive, hbase and others, UI won't be extensible. >> >> For the above mentioned reasons Recipe should me made a server side >> logic. >> Provided recipes [recipes provided out of the box] can run as Falcon >> process. Recipe cooking will be done in a new process if its custom >> recipe [user code]. >> >> For cooking of custom recipes, design proposed should consider handling >> security implications, handling the issues where the custom user code >> can bring down the Falcon server (trapping System.exit), handling class >> path isolation. >> Also it shouldn't in anyway destabilize the Falcon system. >> >> There are couple of approaches which was discussed >> >> Approach 1: >> Custom Recipe cooking can be carried out separately in another Oozie >> WF, this will ensure isolation. Oozie already has the ability to >> schedule jobs as a user and handles all the security aspects of it. >> >> Pros: >> - Provides isolation >> - Piggyback on Oozie as it already provides the required functionality >> >> Cons: >> - As recipe processing is done in different WF, from operations point >> of view user cannot figure out recipe processing status and thus adds to >> the operational pain. >> >> Approach 2: >> Custom recipe cooking is done on the server side in a separate >> independent process than Falcon process I.e. It runs in a different JVM. >> Throttling should be added for how many recipe cooking processes can be >> launched keeping in mind the machine configuration. >> >> Pros: >> - Provides isolation as recipe cooking is done in a independent process >> >> Cons: >> - Performance overhead as new process is launched for custom recipe >> cooking >> - Adds more complexity to the system >> >> Thoughts? >> >> Thanks, >> Sowmya >> >>
