[jira] Commented: (RIVER-273) Implement discovery kernel

["Jonathan Costers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912240#action_12912240 ] 

Jonathan Costers commented on RIVER-273:
----------------------------------------

It is stated above that code was written for this "discovery kernel", that could possibly be incorporated into the River project.

Would anyone be able to contribute a patch? Or point us to the code in question?

> 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
>            Assignee: Mark Brouwer
>             Fix For: AR3
>
>
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.