Project

General

Profile

Feature #8544

Move spawner code to JNI

Added by Galya B about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD

History

#1 Updated by Galya B about 1 month ago

The spawner executable exists as a separate deployment with the sole purpose of providing admin rights only to a strictly limited part of FWD functionality. OS user authentication requires native code, so naturally the spawner has been written in C. Its maintenance and development thus requires certain expertise. On execution from the Java server the separate native process poses challenges for the inter-process communication, including argument processing, logging and debugging.

At the same time with distributed infrastructure (deployment with brokers) there is another intermediate process (the broker client) used solely for the purpose of being an interface for the spawner installed on the remote machine. This can be deduced by reviewing the interface BrokerClientServices.

An alternative approach would be to move the spawner code to JNI in a broker client with admin rights.
The pros are:
  • validations, logging and overall the spawning process will be driven by Java code;
  • less fragile native code (due to the previous point), actual interface with the native code;
  • easier maintenance and debugging by more developers.
The cons are:
  • This new type of client replacing the broker client and the spawner executable will need to be trimmed down from FWD functionality as much as possible. A new deployment with its own limited classpath will have to be prepared. Ideally the process will only share rpc and authentication mechanics with the core FWD code, so its development may present unexpected challenges.

Also available in: Atom PDF