R: Re: R: Re: [SNMP4J] IllegalStateException in Snmp.send()
Alberto
alberto_mascheroni at fastwebnet.it
Fri Dec 15 16:47:13 CET 2006
Hi Frank,
you suppose right: we use both synchronous and asynchronous (much less)
requests, but up to now the problem occurred only with synchronous ones.
We applied your patch, started the usual tests and got no more
IllegalStateException until now. Tests are anyway still running, I will let you
know.
It seems however there is a little drawback with your correction. Our
application retrieves some table data from every connected agent every 15
minutes with Snmp GET-BULK commands.
Sometimes data from a single agent are not collected: agent is normally
connected, I am quite sure data are available in the agent (I'm trying to set
up a sniffer to be confirmed), but the list of table rows returned by the
library is empty.
Just before we get the list back from snmp4j lib, I can see traces like these
in snmp4j log:
15/12/2006 15:46:03:673 DEBUG [SNMPDriverDispatchPool.0] [Log4jLogAdapter.
debug] Canceling pending request with handle null
I suppose that in these cases your correction avoided the retry handler thread
death, but resulted in returning empty values to the current command.
Could you also check this?
Thank you,
Alberto
>----Messaggio originale----
>Dal: fock at agentpp.com
>Data: 15/12/2006 1.56
>A: "Alberto"<alberto_mascheroni at fastwebnet.it>
>Cc: <snmp4j at agentpp.org>
>Ogg: Re: R: Re: [SNMP4J] IllegalStateException in Snmp.send()
>
>Hi Alberto,
>
>According to your and the others' information I have
>revisited the current synchronous Snmp.send(..) code
>and found a possible cause of the exception.
>
>Please try out the following modification of the
>synchronous send method. The difference is the
>additional "synchronized" block with the comment:
>
> public ResponseEvent send(PDU pdu, Target target,
> TransportMapping transport) throws
>IOException {
>
>...
>
> if (retryRequest != null) {
> retryRequest.setFinished();
> // We need to synchronize here to make sure that the retryRequest
> // is already scheduled when we cancel it. Otherwise it might be
> // canceled before being scheduled which results in an
> // IllegalStateException being thrown in the retry handler.
> synchronized (sync) {
> retryRequest.cancel();
> }
> }
>...
> }
>
>Is my assumption correct that you are using synchronous
>requests?
>
>Best regards,
>Frank
>
>
>Alberto wrote:
>> Thanks a lot Frank for being so quick.
>> Before posting my message, I read all contributions in the mailing list
about
>> the topic, checked my code and I am reasonably sure no Snmp.close() is
called.
>> I have a single static instance of Snmp used for all requests sent (from
>> different threads) to the agents. Snmp session is allocated the first time
and
>> never closed (it dies together with the application). After allocating
Snmp
>> session the first time, Snmp.listen() is called.
>> There is another Snmp session allocated for trap receival. Again here Snmp.
>> listen() is called and it is closed at application shutdown.
>> So ... still dark from my side.
>> Question: is the Snmp.close() traced in snmp4j logs? Because I cannot see
>> anything about that.
>> Moreover: is there any other possibility leading to the problem I
described
>> and related to a misuse of snmp4j lib from my side?
>>
>> PS If you need complete snmp4j logs with debug level, tell me.
>>
>> Ciao,
>> Alberto
>>
>>
>>> ----Messaggio originale----
>>> Dal: fock at agentpp.com
>>> Data: 14/12/2006 0.55
>>> A: "Alberto"<alberto_mascheroni at fastwebnet.it>
>>> Cc: <snmp4j at agentpp.org>
>>> Ogg: Re: [SNMP4J] IllegalStateException in Snmp.send()
>>>
>>> Hello Alberto,
>>>
>>> You wrote that you had to restart your application
>>> in order to use your Snmp instance again after
>>> having caught the error below. This indicates,
>>> that the timer referred to in the exception,
>>> had been canceled. That means that your code
>>> somewhere called Snmp.close() while requests
>>> where pending.
>>>
>>> That is how it is supposed to work: If you close
>>> the Snmp instance, then it is shutdown and
>>> cannot be used again. You will need to instantiate
>>> a new Snmp instance.
>>>
>>> So please do not call Snmp.close() between two
>>> queries!
>>>
>>> Hope this helps.
>>>
>>> Best regards,
>>> Frank
>>>
>>> Alberto wrote:
>>>> Hello,
>>>> I refer to the correction provided in v1.7.1 and described by Frank in
>> email
>>>> below.
>>>> Since I got the same problem in my project, I downloaded the SNMP4J
>> version
>>>> 1.7.5 and reproduced the error with log4j logs enabled.
>>>> Here the result (just reported the PduHandle with the problem, but if
you
>> need
>>>> I have the complete logs):
>>>>
>>>> 13/12/2006 14:30:30:131 DEBUG [pool-10-thread-22] [Log4jLogAdapter.
debug]
>> New
>>>> pending request with handle PduHandle[1826954335]
>>>> ...
>>>> 13/12/2006 14:30:45:579 DEBUG [Timer-15] [Log4jLogAdapter.debug] Running
>>>> pending request (3 left) with handle: PduHandle[1826954335]
>>>> ...
>>>> 13/12/2006 14:31:00:587 DEBUG [Timer-15] [Log4jLogAdapter.debug] Running
>>>> pending request (2 left) with handle: PduHandle[1826954335]
>>>> ...
>>>> 13/12/2006 14:31:00:589 DEBUG [SNMPDriverDispatchPool.2]
[Log4jLogAdapter.
>>>> debug] Looking up pending request with handle PduHandle[1826954335]
>>>> ...
>>>> 13/12/2006 14:31:00:591 ERROR [Timer-15] [Log4jLogAdapter.error] Failed
to
>>>> process pending request PduHandle[1826954335] because Task already
>> scheduled or
>>>> cancelled
>>>> java.lang.IllegalStateException: Task already scheduled or cancelled
>>>> at java.util.Timer.sched(Timer.java:358)
>>>> at java.util.Timer.schedule(Timer.java:170)
>>>> at org.snmp4j.Snmp$PendingRequest.run(Snmp.java:1426)
>>>> at java.util.TimerThread.mainLoop(Timer.java:512)
>>>> at java.util.TimerThread.run(Timer.java:462)
>>>> ...
>>>> 13/12/2006 14:31:00:590 DEBUG [pool-10-thread-22] [Log4jLogAdapter.
debug]
>>>> Removed pending request with handle: PduHandle[1826954335]
>>>> ...
>>>>
>>>> It seems there is a relation between the time the Timer-15 is checking
the
>>>> handle for the second time (14:31:00:587) and the time the answer comes
(14:
>> 31:
>>>> 00:589). They are really very closed one to the other.
>>>> Maybe a synchronization problem among threads?
>>>>
>>>> Of course, after Timer-15 thread dies, no Snmp primitive to the agent is
>>>> possible anymore and my application has to be restarted.
>>>>
>>>> Can you help, please?
>>>> Regards,
>>>> Alberto
>>>>
>>>>
>>>> Frank wrote:
>>>>
>>>>> Hi Fabian,
>>>>>
>>>>> We can catch only a RuntimeException and rethrow it. I have
>>>>> changed the code as follows for v1.7.1:
>>>>>
>>>>> /**
>>>>> * run
>>>>> */
>>>>> public synchronized void run() {
>>>>> try {
>>>>> if ((!finished) && (retryCount > 0)) {
>>>>> ...
>>>>> }
>>>>> }
>>>>> catch (RuntimeException ex) {
>>>>> logger.error("Failed to process pending request "+key+
>>>>> " because"+ex.getMessage(), ex);
>>>>> throw ex;
>>>>> }
>>>>>
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>
>>>> --------------------
>>>> Alberto Mascheroni
>>>> Mob. +39-333-6314222
>>>> _______________________________________________
>>>> SNMP4J mailing list
>>>> SNMP4J at agentpp.org
>>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>> --
>>> AGENT++
>>> http://www.agentpp.com
>>> http://www.mibexplorer.com
>>> http://www.mibdesigner.com
>>>
>>>
>>
>>
>>
>> --------------------
>> Alberto Mascheroni
>> Mob. +39-333-6314222
>
>--
>AGENT++
>http://www.agentpp.com
>http://www.mibexplorer.com
>http://www.mibdesigner.com
>
>
--------------------
Alberto Mascheroni
Mob. +39-333-6314222
More information about the SNMP4J
mailing list