[jadmin] JUD Problems (1.4.2 server) Running in Different Processes
Kevin.C.Hollenshead at mail.sprint.com
Sun Feb 10 20:30:38 CST 2002
I have the 1.4.2 server running with conferencing and JUD in process without error. When I try to run in separate processes, I start having weird issues with the JUD (conferencing works fine).
The first issue is that when I first try to initiate a find after the server comes up, it takes anywhere from 10-30 seconds for the query instructions to come back. While watching the debug output, I saw it hang at "xdb_get() waiting for
jud2.dev.sprint.com jabber:jud:users". I assume that the first time through, it is retrieving the user information from global.xdb in order to populate the JUD information in memory? I guess my question is why isn't this done on startup? Seems odd to
make the first user who wants to search have to wait.
The next issue is that I can see in the JUD process' debug log that the contents of global.xdb are returned. However, when I try to execute a search against a name that I know is in the JUD (and works while the JUD is running in process), then the JUD
returns no matches. If I explicitly register with the JUD from the JabberIM client and then immediately search for myself, I can be located. If I bounce the server and try again, I can't be found until I explicitly re-register. The only catch here is
that the JUD was populated originally while running in-process but that really shouldn't matter.
The other issue (I think) relates to behavior of the <vcard2jud/> tag. When I am running in-process, I have it configured so that new user information goes to the JUD automatically. I left this setup when going to the multiple process configuration but
when I create new users now, their individual XML file is created under the spool/server_name directory but the client (JabberIM in this case) just hangs indefinitely with a "registering/please wait" message. If I cancel this, I can then login but the new
user information is not in the JUD instance until I explicitly re-register.
More information about the JAdmin