river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Trasuk (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (RIVER-273) Implement discovery kernel
Date Wed, 24 Apr 2013 15:57:16 GMT

     [ https://issues.apache.org/jira/browse/RIVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Greg Trasuk updated RIVER-273:

    Fix Version/s:     (was: River_2.2.1)

Not addressed in 2.2.1 maintenance release.
> 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
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message