Flupke Http3 Plugin #320
Flupke Http3 Plugin #320
Conversation
Co-Authored-By: Mahied Maruf <[email protected]>
Co-Authored-By: Mahied Maruf <[email protected]>
|
@mechite what do you think of this so far |
...jex-http3-flupke/src/main/java/io/avaje/jex/http3/flupke/webtransport/WebTransportEvent.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I think "yes". Great simple WebTransport implementation that won't bother
anyone, and HTTP3 done perfectly.
Random thought — do you think we could perhaps bump the source version
down to Java 17? Kwik and Flupke target 11, and the patches don't appear to
have any kind of requirement for newer features, though at the same time I
do see the avaje-jex-parent enforces Java 21 too...
I don't need it at all, but I'm not a fan of throwing the source version up if
it would be like a five-LOC change to potentially get more users / use cases
|
Remember that jex exclusively uses virtual threads so that we can avoid needing to implement any async stuff |
right.. didn't know that. |
Clarify that virtual threads aren't just a default or suggestion, but a hard requirement. Related-to: avaje#320 (comment) Signed-off-by: Mahied Maruf <[email protected]>
|
You can put in a manual override to use a regular executor, but the whole thing was designed with virtual threads in mind |
|
random question... is the in Avaje projects the pattern I picked up was either — same package, (I don't care — but consistency is gold) |
|
I think I get it, it was sending the data frames before the ssl frames, so just need a delay before sending data. EDIT: apparently it was something else |
This reverts commit da5057b.
|
after ptrd/flupke#29 is resolved we should be good to go |
|
@rbygrave I'm good with this |
The `null` check that just output the message was previously not using the lock, though I don't think it's a big issue and I'm not sure why there is a lock in the first place. I inherited that from Flupke, so it's better safe than sorry, though I'm pretty sure System.Logger makes those guarantees, but so does even `System.out`/`System.err`, so it's better to assume that ptrd had his reasons for locking here Signed-off-by: Mahied Maruf <[email protected]>
HTTP3 implementation of jdk.httpserver powered by https://github.com/ptrd/flupke.
part of #46
relies on ptrd/flupke#18 and ptrd/flupke#17