1. started up C++ History demo.

2. started my app that pulls loads of history data.

3. closed history demo while my app was still running.

4. iqfeed connector takes all excess cpu for 30 seconds, then relinquishes and things chug along normally again.

This might be disruptive to other running apps -- I couldn't tell how hoggish the connector was really being.

Otherwise, the multi-access of the connector seems to work nicely.

Thanks for the improvements.

As of IQFeed version 2.3.0.3, IQFeed uses all excess CPU while it is processing history data requests. If your request was large, it easily could have taken 30 seconds. Thanks for posting!

Natalie

---

Natalie Hannan DTN Market Access, LLC.

What I observed is different from DTN's explanation.

I reran the test.

1. On a started C++ history demo and verified that it was working. It was the first app to require IQConnect.

2. I started my history download, modified to ask for 120 days of minute bars for hundreds of symbols. Running by itself, it used up to 75% of a 1GHz machine. Roughly 5-6 secs per symbol retreived. Never 100% as you suggest.

3. I tried to shut down the C++ demo. Now, CPU usage does goe to 100%. This time the 100% hogging lasted 3 minutes and during that time, my history dowload attempts began timing out (they are on a 60 second inactivity (not duration) timeout). The GIF below shows this transition.



4. Once IQConnect recovered, the history download resumed.

So, to restate, my heavy minutebar history downloading does not consume 100% CPU, but shutting down the first IQConnnect user (a C++ demo) does. IQConnect was definitely abnormally distracted, as evidenced by no history being retreived during that time.

I doubt that this is by design.

Thanks for your attention.

These symptoms suggest that bug 2663 still hasn't been fixed...

http://forums.iqfeed.net/index.cfm?page=topic&topicID=433

kdresser,

Thanks for posting again, I now understand the issue that you are seeing. You are correct that a disconnect of one client should not peg the CPU (thus causing other clients to stop receiving data). I will look into it. Thanks!


skunk,

I will look into it. Thanks!

---

Natalie Hannan DTN Market Access, LLC.

I tried reversing the roles of the C++ demo and my app. The problem does not occur when my app starts first and ends first, so a clue to this behavior might lie in how the apps are communicating with IQConnect.

Thanks for looking into this.

I have a few questions for you:

Are you using Sockets or COM in your app to retrieve history?
Which C++ History test app are you using?
Is the C++ demo in the middle of a request when you shut it down?
Can you recreate this issue only using the demo apps?
You are requesting 120 days of 1 minute data for your symbols, correct?

Thanks for your assistance in helping me recreate this issue!

Natalie

---

Natalie Hannan DTN Market Access, LLC.

1. I use sockets.

2. I use the demo apps installed when 2.3.0.4 was installed. c:\progra~1\dtn\iqfeed\HistorySocket.exe has version property 2.3.0.4 and is 28,672 bytes.

3. The history demo is quiet when it is stopped.

4. I tried to get something failing using just demo apps.

Unfortunately, bad behaviour seems random.

In about a dozen trials, I had two identical foul ups: after starting, using, and exiting two demo apps (historysocket and level1socket) the IQConnect.exe would not shut down. No CPU hogging with this though. The lingering IQConnect prevented a new history socket from starting. Process killing was required to clear the deck.

However, there was one bit of badness that I could reliably recreate. Launch historysocket and ask for 10 TickDays of a huge volume stock (I used today's winner, MLNM). Smaller volume stocks won't trigger the problem. This time, it's historysocket that hogs the CPU and it appears to do it after receiving the tick data and filling the memo control. HistorySocket accepts a close and then it's IQConnect that hogs the CPU (forever too it looks like).

I'm hoping that this helps you in tracking down something satisfying to fix.

5. Yes, I'm requesting 120 days of 1 minute data for my symbols.

When I do my daily update tonight I'll experiment with my usual 1-day requests.

###

I see now that the "badness" above is of my own making -- when historysocket goes to 100% CPU it is because it is still receiving data and is busy updatubg its memo control. Closing historysocket while it is still receiving then causes problems for iqconnect.

If I wait long enough, the original historysocket request does finish and shutting it down doesn't upset iqconnect.

However, closing historysocket while it is busy with a response does send iqconnect 2.3.0.4 into 100% CPU where it is unresponsive to both the mouse and other apps requesting a connection.

###

Ok, this thread is getting a little confusing.
Could you please restate the issues that you are still having, if any? Thanks.

Natalie

---

Natalie Hannan DTN Market Access, LLC.

I assume you are joking but maybe not...

The issue is that IQConnect does not detect when a client has disconnected. If a client disconnects while a history response is being sent to the client, then IQConnect is hosed.

Maybe somebody should check the return code from send and not keep trying to transmit if the error is WSAECONNABORTED, WSAECONNRESET, WSAETIMEDOUT.

See bug 2663 in your bug database
Edited by skunk on Jun 23, 2005 at 12:20 PM

kdresser,

I am able to reproduce part of your issue. If I close HistorySocket while it is receiving data, and let it sit for a few minutes, IQConnect does appear unresponsive. But, if I wait a few minutes, it does finish processing, and shut down if it is the last client. The problem is that IQConnect is waiting for all requests to finish processing before terminating. I will log this into the bug database, as it is different than bug #2663. Thanks!

Natalie

---

Natalie Hannan DTN Market Access, LLC.