I'm getting situations where the yada server stops responding, in order to send cljs figwheel app and request to the same origin I have an endpoint that hosts the static files, but that stops responding too. I don't know how to debug a running yada instance. I suspect one of the endpoints' buffers gets full. I have a few normal endpoints and one that sends datascript transactions via SSE using s/connect to a bus topic (this is awesome by the way). But now I can't figure out where it goes wrong.

@bbss Just a hunch from a few weeks ago, if you curl to yada after it has locked up, does the same thing happen?

Are you using a reloaded workflow and resetting, or is the in prod?

If you're using a manofold @bbss are you certain you are shutting everything down and not leaving anything lingering across resets?

@dominicm will try when it happens again.

@malcolmsparks I am just starting manually using cider

(def server (yada/listener (routes) {:port 3000}))

#_((:close server))

@bbss Then doing a cider refresh as you update your code? or an eval of new code?

It could be that the bus that I store in an atom causes some problems? How would I know?

I just eval close and eval server again

ah, okay.

I can paste the code, it's not very verbose, just a naïve sync to everyone interested in one datascript db.

It's been wonderful to work with so far. Really cool to prototype with and I hope I can eventually use it in production when I make something useful.

And then eventually switch to datomic on the back-end.

My thoughts are that perhaps closing the aleph server doesn't cause everything to be cleaned up, so there is some resource leakage eventually causing everything to lock up

But if you are storing a single bus in an atom that leads me to suspect that is not the problem. Unless you are ever re-requring the namespace containing that atom

Are you using defonce for the atom?

Yes I am using defonce. It's in the same namespace currently.

I'm a bit stumped. How quickly does the lock up manifest itself?

I have tried resetting the atom (reset state {}) but that didn't seem to affect it.

Hmm, it occurred after a couple hours of hacking. Only a couple times so far.

Could those manifold.stream/connect's not be shutting down?

I don't have the issue now but I think the thing @dominicm was referring to is the browser having limits on open requests maybe. Which is a valid concern as when I close the server a ton of open subscriptions fail.

That's my thoughts. Could be to do with manifold streams

But refreshing the browser didn't work and I think I tried a different browser too.

Right. Always check with curl

Browsers limit sse connections to the same origin to 4

Will do next time. I also figured it might be how yada handles the connected stream.

Ah, good to know. Let me check, it might have been triggered by opening too many different subs.

Yes! I think that might have been it!

Thanks, I think that was it. Keeping an eye out and trying curl first next time.

IF there's a next time of course 😄

Great to hear. Yada shares a lot of infrastructure with Netty, and a huge benefit is that when things go wrong it is usually in user-space.

Manifold is awesome but you have to be careful to tidy up

The way manifold is designed gives you the control, which is the right design in my view

Yes, I do feel like I am building on solid fundamentals. Manifold looks like a good choice for scaling. But yeah, I do need to figure out how to not get a memory leak somewhere or something like that. Not sure yet how to do that and how I will find out. I know storing this somewhat ephemeral bus in an atom is probably not the way to go.

periodic cleaning up of the buses with no downstream consumers seems like something I'll need to do.

The best advice I can give is to keep things simple and reason about your design, thinking about it until you properly understand what is going on. Take some time to draw pictures or diagrams on scrap paper if that helps.

ah ive been waiting for that one, thanks for the release!

Let me know how it works out @lmergen !