Thanks Nelson. 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.niel...@...> 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. >
