[
https://issues.apache.org/jira/browse/RIVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Firmstone closed RIVER-273.
---------------------------------
Resolution: Abandoned
While an interesting feature, the code was never donated.
> Implement discovery kernel
> --------------------------
>
> Key: RIVER-273
> URL: https://issues.apache.org/jira/browse/RIVER-273
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_discovery
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Priority: Major
>
> This issue is relates to a thread during the Porter project that had as
> subject "Thread creation within JTSK utilities" and for which we have
> unfortunately no archives. The initial discovery was:
> {quote}
> Also after researching 600+ threads in a system that was not doing anything
> beside the normal (idle) activities of the JTSK utilties and some blocking
> takes that were refreshed after some timeout, I found out that there were
> *199* threads that were directly related to
> {{net.jini.discovery.LookupDiscovery}} and these worries me a lot. I counted:
> 99 - multicast announcement timer threads
> 100 - multicast discovery announcement listener threads
> Please don't ask me where one multicast announcement timer went :-) , so it
> appears that there are 100 threads that are listening for multicast
> announcement. And I've got the feeling that when we have multiple instances
> (often 5+) of this software systems running on a 4CPU Sun E420 that this is
> what is bringing it to its knees. So I was wondering whether it wouldn't be
> possible in the future to modify this utility in such a way that not for each
> instance a blocking thread would be created that is bound to one or more
> interfaces and listening to multicast packets, but that some sort of
> discovery kernel would be establised that would have support for NIO,
> various instances of LookupDiscovery on top of this but each with its own
> associated ACC and CCL.
> Unfortunately I can't resuse {{LookupDiscovery}} for the various sdm and join
> managers as services have the ability to modify the groups and lookup locator
> for each of these therefore I need to have a one to one relation ship with
> {{LookupDiscovery}} and each of the JTSK utilties that uses them.
> {quote}
> As result of the above observation a discovery kernel has been developed by
> Sun that can result in massive resource savings under some circumstances and
> which has been slightly modified for configuration purposes. This kernel has
> been running happily for a long time and should flow back to the River
> codebase.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
