[AGENT++] Re: recvfrom's blocking and process grinding to a halt

[John McCaskey]

Hi Jochen,

On 3/22/06, John McCaskey <jmccaskey at gmail.com> wrote:
>
> Hi Jochen,
>
> On 3/22/06, Jochen Katz <katz at agentpp.com> wrote:
>
> > Hi,
>
>
> <snip>
>
> Each Snmp object opens its own socket (random port if not specified). So
> > they cannot interfere with each other and no thread can receive data for
> > another thread.
>
>
> Ahh... I'm stupid.  I wasn't thinking through the UDP send/recv process
> correctly, and was not accounting for the fact that each thread has bound a
> socket to a specific port for its recvfrom calls.  This makes sense now, and
> I agree it should not be causing me issues.
>

Ok, so it turned out the real issue was that I wasn't always deleting Snmp
objects I allocated dynamically.  This was causing me to leak sockets, and I
was eventually (since I'm under heavy stress testing) running out of open
ports to bind the sockets to.  I'm still not sure why there were calls
blocked on recvfrom, but as soon as I fixed the leaking sockets I had no
more issues with it.

However, looking at the code in uxsnmp.cpp I did notice one more thing.  In
Snmp::init() I see that a socket gets allocated with a socket() call early
on, then if that succeeds a bind() call occurs.  If either of these fails
construct_status is set to some error code.  Then in the destructor the
construct_status member is checked, and if not set to an error the socket is
closed by a call to close().  The issue here is if the socket() call
succeeded, but the bind() call failed, then the socket is never closed.
There should probably be a close() call within the error handling right
after the bind() call fails.  This appears to apply to both ipv4 and ipv6
within the function.

That said everything seems to be working well for me once again... Thanks
again for all the help.

John