Re: [Quickfix-developers] Too many open files
Brought to you by:
orenmnero
From: <OM...@th...> - 2002-06-07 14:20:10
|
Rainer, First off, good catch on the file descriptors leak. One additional thing you should do is use the socket_close method defined in Utility.h. Reason is that this function is portable (Windows does not use close on socket descriptors. go figure). Second, just so you know, the new version being released soon has an additional multithreaded implementation of the socket code. In this scenario, each session has it's own thread which not only solves the connect problem, it also makes it so sessions that take up a lot of processing time (if there are database accesses or whatever when an application message is processed) do not interfere with other sessions. The single threaded code should still be updated for the reason you pointed out, but you will also have another alternative. Thanks! --oren |---------+-----------------------------------------------> | | Rainer Staringer | | | <ra...@aa...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 06/07/2002 08:44 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: qui...@li... | | cc: | | Subject: Re: [Quickfix-developers] Too many open files | >----------------------------------------------------------------------------------------------| Ok, found the problem. SocketConnector::connect seems to be missing a close() in the error case. int SocketConnector::connect( const std::string& address, int port ) { int sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); sockaddr_in addr; addr.sin_family = PF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = inet_addr(socket_hostname(address.c_str())); int result = ::connect(sock, reinterpret_cast<sockaddr*>(&addr), sizeof(addr)); if(result == 0) { m_monitor.add(sock); return sock; } else { // Added by rainer. close(sock); return 0; } } There is another problem with this code, in that if one has more than one FIX session specified in the config file and one of the servers is unreachable, the whole process (all FIX sessions) will hang on each reconnect attempt - not good! Only solution is to put the socket in non-blocking mode and handle the connect asynchronously. Since I need multiple FIX connections, I might have a go at it... Rainer > On Friday, June 7, 2002, at 02:59 PM, Rainer Staringer wrote: > > Hi, > > I am developing a FIX client based on quickfix. > > I noticed that quickfix (Linux kernel version 2.4.16), when left > running long enough, uses up all available file descriptors for the > process, even when only heartbeat messages are exchanged. > > Anybody else encountered this problem? Known patch/workaround? > > Thanks, > > Rainer > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |