This discussion is archived
14 Replies Latest reply: Sep 26, 2012 5:07 PM by jtahlborn RSS

Execute subprocesses from within application server

964537 Newbie
Currently Being Moderated
I'm trying to execute subprocesses from within my application server (glassfish 3.1.2) Therefore I discovered the apache commons exec library. The problem is that this library creates threads which should not be done on an application server because the server is not aware of these threads. What could be a solution to this problem ? Would it be possible to create a message component written in Java SE who consumes messages containing information about pending jobs and register it with the application server? The application server would then not have to deal with runtime exceptions and threads but just consume messages which contain the result or an exception. Do you have any better ideas?

Edited by: 961534 on 26.09.2012 05:35
  • 1. Re: Execute subprocesses from within application server
    gimbal2 Guru
    Currently Being Moderated
    I've used JMS in the past for such a purpose; fire off (autonomous) jobs by simply sending messages. But you may also look into asynchronous EJB invocations since you're on the JEE 6 platform.
  • 2. Re: Execute subprocesses from within application server
    964537 Newbie
    Currently Being Moderated
    if I use EJB's I would have to rewrite/transfer the complete apache commons exec library to EJB's and make it useable for application servers. That sounds quite hard :/

    Edited by: 961534 on 26.09.2012 06:06
  • 3. Re: Execute subprocesses from within application server
    gimbal2 Guru
    Currently Being Moderated
    961534 wrote:
    if I use EJB's I would have to rewrite the complete apache commons exec library and make it useable for application servers. That sounds quite hard :/
    I wouldn't know why, but if you're convinced this is so - well I can't give any further advice, I don't know what is racing through your head here.
  • 4. Re: Execute subprocesses from within application server
    964537 Newbie
    Currently Being Moderated
    At least this is what I thought... Wouldn't I have to eliminate every instance of Runnable (e.g the watchdog) in the library?
  • 5. Re: Execute subprocesses from within application server
    jtahlborn Expert
    Currently Being Moderated
    961534 wrote:
    if I use EJB's I would have to rewrite/transfer the complete apache commons exec library to EJB's and make it useable for application servers. That sounds quite hard :/
    no, you would create a new, asynchronous EJB which wraps the commons exec functionality. that said, this still doesn't solve your problem of using threads in an app server.

    generally, whenever i have needed to do something which involved threads in a JEE env, i've encapsulated this functionality in a JMX MBean (as those are free to do what they like). in ejb 3.1, you can use the new singleton EJBs which are effectively equivalent. you would encapsulate the process management functionality inside this mbean/singleton and then you can invoke the methods to interact with the executions from your other EJBs.
  • 6. Re: Execute subprocesses from within application server
    964537 Newbie
    Currently Being Moderated
    Yes indeed this wouldn't solve my problem at all. It would just be an asynchronous bean creating threads. And creating threads is the thing I'm trying to avoid...

    Relating to your singleton proposal : Then the singleton bean would create these threads ? That would ensure that there's always only on subprocess running right? That would be no alternative for me because the subprocesses are running for quite a long time and thereby my webservice could be used by just one user.
  • 7. Re: Execute subprocesses from within application server
    gimbal2 Guru
    Currently Being Moderated
    961534 wrote:
    Yes indeed this wouldn't solve my problem at all. It would just be an asynchronous bean creating threads. And creating threads is the thing I'm trying to avoid...
    No, an asynchronous EJB call or invocation, which in itself is a thread created by the container (or whatever is chosen to implement the asynchronous nature)... the whole deal was to not have to create threads yourself, by employing JMS/message driven beans or asynchronous EJB invocations you let the server handle it.

    But I must not be understanding something fundamentally about the question asked here, so I'll shut up now.
  • 8. Re: Execute subprocesses from within application server
    964537 Newbie
    Currently Being Moderated
    I read that it's not recommended to use threads within an application server. The problem is that my external library uses threads. I use my external library within my application server -> so I use threads in my application server (that's transivity). I'm trying to avoid that.
    I read that the application server which is able to manage threads is not aware of threads which are started by instances of Runnable, Callable.

    Now suppose I use an EJB and asynchronously call a library method which uses threads. Then in my opinion this makes no difference because the application server is still not aware of the (by the library created) thread and therefore can't manage it.

    That's the best I can do in order to explain my problem

    Edited by: 961534 on 26.09.2012 07:08
  • 9. Re: Execute subprocesses from within application server
    jtahlborn Expert
    Currently Being Moderated
    gimbal2 wrote:
    961534 wrote:
    Yes indeed this wouldn't solve my problem at all. It would just be an asynchronous bean creating threads. And creating threads is the thing I'm trying to avoid...
    No, an asynchronous EJB call or invocation, which in itself is a thread created by the container (or whatever is chosen to implement the asynchronous nature)... the whole deal was to not have to create threads yourself, by employing JMS/message driven beans or asynchronous EJB invocations you let the server handle it.
    running a sub-process involves multiple threads (to read and write the streams). so the async method itself would be starting threads, hence the problem.
  • 10. Re: Execute subprocesses from within application server
    jtahlborn Expert
    Currently Being Moderated
    961534 wrote:
    Yes indeed this wouldn't solve my problem at all. It would just be an asynchronous bean creating threads. And creating threads is the thing I'm trying to avoid...

    Relating to your singleton proposal : Then the singleton bean would create these threads ? That would ensure that there's always only on subprocess running right? That would be no alternative for me because the subprocesses are running for quite a long time and thereby my webservice could be used by just one user.
    in short no. mbeans/singleton ejbs are very different beasts from "normal" ejbs (hence the ability to use threads). "singleton" does not mean "single-threaded". they are singleton instances where their methods can (by default) be invoked simultaneously by multiple threads. you therefore, need to either handle synchronization yourself (like a normal shared service), or, for singelton ejbs i believe you can use annotations to control the threaded nature of the method calls. therefore, you should be able to support as many users as you desire (and your jvm can handle).
  • 11. Re: Execute subprocesses from within application server
    964537 Newbie
    Currently Being Moderated
    Do you have any source which supports that it's allowed to create threads in a singleton bean ? I googled it but I did not find one. Even if not : Why is it that only singletons are allowed to do so ?
  • 12. Re: Execute subprocesses from within application server
    jtahlborn Expert
    Currently Being Moderated
    961534 wrote:
    Do you have any source which supports that it's allowed to create threads in a singleton bean ? I googled it but I did not find one. Even if not : Why is it that only singletons are allowed to do so ?
    i've never actually used singleton ejbs (haven't done full JEE in a while), but i am familiar with them in general. i know that you can handle concurrency yourself, and from that i assumed you could also use threads. however, doing some googling, i think you are correct, in that technically, singleton ejbs do still not give you "permission" to use threads explicitly.

    that probably leaves you with JMX MBeans, then. JMX MBeans are actually pretty nice in terms of implementing and using these days. the major "pain" with using them is that there is still no standard way to deploy them. jboss tends to be pretty friendly in this respect since it uses mbeans heavily internally. dunno much about other app servers.
  • 13. Re: Execute subprocesses from within application server
    964537 Newbie
    Currently Being Moderated
    I saw your reply to a similar problem on stackoverflow and I'm glad that finally someone understands what I'm talking about :)
    Ok so JMX MBeans could be a solution so I'm going to have a look at them. Have you ever heard about the WorkManager interface? I havn't dived into it yet but from what the spec says this could be a solution, too. What do you think? http://docs.oracle.com/javaee/6/api/javax/resource/spi/work/WorkManager.html
  • 14. Re: Execute subprocesses from within application server
    jtahlborn Expert
    Currently Being Moderated
    961534 wrote:
    Have you ever heard about the WorkManager interface? I havn't dived into it yet but from what the spec says this could be a solution, too. What do you think? http://docs.oracle.com/javaee/6/api/javax/resource/spi/work/WorkManager.html
    i remember reading a bit about this once, but have not looked at it too deeply. looking at it now, it basically looks like a JEE ThreadPool. :) assuming that a Worker is "allowed" to launch a Process, it seems like you could easily handle the various streams using additional Workers. i'm not sure how easily you can integrate this w/ apache commons exec, though (not familiar w/ the library myself). if it allows you to control the stream Runnables, then you can probably make it work on a WorkManager.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points