|
Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
01:53
Xliff joined
10:03
sena_kun joined
11:30
sena_kun left
11:31
sena_kun joined
|
|||
| patrickb | o/ | 19:53 | |
| I'm still hunting the cro bug of sometimes not sending a request and thus hitting the header timeout. | 19:54 | ||
| What I have found out: - It's not reproducible. Sometimes it happens on the very first connection attempt, sometimes on a later reconnect. | 19:55 | ||
| - The HTTP2 connection is successfully established (packets on the wire are fine, cro trace shows the setup happening), but in the failure case the `emit` on the request pipeline never reaches the HTTP2::RequestSerializer. | 19:57 | ||
| - It only happens with HTTP2. I can't reproduce it with HTTP1. | 20:02 | ||
| - I the test script is as minimal as a Cro::Client example program can be: gist.github.com/patrickbkr/637e1e4...173dabc5f3 | 20:04 | ||
| I'm starting to wonder if this even is a bug in Cro or Rakudo core. | 20:05 | ||
| From all I can see in the code the HTTP2::RequestSerializer should be the thing directly listening at the other end of the supplier used in Cro::Client HTTP2 request supplier. | 20:07 | ||
| Is there a simple way to introspect the listeners of a given supplier? | 20:08 | ||
| I'll ask that last question over on #raku | 20:09 | ||
|
20:25
sena_kun left
|
|||
| patrickb | OK. I have sprinkled some debug prints around. The consumer directly attached to the supply in the Cro::Client HTTP2 request pipeline is the SerializerExtension. As I suspected. The `emit` does not reach the code in the `whenever` in the error case. | 20:41 | |
| It seems that this is a problem with rakudo itself and not Cro. I wonder which components are necessary to trigger this as under normal circumstances supplies are super stable. | 20:42 | ||
| I suspect and fear it's a bug in the VM itself. | |||
| patrickb tries to trigger it without the JIT | |||
|
20:43
Xliff left
|
|||
| patrickb | Also happens with MVM_SPESH_DISABLE=1. Phew! | 20:47 | |
| Verified on 2021.12 and 2022.07 | 20:54 | ||