You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Sanket Sharma <sa...@gmail.com> on 2006/06/15 21:02:50 UTC

Deadline: Monitoring and Management Requirements for Derby June 18

Hi,
We request all Derby users to please look at the document called
"Requirement Specifications for Monitoring & Management Extensions
using JMX" at the Derby Wiki and assing priorities to the features
they feel are most important.

We will be freezing the requirements document on 18th June so *please*
make sure that you do review the document and let us know what is
important for you and what monitoring and management features would
like to see in Derby!

In case you feel some features are missing from the matrix, please
feel free to add those features along with comments.

The Wiki can be reached at
http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX

Thank You

Best Regards,
Sanket Sharma

Re: Deadline: Monitoring and Management Requirements for Derby June 18

Posted by Craig L Russell <Cr...@Sun.COM>.
I have to agree that the focus of the project should be on the  
implementation of the MBeans for Derby. Lots of clients can access  
the properties exposed by the MBean.

Craig

On Jun 19, 2006, at 3:11 PM, David Van Couvering wrote:

>
>
> Sanket Sharma wrote:
>> What ever feature I deliver, will be through a nice GUI console or a
>> web interface.
>
> I would argue it's more important to get the basic MBeans written  
> and the JMX infrastructure in place before implementing a GUI.  As  
> of JDK 1.5 the tools include jconsole - see http://java.sun.com/ 
> developer/technicalArticles/J2SE/jconsole.html.  Do we really need  
> to spend a lot of time building a GUI?
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Re: Deadline: Monitoring and Management Requirements for Derby June 18

Posted by David Van Couvering <Da...@Sun.COM>.

Sanket Sharma wrote:
> What ever feature I deliver, will be through a nice GUI console or a
> web interface.

I would argue it's more important to get the basic MBeans written and 
the JMX infrastructure in place before implementing a GUI.  As of JDK 
1.5 the tools include jconsole - see 
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html.  Do 
we really need to spend a lot of time building a GUI?



Re: Deadline: Monitoring and Management Requirements for Derby June 18

Posted by Sanket Sharma <sa...@gmail.com>.
Hi,
Apologize for the late reply.

> It is a little hard to understand what I am voting on without details
> of what is going to be provided.  Do you recommend any specific reading
> to be able to understand jmx and what you want to do for derby in that
> context.

Check out the references on the Requirements for JMX page.
The following article from IBM developerworks is also a good read to
gain a general understanding about JMX and its uses.
http://www-128.ibm.com/developerworks/java/library/j-jmx1/

I'm also writing a small article that describes what JMX is and what
it can do for Derby. It will be up on wiki in a few days.

  For instance derby already presents
> a way to look at a list of all locks in the system, if you are just
> going to repackage the list into a different linear list then that is
> not that interesting, but if you will provide a much friendly view of
> the info then I would rate that high.

Nope. Not just repackaging. A console and/or a web interfaces is on the cards.
>
> Some of the low level monitoring is hard to comment on without
> understanding the costs incurred by the monitoring.  xact/second may
> be interesting but not at the cost of slowing down every xact in the
> system.
>
Agreed. I'll need a way to figure the costs and put it up on the wiki
for further discussion.
> I would rate creating and using a backup as 4's, it would be really nice
> to have a user friendly way to do this.  Even better would be a user
> friendly way to set up a system of daily incremental using rollforward
> backup and weekly full backup.

What ever feature I deliver, will be through a nice GUI console or a
web interface.

> I would rate running recovery as 0, there is no way to run recovery
> other than automatically by connecting to the system.
>
> I would add compressing a table to management, probably same priority
> as rebuilding indexes.


> Depending on when suresh is done it may be nice to add encrypting
> existing db to management, i believe interfaces are already checked in
> so early development on management should be possible.

Note taken.


> Are "notifications" binary this happened events, or is info also passed.
> A programatic way to get the query text of executing queries may be
> interesting - I don't know if this is monitor or notification.

Some info will passed to give application some idea of what happened exactly.
Are you referring to Query plan when you say "query text of executing queries".
If yes, than that is already on list under monitoring features (Mon 19)

> how about compile vs. execution time of queries.

I'll have to check the overheads involved. Will get back with stats on
these issues.

Thank you for your feedback!!

Best Regards,
Sanket Sharma

Re: Deadline: Monitoring and Management Requirements for Derby June 18

Posted by Mike Matrigali <mi...@sbcglobal.net>.
Sanket Sharma wrote:
> Hi,
> We request all Derby users to please look at the document called
> "Requirement Specifications for Monitoring & Management Extensions
> using JMX" at the Derby Wiki and assing priorities to the features
> they feel are most important.
It is a little hard to understand what I am voting on without details
of what is going to be provided.  Do you recommend any specific reading
to be able to understand jmx and what you want to do for derby in that
context.  For instance derby already presents
a way to look at a list of all locks in the system, if you are just
going to repackage the list into a different linear list then that is
not that interesting, but if you will provide a much friendly view of
the info then I would rate that high.

Some of the low level monitoring is hard to comment on without 
understanding the costs incurred by the monitoring.  xact/second may
be interesting but not at the cost of slowing down every xact in the
system.

I would rate creating and using a backup as 4's, it would be really nice
to have a user friendly way to do this.  Even better would be a user
friendly way to set up a system of daily incremental using rollforward
backup and weekly full backup.

I would rate running recovery as 0, there is no way to run recovery
other than automatically by connecting to the system.

I would add compressing a table to management, probably same priority
as rebuilding indexes.

Depending on when suresh is done it may be nice to add encrypting 
existing db to management, i believe interfaces are already checked in
so early development on management should be possible.

Are "notifications" binary this happened events, or is info also passed.
A programatic way to get the query text of executing queries may be
interesting - I don't know if this is monitor or notification.

how about compile vs. execution time of queries.

> 
> We will be freezing the requirements document on 18th June so *please*
> make sure that you do review the document and let us know what is
> important for you and what monitoring and management features would
> like to see in Derby!
> 
> In case you feel some features are missing from the matrix, please
> feel free to add those features along with comments.
> 
> The Wiki can be reached at
> http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX 
> 
> 
> Thank You
> 
> Best Regards,
> Sanket Sharma
> 
> 


Re: Deadline: Monitoring and Management Requirements for Derby June 18

Posted by David Van Couvering <Da...@Sun.COM>.
Thanks, Sanket, great email.  One small point, nothing major at all. 
Apache is seen as a community of individual volunteers rather than 
groups and sub-groups; thus 'we request' should probably have been 'I 
request'.

Cheers,

David

Sanket Sharma wrote:
> Hi,
> We request all Derby users to please look at the document called
> "Requirement Specifications for Monitoring & Management Extensions
> using JMX" at the Derby Wiki and assing priorities to the features
> they feel are most important.
> 
> We will be freezing the requirements document on 18th June so *please*
> make sure that you do review the document and let us know what is
> important for you and what monitoring and management features would
> like to see in Derby!
> 
> In case you feel some features are missing from the matrix, please
> feel free to add those features along with comments.
> 
> The Wiki can be reached at
> http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX 
> 
> 
> Thank You
> 
> Best Regards,
> Sanket Sharma