Having problems with message search?
Here are comments from the developers.
"There are no limits to quotes queuing-- except for memory in the machine. That said, we can't imagine a single reason or situation to allow your program to do that. Grab the data, store it locally, and get out. Let the rest of your code process it all you want, just don't do it in the event handler.
"As far as handing off the quote to another thread, be advise that (currently) the QUOTERECORD and similar structures are really just standard C++ pointers; they are essentially on loan from the calling function (the event handler) and are *only guaranteed to be in scope until the event handler returns*. What this means is that if you are not done processing on the quote record's values by the time the event returns and wish to pawn it off onto another thread, you have to make your own copy of the data within it (i.e. your own object/structure). The Navigator's client code always makes a deep copy which the client code owns.
"This behavior will be changing somewhat in an upcoming release, because we are replacing all the dumb structures with full-blown reference-counted, thread-safe COM objects, so instead of having a QUOTERECORD* as a parameter to the callback, it will be something like an MbtQuoteRecord* object, with read-only properties for each of what is currently just a member of the QUOTERECORD structure. That will mean you can pass the processing of the quote to a different thread, and as long as you maintain a reference on it, the object reference you have can be directly held onto as long as you want, and will only die after you and any other clients have released it.
"It will still only be in scope in its current state until the event handler returns though, so if you queue up every quote object reference in a linked list and are slow to process this queue in your other thread, the internal values of the record could change by the time you process them. In that case we'll add a .Lock and .Unlock method on them like our collections so you can lock them temporarily while you iterate through the record's properties and be guaranteed no other thread will not change, say, the total volume just as you are looking at it. From a practical sense, the record *might* just be the same actual object given to you from one handler call to the next, so if you are looking for every quote's event's exact changes of state, you will still want to make a private copy of its data from within the handler, and queue up that copy. This is all client-specific stuff in terms of whether any of this behavior is important to a given app, but the fundamentals are still very important to understand since it may affect an app's design.
Phil Huether <mbtsdk@...> wrote:
1. To answer your question, and without asking the developers, I would say there is no limit to the queue that stores quote data, should your event handler be to busy to keep the queue empty.2. My suggestion still stands of having your event handler pass off each quote to another Sub or Function. I'm willing to bet that Sub or Function will spawn as many processes as needed to handle even the heaviest number of quote objects, while keeping the appropriate (chronological) order.3. Also my suggestion of using a button to stop / start the flow of quotes:Private Sub cmdQuotes_Click()
FlipQuotes
End SubPrivate Sub FlipQuotes()
Select Case cmdQuotes.Caption
Case "Quotes ON"
cmdQuotes.Caption = "Turn Quotes OFF"
g_oQuotes.Disconnect
Case "Quotes OFF"
cmdQuotes.Caption = "Turn Quotes ON"
g_oQuotes.Connect
End Select
End SubPrivate Sub g_oQuotes_OnConnect(ByVal lErrorCode As Long)
cmdQuotes.Caption = "Quotes ON"
End SubPrivate Sub g_oQuotes_OnClose(ByVal lErrorCode As Long)
cmdQuotes.Caption = "Quotes OFF"
End Sub
zsolt_szakaly <zsolt_szakaly@...> wrote:Pete,
I don't think it is necessarily true. If you make an exe using MBT,
it will become a multithread application. Depending on the debugger I
can imagine both scenarios, i.e. stopping all the threads of the
application or only one.
One easy way to check that you have more threads is using Process
Explorer. There you can see all of them and can suspend only the main
one. You will still see the other threads running.
Raja,
It is really depending on how you use the L2 data. If you always need
only the last one and a "bit cached" data can confuse your algorithm
then I see why it is a problem for you. Having said that, I think
there is a risk in your code, even if you avoid this, because it
means that you need very fast data (always the very last), but
calculating with them takes more time than how fast they come. So by
the end of your calculation (when I guess you make your decision), it
is already out-of-time.
Anyway, one way to avoid this is to use one more thread. I know Phil
does not like it, but if only ONE of your own threads uses MBT then I
see no problem. This thread you can program to capture and store the
last quotes very fast (milliseconds). Your main thread can calculate
what it has to, once you get a trigger, and when it finishes it can
check whether there was an update in the data capturing thread. If
yes then you do it again with the last data, if not then go to a
suspend mode and wait until the data capturing thread forwards a new
quote if and when it receives it and "wakes up" your data analysis
thread.
BTW, my concern was just the opposite. I was afraid that by
calculating too long (meaning tens of millisenconds) I might miss
quotes. So from my prospective Phil's answer is reassuring.
Phil,
Do we know the size of the queue or cache in your dll? If one uses 10
L2, 100 L1 / I don't :-) /then the data feed might be massive. Is
there a built in limit, or it is up to the computer's memory?
Thanks,
Zsolt
--- In mbtsdk@yahoogroups.com, "Pete"wrote:
>
>
> A library or DLL is just code, its not a process. MBT's lib does not
> continue to receive data when you have the debugger stopped - it
can't
> because the library runs in the context of your program, its not
like
> there is a separate process running on your machine accepting data,
its
> all single threaded.
>
> Given that I don't see how you expect anything other then queued
data to
> result if you advise a symbol and then delay processing the
callbacks
> (because you stop the code in the debugger)
>
>
> --- In mbtsdk@yahoogroups.com, "Raja"wrote:
> >
> > Yes Michalel, but if you get one or two at that level it makes
sense.
> But these updates where for the top most entries and includes Ask
price
> near that range. If you have L2 Ask side update that is much lower
than
> current bid/ask price that is a serious problem. I had MBT Navigator
> running on my real account at that time and I could see the
difference.
> >
> > Phil, by returning control I meant returning from OnL2 call back
> function - that is back to the Lib that called me. (I had this
function
> under debugger for a while and then removed all break points and
started
> running it without interruption, I started getting what appeared
like
> cached data. By caching data I meant, your server is not going to
stop
> because I am debugging. It keeps sending data to my computer, your
Lib
> receives them, but since the previous call to OnL2 callback has not
> returned you are not going to call OnL2 again until I return. I
> eventually return control and you have so much of queued data that
needs
> to be fed to me through OnL2 callback. If your Lib receives data
and not
> cache or queue them we should not have seen the problem. You could
set a
> break point in ProcessBids in L2 sample code and see this behavior.
> >
> >
> >
> > ----- Original Message -----
> > From: Michael Murillo
> > To: mbtsdk@yahoogroups.com
> > Sent: Friday, March 30, 2007 1:06 PM
> > Subject: Re: [mbtsdk] Level2 data
> >
> >
> > Raja,
> >
> > Don't forget, it's possible that orders were being replaced at
various
> levels...it's entirely probable that the L2 market was updating
order
> information at those levels even though At-Market was in the 230.40
> range. Bids could be lower than 230.40, and therefore could still be
> adding/replacing that low on the totem.
> >
> > ---
> > (I noticed this when debugging my code with GBP/JPY L2, walked
away
> for a while, when the current quote was around 230.40 I was
processing
> L2 data around 229.60 range).
> >
> > Thanks
> > Raja
> > ---
> >
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/mbtsdk/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/mbtsdk/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:mbtsdk-digest@yahoogroups.com
mailto:mbtsdk-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
mbtsdk-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
Online Now 
Send Email
