> > My original intention with lowMark was to allow individual data > producers to produce capacity updates before their respective capacity > window hits zero and the data stream stalls. I am open to newer ideas > or better solutions. >
The concept makes perfect sense, the implementation is just kinda... cattywampus. For one thing, I think that `lowMark` is being set according to the wrong settings (remote, instead of local). For another, I think that the input connection window should be expanded to Integer.MAX_VALUE early on (i.e. during settings negotiation), instead of waiting for the window to fall below `lowMark` for the first time while consuming DATA frames. Finally, it appears that `lowMark` is being used for both streams and the connection window, and I think these should be separated: the `lowMark` for streams should be defined in terms of `SETTINGS_INITIAL_WINDOW_SIZE`, and the low mark for the overall connection window should just be hardcoded to 10MiB or whatever. Is there an exception I could take a look at without running > SubscribeToShardIntegrationTest and the whole test suite? > > I should have more bandwidth later this week and could try to run the > test suite locally. > I need to continue investigating this. The test is actually running pretty reliably now, even with weird H2Config settings (e.g. initial window size of 1kB) and more stream throughput. Like I said, I suspect the problem is in the test code itself, and I'm trying to add logging and callbacks to find it. Let me know if you need a helping hand here specially if can reproduce > the same issue with httpclient integration tests. > I could definitely use help with these. I think I'll push my HttpClient branch to GitHub so you can run what I'm running and hopefully reproduce the problem. It's non-deterministic, but I get a test failure at least 25% of the time in my IDE.
