I have three machines running WLP and I have updated one of them to 6.2.
Two 6.1 machines are working fine but 6.2 machine started causing ThreadAbortException pretty much every day since updated to 6.2.

The call stacks are below.

CODE:
Please log in to see this code.

CODE:
Please log in to see this code.

CODE:
Please log in to see this code.

CODE:
Please log in to see this code.

This is just a headsup so far as I haven't nailed the root cause of this exception but this is definitely a regression from 6.1.

Hi kazuna, could you provide the context in which those message show up? And, are those times in ET?

Two streaming windows (symbols are FAS and FAZ) are running simultaneously in 1 min time scale.
Those times are in PST.

I installed WLP 6.2 on my spare laptop today and I observed the same thread abort exception.
There appears something changed in WLP 6.2 where it process the new bar data.

Something did change - the streaming "heartbeat" works now (and didn't work so well before). The heartbeat "closes" the bar on schedule instead of needing to wait for a tick in the next interval to determine that the current interval has ended.

(I suspected it has something to do with streaming, but if the times were ET, two of those events would have been outside market hours; that's why I asked.)

Are these pairs scripts? Any other hints to help reproduce?

Yes, these are pairs scripts. Two screaming windows open the same script and runs a pair of symbols.
However, these two streaming windows are independent and they don't even use GetExternalSymbol as I had an issue accessing the external symbol while streaming (you remember the issue that the external bar data gets a few bars behind).

I'm wondering if the "heartbeat" change makes the window too narrow for the strategy run to complete before the bar data is updated. Or maybe some race condition among two threads while accessing the bar data while bar data being updated.

Anyway, SetScaleDaily and Synchronize are the functions often showing up in the stack when the thread was being aborted.

I do remember the issue, and sorry if I didn't get back to you about this, but there's a way you can work with the pair in a Streaming Window and keep the external symbol in synch with minor delay by sleeping the thread for 5 or 10 seconds. Try this example (click on FAZ since the external symbol is FAS) -

CODE:
Please log in to see this code.

QUOTE:
I'm wondering if the "heartbeat" change makes the window too narrow for the strategy run to complete before the bar data is updated.

The strategy won't run until the new bar is added to the chart, which occurs when the heartbeat closes the bar. But if you're doing something in another thread (Strategy Window) that's required by another, then it's definitely possible you have a problem passing information across threads. If required, please create a ticket so that I can get details.

QUOTE:
keep the external symbol in synch with minor delay by sleeping the thread for 5 or 10 seconds.

Sounds like a great idea. Unfortunately, as I'm paying $ for faster machine to get the strategy to execute as faster as possible, 5 - 10 seconds are unacceptable. Instead, I'm using Windows registry to share the last bar data between the Streaming Windows and one spins (with 0.1 second sleep) on another until the last bar data becomes available. It's typically just a second or two and only until one creates a position.

QUOTE:
But if you're doing something in another thread (Strategy Window) that's required by another

I think the spin just for a second or two won't be problem. Other than that my strategy doesn't do anything special.

Any idea what would be causing the thread exception in the new version?

I don't recall having seen it occur during testing, but we've already mentioned the heartbeat fix, which is the suspect here. Ultimately, the heartbeat fix should help your cause since it will close the interval "on time" instead of [almost] always waiting for a tick in the next interval to close the previous one.

I can try creating a script that spins waiting for the data to be made available by the other, but if you could help me out by providing a stripped-down script that performs your data operations that we can use to duplicate the error, I'd appreciate it.

Q: Once the error occurs, the Strategy window continues functioning at the next interval, right?

QUOTE:
if you could help me out by providing a stripped-down script that performs your data operations

It didn't occur today but I will see what triggers the problem.

QUOTE:
Q: Once the error occurs, the Strategy window continues functioning at the next interval, right?

I guess so but I'm not sure as I always rerun the strategy when I get the exception. I will see if the Streaming Window continues receiving the new bar data when I get the exception next time.

QUOTE:
I will see if the Streaming Window continues

Yes, please. Give it the next minute unless you think you have to enter a trade on that bar. There is other older logic (not related to the heartbeat fix) that would abort the thread if a script is running on symbol XYZ when a new bar is received for XYZ.

Even that's been there since at least 5.6, this may be what you're seeing, but generally it would occur only if you manually initiate the script running near the end of the interval and it is still executing as the next interval ends. In this case, execution will continue without incident on the next interval.

I confirmed that Streaming Window continues at the next bar after the exception.