When I tried to turn on streaming updates for the Account Balances window, WLP 6.9.22.7 crashes. This was not a problem in WLP 6.9.20.7; I cannot speak for WLP 6.9.21.X.


Well, the screenshot doesn't tell us much, but the .NET application log (below) appears to indicate the crash occurred in the WealthLab.DataProviders.FidelityACTIVStreamingProvider.f() module. That doesn't mean there's something wrong with that module; only that the crash occurred when executing it. My "wild guess" is that this bug was introduced in WLP 6.9.21.X when the ability to view "All Live Accounts" in the Account Balances window was restored. (But I could be wrong.)

CODE:
Please log in to see this code.

If you can't reproduce this bug, let me know.

Hi,

Thanks for your bug report. Can this be reproduced steadily or is this a one off event?

QUOTE:
Can this be reproduced steadily or is this a one off event?

Well, I ran streaming updates yesterday without any problems, but "All Live Accounts" was selected at that time and I turned it on when the market wasn't open.

Today, I turned it on when the market was open and when a specific account was selected when it ABENDed. So the circumstances were different. I think your point is that I haven't revealed all the information to reliability reproduce this ABEND, and that may be true. I don't want to encourage too many ABENDs on my side because they corrupt my WealthLabConfig.txt file.

I do have multiple Fidelity accounts I trade on, but I can't tell you if that's a requirement to reproduce this ABEND problem. Also, I don't normally enable streaming updates either, but since the Update button will no longer update the Last Price column, I've began using streaming updates. It would be good to get that Update button fixed as well; see my earlier post about that. https://www.wealth-lab.com/Forum/Posts/Accounts-Balance-window-quot-Last-Price-quot-wrong-for-WLP-6-9-22-7-39932 I think that Last-Price-column Update-button bug is very reproducible. (Maybe these two problems are related.)

If the developer can't reproduce the ABEND problem himself, then we need to talk more. That would be better than trying to rely on a log4net error log to locate the cause of the problem (streaming collection indexes out of range), which would be the last resort. :(

---
Oops, I got another WL re-login to do. That's three four within the last hour. I'm on a re-login roll today. Please get that fixed soon. I could downgrade to 6.9.20.7 and see if all these problems go away.

fwiw, I could not duplicate this (on 31 Dec) using the 34 "live" QA accounts holding 121 positions.

I tried turning on Streaming Updates in the Account Balances windows (for WLP 6.9.22.7) on Friday, 1/3/2020, and it didn't ABEND. Then I remembered prior to the 12/31/2019 ABEND I was trying to get the Update button on the Account Balances window to work unsuccessfully for the Last Price column before turning Streaming Updates on. So there are more steps involved to reproducing this ABEND as Post #2 suggests.

The crash trace in Post# 1 says the indexes for ACTIVStreamingProvider List collection are out of range. But the Update button wouldn't be messing with those indexes in the first place (Right?). Moreover, System.Collections.Generic.List.Remove(), .RemoveAt(), Add(), etc. should be the only member functions messing with these indexes, and I serious doubt there's a problem with them since many Windows applications depend on these List functions.

Bottom line, this looks more like a thread safety problem with the ACTIVStreamingProvider List collection. In other words, you're never going to be able to reproduce this problem reliably because one can't control what's on the Windows threads scheduler "ready list" (i.e. ready-to-execute list). Also, an attempt to debug any thread safety problem with log4net would require the error handler to dump the ready list to the error log when the ADEND occurs. The developer could then determine which conflicting threads are using the .Remove() and .Add() functions in conflict. Let's not bother with that because the solution in all cases will be the same....

If this continues to be a problem, the developer will need to switch management of the ACTIVStreamingProvider List collection to a thread-safe List datatype. But let's wait this out first. I don't like thread-safe datatypes because they tie the hands of the thread scheduler too much and create overhead. Let's see if these ABENDs continue first.

Meanwhile, you could ask the developer if all ACTIVStreamingProvider List collection activity could be placed in one single execution thread so as to avoid conflicts so thread safety isn't an issue? That may not be possible (Windows.Forms streaming updates is a separate execution thread from the streaming provider execution), but it doesn't hurt to ask.

One other thought. The thread safety issue may only be a crash risk when you "start" Streaming Updates. So if you leave it running, the two conflicting threads may synchronize themselves in harmony within the thread scheduler's ready list, so the work around may be to leave Streaming Updates running. If you want to reproduce the crash (and thread safety problem), just try toggling Streaming Updates on-and-off many times to throw their thread execution out of sync.