Hi Mark,
Whoa. I hadn't expected that you would have a Java _Server_
lying around. I like the bit about having a simple comm
protocol, because my current interests lie on the client
side. Having java on the server side causes me some
concern regarding performance and dependability. In
resource strained scenarios, I would expect pmjd to be
more fragile than pmcd. Have you seen so, or differently?
- mtw
Mark Goodwin wrote on Mon, Apr 04, 2005 at 03:00:12PM +1000
I'll answer for Ken since he's currently on vacation for a few days.
On Sun, 3 Apr 2005, Mike Werner wrote:
>
> Is any of that old, dead Java project eligible for release
> as Open Source?
probably, but depends on a few things. You'll have to wait a
few days for an answer to this.
> What can you tell about what you have?
we have (yet) another PCP daemon called pmjd ("Performance Metric
Java Daemon"). Basically, it bahaves like an inetd service: i.e listens
on a socket and forks a daemon to service each client connection.
Each instance of the pmjd service daemon responds to PCP commands with
an ascii protocol. The commands allow a client using this protocol
to perform most of the PMAPI functionality, e.g. create and manipulate
PCP contexts (live or archive), walk the name space, fetch metric
descriptors, enumerate the instance domain for a metric, and (of course)
fetch metric values. It's a very simple protocol. Clients can be written
in basically any language supporting a tcp/inet API, e.g. glibc, Perl,
PHP, Java, Python, Telnet, whatever. There is also a tiny library
and Java class that supports a JNI linkage. This simply passes strings
via a function call rather than via a socket and would be used for
efficiency with local live contexts, and (especially) for replaying
PCP archives.
Thanks
-- Mark
|