DO NOT REPLY [Bug 51587] New: Implement status and uptime commands

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51587

             Bug #: 51587
           Summary: Implement status and uptime commands
           Product: Tomcat 7
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: knst.kolinko@gmail.com
    Classification: Unclassified


In Tomcat HowTo wiki it is mentioned that it would be nice to have "status" and
"uptime" commands in Tomcat. [1]

[1]
http://wiki.apache.org/tomcat/HowTo#How_do_I_check_whether_Tomcat_is_UP_or_DOWN.3F_There_is_no_status_command


My thoughts on implementing it are the following:

1. Create a Listener class "TomcatStatusListener" and add it to server.xml.

2. The class will implement a non-daemon waiting loop, like the one implemented
in StandardServer.await.  One of issues in StandardServer.await is that it
starts listening on a port only after Tomcat startup completes. If it fails to
open the port (e.g. another Tomcat instance is running) it shuts down Tomcat,
but I think that it happens too late. (*)
The listener can start listening on the port earlier.

(*) existing workarounds are using CATALINA_PID setting in
catalina.sh/setenv.sh and configuring o.a.c.s.EXIT_ON_INIT_FAILURE system
property.


3. The control port and shutdown command for the listener can be read from the
StandardServer object.

After that the await behaviour of the server can be disabled by
programmatically changing StandardServer.port to a negative value. I think that
there is some undocumented code for the value of -2 there already,  or we can
add some additional explicit flag to the StandardServer object.

Note, that when shutting down Tomcat the port number is being read from port
attribute on the Server element. The code wouldn't look for the listener
implementations, so there would not be much sense in specifying a different
port on the Listener element.


4. Implement additional commands, "status" and "uptime" in the listener.

The "status" command can print the value of StandardServer.getStateName().

It might be done that the output of the "status" command were enhanceable. E.g.
some structured data (status, uptime, start date) - compare with comment 7 in
bug 49395.

It is up to the other side of control port connection to interpret the value
and print a more human-friendly message. E.g.:

Tomcat Status: STARTED, 13:0:14, 2011-07-30T11:51
Running. Started on July 20, 2011 11:51. Uptime 13 day(s) 0 hour(s) 14
minute(s).


5. If shutdown is implemented by the listener, it would be possible to initiate
shutdown before Tomcat fully starts up.

6. If there is no such listener in server.xml, the behaviour remains the same
as earlier with await loop being run by StandardServer.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

DO NOT REPLY [Bug 51587] Implement status and uptime commands

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51587

--- Comment #2 from Konstantin Kolinko <kn...@gmail.com> 2011-08-02 07:53:04 UTC ---
(In reply to comment #1)
> I'm not sure why you'd use a non-daemon waiting loop, instead of a simple
> single-threaded daemon listener.

That there should always be a non-daemon Thread in a JVM, because that is what
keeps JVM alive. Currently this task is performed by Main thread that loops
inside StandardServer.await().

I thought that maybe this task can be performed by the listener as well, and
let the Main thread just exit without waiting.

Maybe it is over-engineering though and these tasks could be separate.

> There is no need for a "shutdown" command on this port IMO.

Look at Catalina.stopServer(String[]) and createStopDigester() that it calls.
The support for new command, Catalina.status(..), could be implemented in the
same place. It is easier to read port number from <Server> element like
createStopDigester() does than trying to figure what Listeners are configured.
Thus it is the same port.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

DO NOT REPLY [Bug 51587] Implement status and uptime commands

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51587

--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> 2011-08-01 18:24:38 UTC ---
I'd like to see more structured data available in the response. Either in
CSV/TSV or in XML (maybe selectable via a request parameter/header).

I'm not sure why you'd use a non-daemon waiting loop, instead of a simple
single-threaded daemon listener. Is that because you want this status listener
to be able to reply with a "Tomcat connector dead" response or something like
that? I figure that if no connectors start, Tomcat should probably die and the
"Tomcat is dead" response would just be a connection failure.

There is no need for a "shutdown" command on this port IMO.

Maybe you could just re-purpose the existing shutdown listener entirely and add
more commands that it recognizes, like "STATUS" and "UPTIME" (though one might
argue that those are really the same command). This is likely to require
re-factoring because, as you mention, you can't SHUTDOWN before Tomcat has
fully initialized anyway. Being able to shut down Tomcat before startup
completes (for example, under a faulty configuration that stalls forever while
starting up) would be a good thing to be able to do.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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