|
Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!
(Move your cursor to this area to pause scrolling)
"Everything is working great with the API. I love it." - Comment from Calvin
"This is an excellent value, the system is generous (allowing for 500 stocks) and stable (and really is tick-by-tick), and the support is fantastic." - Comment from Shirin via Email
"Its working FABULOUSLY for me!! Holy cow...there has been so much I've been missing lately, and with this feed and Linnsoft software...I'm in the game now." - Comment from Chris R.
"I am very happy I changed. I love the product, but more so I am thrilled with Tech Support. You are knowledgeable, polite, pleasant and professional." - Comment from Pat
"Thank God for your Data Feed as the only Zippers I see are on my pants (LOL), and no more 200 pip spikes to mess up charts." - Comment from Spiro via Email
"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"I am enjoying the feed very much - so superior to the broker provided feed I was previously using." - Comment from George
"I'm very glad I switched to IQFeed. It's working perfectly with no lag, even during fast market conditions." - Comment from Andy via Email
"The service is great, I see a noticeable improvement in my volume profiles over [broker]'s data feed" - Comment from Larry
"With HUGE volume on AAPL and RIMM for 2 days, everyone in a trading room was whining about freezes, crashes and lag with *******, RealTick, TS and Cyber. InvestorRT with IQFeed was rock solid. I mean SOLID!" - Comment from Public IRC Chat
|
|
|
|
Joined: |
May 19, 2004 08:23 PM |
Last Post: |
Feb 17, 2009 01:35 PM |
Last Visit: |
Feb 17, 2009 01:35 PM |
Website: |
|
Location: |
|
Occupation: |
|
Interests: |
|
|
|
skearns23 has contributed to 37 posts out of 21191 total posts
(0.17%) in 7,291 days (0.01 posts per day).
20 Most recent posts:
well that IS a bummer.
Don't you think you should make an iq_jni_64.dll?
usually this requires merely a recompile.
I am unable to use DTN from my java app on vista x64. When it attempts to load the library iq_jni.dll i get the message:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Program Files (x86)\DTN\IQFeed\iq_jni.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.load0(Unknown Source) at java.lang.System.load(Unknown Source) at com.iqfeed.IQ_32.<clinit>(IQ_32.java:28)
Thanks for the quick reply.
In the next version , don't forget the "maxbars" parameter in addition. There is no easy way for a client to know how many ticks are between two dates. Minutes are computable, but then there are complications involving session closing times etc.. It could be 1000000 or it could be 10. So if a client just wanted 3000 ticks, it would be very difficult to achieve without a maxbars parameter.
Many of the historical requests require a "maxdays" parameter giving the number of days of data to load.
If this value is 1, and it is 2008-08-23 15:00, then does this retrieve the values: (1) between now and 2008-08-23 00:00, or (2) between now and 2008-08-22 15:00, or (3) between now and 2008-08-22 00:00.
please answer and update your documentation.
I have long requested an api that lets me specify a fromtime, a toTime, and a maxbars, with the semantics being "give me atmost maxbars of the most recent data >= fromtime and <= toTime". This is useful in limiting the data requested, and in filling in older data for a chart without requerying the newer data.
I am not getting any minute history data (request timing out) today. querying for ES, QCL among others.
I seem to be getting some daily history though.
please fix. Edited by skearns23 on Jan 11, 2008 at 07:33 AM
the problem appears in minute data , not tick data.
I've tried 4 times. same result each time. I am using software that has run well for 4 years, It loads @TY data correctly.
If you want to duplicate: My login is 182760 connecting to 66.112.148.227 port 5002 iq feed verwsion 4.2.1.4 symbol is @ESH8
OK, that explains the QCL, but what about the missing data for @ES?
I am getting some very strange results all of a sudden. QCLF8 - no historical data after 4:42am today 12/12 a strange realtime tick 7$ below the last known price.
@ESH8 - no historical data after 11:30am today 12/12 then starts up at 15:00
A Workaround Seems To Have Been Found!!!!
When I replaced :
mSinSocket.connect(new InetSocketAddress(InetAddress.getLocalHost(), 9100)); which actually connects to my internet address on the local lan: "192.168.1.100" with :
mSinSocket.connect(new InetSocketAddress("127.0.0.1", 9100));
it all magically started working consistently.
I even have a theory how this could trigger a bug in dtn's code. In an earlier message I pointed out that most programmers wrongly think that they will receive a full line of data when they read from a socket. Even if the sender of the data sends a full line, there is in fact no guarantee that this will happen. So one possibility is that connecting to "192.168.1.100" takes a bit longer, routes through a router, etc.. which can cause a less than full line to occasionally come through; since the dtn app is probably not expecting this, it gets misparsed and havoc results.
Another, less likely possibility is that my router or msft's ip stack is messing up loopback connections. But this is inconsistent with the fact that it only happens with HX (tick data requests).
In any case, I am glad to be thru this horrific experience lasting 6 months, which I wasted 100's of hours on. It would be nice if dtn would compensate me for their bug with several months of free service.
well that is disappointing.
it sounds to me like we need to turn on logging of the iq app, so that we can trace the problem back.
Where do you stand in getting a version of the iq connection manager which logs faster, by not closing and reopening the log every time?
I have created a newer version of my application, which shows consistent errors on my machine. Please try this newer version, which finds more of the errors.
If anyone else has java installed and can try this on their machines, that would also be appreciated.
http://www.softwaretruth.com/stevek/dtn/DtnControllerSimple.java
(I also uninstalled my iqfeed 4.1.0.0 beta installation and re-downloaded and re-installed, but no change was evident.)
ooops, I noticed in an earlier post that I said I had set logging registry value to 1, but in fact the error shows up only when it is set to 0, probably because of the speed issue.
ahhhhh, I guess that contract expired....
You might change the symbols that end in G6 to end in H6 instead...
-steve
To answer your question, the 2 minutes the sample program takes is similar to the time it takes me. Here are two sample runs for me:
2 min 42 sec
2 min 15 sec
and errors each time
Great, I am glad that you were able to duplicate the duplicate !ENDMSG! error. If you look in DtnControllerSimpleLog.txt which should be in the root directory from which you ran DtnControllerSimple.java is. If you renable the partof the code that saves output that is received, then you can search for ENDMSG. When you find the extraneous one, which is evident because it is followed by more data, and not by another request, you may also see that the line before the ENDMSG is garbled.
I don't see the relationship to the other thread that you linked to, since these requests are returning data, and all requests I do return some data.
I spent alot of time developing that sample app for you, so I want to make sure that you ran it in a way that would show you the problem.
Specifically, if you run it from a console window, or within a debugging environment that shows you the "std output", then you would have to scan the output looking for lines that look like:
Error: Found 47 lines that starts with ','
or
java.net.SocketTimeoutException: Read timed out
Of course, if you turned off my printouts then you would not see these errors. My printouts are an less than trivial amount of time, so there is no benefit to turning them off.
If you run the app 4 times and get no error lines printed out, then that would be a sign that we have different environments, since I get errors (in different places) 9 times out of 10.
In case it depends on the server, it looks like my current connection is to 66.112.156.221 port 60002, version 4.1.0.0 I am using logLevel 1
Also, no amount of network issues could make your program send extraneous !ENDMSG! lines, right?
Just wondering if you were still pursuing this problem.....
-steve
If it is necessary to put delays in like this, it is usually a sign of two problems in the dtn server, (i.e. the dll that we connect to as clients) that dtn could fix if motivated:
(1) when you create your server, there is an option for specifying the number of server connection attempts that are queued. I think the default is 5. Of course, boosting this to 50 would help alot.
(2) you are supposed to do as little work as possible after an accept() returns, and as quickly as possible create a new thread to handle the request. This way, accept requests are handled quickly, and fewer requests build up in the queue.
I have created a simple one file app that you can run to see the problem. The problems have only occurred with the HX request, and definitely seem to be triggered by large requests.
You will have to edit the file to add in my or your password and app name.
see:
http://direct.softwaretruth.com:8001/stevek/dtn/DtnControllerSimple.java
-steve
|
|