It uses a separate thread per connection. The thread blocks until it receives a request from a client. Upon receiving a request, the thread performs all processing for that request and then goes back to waiting for the next request. Unless you have a huge number of connections established at the same time, this shouldn’t have any substantial performance implications (and the in-memory server isn’t really tuned for great performance anyway).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you very much for the fast answer. we are using it since two years as an ldap proxy in several production environments. so far we didn't encounter any stability or performance problems. you did a very good job! :-) but one customer has 3000 active connections. 3000 threads are using around 800 mb memory. I don't know if i should try to add a thread pool. and maybe we get a new customer with around 20000 active connections.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I’m happy to hear that you’ve found the LDAP SDK useful and reliable.
Unfortunately, redesigning it to use a thread pool to address the issue of memory consumption would be a pretty huge undertaking.
The LDAP SDK uses Java’s blocking socket API for performing network communication. This API is much simpler than using selectors and channels (and if SSL/TLS is in the picture, using SSLSocket is much, much, much simpler and less error-prone than using SSLEngine). It also offers better performance and lower latency when you have a relatively small number of connections, and even for a large number of connections, the performance difference isn’t that substantial.
It wouldn’t be all that difficult to add a thread pool into the in-memory directory server for the purpose of limiting the number of operations being processed concurrently, or for allowing multiple requests from the same client to be processed concurrently. But since each listener connection has a dedicated thread waiting to read data from the connection, that wouldn’t help with the memory consumption or number of threads. The only way to accomplish that would be to use Java’s selector API to have a limited number of threads reading requests from clients, and that would require adding or rewriting a substantial amount of new code. Unfortunately, that’s probably not likely to happen any time soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Does the InMemoryServer use a thread pool to process requests or does it create a thread per connection?
It uses a separate thread per connection. The thread blocks until it receives a request from a client. Upon receiving a request, the thread performs all processing for that request and then goes back to waiting for the next request. Unless you have a huge number of connections established at the same time, this shouldn’t have any substantial performance implications (and the in-memory server isn’t really tuned for great performance anyway).
thank you very much for the fast answer. we are using it since two years as an ldap proxy in several production environments. so far we didn't encounter any stability or performance problems. you did a very good job! :-) but one customer has 3000 active connections. 3000 threads are using around 800 mb memory. I don't know if i should try to add a thread pool. and maybe we get a new customer with around 20000 active connections.
I’m happy to hear that you’ve found the LDAP SDK useful and reliable.
Unfortunately, redesigning it to use a thread pool to address the issue of memory consumption would be a pretty huge undertaking.
The LDAP SDK uses Java’s blocking socket API for performing network communication. This API is much simpler than using selectors and channels (and if SSL/TLS is in the picture, using SSLSocket is much, much, much simpler and less error-prone than using SSLEngine). It also offers better performance and lower latency when you have a relatively small number of connections, and even for a large number of connections, the performance difference isn’t that substantial.
It wouldn’t be all that difficult to add a thread pool into the in-memory directory server for the purpose of limiting the number of operations being processed concurrently, or for allowing multiple requests from the same client to be processed concurrently. But since each listener connection has a dedicated thread waiting to read data from the connection, that wouldn’t help with the memory consumption or number of threads. The only way to accomplish that would be to use Java’s selector API to have a limited number of threads reading requests from clients, and that would require adding or rewriting a substantial amount of new code. Unfortunately, that’s probably not likely to happen any time soon.