When does soap_accept() set soap-errnum to 9? Any help?
--- In [email protected], "bobbsey0" <bobby.zom...@...> wrote: > > > I verified ulimit -n file descriptor limit. Lowering the number didn't > reproduce the issue. Also, Connecting and then instantly disconnecting > repeatedly didn't help in reproducing it. Whenever it happens, we need to > restart the application. It affects all subsequent requests causing accept > failures. The soap errnum returns 9 (namespace?), which is confusing in this > context since the fault description says "Bad file number", which is no where > related to soap->errnum 9 afaik. In case of namespace issue while talkin to > the client, it should happen every time we talk to the client. But it happens > inconsistently. > > Do you see any logical connection btw errnum 9 and badfile number/accept > failures? When does soap_accept() return soap->errnum 9 (SOAP_NAMESPACE) ? > > B > --- In [email protected], Adam Nielsen <adam.nielsen@> wrote: > > > > > Error 28 fault: SOAP-ENV:Client [no subcode] "Bad file number" > > > Detail: accept failed in soap_accept() > > > > > > The ulimit is 15K, which is too far for the appl to reach. fd count > > > in /proc/*/fd is consistent. The issue goes away only with restart. I > > > tried releasing all keep alive sessions, cleaning up tmp soap buffer, > > > deallocate de-serialized content and instances and start over again > > > accepting requests on the same master skt but to no avail. > > > > > > what could be the reason? Is this a result of broken pipe or a > > > malformed req msg from the client? Could someone pinpoint the area > > > where I need to debug further? > > > > We don't use soap_accept() so I'm just guessing here, but do you mean > > you need to restart the application or restart the machine? If you need > > to restart the machine then it's a bug in your OS, as any leftover > > connections should be cleared when your app terminates. > > > > You could perhaps try severely lowering the ulimit values to see if you > > can find out whether it is reaching one of the limits (and if so which > > one), or whether those limits are unrelated. > > > > Once this issue happens does it affect all requests? That error > > (according to the accept() manpage) means the descriptor was invalid - I > > don't know whether connecting and then instantly disconnecting could > > cause that problem, although presumably accept() needs a descriptor of > > some listening socket - if that listening socket goes away for some > > reason, then presumably all future calls to accept() will fail. > > > > Have you tried running your app through something like Valgrind? It > > might be able to help if the issue is related to allocating some > > resource and then forgetting to release it again. > > > > Anyway, just some ideas! > > > > Cheers, > > Adam. > > >
