You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2005/03/23 06:36:08 UTC
Thoughts on the to-do list
In reexamining the to-do list I think we should consider identifying some low hanging fruit or mark projects as beginner, intermediate and advanced. We could add in notes for recommended implementation and perhaps identify a committer willing to volunteer not to do the
project but serve as mentor or consultant on the project, promising to at least respond to questions that the implementer asks on the list if not answered by someone else, review code submissions etc. This way can give potential contributors the support they need to add value to Derby and reach committer status.
For the low hanging fruit, not only features, but bugfixes could be identified as well.
In an even more interactive scenario, less experienced developers could team up with those working on projects of interest and learn a lot. I am sure everyone who is working on Derby could could use help on the projects that we are working on, so if you are interested in anything that is going on, please speak up and I am sure there is plenty to do.
A couple of items off the top of my head in the beginner low hanging fruit category.
The long identifier patch was very close and just needed resolution of some test issues and some tests added I think. Maybe somebody could contact that person and offer to clean up their patch if they will resubmit it with the changes. I think (not sure) the original author has to submit it but I could be wrong here.
The repro for Derby- 176
Derby throws ERROR XBCM1: Java linkage error thrown during load of generated class org.apache.derby.exe.aced07c066x0102xca87x3319x00004aa5686e1 during execution of large query
could really use some additional test cases, to get the code generation issue fixed for sure this time. Think big, big in clauses, huge joins, anything you can do in a big way. The repro was submitted in the functional tests format. We could go ahead and check it in with low limits and raise them up as we fix the issues.
Rename that darn DB2jServerImpl to NetworkServerControlImpl. Every week I tell myself I'm going to do it but just never do.
Clean up the javadoc.
Help facilitate the new and improved to-do list. Maybe a wiki would be good.
Incorporate more tests into the network server suite.
In the intermediate category.
I would really love to do some performance, capacity and memory work on Network Server and I think there are lots of opportunities there. It's not that much code either so perhaps less intimidating than diving into the core database.
Anyway, just a few thoughts, but I would be really interested in hearing what folks are interested in working on, because I could make a big list of things that nobody cared about and that wouldn't be that productive. I would love to hear what projects folks want to work on (whether they feel they can take it on alone or not) and then we can bring our to-do list to life.
Thanks for listening
Please post your ideas.
Kathey
Re: Thoughts on the to-do list
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Summary: we can't add a new issue type ("Performance") like we can
components. But you can specify multiple components for a given issue;
for example, "Network Server" and "Performance".
-jean
Jean T. Anderson wrote:
> Jean T. Anderson wrote:
>
>> Sunitha Kambhampati wrote:
>>
>>> <snip /> There are performance related jira entries but i think they
>>> have been logged as bugs /improvement. In Jira, the list of
>>> possible values for IssueType does not have performance. Should/can
>>> we add it ?
>>
>>
>>
>> I just added "Performance" to Derby's list.
>
>
> Actually, I added this as a component, which is on part with
> "Documentation, JDBC, Localization, Security" etc.
>
> I can't seem to add it at the same level as "Bug, New Feature,
> Improvement" etc, which is what Sunitha originally requested.
>
> Could another committer with Jira admin try adding Performance to the
> system defaults on this form?
>
> http://issues.apache.org/jira/secure/project/ManageFieldLayoutSchemes.jspa?pid=10594
>
>
> thanks,
>
> -jean
Re: Thoughts on the to-do list
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Jean T. Anderson wrote:
> Sunitha Kambhampati wrote:
>
>> <snip /> There are performance related jira entries but i think they
>> have been logged as bugs /improvement. In Jira, the list of possible
>> values for IssueType does not have performance. Should/can we add it ?
>
>
> I just added "Performance" to Derby's list.
Actually, I added this as a component, which is on part with
"Documentation, JDBC, Localization, Security" etc.
I can't seem to add it at the same level as "Bug, New Feature,
Improvement" etc, which is what Sunitha originally requested.
Could another committer with Jira admin try adding Performance to the
system defaults on this form?
http://issues.apache.org/jira/secure/project/ManageFieldLayoutSchemes.jspa?pid=10594
thanks,
-jean
Re: Thoughts on the to-do list
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Sunitha Kambhampati wrote:
> <snip />
> There are performance related jira entries but i think they have been
> logged as bugs /improvement. In Jira, the list of possible values for
> IssueType does not have performance. Should/can we add it ?
I just added "Performance" to Derby's list.
-jean
Re: Thoughts on the to-do list
Posted by Sunitha Kambhampati <ks...@gmail.com>.
> o Query Jira for existing performance bugs.
>
>
There are performance related jira entries but i think they have been
logged as bugs /improvement. In Jira, the list of possible values for
IssueType does not have performance. Should/can we add it ?
Thanks,
Sunitha.
Re: Thoughts on the to-do list
Posted by Jeremy Boynes <jb...@apache.org>.
Kathey Marsden wrote:
> o Some sort of automatic connection thread management for Network
> Server.
> Currently for network server the Connection Threads are created
> on demand and recycled,
> but never reclaimed if the load is low.
>
How about an abstraction for thread management in general so that if
Derby is run inside an app server the app server can control the
resources available to the database?
Something to consider is the proposal for JSR-237 (Work Manager).
--
Jeremy
Re: Thoughts on the to-do list
Posted by Kathey Marsden <km...@sbcglobal.net>.
Darcy Benoit wrote:
> Presently, I want my students to be working on just about anything
> that will improve the performance of Derby. It would be a bonus for
> my research area if this performance improvement was autonomic
> (something resource that can automatically adjust itself depending on
> the performance of the system).
>
To keep Derby zero admin I think there is a need for a general mechanism
to perform this kind of automatic admin function. Here are a couple of
specific examples that I know of.
o Some sort of automatic connection thread management for Network
Server.
Currently for network server the Connection Threads are created
on demand and recycled,
but never reclaimed if the load is low.
o A zero administration implementation of DERBY-269 to update
cardinality statistics would be very helpful.
In the general performance area.
o Query Jira for existing performance bugs.
o Profile Network Server and the client to identify areas for
improvement.
o Research optimizer improvements.
We get requests for optimizer directives, but for a zero admin
database, we have to ask why.
Ideally the optimizer always knows best #:)
> The second student is doing a general overview of Derby - the
> structure of the code, where the interesting stuff is happening, how
> to get involved in the community, how to do some of the more simple
> patches, etc. He's been posting on the group every once in a while
> and will hopefully do some bug fixes over the summer.
Can this student pick up and prioritize Derby 257 (Format Contributing
to Derby, Tips and Tasks To Get You Started Document for the website)
and link it in to the to-do list?
Thanks
Kathey
Re: Thoughts on the to-do list
Posted by Darcy Benoit <da...@acadiau.ca>.
On Mon, 28 Mar 2005 15:59:19 -0400, Kathey Marsden
<km...@sbcglobal.net> wrote:
> Darcy Benoit wrote:
>
>> On Tue, 22 Mar 2005 21:36:08 -0800, Kathey Marsden
>> <km...@sbcglobal.net> wrote:
>>
>>> In reexamining the to-do list I think we should consider identifying
>>> some low hanging fruit or mark projects as beginner, intermediate and
>>> advanced.[snip]
>>
>> Kathey,
>> I must say that I really like this idea. I've been following the
>> Derby group since the fall, and I have been trying to find the time to
>> get involve but have been unable to find a good starting point.
>> [snip]
>>
>> darcy
>>
>
> I am so glad to hear back on this. Since you are the first to
> respond. I can customize the first set of getting started projects
> that fit the interests of you and your students. I'll post them here
> and then hope that someone with web skills and access will pretty them
> up for the website.
Kathey,
Sorry for taking so long to get back to you on this. Things have been
hectic for a while, but have just managed to calm themselves down enough
for me to get back to this topic.
> Questions
> Are you and your students interested in projects in network server,
> embedded derby or both?
In this case both. We will be using Derby both ways.
> Could you explain a little what you mean by autonomic features and
> maybe give an example?
Most of my work revolves around the automatic diagnosis of performance
problems in DB2. Others that I have worked with did things like work out
algorithms to automatically resize the buffer pools for OLTP workloads. My
area was less of working out an automated tuning algorithm and more of
working on how to determine which database resource needed to be adjusted
in order to fix the tuning problem. I am hoping that I might be able to
apply some of that knowledge to Derby.
Presently, I want my students to be working on just about anything that
will improve the performance of Derby. It would be a bonus for my research
area if this performance improvement was autonomic (something resource
that can automatically adjust itself depending on the performance of the
system).
I am using Derby in several projects at the moment. The first student is
using Derby as an embedded database in a grid project to survey the size
of the web. The second student is doing a general overview of Derby - the
structure of the code, where the interesting stuff is happening, how to
get involved in the community, how to do some of the more simple patches,
etc. He's been posting on the group every once in a while and will
hopefully do some bug fixes over the summer. I have a third student who is
looking at automated checkpointing. A fourth student is considering
working on the in-memory database stuff. And a fifth student is working on
indexing at the moment.
Anyway, sorry for taking so long to reply. I know that stuff has been done
on this already, and I like it. It makes getting my students involved much
easier. :)
darcy
--
Dr. Darcy Benoit
http://cs.acadiau.ca/~dbenoit/
Re: Thoughts on the to-do list
Posted by Kathey Marsden <km...@sbcglobal.net>.
Darcy Benoit wrote:
> On Tue, 22 Mar 2005 21:36:08 -0800, Kathey Marsden
> <km...@sbcglobal.net> wrote:
>
>> In reexamining the to-do list I think we should consider identifying
>> some low hanging fruit or mark projects as beginner, intermediate and
>> advanced. We could add in notes for recommended implementation and
>> perhaps identify a committer willing to volunteer not to do the
>> project but serve as mentor or consultant on the project, promising
>> to at least respond to questions that the implementer asks on the
>> list if not answered by someone else, review code submissions etc.
>> This way can give potential contributors the support they need to add
>> value to Derby and reach committer status.
>
>
> Kathey,
> I must say that I really like this idea. I've been following the
> Derby group since the fall, and I have been trying to find the time to
> get involve but have been unable to find a good starting point. I also
> have a group of several undergrad and MSc students who I want to work
> developing Derby (specifically from the perspective of autonomic
> features and performance), but don't really know where to get them to
> start. A list of small targets with identified help would make it
> easier for people to get their feet wet working on the code and lead
> to more contributions. Anything that can help people who have never
> been involved in an open source project would be useful.
>
> darcy
>
I am so glad to hear back on this. Since you are the first to
respond. I can customize the first set of getting started projects
that fit the interests of you and your students. I'll post them here
and then hope that someone with web skills and access will pretty them
up for the website.
Questions
Are you and your students interested in projects in network server,
embedded derby or both?
Could you explain a little what you mean by autonomic features and
maybe give an example?
Again thanks for the interest.
Kathey
Re: Thoughts on the to-do list
Posted by Darcy Benoit <da...@acadiau.ca>.
On Tue, 22 Mar 2005 21:36:08 -0800, Kathey Marsden <km...@sbcglobal.net> wrote:
> In reexamining the to-do list I think we should consider identifying some low hanging fruit or mark projects as beginner, intermediate and advanced. We could add in notes for recommended implementation and perhaps identify a committer willing to volunteer not to do the
> project but serve as mentor or consultant on the project, promising to at least respond to questions that the implementer asks on the list if not answered by someone else, review code submissions etc. This way can give potential contributors the support they need to add value to Derby and reach committer status.
Kathey,
I must say that I really like this idea. I've been following the Derby group since the fall, and I have been trying to find the time to get involve but have been unable to find a good starting point. I also have a group of several undergrad and MSc students who I want to work developing Derby (specifically from the perspective of autonomic features and performance), but don't really know where to get them to start. A list of small targets with identified help would make it easier for people to get their feet wet working on the code and lead to more contributions. Anything that can help people who have never been involved in an open source project would be useful.
darcy
--
http://cs.acadiau.ca/~dbenoit/