You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2018/12/31 07:11:32 UTC

Re: [LDAP API] encoding refactoring status, 7

Hi !

Almost there... ALl the server-iunteg tests are passing but 4 
replication tests.


I had to fight against two nasty bugs yesterday, and it took me a while 
to understand what was going bad.

The fist big bug was difficult to ffix, because it was difficult to 
isolate. The tests were working in the IDE but everything was blocking 
when ran using 'mvn clean install', so it took a while to point out 
which exact test was blocking. At the end of the day, it was a bad PDU 
that generated an exception (on purpose), with a NoticeOfDisconnect not 
being handled the right way server side: the connection was shutdown too 
early on the server, and the NoD was never sent to the client, which was 
hanging forever.

The second bug was almost 10 years old : when an operation was aborted 
server side for any reason - in that case, we configured the server to 
refuse a request that was bigger than a given size -, a NoD was sent and 
never handled by the client, which simply timed out. That was kind of 
passing because the time out was low (30 seconds), and get unnoticed. 
With the changes I applied in the previous bug, the NoD generated a NPE, 
and then the bug was apparent.

So now, NoD are properly handled on both side (client and server).

Some of the other issues I faced with this refactoring is the fact that 
some of the extended response simply don't have a responseName, which 
makes it complicated to find their factory: I finally opted to stored 
the extendedRequest in the ExtendedFuture data structure, so when we 
receive the un-typed response, I just had to check the request to know 
which kind of response it was.

All of these complications are related to the fact that the API must not 
only support extended ops and controls we know of, but also those we 
have no clue about: we should be able to send an unknown control or 
extended operation, assuming the value is properly encoded and decoded 
by the user.


So when those 4 last failing tests will be fixed, I think we will be 
good to go - most of the checks are done in server-integ -. Not sure we 
will be ok this year, and we will definitively not have a release in 
2018, but that may be ok for the very beginning of 2019 ;-)


Happy new year !