Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4C2B200C.6050807@zeus.net.au>
Date: Wed, 30 Jun 2010 20:44:28 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: A new implementation of TaskManager
References: <4C234036.20401@acm.org> <4C234E6D.6050306@zeus.net.au>
 <4C234FB1.5000700@zeus.net.au> <4C28AB68.6020204@acm.org>
 <4C29D012.9030504@zeus.net.au> <4C2A6715.4030902@acm.org>
In-Reply-To: <4C2A6715.4030902@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I started thinking about a replacement, it's in org.apache.river.imp.util.

The name spaces are as follows:

net.jini.* API - must be backward compatible, or breakage minimal for if 
there's a good reason.
com.sun.jini.* - implementation, subject to change.
com.artima.* - implementation, subject to change.
org.apache.river.api.* - new API under review, please feel free to look 
for ways to improve before its frozen in November / December.
org.apache.river.imp.* - new implementation, subject to change, 
eventually the com.* namespace will move there too.

Best bet would be to search for the classes that depend on the Task 
interface, see how they use it and come up with something better.

Agreed, the Task interface is less than optimum, best to replace it.  
TaskManager has been identified as a performance bottleneck.

Thanks,

Peter.

Patricia Shanahan wrote:
> Thanks. I'll ask TaskManager specific questions in this thread, and 
> create a new thread for getting started questions.
>
> The main difficulty I've found so far is the runAfter method in the 
> Task interface. As currently defined, it requires the runAfter caller 
> to have the tasks in question as the first i elements of a List with 
> efficient random access. Although get is indeed marginally faster than 
> an Iterator for random access List implementations, it is 
> unfortunately slow and inflexible for anything else.
>
> Is this interface something that could be changed, subject to 
> corresponding changes in the callers in River, or is it an external 
> interface that cannot change?
>
> In general, the design of TaskManager involves a lot of scans, 
> insertions, and removals in an ArrayList. Has this caused any 
> performance problems, or are the operations sufficiently infrequent 
> and the number of tasks small enough for it to not be an issue?
>
> Patricia
>
> On 6/29/2010 3:50 AM, Peter Firmstone wrote:
>> Yes, river-dev is for general development discussion and questions,
>> river-commits for svn commits and jira issues which are automatically
>> posted. Developers with commit access have a private list for discussing
>> potential new committers based on merit etc, but most things are done in
>> the open.
>>
>> I believe at one stage there was tool com.sun.jini.tool.CheckCodeStyle,
>> there is a test in
>> trunk/qa/jtreg/com/sun/jini/tool/CheckCodeStyle/test.sh The test gives
>> you an idea of the code style required, however the actual tool used for
>> checking code is not present in the source.
>>
>> Fire away...
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> Patricia Shanahan wrote:
>>> I've started taking a look at the code, and have questions ranging from
>>> basic building through coding conventions to details of runAfter usage.
>>>
>>> If I were joining a co-located project I would be arranging to have
>>> lunch and an informal chat with one or more of the existing developers.
>>> Is this mailing list the lunch room, or is there somewhere more
>>> appropriate?
>>>
>>> Patricia
>>>
>>
>>
>>
>
>