issues with local connections on the server

[ahdat81]

generally speaking, i've noticed random connection issues on the server-side. before i deep dive to track down the issues, i wanted to ask about best practices or known issues around this. so here's an example. on the server i have a node app that creates about 10 persistent worker threads. each worker thread creates a client connection to the local db, connecting to the same node. each signs in as the 'admin' . and then creates a live proxy. so the connection would look something like this:

// stagger the init a few seconds between each connection so we're not slamming the db at once
..

const db = new AceBaseClient({ host: 127.0.0.1, port: port, dbname: dbname, https: https });
await db.ready()
await db.auth.signIn(admin,password)
let proxy = await db.ref('scanner').proxy()

seems simple enough. but i would get random issues such as :

• Server did not respond to "subscribe" request after 3 tries
• request failed: access_denied (i'm assuming a disconnect happens and suddenly access is denied)
• various 'timeouts'

it doesn't happen frequently, but randomly one or two here and there, but not consistently. for testing, im making sure the node only has a few small objects. i'm kind of surprised by these errors since this is running on the server via a local connection. So maybe there are some known general strategies for what im doing

• is this generally the best way to connect to a local db the server?
• is the live proxy not recommended to use in this situation? the proxies arnt really overlapping in terms of the data its manipulating
  its the same node (a collection {}) they're modifying objects that should be unique to each thread/connection
• any known issues with multiple connections/proxies to the same node?
• anything else?

thanks

[appy-one]

Sounds like this should not be problematic.

To verify, can you confirm you are running 1 single AceBaseServer instance/thread, and 10 worker threads connecting to that server with an AceBaseClient?

Also, if you can provide minimal example project that can reproduce this, that will really help.

[ahdat81]

yep only one instance of acebaseserver, 10 worker threads with 10 seperate client connections to the db. ill try to put something together once i get a chance

[ahdat81]

looks like the issue was the system was overloaded during initialization and causing acebase to intermittently stall. The cpu usage was at~50%, but it might have been periodically spiking. just letting the system breathe a bit with some sleeps fseems to have ixed the issue, along with checking (and reconnecting) the db before accessing proxies. although that brings up a point, is there a way to raise the priority of the process through a flag or setting (i didnt see it with a quick check of the code)? i dont have an easy way to do it on my system (windows server, running multiple node processes so i cant single out the particuar db process)

[appy-one]

just letting the system breathe a bit with some sleeps fseems to have ixed the issue

I don't know if you are or not, but - do not run heavy synchronous tasks in the server or client processes, that will cause the sockets to hangup. For long running tasks, use async flows with promises. Remember, JS is single-threaded and if you hammer the CPU with a synchronous task, it can't keep websocket connections alive in that same thread. Raising the priority of a process means it will be given priority over other running processes, it does not scale up your NodeJS process to multiple threads.

That aside, make sure to enable transaction logging in your server settings to allow the proxies on your clients to fetch only mutations after disconnects instead of reloading the entire value.

[ahdat81]

I have multiple seperate node apps running on the server. There is a node app for the acebase server that only loads the acebase server. I was going to test manually upping the priority of that acebase server process to see if it helps, but now that you mention it, I didnt consider the acebase-clients were being hung up. But right, i was using pseduo sleeps via await/timeout. Also added some db checking/reconnecting code. Still seeing db reconnects, but not seeing error messages anymore. So definite improvements, will optimize more this wknd.

I saw that the transaction logging was still in beta, you think its good enough to give it a go in production?