[OPENDJ-3707] PersistentSearchControlTest#testMaxPSearch() is disabled because it fails after change to reactive handlers Created: 02/Feb/17  Updated: 07/Nov/19  Resolved: 18/Aug/17

Status: Done
Project: OpenDJ
Component/s: core server
Affects Version/s: 4.0.0
Fix Version/s: 5.5.0

Type: Task Priority: Major
Reporter: Nicolas Capponi Assignee: Jean-Noël Rouvignac
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Depends
depends on OPENDJ-3868 Proxied persistent searches are not c... Done
Dev Assignee: Jean-Noël Rouvignac

 Description   

PersistentSearchControlTest#testMaxPSearch() is disabled because it fails now that the Router is active in the server.

The issue is that there is blocking call in internalClientConnection#search() until the stream is complete, which never happens in the test. So the test hangs.

A simple fix could be to launch the persistent search in a separate thread (the psearch is cancelled at the end of the test, so this would end the blocking call).



 Comments   
Comment by Matthew Swift [ 03/Feb/17 ]

What's changed? From what I can see the InternalClientConnection always did blocking search requests. You PR doesn't seem to change the behavior, so I'm surprised that this test's behavior has changed. I'm not disagreeing, I'm just a bit surprised.

Comment by Nicolas Capponi [ 03/Feb/17 ]

I have not investigated yet, just noted that when running this test the process hangs, and a jstack show that it is blocked on the following line in internalClientConnection#search() method :

 final List<Response> responses = flow.toList().blockingGet();
Comment by Jean-Noël Rouvignac [ 17/Aug/17 ]

The InternalClientConnection.searchAsync() used to be work in a not-to-blocking way prior to the rewrite to reactive.
During the reactive rewrite it was made fully blocking because of this code in InternalClientConnection.search():

final List<Response> responses = flow.toList().blockingGet();

I fixed this test by using an LdapConnectionFactory instead of the InternalClientConnection.

Note: making InternalClientConnection non-blocking again would be nice, even though it is not a priority.
I am not aware of any code in the server using the asynchronous nature of this connection.
All the server code was written when InternalClientConnection was fully blocking.

Comment by Jean-Noël Rouvignac [ 18/Aug/17 ]

FIXED as described above.

Comment by Matthew Swift [ 07/Nov/19 ]

Moved to closed state because the fixVersion has already been released.

Generated at Sun Nov 29 17:10:31 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.