We have callback support in our product and we make use of AsyncSearchResultListener for that. Now this is legacy/old code that I'm trying to clean up. In this particular code we reuse the same AsyncSearchResultListener over and over. Is there any practical benefit to doing that or could we createa a new one with each subscribe request?
Br
Niclas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Either approach works fine. If your listener doesn’t need to maintain any state information that ties it to a particular request, then you can reuse the same one for all of your requests. That would help reduce the amount of memory allocation and garbage collection that would be performed if you create a separate listener instance for each search, but that’s probably not that big a concern in most cases. And if a shared listener needs to incorporate locking or have some other type of synchronization to ensure that it’s safe to use by multiple threads at the same time, then it might be better to have a separate instance per search.
Note that since your other thread talks about connection pooling, then I should warn you that there are caveats to using asynchronous operations on pooled connections. In particular, connection pools don’t provide any direct methods for performing asynchronous operations, so the only way you can do that is by checking out a connection (with the getConnection method) and using one of its methods for processing an asynchronous operation. We strongly discourage releasing a connection back to the pool if there are still active asynchronous operations on that connection, because when a connection is released back to a pool, then that connection shouldn’t be in use by anything.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The thing is that we can have multiple subscribers per DN in the database. Having 1 listener means that the listener would need to have logic that notifies the correct subscribers while having multiple listeners would avoid the need for that. So right now I'm more favorable towards multiple listeners as I don't think it will have a huge impact on memory allocation.
Regarding releasing the asynchronous connection back to the pool is there any limit or negative impact on keeping a connection checked out for a very long time?
In the case that the client crashes I guess that the asynchronous operations would still be running on the server? Would we have to do a clean up of the server or will they timeout or otherwise be cleaned up automatically?
Just want to check. In the scenario where we have 1 shared listener used by several asynchronous search requests would abandoning the search request affect the listener somehow? The legacy code never does that so that is why I'm asking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding releasing the asynchronous connection back to the pool is there any limit or negative impact on keeping a connection checked out for a very long time?
Nope. The only real downside is that the checked-out connection isn’t available for other application threads to use.
In the case that the client crashes I guess that the asynchronous operations would still be running on the server? Would we have to do a clean up of the server or will they timeout or otherwise be cleaned up automatically?
The notion of a synchronous search request versus an asynchronous one is purely a client-side distinction. To an LDAP server, they look identical, and an LDAP server always has to handle the possibility that a client crashes. What that means, though, depends on what you mean by crash. If the application crashes and the JVM stops, then any connections it has open will be closed automatically. But if something happens and something that has checked out a connection fails in some way that leaves the connection alive but permanently checked out, then that’s a much less desirable scenario, and it’s something you should definitely try to avoid by using something like a finally block in your code. But you can use safeguards in the server like configuring the server to automatically close any connections that have been idle for more than a specified length of time.
Just want to check. In the scenario where we have 1 shared listener used by several asynchronous search requests would abandoning the search request affect the listener somehow? The legacy code never does that so that is why I'm asking.
LDAP is an inherently asynchronous protocol, and (with a few exceptions for operations that can change the state of a connection, like bind or StartTLS), you can have any number of operations active at any given time. Abandoning one operation on a connection should not have any impact on any other operation on that connection or any other connection. If you know that an operation isn’t done yet, but you don’t need any more response data for that operation, then abandoning it is a good thing because it allows the server to free up any resources that may be associated with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We have callback support in our product and we make use of AsyncSearchResultListener for that. Now this is legacy/old code that I'm trying to clean up. In this particular code we reuse the same AsyncSearchResultListener over and over. Is there any practical benefit to doing that or could we createa a new one with each subscribe request?
Br
Niclas
Either approach works fine. If your listener doesn’t need to maintain any state information that ties it to a particular request, then you can reuse the same one for all of your requests. That would help reduce the amount of memory allocation and garbage collection that would be performed if you create a separate listener instance for each search, but that’s probably not that big a concern in most cases. And if a shared listener needs to incorporate locking or have some other type of synchronization to ensure that it’s safe to use by multiple threads at the same time, then it might be better to have a separate instance per search.
Note that since your other thread talks about connection pooling, then I should warn you that there are caveats to using asynchronous operations on pooled connections. In particular, connection pools don’t provide any direct methods for performing asynchronous operations, so the only way you can do that is by checking out a connection (with the getConnection method) and using one of its methods for processing an asynchronous operation. We strongly discourage releasing a connection back to the pool if there are still active asynchronous operations on that connection, because when a connection is released back to a pool, then that connection shouldn’t be in use by anything.
The thing is that we can have multiple subscribers per DN in the database. Having 1 listener means that the listener would need to have logic that notifies the correct subscribers while having multiple listeners would avoid the need for that. So right now I'm more favorable towards multiple listeners as I don't think it will have a huge impact on memory allocation.
Regarding releasing the asynchronous connection back to the pool is there any limit or negative impact on keeping a connection checked out for a very long time?
In the case that the client crashes I guess that the asynchronous operations would still be running on the server? Would we have to do a clean up of the server or will they timeout or otherwise be cleaned up automatically?
Just want to check. In the scenario where we have 1 shared listener used by several asynchronous search requests would abandoning the search request affect the listener somehow? The legacy code never does that so that is why I'm asking.
Nope. The only real downside is that the checked-out connection isn’t available for other application threads to use.
The notion of a synchronous search request versus an asynchronous one is purely a client-side distinction. To an LDAP server, they look identical, and an LDAP server always has to handle the possibility that a client crashes. What that means, though, depends on what you mean by crash. If the application crashes and the JVM stops, then any connections it has open will be closed automatically. But if something happens and something that has checked out a connection fails in some way that leaves the connection alive but permanently checked out, then that’s a much less desirable scenario, and it’s something you should definitely try to avoid by using something like a finally block in your code. But you can use safeguards in the server like configuring the server to automatically close any connections that have been idle for more than a specified length of time.
LDAP is an inherently asynchronous protocol, and (with a few exceptions for operations that can change the state of a connection, like bind or StartTLS), you can have any number of operations active at any given time. Abandoning one operation on a connection should not have any impact on any other operation on that connection or any other connection. If you know that an operation isn’t done yet, but you don’t need any more response data for that operation, then abandoning it is a good thing because it allows the server to free up any resources that may be associated with it.
Ok, no more followup-questions :)
Thanks for all the help!
Br
Niclas