Re: (ITS#4322) back-relay should be more user-friendly

[richton@nbcs.rutgers.edu]

> single virtual one.  I haven't tested it this way for a while, so if it
> doesn't work it's a bug.  I'll check the original issue and, in case,

If this is considered a bug, that's great. If you want to play along with
the same thing I'm looking at, ./run -b hdb test012, then modify

--- slapd.1.conf        2006-01-10 13:30:58.969405000 -0500
+++ slapd1confits4322      2006-01-10 13:30:31.765158000 -0500
@@ -82,4 +82,9 @@
 #ldbm#dbnosync
 #ldbm#dbnolocking

+database       relay
+suffix         "o=Beispiel,c=DE"
+relay          "ou=Information Technology Division,ou=People,dc=example,dc=com" massage
+relay          "ou=Groups,dc=example,dc=com" massage
+
 database       monitor


restart the test slapd
../servers/slapd/slapd -f testrun/slapd.1.conf -h "ldap://:9011/";

search the relay
../clients/tools/ldapsearch -x -H "ldap://:9011/"; -LLL -b "o=Beispiel,c=DE" dn

The ldapsearch will never return. slapd trace:

current thread: t@1
  [1] __lwp_wait(0x2, 0xffbff8cc, 0xff3162d4, 0xfec324fc, 0x2, 0xffbff894), at 0xfed1fc38
  [2] lwp_wait(0x2, 0xffbff8cc, 0x45fc0, 0xff303fd4, 0x5, 0xffbff8c4), at 0xfec3d6b0
  [3] _thrp_join(0x2, 0x0, 0x0, 0x1, 0x81010100, 0xff00), at 0xfec390e8
=>[4] ldap_pvt_thread_join(thread = 2U, thread_return = (nil)), line 193 in "thr_posix.c"
  [5] slapd_daemon(), line 2219 in "daemon.c"
  [6] main(argc = 5, argv = 0xffbffadc), line 805 in "main.c"
current thread: t@2
  [1] _poll(0xfe3fd4d8, 0x4, 0xffffffffffffffff, 0xfffffffffffffff8, 0x0, 0xfe3fd6e1), at 0xfed1df0c
  [2] select_large_fdset(0x13, 0x20, 0xfe3fd6e0, 0x0, 0xfe3fd6e0, 0xfe3fd6e0), at 0xfecd2be0
=>[3] slapd_daemon_task(ptr = (nil)), line 1848 in "daemon.c"
current thread: t@3
=>[1] slap_send_search_entry(op = 0x36b5a0, rs = 0xfdbffd50), line 723 in "result.c"
  [2] hdb_search(op = 0x36b5a0, rs = 0xfdbffd50), line 878 in "search.c"
  [3] glue_op_search(op = 0x36b5a0, rs = 0xfdbffd50), line 331 in "backglue.c"
  [4] overlay_op_walk(op = 0x36b5a0, rs = 0xfdbffd50, which = op_search, oi = 0x2de098, on = 0x2de190), line 491 in "backover.c"
  [5] over_op_func(op = 0x36b5a0, rs = 0xfdbffd50, which = op_search), line 551 in "backover.c"
  [6] over_op_search(op = 0x36b5a0, rs = 0xfdbffd50), line 573 in "backover.c"
  [7] relay_back_op_search(op = 0x36b5a0, rs = 0xfdbffd50), line 185 in "op.c"
  [8] overlay_op_walk(op = 0x36b5a0, rs = 0xfdbffd50, which = op_search, oi = 0x2f5f18, on = (nil)), line 499 in "backover.c"
  [9] over_op_func(op = 0x36b5a0, rs = 0xfdbffd50, which = op_search), line 551 in "backover.c"
  [10] over_op_search(op = 0x36b5a0, rs = 0xfdbffd50), line 573 in "backover.c"
  [11] fe_op_search(op = 0x36b5a0, rs = 0xfdbffd50), line 355 in "search.c"
  [12] do_search(op = 0x36b5a0, rs = 0xfdbffd50), line 217 in "search.c"
  [13] connection_operation(ctx = 0xfdbffe14, arg_v = 0x36b5a0), line 1307 in "connection.c"
  [14] ldap_int_thread_pool_wrapper(xpool = 0x2bdbf0), line 481 in "tpool.c"



Hmmm, now that I think about this, some sort of (non-global?) rwm and/or
glue badness?