What is a daemon? Historically, a daemon has been defined by the CTSS group
in 1963 as a "Disk And Execution MONitor", and has been adopted into the
Unix world as a program that is not invoked explicitly, but lies dormant
waiting for some condition(s) to occur.
What are those conditions? Two classes, basically: an unspecified I/O
condition that triggers a stage of the daemon execution process, and a
service request; while we cannot schematize and abstract the first class of
conditions, as these are dependant from daemon to daemon and determine what
a daemon serves (the LPR daemon is different from the HTTP daemon), history
already determined the second class of conditions as signals.
For instance, it is assumed (and specified), that in response to a TERM
signal the daemon should terminate its operation and exit its process, in
response to a HANGUP signal it should hangup a connection, or more recently
reload its configurations and restart.
So, we can now abstract a more "generic" definition for daemon: a daemon is
a dormant program (meaning detached from its parent process, and not
interrupting its flow of execution), which serves I/O requests for its
clients (from here the symmetry daemon=server) and interacts with the
underlying operating system with a defined set of signals or events.
In the Win32 world, the term daemon is substituted with the term "service",
and signals (which do not exist in that environment) have been changed with
specific calls to certain declared functions, but on the overall the design
remains the same.
In any modern multi-user operating system there is a concept of "deamon",
"service", "server", and this concept has been associated with "a dormant
program serving I/O requests for its clients and interacting with the
underlying operating system with a defined set of signals or events"
So far, the Java Platform lacked of a way to build an operating system
daemon using the Java language: Java applications are -all- interactive
programs, as the current invocation mechanism lacks of a way to create a
dormant program, and lacks of a way to interact with the underlying
operating system. Notably, see JavaSoft's Bug # 4323062: the java.exe
application invocator is used as a "deamon" and it fails. The current fix is
a hack, and the platform still lacks of a way thru which an operating system
daemon written in java can receive events triggered by the OS (we can easily
launch "java myClass &" in Unix, but it dies inexorably when a TERM signal
is delivered to its process).
Those are the problems I wanted to solve when I joined the JSR-096 expert
group, those are the issues that in the proposal listed on the JCP site we
are supposed to solve, and this is what the Java community expect us to
deliver.
And today (incredible timing, I would say) I received the last copy of the
specification. And I'm disappointed to see that even in this last copy there
is no reference to the behavior of the JVM process related to its supporting
operating system. This specification does not solve my problem, is not the
reason why I joined this group.
I see this version of the specification as a description on how to build
Java daemons for the Java Platform (one tier up), not a Java daemon for a
generic underlying operating system. This idea is corroborated by the fact
that its test Reference Implementation delivered with the specification is
based on JMX, doesn't touch at all the problems that we need to face when
integrating a generic Java daemon (from the definition above) within the
scope the underlying operating system. In my opinion, this specification is
redundant, JMX and JSR-111 are already a great way to address these problems
(I believe this came out also from our meeting in London last month).
And that's why last week, on my own, silently, I came up with an
implementation that addresses the problems I needed to solve, and were
needed to be solved by my team (the Apache Tomcat team) to deal with how a
daemon written in Java can deal with the operating system.
<http://www.apache.org/websrc/viewcvs.cgi/jakarta-tomcat-4.0/service/>
Being responsible for solving these problems in the Tomcat world, his
implementation is what I feel I can safely deliver to my team and to the
community, while I don't feel that adding another layer of cumbersomeness to
the current specifications will help in any possible way.
And this is why as an Apache member, and its current representative in this
expert group, as a Sun Microsystems employee working on the Tomcat project,
I will not support the current specification until the problems I face, the
problems I endorsed when joining this effort, the problems we were supposed
to solve will be addressed.
My implementation doesn't try to be a full 360 degrees solution to the
problems of daemons, and does not try to be a fancy JCP specification, but
it solves those problems that we, software developers, need to face everyday
when developing daemons in the Java Language and with the help of the
community, will be improved and enhanced.
I believe that this expert group went too far, forgetting its roots, and the
real problems that we needed to solve.
Also, another problem I faced while working with this group was the way in
which the discussion was held. Our mailing list rarely held technical
discussions, if not triggered by one of us in the Apache Software Foundation
(thanks especially to Peter Donald) or few others and the whole
specification was developed internally at Dialogika. I've been thru several
specifications in the Servlet/JSP and XML lands and being a member of the
expert group usually ment to know _what_ was going on, not just listening to
decisions taken inside a company by few and "blessing" them.
In your last email, Thomas, I quote "As a late reaction of Peter's critics I
did some brainstorming and discussed the control code model once more with
my colleagues". WE, Thomas, are your colleagues on this specification, not
whoever works at Dialogika, my name is on that specification, and apart from
the one in London I never had a brainstorming session with you.
I'm sorry I didn't come to JavaONE, but my current economic situation didn't
allow me to get there, I would have told you this in person, but I feel left
out, and right now I should have to bless a specification that I don't agree
with and that doesn't include any of my thoughts on the matter.
Apart from this my vote on JSR-096 is a veto, a -1, for technical reasons,
we don't solve those problems we were supposed to.
Sincerely,
Pier Fumagalli
- Apache Software Foundation (member, JSR-096 representative)
(CCing to the Tomcat Developers mailing list, the Apache JCP mailing list,
the Apache Members mailing list and my manager at Sun Microsystems)
