db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Thu, 08 Jun 2006 18:52:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12415402 ] 

David Van Couvering commented on DERBY-1387:
--------------------------------------------

Hi, Sanket, thanks for a very nicely organized and formatted set of requirements!

Here are my comments:

- 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.

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...

- 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.

- 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.

- A well-thought-out and great list of features!  There are a *lot* of features here.   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'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.

- 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.


- 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?



> Add JMX extensions to Derby
> ---------------------------
>
>          Key: DERBY-1387
>          URL: http://issues.apache.org/jira/browse/DERBY-1387
>      Project: Derby
>         Type: New Feature

>     Reporter: Sanket Sharma
>     Assignee: Sanket Sharma
>  Attachments: Requirements for JMX Updated.html, Requirements for JMX.html, Requirements
for JMX.zip
>
> This is a draft proposal for adding JMX extensions to Derby as part of Google Summer
of Code project. I have identified and enlisted few features that might be added to derby.
The list is open for discussion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message