[RIVER-273] Implement discovery kernel

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Abandoned
• Affects Version/s: jtsk_2.1
• Component/s: com_sun_jini_discovery
• Assignee: Unassigned
• Reporter: Mark Brouwer
• Created: 23/Nov/07 19:20
• Updated: 10/Aug/19 00:04
• Resolved: 10/Aug/19 00:04

Description

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:

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.

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.

Issue Links

• incorporates: RIVER-205 LookupDiscovery can give untrusted code access to privileged threads
• incorporates: RIVER-215 LookupDiscovery throws NullPointerException on terminate
• relates to: RIVER-174 LookupDiscovery could use a WakeupManager to schedule its announcement timeout check.