Fork me on GitHub
#core-async
<
2017-02-04
>
tbaldridge05:02:07

@ska no limit....can you explain more about the code?

tbaldridge05:02:40

Or somehow post a minimal failing use case?

ska11:02:12

This is the main reader which should finally catch all exceptions. I call async/thread in process-the-thing but there I also have a logging exception wrapper around the production code. I don't really see how that could have stopped working, that's why I asked here if there is maybe some internal thing in the channel mechanics that could overflow or something. The receiving end of the application still worked fine (Jetty receiving requests and putting them into the channel).

ska11:02:38

Unfortunately, the code itself is closed source. Guess, I could find a way to send it privately.

serioga13:02:36

@ska for me it sounds like all threads in core.async's thread pool are busy. I would check the code for blocking ops in go-loop.

serioga14:02:38

at least those deref's looks dangerous but it's not clear what they deref exactly

ska14:02:59

They just deref an atom that contains the channel. I store it there at program start once. Thread starvation is one of my thoughts, too. Unfortunately, I had to restart the app and did no thread dump at the time. But I will keep an eye on it. I just wanted to clarify here, if there are known limitations on the number of items that can be read from a channel.

serioga14:02:26

such limitations has no sense but you can look in source code 🙂

serioga14:02:46

> I store it there at program start once. so why you deref it twice in the go-loop instead of reading it before loop?

ska14:02:47

At least during development I may reset the channel from time to time. I don't think it causes any trouble because it ran in production for more than 5 months. 🙂

tbaldridge16:02:07

@ska what does state/prq-unqueued! and process-the-thing do?

tbaldridge16:02:24

any sort of channel ops, or IO in those?

ska21:02:05

@tbaldridge prq-unqueued is trivial, it basically incs an atom.. process-the-thing is pretty heavy. It starts a core.async/thread (again with exception logged) and does a lot of HTTP calls to 2 different sites. It is very kind that you offer to help with this. That is more than I was asking for. I just needed the confirmation that there are no known internal limitations to channels. 🙂