RIVER-273

[Jools Enticknap <jo...@gmail.com>]

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.

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

Re: RIVER-273

[Jools Enticknap <jo...@gmail.com>]

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,

Re: RIVER-273

[Mark Brouwer <ma...@cheiron.org>]

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,
-- 
Mark