DPS 6.3.1.1 - Issues while connecting through SSL

Question

Hello !!
I have a issue where my application client reported that they are unable to connect to the LDAP using SSL. Where as everything works fine in LDAP (non secured)
This is how our deployment looks.
Clients <=> Load Balancer <=> DPS (2 instance) <=> DS (2 masters)
The DPS is configured with DSP (data source pool) (with proportional algorithm of 50:50 to backend data sources). Client Affinity ("read-write-affinity-after-any") is configured for this DSP. The DSP is attached with 2 data sources.
So when the client connected in a secured port using LDAPS, they are unable to authenticate/search against this environment. No issues were found in DS logs for any of the bind/search requests. But in DPS, we noticed below log which i want to get clarification on.
Note: I have removed the hostnames/Ip where ever applicable from the logs.
=====================================================
[04/May/2011:12:24:39 -0400] - PROFILE - INFO - conn=1255260 assigned to connection handler cn=default connection handler, cn=connection handlers,cn=config
[04/May/2011:12:24:39 -0400] - CONNECT - INFO - conn=1255260 client=x.x.x.x:52461 server=x.x.x.x:636 protocol=LDAPS
[04/May/2011:12:24:39 -0400] - OPERATION - INFO - conn=1255260 op=0 BIND dn="uid=app_id,ou=applications,dc=example,dc=com" method="SIMPLE" version=3
[04/May/2011:12:24:39 -0400] - SERVER_OP - INFO - conn=1255260 op=0 BIND dn="uid=app_id,ou=Applications,dc=example,dc=com" method="SIMPLE" version=3 s_msgid=3 s_conn=ds_Master2:26560
[04/May/2011:12:24:39 -0400] - SERVER_OP - INFO - conn=1255260 op=0 BIND RESPONSE err=0 msg="" s_conn=ds_Master2:26560
[04/May/2011:12:24:39 -0400] - PROFILE - INFO - conn=1255260 assigned to connection handler cn=CH_ENV_catch-all_LDAPS,cn=connection handlers,cn=config
[04/May/2011:12:24:39 -0400] - OPERATION - INFO - conn=1255260 op=0 BIND RESPONSE err=0 msg="" etime=0
[04/May/2011:12:24:39 -0400] - OPERATION - INFO - conn=1255260 op=1 msgid=2 SEARCH base="ou=people,dc=example,dc=com" scope=2 filter="(uid=abcdef)" attrs="*"
[04/May/2011:12:24:39 -0400] - SERVER_OP - INFO - conn=1255260 op=1 SEARCH base="ou=people,dc=example,dc=com" scope=2 filter="(uid=abcdef)" attrs="*" s_msgid=498 s_conn=ds_Master1:26072
[04/May/2011:12:24:39 -0400] - SERVER_OP - INFO - conn=1255260 op=1 SEARCH RESPONSE err=0 msg="" nentries=0 s_conn=ds_Master1:26072
[04/May/2011:12:24:39 -0400] - OPERATION - INFO - conn=1255260 op=1 SEARCH RESPONSE err=0 msg="" nentries=0 etime=0
*[04/May/2011:12:24:39 -0400] - DISCONNECT - INFO - conn=1255260 reason="other" msg="Exception caught while polling client connection LDAPS.x.x.x.x.52461 -- javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?"*
=======================================================
If noticed in the above logs, the initial Bind request via LDAPS is routed to Master 2. But the susequent search request (for user abcdef) is routed to Master 1.
And finally the DISCONNECT operation came (last line) without a proper unbind.
Is this alternate routing a expected behavior when client affinity is turned ON ? Is this exception causing the application's search failures ?
Please shed some pointers on this..
Thanks.
Edited by: Prasee on May 6, 2011 8:07 AM

Answer 1

Pls see inside:
Thanks for the reply. Yes the client is a loadbalancer in this case. So does it mean that this behavior (sending request to 2 different DS in a same connection) is expected ? I have few additional queries that arise from your reply :-)
Loadbalancing algorithm takes precedence "if the request that starts client affinity has not yet occurred"
Since its the load balancer that connects to DPS for any/every request every time., How do the DPS know whether a request that starts client affinity has occurred / not occurred ?Well, client affinity starts with a certain operation (not by establishing the client<->dps connection) as specified by your client affinity policy. In your case ("client-affinity-policy:read-write-affinity-after-any") it starts for all operations after the first read or write operation. DPS is not a (network) connection based router - so it does not route the client connection to the data source but forwards the client operations (request) on dedicated bind,read,write,.. connections to a data source selected by your load balancing and/or client affinity policy.
In our case, Its the same connection (conn=1255260) that receives bind and search request from the client. So when a connection is established, the client affinity should have got enabled and sent the bind request to Master 2 initially, so for the next search request, shouldn't it be sent to Master 2 again ?No, see above.
>
Sorry for these questions, I am basically trying to understand more on how client affinity works when a load balancer is in between.
Coming to the exception,
[04/May/2011:12:24:39 -0400] - DISCONNECT - INFO - conn=1255260 reason="other" msg="Exception caught while polling client connection LDAPS.x.x.x.x.52461 -- javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?"
Does this abrupt shutdown of connection means the search response would have got dropped before reaching the end client (application) ?Yes, that may be possible ...
>
Thanks for your help !!