[snmp] Possible flaw in transmitter?

[Andrew Chandler]

Thanks - I've got it in play and it combined with something else I did has
apparently fixed my 5 + year running bug ! 

Interesting thing to note folks, although probably many of you realized this
already:

The operation ++ is not threadsafe.   By this I mean if you have a member
int x in an object.   If you then update that count by  
Doing an "x++" operation inside an update method.   The x++ is actually a 4
step process.    JDK 5 and above provides an AtomicInteger (and other types
as well) that allows you to do these things in a thread safe way. (They
probably just synchronize all access but hey its easier than doing it
myself).      I post this here because I suspect with regards to timeouts
etc there might be a couple of areas in the stack that warrant scrutiny.
After changing the me.interrupt in the stack the problem had not gone away
entirely.   However after changing to an AtomicInteger that I incremented to
show how many of the tried community strings had returned my problem seems
to have gone away.



-----Original Message-----
From: snmp-bounces at snmp.westhawk.co.uk
[mailto:snmp-bounces at snmp.westhawk.co.uk] On Behalf Of Birgit Arkesteijn
Sent: Monday, February 05, 2007 9:14 AM
To: List for discussion of the Westhawk SNMP stack
Subject: Re: [snmp] Possible flaw in transmitter?

I added Tim's code suggestion to Transmitter.interruptMe(), but didn't test
it.
The code is checked into cvs (on SF), see previous announcement.

Birgit


On Thu, Feb 01, 2007 at 10:28:11AM +0000, Tim Panton wrote:
> Andy, thanks,
> 
> Yes, and I don't think it is strictly needed here.
> 
> How about something as simple as:
> 	if(  me!= null){
> 		me.interrupt();
> 	}
> 
> If you follow Andy's case, then interrupt won't get called.
> That isn't a problem because all the interrupt does is to speed things 
> up, the recv will timeout and the thread will clean itself up, just a 
> bit later than it would have.
> 
> I'll do some testing to see if this has any unpleasant side-effects, 
> but it looks like the simplest solution, and one that won't slow down 
> the vast majority of cases. (i.e. the _rare_ case is slower, but the 
> rest
> not)
> 
> Tim.

--
-- Birgit Arkesteijn, birgit at westhawk.co.uk,
-- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK
-- tel.: +44 (0)161 237 0660
-- <URL: http://www.westhawk.co.uk>
_______________________________________________
snmp mailing list
snmp at snmp.westhawk.co.uk
http://snmp.westhawk.co.uk/mailman/listinfo/snmp