SSL poll looping after initial LDAP request has been sent

NEW
Unassigned

Status

7 years ago
2 years ago

People

(Reporter: mayhemer, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
During test of LDAP server in bug 723551 I have found out that LDAP loops socket poll (PSMPoll) after it had sent the initial request out and the handshake had completed.

Log snip (ldap:5,pipnss:5):

0[55ea10]: nsLDAPOperation::SimpleBind(): called; bindName = 'xxxxxxx'; 
0[55ea10]: [8b00548] Socket set up
0[55ea10]: [a0b8ef8] starting AuthCertificateHook
0[55ea10]: AuthCertificate setting NEW cert 9d30d20
0[55ea10]: HandshakeCallback KEEPING cert 9d30d20
0[55ea10]: [8b00548] wrote 29 bytes
0[55ea10]: pending operation added; total pending operations now = 1
4280[9e91710]: [8b00548] poll SSL socket using lower 1
4280[9e91710]: [8b00548] poll SSL socket returned 1
4280[9e91710]: [8b00548] poll SSL socket using lower 1
4280[9e91710]: [8b00548] poll SSL socket returned 1
4280[9e91710]: [8b00548] poll SSL socket using lower 1
4280[9e91710]: [8b00548] poll SSL socket returned 1
4280[9e91710]: [8b00548] poll SSL socket using lower 1
4280[9e91710]: [8b00548] poll SSL socket returned 1
4280[9e91710]: [8b00548] poll SSL socket using lower 1
4280[9e91710]: [8b00548] poll SSL socket returned 1

..... looping the same for some 100ms, 1000+ lines

4280[9e91710]: [8b00548] poll SSL socket using lower 1
4280[9e91710]: [8b00548] poll SSL socket returned 1
4280[9e91710]: [8b00548] read 14 bytes
4280[9e91710]: InvokeMessageCallback entered
4280[9e91710]: pending operation removed; total pending operations now = 0


Interesting is that LDAP lib doesn't call on the PSMRecv during the loop, so it is hard to figure out the cause of the loop.

This is not a major issue since the main thread, where this loop happens, is blocked anyway.  This may cause CPU loads when accessing an extremely slow server.  I have no knowledge of any timeout in this code but I presume there is one and is probably quit short, so CPU load would occur just for a short time.

My suggestion is to fix this (if not naturally removed) as part of complete LDAP overhaul to asynchronous design.
Keywords: perf

Comment 1

7 years ago
(In reply to Honza Bambas (:mayhemer) from comment #0)
>
> My suggestion is to fix this (if not naturally removed) as part of complete
> LDAP overhaul to asynchronous design.

do we need a bug for that?
I didn't find any.
(Reporter)

Comment 2

7 years ago
(In reply to Wayne Mery (:wsmwk) from comment #1)
> (In reply to Honza Bambas (:mayhemer) from comment #0)
> >
> > My suggestion is to fix this (if not naturally removed) as part of complete
> > LDAP overhaul to asynchronous design.
> 
> do we need a bug for that?
> I didn't find any.

No.  I think you or someone from the mailnews team should file one.

Updated

2 years ago
Duplicate of this bug: 727883
You need to log in before you can comment on or make changes to this bug.