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

Venkat Muthuswamy commented on TRAFODION-1578:
----------------------------------------------

1. I suggest that we keep the interface generic not just for JARs. It should 
allow to deploy UDF files too.

2. Storing SPJs in user specific directories can be a problem. You cannot share 
it with other users. Often times, a SPJ developer or admin will deploy the SPJs 
and other users/application will call the SPJ.  So limiting access to the user 
who deployed it will not work. The security concerns can be addressed using the 
SQL privileges on the Library object which encapsulates the jar or udf file. We 
had a similar design in the pre-apache product and we had to revert to using a 
single directory or store because it became too cumbersome to manage between 
roles and users and public.

3. We should keep in mind the ODBC buffer limits and the size of the jar. The 
client (TrafCI) here will have to send the jar contents in chunks and the SPJ 
has to assemble them into the single LOB or HDFS file.

4. I have a security concern about the additional commands being proposed: 
"list all JVMs in user; kill one of them that no long in use; Restart JVMs with 
latest JARs and so on". How will you enforce security here. Consider leveraging 
and extending the Trafodion REST server for these kind of manageability 
functions. These features do not seem to belong in TrafCI.

5. Make sure the proposed interfaces prevent any Denial of Service attacks and 
adds necessary checks to limit size of the file etc..

> Proposal for SPJ management
> ---------------------------
>
>                 Key: TRAFODION-1578
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-1578
>             Project: Apache Trafodion
>          Issue Type: Improvement
>          Components: connectivity-dcs
>            Reporter: Kevin Xu
>
> JAR upload process:
> 1. Initialize JAR upload procedure by default
> 2. JAR upload by Trafci(add library LIB_NAME JAR_LOCAL_PATH). Upload and 
> create library will be done here. And also, you can only upload the JARs by 
> UPLOAD command on Trafci that it will not create a lib.
>    Tips: Before put the JAR into HDFS check MD5 first, if the file exists, 
> only add a record in metadata table in case users upload the same JAR many 
> times on platform.
> 3. On server-side, the JAR will store in HDFS. At the same time JAR 
> metadata(path in HDFS, MD5 of the file, and others) stores in store procedure 
> metadata table.
> 4. create procedure is the same as now.
> JAR perform process:
> 1. Send a CALL by Trafci/JDBC/ODBC/ADO.NET.
> 2. DCSMaster assign a DCSServer for the CALL.
> 3. DCSServer start a JVM for the user. User can modify JVM options, program 
> properties and JAVA classpath. At the same time, a monitor class will be 
> starting in the JVM witch will register a node on Zookeeper for this JVM as 
> well as metadata info( process id, server info and so on) and the node will 
> be removed while JVM exiting. It allows customer to specify JVM idle time in 
> case of some realtime senarior like Kafka consumer. 
> 4. Useful commands on Trafci: list all JVMs in user; kill one of them that no 
> long in use; Restart JVMs with latest JARs and so on.



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

Reply via email to