Joined: |
Apr 16, 2007 07:43 AM |
Last Post: |
Jun 27, 2007 07:59 AM |
Last Visit: |
Jul 20, 2007 01:44 AM |
Website: |
|
Location: |
|
Occupation: |
|
Interests: |
|
|
AIM: |
|
ICQ: |
|
MSN IM: |
|
Yahoo IM: |
|
|
dis has contributed to 24 posts out of 21251 total posts
(0.11%) in 6,444 days (0.00 posts per day).
20 Most recent posts:
Some comments from MSDN forum:
Quote: I'd guess the COM server is starting up an unmanaged thread. The CLR is not going to trap unhandled SEH exceptions in unmanaged threads. They'll bomb your app, nothing you can do about it.
The thread is here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1784273&SiteID=1
It would be great if there wouldn't be any unhandled exceptions
Sincerely, DIS
A lot of threads will decrease your performance because there would be some CPU time to switch between them. The good practice is to have one thread per one CPU.
I have desktop application which has 2 threads: main (GUI - request data and watch results) and background one which listens the socket and sends data to the UI. It updates ~700 symbols using single socket and works fine for me.
Since last weekend I receive historical data in the following order: started with most recent to the least recent for some symbols like SPX.XO and maybe some other (for AAPL data returns as usual). I've been using IHistoryLookup for a few month and I always receive from least recent to most recent. I think it's so because of new servers. Could you please check this issue.
Hello guys,
While testing my application on different use cases and situations, I have found a reproducible issue where a crush of my .NET 2.0 application occurs.
It can be reproduced when I'm logging into IQFeed twice from different computers with the same account. On the first PC I see the following message: "IQConnect has been disconnected from the server. Please make sure you are logging in only once". At that time my application was performing the batch update of historical data for many symbols. It deals with IQFeed using COM interface (DTNHistoryLookup.dll). After the disconnect, my application crushed with unhandled win32 exception "access violation..."
Here is my unmanaged stack trace (from last):
ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!7c919aeb() ntdll.dll!7c919ba0() ole32.dll!774ffaba() DTNHistoryLookup.dll!08e3ebb4() DTNHistoryLookup.dll!08e40214() ntdll.dll!7c90104b() DTNHistoryLookup.dll!08e3fa31() DTNHistoryLookup.dll!08e40214() DTNHistoryLookup.dll!08e3ea4c() DTNHistoryLookup.dll!08e3ea72() > mfc80.dll!ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::AllocSysString() Line 2185 + 0x40 bytes C++ DTNHistoryLookup.dll!08e3dd57() MSCTF.dll!74730e71() user32.dll!7e41f84a() user32.dll!7e41f7f6() user32.dll!7e41f805() user32.dll!7e41f805() user32.dll!7e41f94b() user32.dll!7e41f95b() ntdll.dll!7c90eae3() user32.dll!7e42e051() mfc80.dll!AfxInternalPumpMessage() Line 153 + 0xf bytes C++ mfc80.dll!CWinThread::Run() Line 625 + 0x7 bytes C++ mfc80.dll!_AfxThreadEntry(void * pParam=0x0c84f61c) Line 126 C++ msvcr80.dll!_callthreadstartex() Line 348 + 0x6 bytes C msvcr80.dll!_threadstartex(void * ptd=0x0b4aca30) Line 326 + 0x5 bytes C kernel32.dll!7c80b683()
And here are the error details:
Unhandled exception at 0x7c918fea in <myapp>.exe: 0xC0000005: Access violation writing location 0x61746174.
EventLog item: Faulting application <myapp>.exe, version 1.0.0.0, stamp 467a9608, faulting module ntdll.dll, version 5.1.2600.2180, stamp 411096b4, debug? 0, fault address 0x00018fea.
As you know, .NET Framework 2.0 provides exception wrapping. It means that they guarantee that all non .NET exception (as the native win32 exception) would be wrapped to .NET compatible exceptions and users will be able to catch and process them. However, framework bypasses this one. I think it's probably a bug in the framework.
I do not assume that you, on your side, are doing something wrong. I'm just asking to check (once again) what's happening on the forced connection closure.
It's very important for me as the same crush has been reproduced with other situation. Say, if my application is working for a few hours (requesting historical data and adding a watch list for about 700 symbols). Thus I cannot handle this exception and the crush doesn't give me the chance to save my data, workspace and so forth. I have to avoid it somehow.
Thanks for your help and support.
Have a nice day.
Dis
Hi support!
http://forex.tradingcharts.com/charts/
Can you please give me the IQFeed's symbol names.
Thanks in advance
Hi Steve,
I often receive similar corrupted messages. My connection is not very fast, it's latency is 200+ms. What can we do to avoid data corruption? Maybe it's possible to increase local data buffer or something else?..
Hi Steve,
I have one more question. I'm receiving a lot of quotes (update messages). I'm collecting a set of them with the same Time (field 18 update message) to build a 1 minute bar. For example, a quote's time is 9:32. What time should I assign the 1 min bar to: 9:32 or 9:33? What's the way you store the historical data?
Its 1 minute bar parameters (open, high, low, close) are 10 times smaller than for its daily bar for the same time period. Is that correct?
I’ve noticed some strange behavior in the historical data retrieved by my application or by DTN.IQ.
Here’re some of my observations:
1. DAX.X, 06/15/07 7:01. High is 16206. Nearest bars have ~8000. 2. @GLD#, Daily data. 01.08.2006 - 1.12.2006. The large part of bars have low=0. 3. +HG#, 05/25/07 10:45. Low is 32.6 but nearest bars have ~320
I wonder what could cause the issue.
Let me know if you have any idea. Thanks for all!
I've sent an e-mail.
Sorry, I haven't observed that this message was simply moved to the Client support.
I'm watching symbol X in DTN.IQ, and here is what I see:
Snap Quote window: T Time: 12:14, but this quote affected the 12:32 minute bar I see in Time And Sales window (type:minute, interval 1). Why is it so?
I'm watching symbol X in DTN.IQ, and here is what I see:
Snap Quote window: T Time: 12:14, but this quote affected the 12:32 minute bar I see in Time And Sales window (type:minute, interval 1). Why is it so?
I'm not experiencing a bug, I'm offering you to enhance it a bit so that the AbortLoad event needs to be raised in some additional case, or MinuteProgress event brings 0 bars loaded in its event args in case if there is no data on the requested interval. This does not require the changes in the interface.
But... If OnAbortedLoad event would be raised, how I could determinate which request failed?
Is it possible to do 2 historical requests (daily and intraday) from separate threads at the same time? Can the data be corrupted in such situation?
It would be a great addition to existing capabilities if requests and received data could be marked with some identifier.
Here’re my reasoning:
1. Request method must return request id: void RequestMinuteHistory (BSTR bsSymbol, long lDays, long lInterval); Change methods return a value from void to long - assign the identifier to the request.
LONG RequestMinuteHistory (BSTR bsSymbol, long lDays, long lInterval); so it would be possible to keep it until the event is raised.
2. Add the identifier to the event's arguments: STDMETHOD OnMinuteCompleted (LONG id, INT iMinutesReceived, VARIANT Time, VARIANT Open, VARIANT Close, VARIANT High, VARIANT Low, VARIANT Volume, VARIANT IntVolume) By this way, I'll see that data is received properly.
The same can be done for daily methods/events.
As for the backward capability the methods have to stay as they are now. However, is it possible to add the new methods with identification support in the near future?
The feature is very important for my application.
Thanks for your consideration.
HistoryLookupClass.RequestMinuteHistory("MSFT", 1, 1); The situation reproduces if I'm doing such request on Monday morning (or holidays...), because there is no historical data.
Suggestion is following: Raise an event in case when no data available for the requested interval. Now my calling thread is sleeping up to timeout (20 seconds - 1 minute for me). It would be great if the event would inform about it immediately. It is very important for my application.
Many thanks for your consideration.
Hi Steve!
I'm still debugging my bar-build mechanism. OHLC parameters seem to be ok now, but volume parameter is not the same, compared to the historical data. It is greater or equal. Can you please tell me the update messages with which trade indicator (t,T,b,a,o - c part of 18th field of the update message) must influence the OHLC and\or volume parameter of the current 1-min bar?
Thanks in advance.
|
|