Uncatchable issue

[manson]

@kamalshkeir
Hi! It's been a time I've been working on my project. So far so good, I haven't used all of the features of Kago except those we've talked. But I found a strange behavior in a some situation. I have an opened table in admin panel and I have my project running in a browser and pulling data from that table. So I manually change some value in a table via admin, refresh page with my app, it pulls changed data from database. It's simple use case (I did this for testing). So in some point of time I found out that server hangs. Just do not respond on any routes it has.
First I thought this was related to admin panel and tried this way: change data and logoff, then refresh app page. Firstly I thought it helped, but not. Hangs became less, but not disappeared. And finally I've arrived at a decision that admin panel has nothing to do with.
After all, I have decided that this is SSE influences. When I turn it off (I have a connection to a server), there is no any hangs, everything works well. I thought I have a mess with mutexes in my broker that processes user's SSE connections (store them, send message to a specific user and so), but no, looks like it is not. I have even written several variants of brokers and it behaves the same way. But I found that ctx.Done() in most cases doesn't return event on closing the connection. So just refreshing the page with SSE connection doesn't raise that event for previous broken by refresh connection. So every refresh adds new connection and not dropping the previous. So, they accumulate on server side.

Maybe that's that's reason? I don't know. To be true - sometimes I saw the message on closing connection, but very rarely. Well, a bit tired with this, so maybe will try with websockets. It is interesting how they will behave.

[kamalshkeir]

@kamalshkeir
Hi! It's been a time I've been working on my project. So far so good, I haven't used all of the features of Kago except those we've talked. But I found a strange behavior in a some situation. I have an opened table in admin panel and I have my project running in a browser and pulling data from that table. So I manually change some value in a table via admin, refresh page with my app, it pulls changed data from database. It's simple use case (I did this for testing). So in some point of time I found out that server hangs. Just do not respond on any routes it has.
First I thought this was related to admin panel and tried this way: change data and logoff, then refresh app page. Firstly I thought it helped, but not. Hangs became less, but not disappeared. And finally I've arrived at a decision that admin panel has nothing to do with.
After all, I have decided that this is SSE influences. When I turn it off (I have a connection to a server), there is no any hangs, everything works well. I thought I have a mess with mutexes in my broker that processes user's SSE connections (store them, send message to a specific user and so), but no, looks like it is not. I have even written several variants of brokers and it behaves the same way. But I found that ctx.Done() in most cases doesn't return event on closing the connection. So just refreshing the page with SSE connection doesn't raise that event for previous broken by refresh connection. So every refresh adds new connection and not dropping the previous. So, they accumulate on server side.

Maybe that's that's reason? I don't know. To be true - sometimes I saw the message on closing connection, but very rarely. Well, a bit tired with this, so maybe will try with websockets. It is interesting how they will behave.

@manson indeed it can be because of SSE, tell me how websockets go

[kamalshkeir]

@manson how are you ?
New updates on the UI, also https://github.com/kamalshkeir/korm#example-nested-or-embeded-structs

[manson]

@manson how are you ?

@kamalshkeir
Hi! Nice to see the project work in progress :-) Just updated (again, had a long delay with my pet project). Yesterday I wanted to write you a small report, but you asked first when today I crawled up to my computer. If not this, I could miss your question. Don't know why, but Git did not inform me on your message.
I looked at our discussions - I think it looks like not how it was intended by Git - we have a mess with issues and discussions. Maybe some questions are better to discuss in emails? If yes, may developer's email is [email protected]

I've looked at your updates - they are great. Really. It is not what I intend to use in my pet project (you know, not all the possibilities of framework are needful in a project) but I understand what you did. Maybe not in nuances or usage, but the idea. Nested structs a great. New admin is nice as well. :-) Definitely better in design, even though you know my preferences - I think the common admin panel like in go-admin or in pocketbase are the ideal. I am about to start doing an admin panel for my pet project that users will deal with, so it will be like I mentioned above. I will use this one: https://github.com/epicmaxco/vuestic-admin
But internal original admin panel will be used too, solely by me. So any improvements are very welcome :-)

Going back to my project, I have switched to a server bus via websockets that you have implemented. Although you know that I consider it overcomplicated for most use cases, I have decided to use as it is the natural way for this framework and I didn't want to include some other libraries that overlap or replace the internal functionality. I'm saying about SSE. I could attach the side engine, but didn't want to do this. So I tried Bus and was amazed by the simplicity of its usage! Attaching it really reduced SSE server management to almost zero code, leaving some code for managing users and some nuances on notifications' delivery, but that is application logic, not communication manager. So, yes, your Bus is perfect, especially if websockets are preferable method of communication. I've decided to leave it in this project. And for a while I have not faced that issues with hangs I have mentioned above for SSE. But I have some small suggestions for small improvements :-)

1. Your Bus.js is intended to be used in pure javascript environment. But almost all uses some frameworks like React, Vue, Svelte. And it would be great to give some instructions how to integrate it in every. I use Vue, so had to discover this on my own. To do this the right way, Bus.js should be slightly changed to comply with modules loading or importing, but I did not want to change the Bus.js itself, so did the next steps (workaround for Vue.js). If you wish, you may include this in documentation for users, or write your own recommendation (I will follow them):

• Include file into the main index file like:

<script src="/static/tools/Bus.js"></script>

Of course, this is used here if dashboard is used. I don't know where this file exist if no dashboard is used, so its your's responsibility to correctly describe this :-)

• In main.js of regular Vue project add this:

app.provide('ServerBus', Bus);

Bus is globally available, but to correctly include it in Vue infrastructure it can be done like this.

• In any Vue component where access to Bus is needed user can do it like this:

const $ServerBus = inject("ServerBus");
let serverBus = new $ServerBus("localhost:9313");
serverBus.autorestart = true;
...

2. I have looked into the Bus.js and saw that it absolutely must include the address to connect to. It's not convenient in most cases because address almost all the time will be the same as application address (although it may be different in some cases). Currently, to be sure that application will work in a domain app will serve, I need to have a small headache to supply bus the correct domain(address) via config or some logic to extract it from browser URL. I would prefer to have a dual constructors. One is like it is currently implemented and second - if address is missed, to read it from window.location object or whatever. In last case it would be mostly used by all users.

3. I do not exactly remember, but for websockets route (/ws/bus in our case) user, if using nginx (I do) in front of application should describe this route in a special manner to work it correctly (as far as I remember, specify some protocol upgrade settings), It would be nice to describe this too, and probably do this for other web-servers or reverse proxies (Caddy and others).

So, thanks for your updates and for your interesting about my work :-)