We're running the latest version of IQConnect (4.0.0.2) via the Java API.

When it is initiated by our Java application by calling the DLL, if there is no internet connection available, IQConnect enters a state in which it can NEVER connect to the IQFeed servers. Only manual intervention works at this point, and in fact pressing the "Connect" button does nothing at all, even once the internet connection is restored.

IQConnect also does not respond to RemoveClientApp() calls from our application, which are what we normally use to shut it down. It just sits there displaying the message "Unable to connect to IP list server". From a Java point-of-view, IQConnect never returns from our call to RegisterClientApp() and must be killed manually.

Incidentally, although we have full IQFeed logging turned on, no log file is created in this situation.

Is anyone else seeing this?

Is this a known bug?

If you download the DTN.IQ software, it runs IQConnect version 3.5.0.5 "Mercury" version 2.53.1 which behaves quite differently. It runs through a list of alternate servers (taking a few minutes), before ending up in the same, useless, state.

Dont feel bad. Previous versions (IQConnect Version 2.3.0.1, Mercury Version 2.53.1) crash when confronted with the same conditions.

Following is an extract from Dr Watson log file.

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
011DFFB4 7C57B388 74FDA57D 00133258 0014F1A0 001392D0 ntdll!ZwRemoveIoCompletion
011DFFEC 00000000 74FD6311 001392D0 00000000 012E0000 kernel32!lstrcmpiW

*----> Raw Stack Dump <----*
011dff84 63 63 fd 74 44 01 00 00 - bc ff 1d 01 b0 ff 1d 01 cc.tD...........
011dff94 a4 ff 1d 01 08 64 fd 74 - 58 32 13 00 a0 f1 14 00 .....d.tX2......
011dffa4 00 00 00 00 1c 00 00 00 - 00 00 fd 74 28 3c 0a 01 ...........t(<..
011dffb4 ec ff 1d 01 88 b3 57 7c - 7d a5 fd 74 58 32 13 00 ......W|}..tX2..
011dffc4 a0 f1 14 00 d0 92 13 00 - 00 c0 fd 7f 00 00 00 00 ................
011dffd4 c0 ff 1d 01 00 00 00 00 - ff ff ff ff 44 1f 5c 7c ............D.\|
011dffe4 08 2b 57 7c 00 00 00 00 - 00 00 00 00 00 00 00 00 .+W|............
011dfff4 11 63 fd 74 d0 92 13 00 - 00 00 00 00 00 00 2e 01 .c.t............
011e0004 50 00 8a 00 00 00 00 00 - 00 00 00 00 00 00 10 00 P...............
011e0014 00 00 10 00 c0 00 00 00 - 00 0b 00 00 65 02 00 00 ............e...
011e0024 70 01 00 00 00 00 00 00 - f8 44 8a 00 e8 c8 80 01 p........D......
011e0034 19 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
011e0044 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
011e0054 00 00 00 00 00 4e 41 2e - 5a 0a 72 50 43 52 00 4e .....NA.Z.rPCR.N
011e0064 41 2e 5a 0a 72 50 43 52 - 41 54 49 4f 2e 5a 0a 72 A.Z.rPCRATIO.Z.r
011e0074 56 49 4e 44 2e 5a 0a 72 - 56 49 58 2e 58 4f 0a 72 VIND.Z.rVIX.XO.r
011e0084 40 45 52 32 48 35 0a 72 - 54 49 43 4b 2e 5a 0a 72 @ER2H5.rTICK.Z.r
011e0094 46 49 4e 48 2e 5a 0a 72 - 40 42 50 48 35 0a 72 40 FINH.Z.r@BPH5.r@
011e00a4 45 53 48 35 0a 72 40 4a - 59 48 35 0a 72 40 55 53 ESH5.r@JYH5.r@US
011e00b4 48 35 0a 72 40 45 55 48 - 35 0a 72 46 49 4e 4c 2e H5.r@EUH5.rFINL.

Natalie/Jay,

Is this a known issue, or just something that only Skunk and we have observed?

Regards,

Dennis

Dennis,

I am able to reproduce this and it is something Natalie will need to look into. It doesn't look like IQFeed is attempting to connect to the secondary system, which after failing on the secondary system, should then return something to the client allowing you to kill IQFeed or retry.

We will look into it..

---

Jay Froscheiser
DTN - Trading Markets

Thanks Jay.

Just wondering what sort of priority this is for you.
Because I run unattended, even a small internet glitch will stop me running until I can close the IQ window manually (after I receive an alarm) to allow the reconnect to happen. I've effectively lost 2 days data in the last 5 under these circumstances when the alarm failed to wake me at 3am (I'm in Oz).

If it's not a high priority then I will have to write some code to detect the situation and kill the IQ process and restart.

Dennis.

Hello Dennis,

This is not a high priority item, because it existed in previous versions of IQFeed. Right now, we are working to correct issues that were introduced in the 4.0 series.

The one thing that will be fixed in the next version, is that the Connect button will actually try to reconnect...right now it doesn't. So, if the connection was restored, and Connect was pressed again, it would connect. I know that this doesn't really help you, because it is still a manual process, but I thought I'd mention it.

Natalie

---

Natalie Hannan DTN Market Access, LLC.

Natalie,

This problem did NOT exist in previous versions but was introduced in the 4.0 release.

It is true that previous versions did not automatically attempt to reconnect after an Internet outage but they responded to an API call to shut down (RemoveClientApp). The 4.0 release does not respond and therefore doesn't allow an application to take control by stopping and restarting the IQFeed client.

I'm sure that many developers in this forum are writing automated trading applications. This new bug in release 4.0 makes this impossible. We can roll back to previous versions of the client but we are loathe to go back to the high level of corrupt records that we experienced with those clients.

Dennis

Dennis,

If this is the case, we will definately get it corrected so it (RemoveClietnApp) functions as well as in the previous version. We will take a look at the diff between the versions and see what changed to cause it to no longer work.

---

Jay Froscheiser
DTN - Trading Markets

dhakme,

I have fixed the issue where IQFeed does not respond to RemoveClientApp. I am packaging a release, and should have it to QA this week.

In an effort to this get out, I am going to postpone the fix where the Connect button will actually try to reconnect. Thanks!

Natalie

---

Natalie Hannan DTN Market Access, LLC.

dhakme,

I'd like to send you a test build. Can you email developer support with an address where you'd like me to send the build? Thanks!

Natalie

---

Natalie Hannan DTN Market Access, LLC.

Natalie/Steve,

Jay informed us that new server software is expected in the next few weeks that may not work with earlier versions of IQFeed client and advised us to upgrade.

We are currently testing with v4.1.1.1 and can see that some of the bug fixes that were implemented in test clients sent to us in January have not been incorporated into this release.

There are two bugs that particularly concern us in the v4.x releases:

1) RegisterClientApp() doesn't return if a connection with the servers cannot be established eg. Internet down. This was fixed in test code sent to us but is not included in the latest release.

2) RemoveClientApp(). When called and the client is not in a connected state it returns successfully but doesn't actually terminate the client. This can get messy in an automated system http://members.ozemail.com.au/~dhakme/iqfeed-mayhem.jpg

While we have a work-around for (1) by using a separate thread, (2) poses a more serious problem. In earlier releases we were able to automatically kill the IQFeed client process through other means but the current version WILL NOT DIE. Do you anticipate a client release of the client with bug 2 fixed?

Dennis,

I don't think that we ever came up with a fix for either of the bugs you mentioned. The last email I have from you stated that the fix I gave you was working like this:

At the moment, when the Internet is unavailable the IQFeed client returns with an INVALID state (a=0 b=1) . When this occurs we execute RemoveClientApp() but the IQFeed window remains open. We then execute RegisterClientApp() to make a second attempt and our JVM crashes.

Natalie

---

Natalie Hannan DTN Market Access, LLC.

Natalie,

You're partly correct. Previously, RegisterClientApp() would not return at all if the client couldn't establish a connection. The latest test code did return with an INVALID state (a=0 b=1) and hence bug (1) seemed to be fixed.

The JVM crash was a new development that was most likely related to the second RegisterClientApp() call after RemoveClientApp() had failed to remove the existing client. Fixing RemoveClientApp() so it worked in all situations seemed to be the final obstacle.

Dennis

Natalie,

Our last communication was in early January having spent around 5 weeks together trying to fix these bugs. During this time we received four different development clients to test as part of what was becoming an endless to and fro. It didn't help that being in a different time zone prolonged this whole process.

We are happy to assist in identifying bugs and to help you in replicating them, but we really shouldn't be part of the development/testing process.

Your last request was a sample of our java application. However, the outstanding bug (RemoveClientApp not working in all situations) is the problem that needed to be solved, not a JVM crash after calling functions that don't work. Our environment is a tightly integrated group of applications and scripts that would need hours of work to create a separate jar file that could be run on a Windows machine (we use cygwin).

But that's not the real point. You had trouble replicating our problem because it was a real world problem a user faces when they cannot access a server via the Internet. Until you have a test environment that adequately replicates what all your users have to deal with you can never be sure your application works properly.

Regardless of communication from us, my question is when do you expect to have fixes for two known bugs incorporated into a release?

Dennis,

I appreciate your comments. Here is the status of the bugs:

I am working out a few details with bug #1 ( RegisterClientApp() doesn't return if a connection with the servers cannot be established eg. Internet down. ) We are planning to send a release candidate to QA in a week or two, and I will do my best to include the fix in that release.

The work on bug #2 is still in progress, and I do not know if we will have a fix in the next release.

Thanks!

Natalie

---

Natalie Hannan DTN Market Access, LLC.