search

microp11 / iridiumlive

web visualizer for gr-iridium frames
GNU General Public License v3.0
49 stars 11 forks source link

Fix the polling mechanism #4

Closed microp11 closed 4 years ago

microp11 commented 4 years ago

Most likely the polling mechanism implemented is incorrect in the current server context. It looks like when a tab is closed by the user (and not by navigating to another page). This needs be further investigated and the right mechanism implemented, perhaps a pooling starting at the user level in JS.

Originally posted by @microp11 in https://github.com/microp11/iridiumlive/issues/1#issuecomment-566871030

microp11 commented 4 years ago

I assume this has to do with the incorrect implementation of the Blazor Client-Server. The Blazor client part is missing, and as such there is no Blazor web assembly to take care of the DOM tree representation on the server side.

microp11 commented 4 years ago

The first iteration was a mess. This is a server only blazor app. As such there is no need for http, controllers and anything http related. The calls can be made directly to the database using standard blazor DI services.

After replacing the http calls, the next step was to fix the page navigation. The original implementation taken from the BlazingPizza project used cancellation tokens and a mechanism to reload the content of the page automatically. This might worked well in the demo, however created an issue when navigation in a server only app. You could not open any other page than the "home page" and then you can use the buttons from the home page to navigate. This was not right, this is a web service, one should be able to navigate to any page just by putting it in the browser.

Another problem was the use of EF. After digging and digging, the best agreed upon approach is to open database connections for each transactions, use the connection and dispose afterwards. Lots of new connections! If I created the database connection as Transient in the Startup, it got disposed when trying to use it in a page. The solution that worked, and I tried several was to create the connection on every page and let the GC dispose of it after use.

A timer is now used instead of cancellation tokens and while loop. This has its own issues but found a way to fix them. A page that requires pooling starts a timer on after rendering and when the timer expires a new rendering gets triggered. The the timer is started again on after rendering.