Reporting issues with virtual threads

[Philip Boutros]

Thanks Alan

I'll follow up with the net-dev on the *HttpClient thread ex**plosion *and
*ReadableByteChannel/**HttpResponseInputStream deadlock *issues.

On the HTTP/2 issue you reference, it's not at all related to virtual
threads (I just happened to find it incidentally) and Google's endpoints do
in fact limit the stream count to 100. The problem appears when one wants
to go over 100, for a given scheme:host:port there seems to be no way (even
using additional HttpClient objects) to establish an additional connection
and hence a new 100 streams. Maybe I'll take that one to net-dev too.

Thanks
-P



On Tue, Nov 21, 2023 at 1:13 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 21/11/2023 17:34, Philip Boutros wrote:
>
> Hi
>
> I recently ran into a number of issues with virtual threads as documented
> in this article.
>
> https://medium.com/@phil_3582/java-virtual-threads-some-early-gotchas-to-look-out-for-f65df1bad0db?source=friends_link&sk=f1f6ed425c4d17cdc1188f85a0d13d4d
> (Friend link, no paywall)
>
> At least two of these issues (HttpClient thread explosion and ReadableByteChannel/HttpResponseInputStream
> deadlock) are in the Java core libraries but I'm at a loss as to how to
> proceed since I don't have Author status to even report them to
> https://bugs.openjdk.org/ let alone fix and PR them myself. Some
> direction would be appreciated.
>
>
> Thanks for the link. There are a few things in the article that don't look
> right, for example it says that several HttpClient instances share
> connections but this isn't so. Another thing is that the HTTP/2 spec allows
> a server to impose a limit on the number of concurrent requests and it
> looks like this is happening here. I think it might be useful to start a
> thread on the OpenJDK net-dev list with the HTTP related issues as I think
> it should be possible to explain most of these.
>
> On the issues with synchronized and pinning. Yes, this is problematic
> right now. There is work in progress to help with this and we hope to have
> changes in the loom repo soon for testing.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231121/a911753a/attachment.htm>