You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/06/06 04:42:18 UTC

A new implementation of TaskManager

A new implementation of TaskManager could take advantage of:

java.util.concurrent.PriorityBlockingQueue

However there is risk inherent in using Comparator, this could introduce 
new bugs and may not be appropriate:

    "Caution should be exercised when using a comparator capable of
    imposing an ordering inconsistent with equals to order a sorted set
    (or sorted map). Suppose a sorted set (or sorted map) with an
    explicit comparator c is used with elements (or keys) drawn from a
    set S. If the ordering imposed by c on S is inconsistent with
    equals, the sorted set (or sorted map) will behave "strangely." In
    particular the sorted set (or sorted map) will violate the general
    contract for set (or map), which is defined in terms of equals."

There is one particular featuresabout TaskManager's implementation I 
don't like:

   1. Fields that rely on synchronized methods for safety, are declared
      protected, so a subclass could destroy the synchronization safety
      of TaskManager.


TaskManager is utilised by the following Jini API classes:

LookupDiscovery
LookupLocatorDiscovery
LeaseRenewalManger
ServiceDiscoveryManager
JoinManager

If we are to refactor the classes in com.sun.jini.thread, I think we'd 
need to refactor everything that relies on them too and this will take 
some work.

If someone is willing to donate time, I'm certainly for such a refactoring.

Regards,

Peter.


Re: A new implementation of TaskManager

Posted by Peter Firmstone <ji...@zeus.net.au>.
To clarify, I mean using as much from java.util.concurrent as possible.

Peter Firmstone wrote:
>
> If we are to refactor the classes in com.sun.jini.thread, I think we'd 
> need to refactor everything that relies on them too and this will take 
> some work.
>
> If someone is willing to donate time, I'm certainly for such a 
> refactoring.
>
> Regards,
>
> Peter.
>
>