Example/Suggestions for long-lived processes?

[orware]

I've been working on a mini project this weekend which features LDAP integration and I'm using LdapRecord to provide that functionality (been a long-time user of your packages, going back to 2009 or so, so I'm a big fan :-).

I ended up creating several variations for this mini project, which includes an amphp/http-server that features the LDAP authentication inside of it, which is pretty much my first simple HTTP server using amphp.

One thing I observed was that during my authentication check, when I connected to the LDAP Connections, I was only using connect(), but wasn't using disconnect() (or the reconnect()) methods.

This wasn't such a big deal for a short-lived process (such as would be the case for a normal PHP page access), but with the long-lived HTTP server process, this was resulting in the LDAP connections staying open for about 20-30 minutes (and being reused throughout that time) before eventually timing out.

Once the LDAP connection timed out, subsequent attempts to run the connect() appeared to only result in a "Can't contact LDAP server" message.

I believe I've solved it by switching my connect() calls to be reconnect() calls instead, and also added in disconnect() calls where appropriate and I'm currently running some observations to make sure that this indeed fixes the "Can't contact LDAP server" problem.

However, I suppose if I was looking for the best speed possible, leaving the connections open, but being able to reconnect as needed automatically, could be another approach, since the open connections would potentially make things even faster on a server that is receiving a lot of authentication requests, so I wanted to ask how that might be possible (since I didn't really seem to see any examples in the documentation related to using disconnect() and reconnect() directly, or any other methods that might be handy in a scenario like this).

Thank you!

[stevebauman]

Hey @orware! Thanks so much for your kind words! ❤️ I'm really happy to hear that you enjoy my work 😄

but with the long-lived HTTP server process, this was resulting in the LDAP connections staying open for about 20-30 minutes

This is something I actually haven't thought about. I absolutely want LdapRecord to be compatible with this type of server setup (being able to be used it long running processes).

However, I suppose if I was looking for the best speed possible, leaving the connections open, but being able to reconnect as needed automatically, could be another approach

I have this functionality in place at the moment:

1. LDAP connections will be automatically be "connected to" if any operations are passed to the run() method within the Connection class (this method is used for almost all LDAP operations -- except for the initial connection).
2. Automatically reconnect if there's a connection or operation failure (seen in the tryAgainIfCausedByLostConnection method on the Connection class):

LdapRecord/src/Connection.php

Lines 252 to 275 in 415fa35

	public function connect($username = null, $password = null)
	{
	$attempt = function () use ($username, $password) {
	$this->dispatch(new Events\Connecting($this));
	is_null($username) && is_null($password)
	? $this->auth()->bindAsConfiguredUser()
	: $this->auth()->bind($username, $password);
	$this->dispatch(new Events\Connected($this));
	$this->retryingInitialConnection = false;
	};
	try {
	$this->runOperationCallback($attempt);
	} catch (LdapRecordException $e) {
	$this->retryingInitialConnection = true;
	$this->retryOnNextHost($e, $attempt);
	}
	return $this;
	}

However -- disconnections do not occur automatically, so I'm assuming this is what is actually causing them to stay open, since you yourself would have to call the method at some point to remove the open resource's from memory.

so I wanted to ask how that might be possible (since I didn't really seem to see any examples in the documentation ...

You're right -- I think I need to expand on the docs further in this regard 👍

which includes an amphp/http-server

Do you know if this server eventually (over time, or some other mechanism) tears down instantiated objects using the __destruct method? I'm wondering if we can handle this automatically somehow so LDAP connections are automatically terminated and then can get re-created when needed?

[orware]

Thanks @stevebauman for the reply (to provide a quick history, I first used adLDAP back in 2009 to create an online staff directory for my workplace, but it's also been useful in multiple custom web applications over the years as well for us, since we used LDAP authentication for most everything until about 2-3 years ago when we started to adopt SSO a bit more, but LDAP authentication situations still crop up like for this project :-)!

---

This is how I have things now to better work with the long-lived process (so far, this appears to be working as expected since I left the new version of the code running overnight and after each SFTP connection timeout the SFTP client was able to reconnect/reauthenticate which triggers the lines highlighted in the link below, and that's something that had been failing before...the amphp HTTP server is only using about 5 MB right now as well so is pretty lightweight...now it makes me want to experiment more with amphp/http-server and other similar solutions 😄):
https://github.com/orware/sftpgo-ldap-http-server/blob/main/functions.php#L42-L87

This is how I had things previously (which worked fine for a normal short-lived process):
https://github.com/orware/sftpgo-ldap-http-server/blob/6dea0be9a86bf86260218ceb43bf3bc0391fdeaa/functions.php#L41-L77

I switched to the approach in the first link after reviewing the Connection class and seeing what the reconnect() method was doing, so that seemed to ok to swap out and use instead of connect() and then I added in the disconnect() calls as well to help ensure the connections are disconnected immediately after they've handled their part of the process. At the moment, I figured it was safer to use reconnect() since it helps to force a disconnect(), initialize(), and connect() in a single step and adding in the disconnect() would also help to prevent any LDAP connections from staying open between requests (which is probably the best in my use case if I'm being honest about it, since the number of SFTPGo authentications would likely be minimal throughout any particular day, so keeping the LDAP connections open all the time is probably more wasteful than it should be).

In the previous version of the code, it was running into an exception on the connect() method after sometime had passed (the SFTPGo application has a default connection timeout of 15 minutes, so after that time has passed the SFTP client has to reauthenticate and it triggers another web hook authentication behind the scenes, which would hit the http://localhost:9001 URL that I have this mini PHP HTTP server process running on locally on the server...but if the LDAP connections had timed out or gotten disconnected in some way, then the connect() would simply trigger that "Can't contact LDAP server" exception, so additional logins would fail, and I didn't have any extra logic in there to try and reconnect if necessary in that sort of situation).

I'm currently happy with the updated version's reliability (unfortunately I haven't combed through the amphp/http-server docs enough to answer your last question, but it's possible it does have something related to that available that might be useful in a situation like this), but happy to hear if there are any suggestions you can think of :-).

Hopefully the extra details help make the situation a bit more clear since I didn't share any links in my initial message above!