river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Costers (JIRA)" <j...@apache.org>
Subject [jira] Commented: (RIVER-273) Implement discovery kernel
Date Sun, 19 Sep 2010 15:21:36 GMT

    [ 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.

View raw message