CODEWITHSUNDEEP
javashellruntime.execprocessbuilder
user390517
user390517

Reputation:

Implementation design regarding ProcessBuilder

I would like to do the following:

Write a file to disk. Then run a shell command. The shell command reads/manipulates this file sends a request over the network writes the response to another file and returns and exit value.

In order to run the shell command i have read about ProcessBuilder and Runtime.exec().

How exactly would one implement the above functionality. The webapp (struts) responsible will be hosted in Jbossas 7.1.

Do i need some like JCA since i.o and EJBs are not recommended (although only one server will be used in my case). Can i simply use a POJO (Struts action) i am not sure how to deal with multiple threads, although Struts actions are "thread safe".

Thanks in advance,

If i were to use a pool of threads in order to handle multiple requests in parallel would this be a reason to use a JCA.

Upvotes: 2

Views: 586

Answers (2)

kaos
kaos

Reputation: 1608

You should take a look at the Apache Camel framework: http: //camel.apache.org/index.html. It is a very useful and easy to learn/use integration framework. It has all the components that you need:

I used it in a Java EE environment in one project (JBoss AS 7.1 + JSF2/Richfaces) and like it very much.

Upvotes: 2

Yves Martin
Yves Martin

Reputation: 10361

I confirm there is no need to bother with JCA and EJB as far as two-phase-commit transaction propagation in such a context does not sound relevant and definitely hard to implement.

I recommend you to create request and response (first empty) files in Java thanks to File.createTempFile to avoid collision on file names between threads and invoke your shell script with ProcessBuilder.

Technically speaking, the most difficult point for such an implementation is error handling to free resources: temporary files, stuck processes:

  • use try/finally to remove file after usage
  • as File.deleteOnExitis not relevant for a long running server, you will have to implement a regular job to clean temporary files left after unexpected failures
  • a timer watch dog should kill script processes than have not answered in delay, some may be stuck for any reason

By the way, to avoid troubles with temporary files and improve performance, if your code runs on a Unix system, I recommend you to use stdin/stdout to pass request and response between processes and design your script as less file access as possible.

But your system may raise some limits: the resources required to create a new process and the processing time of a script can lead to thousands of processes living in your operating system, in addition to JBoss threads waiting for process returns (so less threads available to process short web requests). To avoid crashes, the watch dog should limit the number of created processes in any moment - and that threshold must be defined thanks to a benchmark.

Upvotes: 1

Related Questions