race condition on http2 server push

[Woo-Seok Jeong]

Hi,

I am currently playing with http2 server push for implementing rest API streaming between vertx client and vertx server.
Recently I just observed strange behavior of push event.

It looks like race condition on sequence of streaming if I used artificial delay for each response events to simulate realistic async events.
Let's say,
(1) push1 with 100ms delay
(2) push2 with no delay
(3) main response end() after 450ms delay

Expected sequence was seen when only first time I loaded the process, then subsequently showing this order :
(2) push2 (no delay) -> (3) main response (450ms) -> (1) push1 (450ms)

Would you please let me know if I need to set some options to avoid this? I guess push1 is suspended by certain event scheduler.
example source:
http2 server : https://github.com/twobassdrum/http2Server-vertx/blob/master/src/main/java/com/twobassdrum/Http2Server.java
http2 client : https://github.com/twobassdrum/http2Client-vertx/blob/master/src/main/java/com/twobassdrum/Http2Client.java

Interestingly, node-http2 didn't show same problem and it always guarantees the sequence of server push queue.
 
Currently I am using h2c with no SSL, no ALPN since mutual side I could handle and configure. (SSL and ALPN options are also tested but same behavior)

vertx-core version : 3.3.2

Please help :)
thanks,
Wooseok Jeong

[Julien Viet]

can you provide a full reproducer ? i.e a fatjar with a main the start the server then run the client

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/10df4872-a8fa-4b60-a90e-7c561fb17059%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Woo-Seok Jeong]

Thanks for prompt response.
Couldn't attach too big fatjar files here but below git repo will be better environment to reproduce, modify and debug.
https://github.com/twobassdrum/http2Server-vertx
https://github.com/twobassdrum/http2Client-vertx
while running both servers, test can be done by hitting test url with actual browser, at http://localhost:8080/
Please let me know if test env is not properly setup.
thanks,
wooseok

[Woo-Seok Jeong]

do you have any luck of finding?

[Julien Viet]

just had a quick look

indeed it happens because we don’t flush the connection when writing a push promise, I will change that as we want to client to get the push as soon as possible.

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/eddc7096-e7c7-463f-96df-4aa1bc7a4921%40googlegroups.com.

[Woo-Seok Jeong]

Thank you so much for your response.
Yes, I think it's really important to get server push to client by the original design of http2.
Best regards,
Wooseok Jeong

[Woo-Seok Jeong]

In addition to http2 push, it would be good if you provide an API that I can force to flush any response back to the client.
For example, chunked http response (both of http1.1 and http2) will enable progressive flush so that client can partially consume the chunks as soon as their arrival. Just end() function is too late signal to send back everything altogether.
thanks

[Julien Viet]

https://github.com/eclipse/vert.x/issues/1546

you can try it from the master to check it works.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0fd9cec1-e99d-4f78-82bc-b7149ef480d0%40googlegroups.com.

[Woo-Seok Jeong]

Tested it with latest master branch that working as expected.
Thank you so much.

On Tuesday, July 26, 2016 at 10:59:35 PM UTC-7, Woo-Seok Jeong wrote: