river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jools Enticknap <jool...@gmail.com>
Subject Re: RIVER-273
Date Wed, 21 May 2008 08:33:19 GMT

Hi Mark,

Thanks for the response, and sorry for rather tardy one !

If I can help in the testing, and merging of the code into the current 
codebase, please let me know.


Cheers,

--Jools

> Hi Jools,
>
> Jools Enticknap wrote:
>>
>>
>> Hi All,
>>
>> Just been reviewing some of the outstanding issues in Jira firstly 
>> looking for ways in which I can donate some time to helping getting 
>> issues resolved.
>
> Cool.
>
>> I noticed this items RIVER-273, which discusses a new discovery 
>> Kernel, but it does not give any information regarding where the code 
>> has been submitted.
>>
>> @Mark, Could you let me know where the code is in subversion ?
>>
>> Cheers,
>>
>> --Jools
>
> The code is not in Subversion yet although it is live and kicking. The
> code for River-273 which has been developed by Vinod (and modified by me
> for configuration purposes and for a further reduction and threads
> referred to as RIVER-174 and incorporation of RIVER-205 and RIVER-215)
> is in production for almost 2 years now as part of Seven at various
> places (It is part of the 0.1.2 release). However due to the long time
> between the latest JTSK and the version of the JTSK the Cheiron project
> is using (containing other required enhancements) the patch isn't that
> trivial to distill anymore. Other enhancements touched the same classes
> as the ones modified due to the discovery kernel. Nevertheless this work
> has to be done and I guess that the coming weeks I can make some time
> free to do this.
>
> Testing is the hard part though for me as I don't know how to run the QA
> framework for Jini. I test modifications of the JTSK codebase through
> Seven but as that one relies on other enhancements as well I might have
> problems validating the River codebase at this point in time. So if you
> could help here (as well as the code review) that would be really great.
>
> BTW are you experiencing problems due to the number of
> net.jini.discovery.LookupDiscovery related threads?
>
> The actual savings you can get with the discovery kernel depends on many
> factors, whether you have multiple LookupDiscovery instances (for the
> same set of interfaces) in one service, or that you have many services
> running in one JVM. In the latter case the largest reduction can be
> obtained by making the discovery kernel part of the Platform JAR file,
> which I believe is the default for River. In my case the example given
> in the issue about the 200 threads (multicast announcement timer threads
> and multicastdiscovery announcement listener threads) I was able to
> reduce them to 2 threads but that is because I'm able to share a
> (virtual) WakeupManager (RIVER-174) between various LookupDiscovery
> instances for which. Anybody can do this and if you are interested I can
> explain how to do that. In case you don't want to share a WakeupManager
> the saving is about 99 threads in this case.
>
> Regards,



Mime
View raw message