[SNMP4J] Problem with Snmp.removeNotificationListener

[Frank Fock]

Hi Nídia,

Ok, now I understand the problem and already found a fix
(to be honest, I think I found one):

     public synchronized boolean
         removeNotificationListener(Address listenAddress)
     {
       TransportMapping tm =
           (TransportMapping)notificationListeners.remove(listenAddress);
       if (tm == null) {
         return false;
       }
       //---> Add the following line to fix the memory leak:
       notificationTransports.remove(tm);
       tm.removeTransportListener(messageDispatcher);

       try {
         tm.close();
       }
       catch (IOException ex) {
         logger.error(ex);
         if (logger.isDebugEnabled()) {
           ex.printStackTrace();
         }
       }
       return true;
     }

Hope this helps.

Best regards,
Frank

Nídia S. Campos wrote:
> Hi Frank,
> No. In fact, I want that users control theses ports
> and I initialize them instancing UdpAddress and  TcpAddress objects
> with the last value from a configuration file.
> 
> For example, if the latest value is 196.135.146.15/162,
> then a Thread will be created to DefaultUdpTransportMapping with this value
> when I start it up.
> But, if I want to change it for 196.135.146.15/15789 in running time,
> I use Snmp.removeNotificationListenener() to remove the older port
> and after  Snmp.addNotificationListenener() to add the new one.
> 
> The problem is DefaultUdpTransportMapping's thread with the first
> address/port remains after use Snmp.removeNotificationListenener() and I
> think that it should be killed, don't you?
> if I want to change this port again and again, it'll work,
> but  that DefaultUdpTransportMapping's thread, the first one, from
> initialization
> remains during all running time.
> The methode  Snmp.removeNotificationListenener() doesn't work for the first
> DefaultUdpTransportMapping added using Snmp.addNotificationListenener().
> 
>>
> I'm using the latest Snmp4J version.
> 
> Did you understand it?
> 
> Thank you very much for your help,
> Nídia
> 
> 2007/2/12, Frank Fock < fock at agentpp.com>:
>>
>> Hi Nídia,
>>
>> If I understand you right then you want to
>> dynamically control trap receiving ports (addresses).
>> Then you should use the default constructor of
>> Snmp() to create your instance.
>>
>> Using that, you will not have any "initialization"
>> transport mapping.
>>
>> Does this help?
>>
>> Best regards,
>> Frank
>>
>> Nídia S. Campos wrote:
>> > Hi!
>> > I've configured  my manager to listen UDP and TCP traps using
>> > Snmp.addNotificationListener(), and,  
>> Snmp.removeNotificationListener ()
>> > with
>> > respectives addresses to change port addresses.
>> > Debugging, I notice that it doesn't work to DefaultUdpTransportMapping
>> port
>> > trap that the manager is initialized with, then a new thread is created
>> and
>> > the older isn't killed. If I change the port again, it works but the 
>> one
>> of
>> > initialization remains....
>> > To DefaultTcpTransportMapping, it works but
>> > Snmp.removeNotificationListener()
>> > returns false.
>> >
>> > So, anyone may help me?
>> >
>>
>> -- 
>> AGENT++
>> http://www.agentpp.com
>> http://www.mibexplorer.com
>> http://www.mibdesigner.com
>>
>>
> 
> 

-- 
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com