Closed
Bug 263557
Opened 20 years ago
Closed 20 years ago
Sending a request fails on Windows when the ber size is larger than 64MB
Categories
(Directory :: LDAP C SDK, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
5.14
People
(Reporter: norikoyasuo, Assigned: mcs)
Details
Attachments
(1 file, 1 obsolete file)
2.94 KB,
patch
|
mcs
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: .LDAP C SDK V5.13 Sending a big entry (larger than 64MB) fails if the sender is running on the Windows machine. The reason is ldap request api (e.g., ldap_add_ext) eventually calls Win32 api WriteFile (.as ber_flush -> prldap_write -> PR_Send -> WriteFile) to send the request to the server, and WriteFile returns the error ERROR_NO_SYSTEM_RESOURCES. I modified mozilla/directory/c-sd/ldap/libraries/libprldap/{ldappr-int.h,ldappr-io.c} as attached and verified the large ber was successfully sent to the server. If you could take a look at the change, I'd greatly appreciate it. Reproducible: Always Steps to Reproduce: This is the original scenario that reveals the problem. 1. prepare an entry larger than 64MB 2. set up a master directory server and its consumer on a windows box 3. add the entry to the master server from non Windows machine Actual Results: The entry is added to the master, but it's not replicated to the consumer: the replay fails with LDAP_SERVER_DOWN on the master, although the consumer server is up and running. The consumer sees the connection is closed by the master. Expected Results: The entry is supposed to be replicated.
Reporter | ||
Comment 1•20 years ago
|
||
Assignee | ||
Comment 2•20 years ago
|
||
Comment on attachment 161536 [details] [diff] [review] cvs diff ldappr-int.h and ldappr-io.c The patch looks OK to me. I would not #undef PRLDAP_MAX_SEND_SIZE unless there is a specific reason we need to do so though.
Attachment #161536 -
Flags: review+
Assignee | ||
Comment 3•20 years ago
|
||
Adding Wan-Teh to the bug CC in case there is a need to fix this inside PR_Send().
Status: NEW → ASSIGNED
Comment 4•20 years ago
|
||
Perhaps PRLDAP_MAX_SEND_SIZE should be a smaller value than 32MB? Windows kernel will try to allocate 32MB of memory for the buffer when it prepares to send it. Something smaller (8MB maybe?) may be more memory efficient.
Assignee | ||
Comment 5•20 years ago
|
||
8MB sounds better than 32MB to me. Noriko, has this code been tested? Should I check it in soon?
Reporter | ||
Comment 6•20 years ago
|
||
I haven't tested with 8MB. Also, my test has been done only on Windows. I'm going to make it 8MB and run the test again on a couple of platforms...
Reporter | ||
Comment 7•20 years ago
|
||
I tested with 8MB PRLDAP_MAX_SEND_SIZE (just replacing the value in ldappr-int.h) on Windows 2000, Solaris 8 and Linux AS2.1, and I didn't see any problem.
Comment 8•20 years ago
|
||
Let me know if you think we should fix this inside PR_Send.
Assignee | ||
Comment 9•20 years ago
|
||
I think it would be a good idea to fix this inside PR_Send() (we will commit the libprldap change in any case though so this works with older copies of NSPR). At the least, the issue should be documented for NSPR users.
Assignee | ||
Comment 10•20 years ago
|
||
Fix committed to the trunk (I will post the final patch in a moment): mozilla/directory/c-sdk/ldap/libraries/libprldap/ldappr-int.h new revision: 5.4; previous revision: 5.3 mozilla/directory/c-sdk/ldap/libraries/libprldap/ldappr-io.c new revision: 5.5; previous revision: 5.4 Fix bug # 263557 - Sending a request fails on Windows when the ber size is larger than 64MB. Break up large messages into <= 8MB sized chunks inside prldap_write().
Assignee | ||
Updated•20 years ago
|
Target Milestone: --- → 5.14
Assignee | ||
Comment 11•20 years ago
|
||
I changed the comments slightly and changed 32 to 8.
Attachment #161536 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #162188 -
Flags: review+
Assignee | ||
Updated•20 years ago
|
Attachment #161536 -
Flags: review+ → review-
Assignee | ||
Comment 12•20 years ago
|
||
Marked bug as Fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•