FAQ

[Tomcat-users] Feature request: "fullstart" command

Francis GALIEGUE
Jun 15, 2011 at 8:01 pm
Tomcat has many abilities to deploy applications at run time (war,
tree, context, you name it). However, when used in production, these
abilities are used cautiously, if they are used at all.

In many scenarios, Tomcat just starts, spends its life, and stops,
with a defined set of webapps, and has no automatic deployment
capabilities configured in at all. But the builtin startup scripts,
and in fact, the Java code itself, lack at least two critical inputs
for such scenarios:

* Bootstrap will return (and therefore the startup scripts too) before
webapps configured at startup time are deployed, and while
bootstrapping is fast, deploying applications at startup can be very
long;
* even with a hackish way (watch the log file to account for complete
server startup) in order to wait for webapps to be deployed, there is
no status about these deployments at all (has this and that webapp
been deployed successfully?).

Proposal: implement a fullstart command to Bootstrap which:

* does NOT return until ALL webapps configured at start time are
(attempted to be) deployed;
* exits with a positive error code representing the number of webapps
NOT correctly deployed (or 1 - I don't care as long as it's not 0, but
please not -1, think WIFSIGNALED()).

--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
reply

Search Discussions

21 responses

  • Caldarale, Charles R at Jun 15, 2011 at 8:12 pm

    From: Francis GALIEGUE
    Subject: Feature request: "fullstart" command
    Proposal: implement a fullstart command to Bootstrap which:
    * does NOT return until ALL webapps configured at start time are
    (attempted to be) deployed;
    * exits with a positive error code representing the number of webapps
    NOT correctly deployed (or 1 - I don't care as long as it's not 0, but
    please not -1, think WIFSIGNALED()).
    Check the system property org.apache.catalina.startup.EXIT_ON_INIT_FAILURE and see if it meets your needs. (It might not be setting an exit code.)

    http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html

    - Chuck


    THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
  • Francis GALIEGUE at Jun 15, 2011 at 8:23 pm

    On Wed, Jun 15, 2011 at 22:11, Caldarale, Charles R wrote:
    [...]

    Check the system property org.apache.catalina.startup.EXIT_ON_INIT_FAILURE and see if it meets your needs.  (It might not be setting an exit code.)

    http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html

    - Chuck
    It doesn't. The only use of it in StandardService is to throw an Error
    (it will then exit(1) as it is an uncaught error) if connectors
    initialization fails. But this is not what I'm after (checked in
    7.0.14 source code).


    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 16, 2011 at 10:30 am

    On 15/06/2011 21:00, Francis GALIEGUE wrote:
    Tomcat has many abilities to deploy applications at run time (war,
    tree, context, you name it). However, when used in production, these
    abilities are used cautiously, if they are used at all.

    In many scenarios, Tomcat just starts, spends its life, and stops,
    with a defined set of webapps, and has no automatic deployment
    capabilities configured in at all. But the builtin startup scripts,
    and in fact, the Java code itself, lack at least two critical inputs
    for such scenarios:

    * Bootstrap will return (and therefore the startup scripts too) before
    webapps configured at startup time are deployed, and while
    bootstrapping is fast, deploying applications at startup can be very
    long;
    * even with a hackish way (watch the log file to account for complete
    server startup) in order to wait for webapps to be deployed, there is
    no status about these deployments at all (has this and that webapp
    been deployed successfully?).
    An application might report that it's started, even it hasn't finished
    initialising.

    Proposal: implement a fullstart command to Bootstrap which:

    * does NOT return until ALL webapps configured at start time are
    (attempted to be) deployed;
    * exits with a positive error code representing the number of webapps
    NOT correctly deployed (or 1 - I don't care as long as it's not 0, but
    please not -1, think WIFSIGNALED()).
    'fullstart' is an odd name, people might start using it thinking that
    'start' did not fully start the server.

    Returning an exit code which describes the number of apps successfully
    started isn't much use unless you (or the init script) know the number
    of apps configured.


    p
  • Sebb at Jun 16, 2011 at 11:04 am

    On 16 June 2011 11:29, Pid wrote:
    On 15/06/2011 21:00, Francis GALIEGUE wrote:
    Tomcat has many abilities to deploy applications at run time (war,
    tree, context, you name it). However, when used in production, these
    abilities are used cautiously, if they are used at all.

    In many scenarios, Tomcat just starts, spends its life, and stops,
    with a defined set of webapps, and has no automatic deployment
    capabilities configured in at all. But the builtin startup scripts,
    and in fact, the Java code itself, lack at least two critical inputs
    for such scenarios:

    * Bootstrap will return (and therefore the startup scripts too) before
    webapps configured at startup time are deployed, and while
    bootstrapping is fast, deploying applications at startup can be very
    long;
    * even with a hackish way (watch the log file to account for complete
    server startup) in order to wait for webapps to be deployed, there is
    no status about these deployments at all (has this and that webapp
    been deployed successfully?).
    An application might report that it's started, even it hasn't finished
    initialising.

    Proposal: implement a fullstart command to Bootstrap which:

    * does NOT return until ALL webapps configured at start time are
    (attempted to be) deployed;
    * exits with a positive error code representing the number of webapps
    NOT correctly deployed (or 1 - I don't care as long as it's not 0, but
    please not -1, think WIFSIGNALED()).
    'fullstart' is an odd name, people might start using it thinking that
    'start' did not fully start the server.

    Returning an exit code which describes the number of apps successfully
    started isn't much use unless you (or the init script) know the number
    of apps configured.
    And it may cause problems on some OSes which don't use unix-style exit codes.
    For example, OpenVMS uses the low order 3 bits of a process exit code
    as a severity indicator, and odd is success, even is failure.
    [IThe JVM automatically converts exit 0 to exit 1 to compensate, but
    cannot deal with all exit codes].
    p
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 11:17 am
    On Thu, Jun 16, 2011 at 13:04, sebb wrote:
    [...]
    And it may cause problems on some OSes which don't use unix-style exit codes.
    For example, OpenVMS uses the low order 3 bits of a process exit code
    as a severity indicator, and odd is success, even is failure.
    [IThe JVM automatically converts exit 0 to exit 1 to compensate, but
    cannot deal with all exit codes].
    It's up to main() to call System.exit(), so how is that a problem?

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Sebb at Jun 16, 2011 at 11:30 am

    On 16 June 2011 12:16, Francis GALIEGUE wrote:
    On Thu, Jun 16, 2011 at 13:04, sebb wrote:
    [...]
    And it may cause problems on some OSes which don't use unix-style exit codes.
    For example, OpenVMS uses the low order 3 bits of a process exit code
    as a severity indicator, and odd is success, even is failure.
    [IThe JVM automatically converts exit 0 to exit 1 to compensate, but
    cannot deal with all exit codes].
    It's up to main() to call System.exit(), so how is that a problem?
    If the exit code is not passed to the OS, but is merely a method
    return code, then of course it's not a problem.

    But I understood the term "exit code" to mean the code returned to the
    OS through System.exit().
    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 11:33 am
    On Thu, Jun 16, 2011 at 13:30, sebb wrote:
    [...]
    It's up to main() to call System.exit(), so how is that a problem?
    If the exit code is not passed to the OS, but is merely a method
    return code, then of course it's not a problem.

    But I understood the term "exit code" to mean the code returned to the
    OS through System.exit().
    You lost me. System.exit() acts at the JVM level anyway, therefore the
    process level. Don't we talk about the same thing?

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Sebb at Jun 16, 2011 at 11:52 am

    On 16 June 2011 12:32, Francis GALIEGUE wrote:
    On Thu, Jun 16, 2011 at 13:30, sebb wrote:
    [...]
    It's up to main() to call System.exit(), so how is that a problem?
    If the exit code is not passed to the OS, but is merely a method
    return code, then of course it's not a problem.

    But I understood the term "exit code" to mean the code returned to the
    OS through System.exit().
    You lost me. System.exit() acts at the JVM level anyway, therefore the
    process level. Don't we talk about the same thing?
    The value passed to System.exit(int) is passed to the OS.

    In Unix systems, 0 means success and anything else is generally not success.

    OpenVMS behaves differently, as already noted.
    If a process returns an error or fatal code to VMS, then by default
    the script running it will exit with an error.

    So changing the OS exit code can affect existing users.

    The point is that exit codes are not portable across OSes; the most
    one can hope for is sucess or failure indication.
    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 12:00 pm
    On Thu, Jun 16, 2011 at 13:51, sebb wrote:
    [...]
    The value passed to System.exit(int) is passed to the OS.

    In Unix systems, 0 means success and anything else is generally not success.

    OpenVMS behaves differently, as already noted.
    If a process returns an error or fatal code to VMS, then by default
    the script running it will exit with an error.

    So changing the OS exit code can affect existing users.

    The point is that exit codes are not portable across OSes; the most
    one can hope for is sucess or failure indication.
    It's not my fault if OpenVMS is broken in that regard, but anyway, I
    was not talking about implementing this for existing Tomcat versions,
    but for future ones (although if 7.0.x had this I'd be very happy).
    And I'm mostly sure that Java can do whatever is required because it
    can detect what OS it runs on. I mean, C has EXIT_SUCCESS and
    EXIT_FAILURE, it's only a matter of defining such constants in the
    Tomcat code as well - unless the JVM already has such exit code
    defintions handy, in which case all is left to do is implementing
    them.

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 11:15 am
    On Thu, Jun 16, 2011 at 12:29, Pid wrote:
    [...]
    An application might report that it's started, even it hasn't finished
    initialising.
    That is the application's responsibility, so not the problem at hand.

    Furthermore, if the application reports a successful start even though
    it is not completely initialized, i consider this an application
    fault, therefore not my concern. As the person being responsible for
    the good behavior of applications in production, I expect webapps that
    I deploy to behave correctly, ie fail to deploy in the event of an
    initialization failure. Tomcat won't provide me with this information,
    EXCEPT if I use the manager webapp (in text mode, of course) to deploy
    it, as I can parse the return "message".

    [...]
    'fullstart' is an odd name, people might start using it thinking that
    'start' did not fully start the server.
    Which is the case in this particular scenario! OK, maybe not
    fullstart, but appstart, something else... As long as this command
    doesn't complete before all webapps configured at startup have
    attempted a deployment.
    Returning an exit code which describes the number of apps successfully
    started isn't much use unless you (or the init script) know the number
    of apps configured.
    No, you misread what I say. What I want is the return code to be the
    number of webapps NOT successfully deployed. But even that, I reckon,
    is not that good an idea: the JVM will return 1 in the event of an
    uncaught exception (or thrown from main()). So, 1+n, where n is the
    number of webapps not successfully deployed. But in any case, obey the
    basic principle that 0 means success, and anything else means a
    failure.

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 16, 2011 at 12:37 pm

    On 16/06/2011 12:15, Francis GALIEGUE wrote:
    On Thu, Jun 16, 2011 at 12:29, Pid wrote:
    [...]
    An application might report that it's started, even it hasn't finished
    initialising.
    That is the application's responsibility, so not the problem at hand.
    What is the value of indicating success or failure, if the answer is
    only partially true? You can't know for certain whether the answer you
    have is meaningful, so it's useless.

    Furthermore, if the application reports a successful start even though
    it is not completely initialized, i consider this an application
    fault, therefore not my concern.
    That makes no sense to me.

    As the person being responsible for
    the good behavior of applications in production, I expect webapps that
    I deploy to behave correctly, ie fail to deploy in the event of an
    initialization failure.
    That seems contradictory, but it's probably my misunderstanding.


    Tomcat won't provide me with this information,
    EXCEPT if I use the manager webapp (in text mode, of course) to deploy
    it, as I can parse the return "message".
    Yes it will, using the same mechanism that the manager webapp uses; you
    can interact with Tomcat over JMX, the API gives you detailed
    information about applications.


    [...]
    'fullstart' is an odd name, people might start using it thinking that
    'start' did not fully start the server.
    Which is the case in this particular scenario! OK, maybe not
    fullstart, but appstart, something else... As long as this command
    doesn't complete before all webapps configured at startup have
    attempted a deployment.
    Returning an exit code which describes the number of apps successfully
    started isn't much use unless you (or the init script) know the number
    of apps configured.
    No, you misread what I say.
    Ok.


    p

    What I want is the return code to be the
    number of webapps NOT successfully deployed. But even that, I reckon,
    is not that good an idea: the JVM will return 1 in the event of an
    uncaught exception (or thrown from main()). So, 1+n, where n is the
    number of webapps not successfully deployed. But in any case, obey the
    basic principle that 0 means success, and anything else means a
    failure.
  • Francis GALIEGUE at Jun 16, 2011 at 12:49 pm
    On Thu, Jun 16, 2011 at 14:36, Pid wrote:
    [...]
    An application might report that it's started, even it hasn't finished
    initialising.
    That is the application's responsibility, so not the problem at hand.
    What is the value of indicating success or failure, if the answer is
    only partially true?  You can't know for certain whether the answer you
    have is meaningful, so it's useless.
    I have a manichean point of view on this: an application is ready to
    operate when its initialization phase is complete, or it's not.
    Success, or failure. I'm not even taking OSGi and this sort of things
    into account here. If the application uses OSGi, fine. What I expect
    of it is to tell it's ready to answer any requests that may be thrown
    at it.
    Furthermore, if the application reports a successful start even though
    it is not completely initialized, i consider this an application
    fault, therefore not my concern.
    That makes no sense to me.
    See above.
    As the person being responsible for
    the good behavior of applications in production, I expect webapps that
    I deploy to behave correctly, ie fail to deploy in the event of an
    initialization failure.
    That seems contradictory, but it's probably my misunderstanding.
    How so? Again, see above.
    Tomcat won't provide me with this information,
    EXCEPT if I use the manager webapp (in text mode, of course) to deploy
    it, as I can parse the return "message".
    Yes it will, using the same mechanism that the manager webapp uses; you
    can interact with Tomcat over JMX, the API gives you detailed
    information about applications.
    I just _don't_ _care_. I don't want to have to use JMX to monitor
    webapp state in this case (although I _do_ use it for monitoring
    purposes, which is a HUGE difference). I wish Tomcat to be able to
    report, with startup-configured web applications, whether these
    webapps were successfully deployed -- at _startup_ time -- and exit
    with a meaningful error code if one or more of these webapps were NOT
    deployed correctly. And yes, I rely on these webapp's startup
    procedures to report failures as well.

    To put an analogy with device drivers, what you basically say is "I
    initialize the driver without a firmware and don't care whether the
    initialization succeeds, I'll see that when the firmware loads". I
    say, "a driver is considered initialized iif the basic initialization
    is OK, _and_ the firmware is loaded and functional". This is a HUGE
    difference. The fact that the device may fail at run time is akin to
    running JMX for webapp monitoring, and this can happen as well. But I
    want a _guarantee_ that the device, when the init routine returns, is
    fully ready to operate.

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at Jun 16, 2011 at 12:49 pm

    2011/6/16 Francis GALIEGUE <fge@one2team.com>:
    On Thu, Jun 16, 2011 at 12:29, Pid wrote:
    [...]
    An application might report that it's started, even it hasn't finished
    initialising.
    That is the application's responsibility, so not the problem at hand.

    Furthermore, if the application reports a successful start even though
    it is not completely initialized, i consider this an application
    fault, therefore not my concern.
    Some resources are allocated only on the first access.

    E.g. starting servlets, or obtaining database connections from a pool.
    Unless you obtain a connection there is no knowing that the database
    is accessible.

    1) Consider implementing a Listener.

    2) Note the bindOnInit option on Connector
    http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

    though binding while Tomcat initializes is necessary to be able to
    access privileged ports. If Tomcat is run with jsvc, jsvc drops the
    privileges once the initialization succeeds.

    3) There was once discussion on this list about starting Connectors
    programmatically. That is, Tomcat starts without connectors (or with
    stopped connectors), somewhat like a hot standby, and starts the
    connectors when everything else is ready.

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 12:54 pm

    On Thu, Jun 16, 2011 at 14:48, Konstantin Kolinko wrote:
    [...]

    Some resources are allocated only on the first access.

    E.g. starting servlets, or obtaining database connections from a pool.
    Unless you obtain a connection there is no knowing that the database
    is accessible.
    I know that. Some initialization phases, though, _do_ (or, if not,
    should) raise errors on deployment, and right now I have no way to
    catch such errors at startup time. And I'm not talking about
    connectors here. I did learn one thing though, about that
    EXIT_ON_FAILURE option: it should have been the default as far as I'm
    concerned, but ohwell...


    Again, connectors are one part of the problem here (I use
    EXIT_ON_FAILURE now on my deployments). But application deployment is
    another. Unless there is some hidden meaning to a Connector which I
    haven't understood.

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at Jun 16, 2011 at 1:02 pm

    2011/6/16 Francis GALIEGUE <fge@one2team.com>:
    On Thu, Jun 16, 2011 at 14:48, Konstantin Kolinko
    wrote:
    [...]
    Some resources are allocated only on the first access.

    E.g. starting servlets, or obtaining database connections from a pool.
    Unless you obtain a connection there is no knowing that the database
    is accessible.
    I know that. Some initialization phases, though, _do_ (or, if not,
    should) raise errors on deployment, and right now I have no way to
    catch such errors at startup time. And I'm not talking about
    connectors here. I did learn one thing though, about that
    EXIT_ON_FAILURE option: it should have been the default as far as I'm
    concerned, but ohwell...


    Again, connectors are one part of the problem here (I use
    EXIT_ON_FAILURE now on my deployments). But application deployment is
    another. Unless there is some hidden meaning to a Connector which I
    haven't understood.
    Implement what you want in a listener. Throw an Error if whatever you
    want fails.

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 1:07 pm

    On Thu, Jun 16, 2011 at 15:01, Konstantin Kolinko wrote:
    [...]

    Implement what you want in a listener. Throw an Error if whatever you
    want fails.
    OK, but then, why isn't there such a listener as standard? I'm sure
    you understand the need, and having this listener as standard in
    Tomcat can bring great value. If it means modifying the server.xml,
    I'm fine with it. I'm a systems engineer, and while I know some Java,
    I'd rather let the Tomcat team do that - they will do a better job
    than I in any case.

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Christopher Schultz at Jun 16, 2011 at 6:37 pm
    Francis,
    On 6/15/2011 4:00 PM, Francis GALIEGUE wrote:
    Proposal: implement a command to Bootstrap which:

    * does NOT return until ALL webapps configured at start time are
    (attempted to be) deployed;
    * exits with a positive error code representing the number of webapps
    NOT correctly deployed (or 1 - I don't care as long as it's not 0, but
    please not -1, think WIFSIGNALED()).
    The above requirements actually might not be possible in a reasonably
    simple system.

    First off, the JVM provides no pure-Java way of letting a process go
    into the background. So, there's really no opportunity to do some work
    in Java and /then/ return to the calling process without terminating.

    Second, an OS return code requires a process termination, and you
    certainly don't want to terminate the JVM you've just started.

    About the best we could do is change catalina.sh from roughly this:

    java org.apache.tomcat.Bootstrap >> logs/catalina.out &

    to this:

    java org.apache.tomcat.Bootstrap >> logs/catalina.out &

    tail -f logs/catalina.out | grep -m 1 "INFO: Server startup"

    exit 0

    There are some problems with this approach:

    1. It's not foolproof... if your server is insanely fast, it might
    start before tail | grep runs, and you might wait forever

    2. The log messages are localized, so you'll have to use the proper
    localized message instead of just "INFO: Server startup"

    3. This is so simple that you should be able to do it yourself

    Does this really need to be a part of the stock Tomcat? I'm not
    convinced that this exact solution would meet everyone's needs so it
    would need to be further customized, anyway.

    - -chris
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Francis GALIEGUE at Jun 16, 2011 at 9:28 pm

    On Thu, Jun 16, 2011 at 20:37, Christopher Schultz wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Francis, [...]
    The above requirements actually might not be possible in a reasonably
    simple system.

    First off, the JVM provides no pure-Java way of letting a process go
    into the background. So, there's really no opportunity to do some work
    in Java and /then/ return to the calling process without terminating.

    Second, an OS return code requires a process termination, and you
    certainly don't want to terminate the JVM you've just started.
    I was actually wondering about these. I think I have my answer now :/
    Solutions in C or other languages are many to achieve that, Java has
    none.
    About the best we could do is change catalina.sh from roughly this:

    java org.apache.tomcat.Bootstrap >> logs/catalina.out &

    to this:

    java org.apache.tomcat.Bootstrap >> logs/catalina.out &

    tail -f logs/catalina.out | grep -m 1 "INFO: Server startup"

    exit 0

    There are some problems with this approach:

    1. It's not foolproof... if your server is insanely fast, it might
    start before tail | grep runs, and you might wait forever

    2. The log messages are localized, so you'll have to use the proper
    localized message instead of just "INFO: Server startup"

    3. This is so simple that you should be able to do it yourself

    Does this really need to be a part of the stock Tomcat? I'm not
    convinced that this exact solution would meet everyone's needs so it
    would need to be further customized, anyway.
    Yeah well, I can understand that since this is what I use right now. I
    make it darn sure that my locale is set up OK, but then any different
    logging configuration will defeat that. Which is why I am right now
    switching over completely to the scenario where Tomcat only starts
    with the manager webapp builtin and further webapps are deployed after
    the initial startup. This still requires to parse the output of the
    manager webapp, but at least it's better than the default :/

    --
    Francis Galiegue
    ONE2TEAM
    Ingénieur système
    Mob : +33 (0) 683 877 875
    Tel : +33 (0) 178 945 552
    fge@one2team.com
    40 avenue Raymond Poincaré
    75116 Paris

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Christopher Schultz at Jun 16, 2011 at 10:14 pm
    Francis,
    On 6/16/2011 5:03 PM, Francis GALIEGUE wrote:
    On Thu, Jun 16, 2011 at 20:37, Christopher Schultz
    First off, the JVM provides no pure-Java way of letting a process go
    into the background. So, there's really no opportunity to do some work
    in Java and /then/ return to the calling process without terminating.

    Second, an OS return code requires a process termination, and you
    certainly don't want to terminate the JVM you've just started.
    I was actually wondering about these. I think I have my answer now :/
    Solutions in C or other languages are many to achieve that, Java has
    none.
    Correct: native code has to be written. tc-native notwithstanding, the
    Tomcat team doesn't like to work with native code too much, and I can
    understand why: it's a total minefield. Different OS versions, different
    architectures, different c-library discrepancies, etc.

    Even if someone wrote something like this in native code, the result
    would be essentially a fork() call which would clone your JVM, which
    isn't going to be a fast process at that late stage of the game (in JVM
    time, that is).
    About the best we could do is change catalina.sh from roughly this:

    java org.apache.tomcat.Bootstrap >> logs/catalina.out &

    to this:

    java org.apache.tomcat.Bootstrap >> logs/catalina.out &

    tail -f logs/catalina.out | grep -m 1 "INFO: Server startup"

    exit 0

    There are some problems with this approach:

    1. It's not foolproof... if your server is insanely fast, it might
    start before tail | grep runs, and you might wait forever

    2. The log messages are localized, so you'll have to use the proper
    localized message instead of just "INFO: Server startup"

    3. This is so simple that you should be able to do it yourself

    Does this really need to be a part of the stock Tomcat? I'm not
    convinced that this exact solution would meet everyone's needs so it
    would need to be further customized, anyway.
    Yeah well, I can understand that since this is what I use right now. I
    make it darn sure that my locale is set up OK, but then any different
    logging configuration will defeat that. Which is why I am right now
    switching over completely to the scenario where Tomcat only starts
    with the manager webapp builtin and further webapps are deployed after
    the initial startup. This still requires to parse the output of the
    manager webapp, but at least it's better than the default :/
    It would be somewhat easy to provide some more tools that could be used
    to script such things, such as a catalina.sh mode that would dump the
    expected text after a successful startup (e.g. it would print "INFO:
    Server startup"). That would let you do something like this:

    START_MESSAGE=`catalina.sh print-start-message`
    catalina.sh start

    tail -f logs/catalina.out | grep -m 1 "${START_MESSAGE}"

    exit 0

    It's pretty easy to write a quickie class that grabs the right string
    from the right properties file given the locale, etc.

    - -chris
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Mladen Turk at Jun 17, 2011 at 5:22 am

    On 06/17/2011 12:14 AM, Christopher Schultz wrote:
    On 6/16/2011 5:03 PM, Francis GALIEGUE wrote:

    I was actually wondering about these. I think I have my answer now :/
    Solutions in C or other languages are many to achieve that, Java has
    none.
    Correct: native code has to be written. tc-native notwithstanding, the
    Tomcat team doesn't like to work with native code too much, and I can
    understand why: it's a total minefield. Different OS versions, different
    architectures, different c-library discrepancies, etc.
    There ARE tomcat developers that are quite fun of C code and
    regularly participate in various "native" projects, so this
    has nothing to do with that.

    Even if someone wrote something like this in native code, the result
    would be essentially a fork() call which would clone your JVM, which
    isn't going to be a fast process at that late stage of the game (in JVM
    time, that is).
    Exactly, and the fork() doesn't work with JVM. fork() only forks the
    single thread, so all your monitor, GC, memory threads are not there.
    For JVM, fork() is only valid if followed by execv which is basically
    what Runtime.exec does.
    Also there is a question of portability. Windows doesn't have fork().

    However I don't see a reason why a separate Listener can't be made
    that would monitor the app deployment, and act accordingly to some
    rule(s). Tomcat currently tries its best to start, meaning that it
    will start regardless of anything. Even if its config is totally
    bogus it will throw pile of exceptions but start no mater what.
    Does that make sense? For embedded usage yes, for standalone I doubt.

    Eg. If port 80 is in use, httpd will log and refuse to start. Tomcat will
    throw exceptions and just continue, meaning you have to inspect
    your log files every time you start the Tomcat.



    Regards
    --
    ^TM

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Christopher Schultz at Jun 20, 2011 at 2:17 am
    Mladen,
    On 6/17/2011 1:21 AM, Mladen Turk wrote:
    On 06/17/2011 12:14 AM, Christopher Schultz wrote:
    On 6/16/2011 5:03 PM, Francis GALIEGUE wrote:

    I was actually wondering about these. I think I have my answer now :/
    Solutions in C or other languages are many to achieve that, Java has
    none.
    Correct: native code has to be written. tc-native notwithstanding, the
    Tomcat team doesn't like to work with native code too much, and I can
    understand why: it's a total minefield. Different OS versions, different
    architectures, different c-library discrepancies, etc.
    There ARE tomcat developers that are quite fun of C code and
    regularly participate in various "native" projects, so this
    has nothing to do with that.
    I wasn't trying to suggest that there was any fear of native code...
    just that it's really only used when necessary (APR, for instance).
    Even if someone wrote something like this in native code, the result
    would be essentially a fork() call which would clone your JVM, which
    isn't going to be a fast process at that late stage of the game (in JVM
    time, that is).
    Exactly, and the fork() doesn't work with JVM. fork() only forks the
    single thread, so all your monitor, GC, memory threads are not there.
    For JVM, fork() is only valid if followed by execv which is basically
    what Runtime.exec does.
    Yes, but the "daemon" function calls fork() and then the /parent/ exist,
    which would ruin everything. I don't believe there's another way to drop
    in to the background after a process is launched like that.
    Also there is a question of portability. Windows doesn't have fork().
    Yup. There are ways of making it work, but it's just another way for
    native code to bite you in the butt.

    - -chris
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org

Related Discussions