db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanket Sharma" <sanketsha...@gmail.com>
Subject Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Fri, 09 Jun 2006 06:43:40 GMT
Hey David.

> - In Section 5.1 you are making the implicit assumption that the JMX functionality is
targetted towards Derby being an enterprise-class database.  I'm not sure if everyone would
agree that's the sweet spot for Derby.  If you look at the charter, the focus is on zero-administration,
embeddability, standards-based, etc.

Well, I apologize for the loose phrasing of the sentence!. What I
inteded was such a functionality is essential if Derby is to used as
part of enterprise-class systems. I guess that is ok?
> That said, I think JMX is important (see "ease of use" and "standards-based"), but when
looking at requirements I want to make sure we don't get too top-heavy...

I let my imagination run wild while making the list. What features we
finally incorporate will depend on a lot of factors including costs.
We'll just have to do some sort of evaluation first.

> - You talk about two key areas that JMX can contribute to: monitoring and tuning.  I
would assume "tuning" includes general system configuration too.  I can see all the existing
Derby properties being exposed through a JMX interface.

Precisely. I think that should be our first starting point. Expose all
the properties.
> - Under proposed features, it would really help if each feature had its own unique identifier,
like MON-1, MON-2, MAN-1, MAN-2, NOT-1, NOT-2, etc.

Good idea. Will do that.

> - A well-thought-out and great list of features!  There are a *lot* of features here.

Thank You!!

>So, how to decide?  Your separate table with priorities is one
approach, but I'd >like to propose something a little more
interactive.  I'd like the feature list section >of the document to a
Wiki page (or maybe it makes sense to migrate the entire >document to
Wik? - your call), and announce it on the derby-user and derby-dev
>lists.  Each developers/user could add a column to the table and
assign their >priorities to each feature.   This would be a chance for
the community to get >involved in picking which JMX features they'd
like to see.


> If you do decide to stick with the current model, I highly recommend merging the priorities
with the main feature table, so you are not constantly having to keep the two in synch, and
so that readers don't have to keep switching back and forth between the two tables.

I think Wiki is more interactive. I'll try and put the tables up on
wiki. Last time I tried the table lost its formatting.
> - I'm a little confused about not providing remote access.  Can you describe how >an
administrator who is not aJMX programmer can view, monitor, and tune an >embedded Derby
database that is not part of a larger application framework that >provides JMX support?
 Whenever I talk to users, remote monitoring and >administration are on the TOP of their
list.  I think this is required, but we do have >to make sure we understand the security
implications of such a topology.

For me, its more of a philosophical issue than anything. If I "embed"
something inside my application, then I should not expose it directly
to outside world.

However, thats one philosophy. My initial take was to provide remote
accessibility, because it makes so much sense. If you have 10 such
applications running on 10 different machines it would certainly be
nice to monitor them from one central location. And it also goes with
the Derby on Amazon S3 device ;-). JMX supports few protocol
connectors that let you monitor your applications/devices over
different protocols like SNMP/HTTP etc.
Anyways, an administrator not using API's has two options:
1)Browser interface: JMX provides a default web interface which is
very primitive. We might have to do some Servlet/JSP to improve
interface and to allow management of multiple instance
2)Using a management Console: This would be a Java GUI application
that can connect to Derby instances using RMI.

These are the two trivial cases. JMX can also work over array of other
Let me know if it clears your doubts.
One more thing I would like to add is that Security should not be a
concern as Sun defines a whole bunch of API's to handle that.

> - A commonly missed aspect of requirements documents are non-functional requirements.
 These are "qualities" of the overall feature.  Things like performance (response time, thorughput,
number of concurrent users), security, ease of use, etc.

Yeh..I missed those completely. Will update my document soon.
> - You had mentioned building our own JMX console.  Is that still on the plate?  Or do
we just let existing JMX tools plug into our framework?
I guess if usability and ease of use is our concern, we will have to
do it? or atleast build something on top of existing tools.

Best Regards,
Sanket Sharma

View raw message