[
https://issues.apache.org/jira/browse/TRAFODION-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996155#comment-14996155
]
Hans Zeller commented on TRAFODION-1578:
----------------------------------------
The JVMs used for the Trafodion server serve mainly the Trafodion engine and
they need to execute multiple UDRs, since we don't know which UDRs will be
executed when we start the master executor:
1. User connecs. A JVM is reused or started for the Trafodion engine. We don't
know yet which UDRs the user will execute.
2. User calls SPJ a. At this time the JVM is already running.
3. User calls TMUDF b. Now we have to reuse the same JVM, if we don't use an
MXUDR server.
Are you saying that a user should specify at connect time how much heap size
they want to have in the JVM used in their connection? We could probably do a
limited set of options like that.
Often it's probably the creator of a UDR, not the user of it, who may want to
specify heap size and other parameters of the JVM used to execute a UDR. End
users may not want to have to worry about that. Having a separate JVM for the
UDRs should help avoid conflicts between Trafodion and UDRs.
Thanks for your patience and your explanations, I hope I understand your
proposal to use sandboxing with a SecurityManager and setting JVM parameters a
bit better and it makes more sense to me now. I still have questions, though,
see comment on the thread above, about the SecurityManager being too
restrictive for many UDRs.
> 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)
