river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brouwer (JIRA)" <j...@apache.org>
Subject [jira] Created: (RIVER-273) Implement discovery kernel
Date Fri, 23 Nov 2007 19:20:43 GMT
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: AR2


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.


Mime
View raw message