New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Events are one behind when calling SendEvent #6

Closed
vernyis opened this Issue Oct 8, 2017 · 17 comments

Comments

Projects
None yet
2 participants
@vernyis

vernyis commented Oct 8, 2017

Hey there, thanks for the library.

I'm having trouble getting the events to send exactly when I call them. If I send an event with data "x", and then send a second even with data "y", the first event will only be received when the second event is called. The second event will only then be received when the third event is called, or when the request closes.

Any ideas on why this could be occurring? It sounds like a simple issue with flushing the response properly, but I didn't immediately see anything wrong with the code.

I've used your example's HTML page to connect to my event-source and I can confirm it's a backend issue,

[Update]
I've also replaced everything custom with my EventService and everything out of my middleware pipeline to match. The SSE is injected into an API controller, and a POST to that controller fires a SendEventAsync which my Index should receive.

[Update2]
I've also replaced my custom service with the services from your demo project on the back end, still no luck.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 Can the issue be reproduced in my demo project as well?

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 Can the issue be reproduced in my demo project as well?

@tpeczek tpeczek self-assigned this Oct 8, 2017

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

No, unfortunately the demo project works wonderfully. I think I've got it though -- sit tight I'll have a response within a few minutes,

vernyis commented Oct 8, 2017

No, unfortunately the demo project works wonderfully. I think I've got it though -- sit tight I'll have a response within a few minutes,

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

And I've got it. Of all the damn things -- it was the response compression. I hadn't originally included it in mine. It's not mentioned anywhere on your Git page nor Getting Started (https://tpeczek.github.io/Lib.AspNetCore.ServerSentEvents/articles/getting-started.html), and the only reason I found out about it is by looking through the demo project.

Now that it's been narrowed down -- why exactly is the compression necessary?

[Smol Update]
I've confirmed it was the compression by removing it from your demo program, in which it then exhibits the similar behavior of lagging behind one Event.

vernyis commented Oct 8, 2017

And I've got it. Of all the damn things -- it was the response compression. I hadn't originally included it in mine. It's not mentioned anywhere on your Git page nor Getting Started (https://tpeczek.github.io/Lib.AspNetCore.ServerSentEvents/articles/getting-started.html), and the only reason I found out about it is by looking through the demo project.

Now that it's been narrowed down -- why exactly is the compression necessary?

[Smol Update]
I've confirmed it was the compression by removing it from your demo program, in which it then exhibits the similar behavior of lagging behind one Event.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

The response compression is included in demo project because previously there was an issue for SSE not working with it in place (#3). It is not mentioned anywhere because it shouldn't be required - this is a bug.

Owner

tpeczek commented Oct 8, 2017

The response compression is included in demo project because previously there was an issue for SSE not working with it in place (#3). It is not mentioned anywhere because it shouldn't be required - this is a bug.

@tpeczek tpeczek added the Bug label Oct 8, 2017

@tpeczek tpeczek added this to the v1.1.1 milestone Oct 8, 2017

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 Thank you for figuring this one out.

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 Thank you for figuring this one out.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 I have one more question regarding your setup. I'm not able to reproduce the use only in case of Kestrel running behind IIS. If I use Kestrel only it works as expected. What server configuration are you using?

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 I have one more question regarding your setup. I'm not able to reproduce the use only in case of Kestrel running behind IIS. If I use Kestrel only it works as expected. What server configuration are you using?

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

I'm using IIS Express locally and nginx in production. I haven't tested the Linux box yet though.

vernyis commented Oct 8, 2017

I'm using IIS Express locally and nginx in production. I haven't tested the Linux box yet though.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 Can you check what happens if you go for Kestrel only locally? All my research indicate that issue occurs only if there is ASP.NET Core Module in place.

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 Can you check what happens if you go for Kestrel only locally? All my research indicate that issue occurs only if there is ASP.NET Core Module in place.

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

I replaced my Program.cs#Main with the old NetCore1.0 build process of

var host = new WebHostBuilder()
    .UseKestrel()
    .UseContentRoot(Directory.GetCurrentDirectory())
    .UseStartup<Startup>()
    .Build();

            host.Run();

Eliminating the module results in the same behavior, however.

vernyis commented Oct 8, 2017

I replaced my Program.cs#Main with the old NetCore1.0 build process of

var host = new WebHostBuilder()
    .UseKestrel()
    .UseContentRoot(Directory.GetCurrentDirectory())
    .UseStartup<Startup>()
    .Build();

            host.Run();

Eliminating the module results in the same behavior, however.

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

I've also just verified that this is also the case with your demo project. Using the builder without any sorts of IIS modules results in the same behavior as if the modules existed. The only factor that affects whether the events lag or not is the compression.

vernyis commented Oct 8, 2017

I've also just verified that this is also the case with your demo project. Using the builder without any sorts of IIS modules results in the same behavior as if the modules existed. The only factor that affects whether the events lag or not is the compression.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 Which launch configuration are you using in case of demo project? I'm able to reproduce only when the launch configuration is "IIS Express", not when it is "Demo.AspNetCore.ServerSentEvents (5000)" or "Demo.AspNetCore.ServerSentEvents (7000)". I've also noticed that when configuration is "IIS Express" the browser still receivers the content with GZip compression despite Response Compression Middleware being removed. It looks like response compression is being added by IIS and impacts when things are being flushed.

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 Which launch configuration are you using in case of demo project? I'm able to reproduce only when the launch configuration is "IIS Express", not when it is "Demo.AspNetCore.ServerSentEvents (5000)" or "Demo.AspNetCore.ServerSentEvents (7000)". I've also noticed that when configuration is "IIS Express" the browser still receivers the content with GZip compression despite Response Compression Middleware being removed. It looks like response compression is being added by IIS and impacts when things are being flushed.

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

@tpeczek I think we're differing a bit here. I have the app configured as such, and it still exhibits the same behavior.

Here is a video demonstrating the behavior -- so we're both clear. https://shifty.site/8x8iH
This was created using the above config, WITHOUT response compression.

vernyis commented Oct 8, 2017

@tpeczek I think we're differing a bit here. I have the app configured as such, and it still exhibits the same behavior.

Here is a video demonstrating the behavior -- so we're both clear. https://shifty.site/8x8iH
This was created using the above config, WITHOUT response compression.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 I see. I will go further with IIS path as I see something there and then get back to no IIS scenario to see if I can repro something. Thanks for the help.

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 I see. I will go further with IIS path as I see something there and then get back to no IIS scenario to see if I can repro something. Thanks for the help.

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

@tpeczek My apologies -- I had the profile selected but was not not running it with the selected profile and was always using IIS Express.

So yes, we are on the same page at least! Without IIS Express the events work as expected without compression.

vernyis commented Oct 8, 2017

@tpeczek My apologies -- I had the profile selected but was not not running it with the selected profile and was always using IIS Express.

So yes, we are on the same page at least! Without IIS Express the events work as expected without compression.

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 This is great. Also I believe how I can fix that (prevent IIS or any other proxy for adding its own compression). Need some time to play with it.

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 This is great. Also I believe how I can fix that (prevent IIS or any other proxy for adding its own compression). Need some time to play with it.

@vernyis

This comment has been minimized.

Show comment
Hide comment
@vernyis

vernyis Oct 8, 2017

If you could do that it might simplify my deployment to nginx; I anticipate having to tell it to bugger off when messing with compression and/or headers.

Cheers mate, thanks for the help.

vernyis commented Oct 8, 2017

If you could do that it might simplify my deployment to nginx; I anticipate having to tell it to bugger off when messing with compression and/or headers.

Cheers mate, thanks for the help.

@tpeczek tpeczek closed this in 4015a7a Oct 8, 2017

tpeczek added a commit that referenced this issue Oct 8, 2017

@tpeczek

This comment has been minimized.

Show comment
Hide comment
@tpeczek

tpeczek Oct 8, 2017

Owner

@SteveV0189 I did what I could. It certainly works for IIS and potentially should work for nginx (but might depend on configuration). It's late so I will push to NuGet tomorrow, please feel free to reach out if you continue to have further issues.

Owner

tpeczek commented Oct 8, 2017

@SteveV0189 I did what I could. It certainly works for IIS and potentially should work for nginx (but might depend on configuration). It's late so I will push to NuGet tomorrow, please feel free to reach out if you continue to have further issues.

@tpeczek tpeczek added the Medium label Oct 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment