Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.
[root@mysystem logs]# java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.10) (rhel-126.96.36.199.10.el5_7-x86_64)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
[root@mysystem logs]# grep java errors
[14/Feb/2012:16:58:19 +0100] - STARTUP - INFO - Java Version: 1.6.0_20 (Java Home: /usr/lib/jvm/java-1.6.0-openjdk-188.8.131.52.x86_64/jre)
My LDAP backend servers are ODSEE 11gR1 servers too, so they don't support the paged result control, that's why I want DPS to block these
requests (they originate from FreeBSD unix hosts set as LDAP clients, when one runs the top command)
I don't understand why there's such a time gap between the etimes of the LDAP backend (153 ms) and the etime of my DPS server, (4398 ms) ?
I was previously using DPS 6.3.x and I had a different behaviour when using such LDAP control requests: the DPS was blocking those requests:
[31/Jan/2012:23:46:07 +0100] - OPERATION - INFO - conn=1452338 op=1 SEARCH RESPONSE err=12 msg="The server is not configured to pass through control 1.2.840.1135184.108.40.2069" nentries=0 etime=234
I've checked the configuration differences between both DPS versions, and it looks the same. Also, I tried to restore the default configuration
with regards to LDAP controls, with the ODSEE 11gR1 instance (see below), but it still the same problem, the request is not blocked :
The 220.127.116.11 behaviour is correct (and 6.3* was wrong) as specified by rfc 2696: If the server does not support this control, the server MUST return an error of unsupportedCriticalExtension if the client requested it as critical, otherwise the server SHOULD ignore the control. If you would makr the control critical (OID:true) it should return with errno 12 (Unavailable critical extension).