Events are one behind when calling SendEvent

[svengeance]

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]

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

[svengeance]

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,

[svengeance]

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]

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]

@SteveV0189 Thank you for figuring this one out.

[tpeczek]

@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?

[svengeance]

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

[tpeczek]

@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.

[svengeance]

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.

[svengeance]

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]

@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.

[svengeance]

@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]

@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.

[svengeance]

@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]

@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.

[svengeance]

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]

@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.