|
|
Home
Search
Register
Login
Recent Posts
»Forums Index
»Archive (2017 and earlier)
»IQFeed Developer Support
» Port 5009 being reopened when port 9100 is opened?
|
|
| Author | Topic: Port 5009 being reopened when port 9100 is opened? (7 messages, Page 1 of 1) |
 taa_dtn -DTN Evangelist- Posts: 150 Joined: May 7, 2004 |
Posted: Jun 26, 2004 09:38 PM
Msg. 1 of 7
Hi, folks. I'm seeing some behavior in IQFeed 2.3.0.1 that I haven't been able to understand completely, so I thought I'd run it by you for a possible explanation.
It appears that each time my app opens port 9100 (e.g. to do a symbol search), a fresh connection to port 5009 is automatically opened by something in the IQFeed software stack. But when my app closes port 9100, the extra connection to port 5009 is not closed. These extra port 5009 connections just seem to hang around forever; according to netstat they're active and not in any of the TCP/IP closing-handshake states. I've worked around this by opening port 9100 once and never closing it. Is that the intent of the API design, or are the stale connections to port 5009 a bug? Allen |
|
DTN_Vik_Kodipelli -Interested User- Posts: 11 Joined: May 7, 2004 
|
Posted: Jun 29, 2004 03:42 PM
Msg. 2 of 7
Do you see this behaviour with the history socket client sample app too. I am not seeing any of this on my end. I do see the 5009 being opened but it gets closed when the app calls removeclientapp.
~~~~~~~~~~~~~~~~ Vik Kodipelli Software Developer DTN Market Access http://www.iqfeed.net ~~~~~~~~~~~~~~~~ Edited by DTN_Steve_S on Sep 19, 2011 at 09:14 AM |
|
taa_dtn -DTN Evangelist- Posts: 150 Joined: May 7, 2004 |
Posted: Jun 29, 2004 04:29 PM
Msg. 3 of 7
Quote: I am not seeing any of this on my end. I do see the 5009 being opened but it gets closed when the app calls removeclientapp. My app doesn't call RemoveClientApp() until it stops monitoring at the end of the day or is closed by its user. It opened ports 9100 and 9200 only when they were needed and closed them afterwards, until I discovered that closing 9100 left an orphan connection to 5009. Large numbers of search or history requests meant large numbers of open connections to 5009. I was worried it might also mean large numbers of blocked threads or other resource leaks that might affect reliability or performance. That's what I was getting at in my previous question. Is this behavior a bug, or is it just the intention of the API designers that ports never be closed and reopened? Normally I free up dynamic resources as soon as they're idle, and I would have expected IQConnect to do the same, but maybe that's the wrong assumption. I'm happy to stick with whatever usage model the designers intended, so if you guys aren't concerned about the orphaned connections, all that's needed is a note in the documentation to help clarify things for future developers. Allen |
|
DTN_Vik_Kodipelli -Interested User- Posts: 11 Joined: May 7, 2004
|
Posted: Jun 30, 2004 10:04 AM
Msg. 4 of 7
I think the reason we have not had an issue with this so far is because most third party developers open these ports and then do not close them till the app shuts down. But as you said this is not a clean way of doing things. This has been brought to the notice of IQFeed developers and you can expect a fix or a new release soon.
~~~~~~~~~~~~~~~~ Vik Kodipelli Software Developer DTN Market Access http://www.iqfeed.net ~~~~~~~~~~~~~~~~ Edited by DTN_Steve_S on Sep 19, 2011 at 09:14 AM |
|
taa_dtn -DTN Evangelist- Posts: 150 Joined: May 7, 2004 |
Posted: Jun 30, 2004 01:28 PM
Msg. 5 of 7
Sounds good. Thanks for the followup!
Allen |
|
tadams -Interested User- Posts: 18 Joined: May 7, 2004 
|
Posted: Jul 1, 2004 09:41 PM
Msg. 6 of 7
Vik,
If I'm not mistaken this has been highlighted a few times, but phrased as 'Number of connections not decrementing'. After I've connected/disconnected to port 9100 roughly 2000 times, IQFeed crashes, Dr. Watson-style. Some of the TCP/IP developers (Me) have encapsulated objects that spawn a connection for specific method calls. The local 'server', IQConnect, should really be able to determine when a disconnect happens. As a workaround, I've had to create a quite nasty middleman that monitors the health of the IQConnect process and doubles as a TCP server. My objects connect to this server to receive IQConnect 'health' messages. When IQConnect crashes (multiple times daily), my objects are broadcast a message indicating that it's down. The middleman forcefully terminates IQConnect then restarts it. When 5009 is alive again, a broadcast is sent out indicating that all is OK again. This is particularly troubling when I'm grabbing a series of historical data. Since I have to code around UP and DOWN events, lots of extra code is required to remember how far I've gotten. On the other hand the middleman is a lifesaver for realtime watches, as my UP event populates a watch list (if IQFeed crashes, the persistent middleman forces it back up ASAP and data capture resumes with no additional coding). Users of the ActiveX objects won't have this issue, but also cannot recover from an IQConnect crash. In summary, this is the most critical issue I've seen as it causes IQConnect to crash in the midst of data capture daily. Hope my marketing of the topic has an effect..... Ted Edited by tadams on Jul 1, 2004 at 09:46 PM |
|
DTN_Natalie_H -DTN Evangelist- Posts: 175 Joined: May 10, 2004 
DTN Market Access, LLC. |
Posted: Jul 2, 2004 10:22 AM
Msg. 7 of 7
Ted,
We're looking into it. Thanks! Natalie Hannan DTN Market Access, LLC. |
|
|