1024 incomplete connections at this time.

IDS Version: 10.00.UC6 OS Level: Sun Microsystems Inc. SunOS 5.10 What's causing this issue and possible fix(es)? IBM Informix Dynamic Server Version 10.00.UC6 -- On-Line (Prim) -- Up 21 days 14:21:32 -- 3028992 Kbytes Message Log File: /ifmx/ifmxxxxxx/online.log 16:53:36 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:37 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:38 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:39 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:40 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:41 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:43 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:44 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:45 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. 16:53:45 1024 incomplete connections at this time. System might be under attack through invalid clients on the listener port. IBM Informix Dynamic Server Version 10.00.UC6 -- On-Line (Prim) -- Up 21 days 14:22:01 -- 3028992 Kbytes Userthreads address flags sessid user tty wait tout locks nreads nwrites 456 active, 6144 total, 6060 maximum concurrent Thanks, ******************************************************************* Ernie Knox IT Database Administrator Specialist Sears Holdings - BU: I & T Group 3333 Beverly Rd. Hoffman Estates, IL. 60179 Office: (847) 286-5735 Email: Ernest.Knox@searshc.com<mailto:Ernest.Knox@searshc.com> Blackberry: 2244650553@messaging.sprintpcs.com<mailto:2244650553@messaging.sprintpcs.com> Informix Email: ifmxdba@searshc.com<mailto:ifmxdba@searshc.com> and Team: InformixDBA@searshc.com<mailto:InformixDBA@searshc.com> Informix Primary: INFORMIXDBAPrimaryPager@searshc.com<mailto:INFORMIXDBAPrimaryPager@searshc.com> Informix Secondary: INFORMIXDBASecondaryPager@searshc.com<mailto:INFORMIXDBASecondaryPager@searshc.c om> MySQL Email: MYSQLDBAe@searshc.com<mailto:MYSQLDBAe@searshc.com> and Team: MySQLDBA2@searshc.com<mailto:MySQLDBA2@searshc.com> MySQL Primary: MYSQLDBAPrimaryPager@searshc.com<mailto:MYSQLDBAPrimaryPager@searshc.com> MySQL Secondary: MYSQLDBASecondaryPager@searshc.com<mailto:MYSQLDBASecondaryPager@searshc.com> For more information, use our DBA Wiki page link below: http://wiki.intra.sears.com/confluence/display/TechStrag/Database+Management#Dat abaseManagement<http://wiki.intra.sears.com/confluence/display/TechStrag/Databas e+Management> " Yes we can make a Change! " " It's always a great day to watch Sports: " GSU ******************************************************************* This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

Original post: DS Version: 10.00.UC6 OS Level: Sun Microsystems Inc. SunOS 5.10 What's causing this issue and possible fix(es)? ... Response: Well that message is coming from the listener thread doing a comparison that is has (in you case) 1024 incoming connections it hasn't gotten to at that particular moment. So basically at the tci/ip layer there's 1024 or more, incoming connection requests queued up that the listener thread hasn't gotten to yet. I believe there is a $ONCONFIG parameter that you can configure that defaults to 1024 (it's MAX_INCOMPLETE_CONNECTIONS) that would control how many incomplete connections you would have before the message was reported. But in any case, if there was a problem with the engine that was some how keeping the listener thread from running, you could see the queue of incoming connection requests get longer then this MAX_INCOMPLETE_CONNECTIONS value...if not that then there isn't anything the engine can do to fix this. It's either a spike in incoming connection requests to the port the server is listening on for database connections that are valid connection requests, or it's invalid connection requests (non-database clients) queueing up connection requests to the database server that the server will need to attempt to process. So it's a warning that perhaps you should do some network sniffing to verify where these connection requests are coming from (port and ip wise) to ensure that they are indeed expected database server client machines. If they are, then it could indicate a server problem that, as I mentioned, would imply that the listener thread is either having a problem getting to run, or processing connection requests slowly which is causing the incoming queue of outstanding connections to get to be larger then this default value of 1024. Jacques Renaut IBM Informix Advanced Support APD Team

Original Post: Well that message is coming from the listener thread doing a comparison that is has (in you case) 1024 incoming connections it hasn't gotten to at that particular moment. So basically at the tci/ip layer there's 1024 or more, incoming connection requests queued up that the listener thread hasn't gotten to yet. I believe there is a $ONCONFIG parameter that you can configure that defaults to 1024 (it's MAX_INCOMPLETE_CONNECTIONS) that would control how many incomplete connections you would have before the message was reported. But in any case, if there was a problem with the engine that was some how keeping the listener thread from running, you could see the queue of incoming connection requests get longer then this MAX_INCOMPLETE_CONNECTIONS value...if not that then there isn't anything the engine can do to fix this. It's either a spike in incoming connection requests to the port the server is listening on for database connections that are valid connection requests, or it's invalid connection requests (non-database clients) queueing up connection requests to the database server that the server will need to attempt to process. So it's a warning that perhaps you should do some network sniffing to verify where these connection requests are coming from (port and ip wise) to ensure that they are indeed expected database server client machines. If they are, then it could indicate a server problem that, as I mentioned, would imply that the listener thread is either having a problem getting to run, or processing connection requests slowly which is causing the incoming queue of outstanding connections to get to be larger then this default value of 1024. Jacques Renaut IBM Informix Advanced Support APD Team Response: So my 1st response isn't 100% technically accurate on what's exactly, happening, but it's mostly correct on what it would mean, although it would actually lean more towards your sever having invalid connections coming into the listener thread's port. So here's the more accurate explanation. So the old method for accepting connections was connection came into port, listener thread saw it, accepted it, and then waited to read data from the new connection. So if something just opened the port and never sent anything, it would freeze the listener thread. So the new method to address that is new connection comes into the port, listener thread accepts it, spawns a new server thread, and new server thread waits to read data from new connection. This allows the listener thread to continue to process connections if a bad one comes in. So what the message means is at the time it's printed, the server currently had 1024 (or whatever you set the ONCONFIG parameter to) threads waiting to receive the 1st data from the new connection request. Generally speaking that probably shouldn't be happening unless you have a lot of bad connection requests coming in (bad meaning they are just opening the port and then not sending any data across the new connection). So you'd still want/need to packet sniff to see where the new connection requests were coming from (I believe there is also a server xtrace component that could be used to get the new connection request's ip address), so you can tell if they should or shouldn't be happening. So this would not mean a slow listener thread, which is why I said it would seem to actually more likely mean bad connection requests coming into your servers listener thread port. Jacques Renaut IBM Informix Advanced Support APD Team