aleph

valerauko 2025-03-18T04:39:36.423919Z

is there a way to specify (adjust) the number of threads used by the server's event loop group?

dergutemoritz 2025-03-19T09:19:13.457049Z

@vale Thanks! As for using a virtual thread executor: this is probably the cause of your issue. Netty isn't really compatible with those, yet. See this thread where somebody else tried the same and ran into pretty much the same problem like you: https://clojurians.slack.com/archives/C0G922PCH/p1722257501702339

dergutemoritz 2025-03-19T09:19:39.795459Z

It also contains some pointers to how it might work these days, i.e. Netty recently added something that looks like it should support virtual threads.

dergutemoritz 2025-03-19T09:19:51.309239Z

But Aleph doesn't yet allow you to use that, I think

dergutemoritz 2025-03-19T09:19:56.771329Z

Patches welcome

dergutemoritz 2025-03-19T09:23:52.536799Z

In particular, this message is relevant: https://clojurians.slack.com/archives/C0G922PCH/p1727084183258159?thread_ts=1722257501.702339&cid=C0G922PCH

valerauko 2025-03-19T11:12:00.655619Z

well that's sad

valerauko 2025-03-19T11:12:20.959009Z

as for the thread pinning: i believe that's resolved in jvm 24 if you can use it

dergutemoritz 2025-03-19T12:41:56.574059Z

even for synchronized?

dergutemoritz 2025-03-19T12:47:23.084309Z

Aha indeed! https://openjdk.org/jeps/491

dergutemoritz 2025-03-19T12:48:05.873139Z

@vale so you're on 24?

valerauko 2025-03-19T13:44:08.995499Z

not yet but if you're telling me that aleph will work better with virtual threads on 24 i will

valerauko 2025-03-19T13:44:34.041619Z

most of my workloads are massively io bound (remote api calls, db queries) so i'd benefit a lot from that

dergutemoritz 2025-03-19T14:52:33.349259Z

well so far the synchronized blocks are the main suspects but it's not certain

dergutemoritz 2025-03-19T14:53:50.093799Z

so dunno if this will really help but worth a shot

valerauko 2025-03-18T04:40:25.442899Z

in start-server this seems to be hardcoded to (* 2 (.availableProcessors (Runtime/getRuntime)))

valerauko 2025-03-18T04:40:53.028779Z

use case is that in a heavily io-bound workload using a virtual thread executor i don't want to be limited by the cpu core count

valerauko 2025-03-18T04:43:22.952809Z

is this something that can be done with the bootstrap-transform option?

dergutemoritz 2025-03-18T13:08:25.584289Z

After a cursory investigation into the code, I don't think this is currently possible. There is https://github.com/clj-commons/aleph/blob/998a32a5ed9ada581fa73a389fbb0df43e8dd2d2/src/aleph/netty.clj#L1267 that could be used for this but the function that reads it is only used by clients...

dergutemoritz 2025-03-18T13:08:33.904619Z

For servers, it appears to be hardcoded

dergutemoritz 2025-03-18T13:09:17.297599Z

And Netty's MultithreadEventExecutorGroup (the relevant base class here) doesn't allow changing the thread count after instantiation.

dergutemoritz 2025-03-18T13:09:25.706849Z

(which would be a way to do it via bootstrap-transform)

dergutemoritz 2025-03-18T13:09:48.642679Z

@vale Would you mind filing a ticket for this? 🙏

valerauko 2025-03-18T15:22:31.493939Z

Sure, but I'd also want to clarify if this is relevant at all with a newVirtualThreadPerTaskExecutor ? Thing is i've been seeing 502 errors (which I assume is aleph/netty refusing connections) when there's very minimal load and my only idea was that there's only one server thread (since the code runs on <1 vcpu) and so it can't accept any more (this using a virtual thread executor) But I don't understand the aleph/manifold execution model well enough (i was bitten by this when i assumed bindings in let-flow would get evaluated as if in separate futures)

valerauko 2025-03-18T15:28:34.893629Z

I tried with bootstrap-transform but AbstractBootstrap does not allow changing .group once it's set

valerauko 2025-03-18T15:29:34.850139Z

https://github.com/clj-commons/aleph/issues/747