Hi Johan, > Now, going out of FDs is expected, but the problem is, whenever I hit > the FD limit, I hit an assert: > > [junit] Too many open files [junit] rc == 0 (signaler.cpp:330) > > And an assert like this yields a total termination of the JVM it > seems. Not so nice in an app server context for example.
What else would you like it to do? Note that the code that fails to open a socket is async, ie. runs in a background while you application is doing some other work. > Any thoughts on alternative ways to handle this kind of situations > such as returning null, letting the caller decide wether to assert or > otherwise handle it gracefully? Same as above. The problem happens in async manner. No call to libzmq may be happening at the time, so there nothing to return null from. > Also, I've seen some weird crashes related in the same tests, my app > opens a REQ socket, connects to the ROUTER, waits for reply, and then > closes it. If i put a heavy load on these sockets, I eventually crash > with the following error: > > Device or resource busy (mutex.hpp:91) Please, do make sure that you are not using the same socket from two threads in parallel. If you are not, the above is definitely a 0MQ bug. > From the code it looks like it's pthread_mutex_destroy which fails. > I'll probably go for keeping the socket in a ThreadLocal for now, > avoiding the re-creation of the socket, but just wanted to report it > anyway. Yes, please. Create a minimal reproducible test case and report the problem via bug-tracker. That way it'll be solved rather than forgotten. > > Please reply directly to me, I only get the digests, will be hard to > do followup answers with only that. You're on cc. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
