2678 - [LDAP] When server is down, Communicator hangs. Need better design.

Status: VERIFIED INVALID

(MailNews Core :: Backend, defect, P2)

Description

[lchiang]

When ldap server is down, Communicator hangs.  Need better design.

<initial description taken from bugsplat 334064.  I pasted most of the relevant
comments to reproduce the bug from that bug report except for the customer name,
the business case, and revenue numbers since bugzilla is a public database.>

Bugsplat bug filed by [e-mail]

If the LDAP server is down (ICMP host unreachable in our case) and you do
something that results in an LDAP query, the entire Communicator client
hangs for a couple of minutes until it times out. There is no way to stop the
transaction, and it doesn't even respond to screen repaints or operations in
other windows (like Navigator.) LDAP servers will occasionally be down, so the
Communicator client needs to be robust.  Make the Stop key work.  Arrange that
the LDAP query doesn't block other threads. Users who have the pinpoint
addressing set to include LDAP directories can lose their client if they are too
slow typing!

I have reproduced this and following are my observations
1)If you shutdown your ldap server (through admin tool) and then try to query
through the client than you get a bind error .
2)If you pull out the network cable from the server and then try to query
through client it just hangs for a couple of minutes.Not only the address book
window but your complete communicator is hung for a couple of minutes.

------- Additional Comments From samit  11/10/98 17:16 -------

Well!the observations is the "TEST CASE".All you need is a directory server and
a communicator client.I have reproduced this and this is a very "CRITICAL" for
the customer.
I though the 2 steps would be simple enough to reproduce but if you need a
detailed test case here it is
1)Start the communicator
2)Add a directory server entry to which you have admin access(by opening address
book)
3)Do a ldap search
4)Shutdown the LDAP server(through admin tool) and do a search.
5)You will get a bind error Which is expected
6)Start the LDAP server and do a search again and it should work fine
7)Now instead of using the admin server to shutdown just pull the network cable.
8)Instead of giving a error message the communicator just hangs for a couple of
minutes.You can't do anything either in the address book window or othee
communicator window .
Customer wants a workaround which will make the stop key work or some workaround
where all the thread windows don't go into a hang mode
I have tried this with Communicator 4.5 on Solaris 2.6

------- Additional Comments From serge  11/17/98 14:14 -------

Yes, it does hangs for a couple of minutes in time out, if dir server
is unreachable.
But, the test case with disconnecting of  the network cable is inappropriate,
you can hang practically any net required apps. For example, here at netscape,
solaris CDE: open only one xterm window, disconnect the network cable and try cd
command, it'll hang xtrem or even X  server. On NT4.0 with network mapped disks:
disconnect the cable and try double click on  "My Computer" icon  twice or more,
it'll hang desktop:)
I don't understand why this one is TS1, there is no any crashes, and every thing
works fine if dir server is up and
running. Setting TFV 4.52

------- Additional Comments From samit  11/18/98 10:04 -------

Serge,
Removing the cable is just to reproduce the problem.It practically means if the
machine goes down due to some reason then the complete communicator will
hang.Imagine for  example customer who has deployed nation wide and their
directory server is always network accessed.
What the customer is asking is a workaround or something which will avoid the
other thread windows(communicator) hanging.
I tried the unix /x-window test .The window where we type the command cd will
hang but you can always open another window through the desktop.

------- Additional Comments From marek  12/28/98 11:50 -------

This is an architectural change that I believe would be too risky for 4.51, but
we should discuss it during the bug meeting. This is something that needs to be
designed well for 5.0 (i.e., we need to reassign ultimately to the 5.0 people)

Comment 1

[leger]

Setting all current Open Critical and Major to M3

Comment 2

[lchiang]

qa contact to esther.

Comment 3

[chris hofmann]

this doesn't look like a M3 kind of bug.  phil can move it back if need be

Comment 4

[Phil Peterson]

LDAP appears in M7

Comment 5

[Phil Peterson]

I won't get to this bug for M7. Pushing to M8.

Comment 6

[Phil Peterson]

*sigh* LDAP pushed out past B1

Comment 7

[sol]

Since LDAP won't be implemented by PR1, this bug does not need to be fixed until
after PR1

Comment 8

[selmer (gone)]

Phil found a way to weasel out of owning this bug.  Reassigning.

Comment 9

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 10

[selmer (gone)]

[LDAP] in summary

Comment 11

[selmer (gone)]

LDAP bugs to M30, nobody, helpwanted

Comment 12

[Ben Bucksch (:BenB)]

This bug is about the old codebase, which never made it into the open, I think.
Marking INVALID.

Comment 13

[Ben Bucksch (:BenB)]

If Netscaep brings over its LDAP code, this might still be intersting. adding to
ldap meta bug.

Comment 14

[pmock]

Verified as invalid.