Slow access to address book functions due to shared address books

Question

We have recently migrated from GW v8.0.3 on NetWare 6.5 to GW 2012.2 on
SLES 11.3. Single PO system, with only 65 users.
We have been experiencing 10 second hangs/delays the first time any GW
address book functions are accessed. Some users are on the GW 2012.0.2
client, others are still on the GW 8.0.3 client, all experiencing the 10
second delay issue. We did not experience this before the migration to
GW 2012.
Testing indicates that the issue is due to shared address books.
The 10 second delay always occurs the *first* time we access an address
book function after starting the GroupWise client. For example, once
the GroupWise client is newly started, if I open the address book, it
takes 10 seconds to open. If I then create a new mail or appointment,
while adding recipients to an e-mail, selecting a new addressbook from
the address selector drop-down menu takes almost 10 seconds for the
drop-down menu to respond to first being clicked on.
Once I've accessed an address book function, though, accessing that
function is much quicker on successive uses. But it does take doing
each of those things once (suffering through the 10 hang) before they
speed up. If a user makes the mistake of closing GroupWise, I'm back to
square one with the first use of each of those address book functions
being slow again.
*BUT*, if I delete all address books that have been shared with me,
there is no 10 second delay, even after restarting the GroupWise client.
No slow access to any address book feature on first use.
Unfortunately, we use shared address books very heavily, so deleting
them for all of my users is not a solution.
Besides running PO/user maintenance, I've looked at possible
communications or DNS issues with no luck.
Any ideas what's going on or how to fix it?
Thanks,
-Greg
former e-mail for posting:
[email protected]

Answer 1

Originally Posted by gtn
We have been experiencing 10 second hangs/delays the first time any GW
address book functions are accessed. Some users are on the GW 2012.0.2
client, others are still on the GW 8.0.3 client, all experiencing the 10
second delay issue. We did not experience this before the migration to
GW 2012.
Testing indicates that the issue is due to shared address books.
We have been dealing with this same if not similar sounding issue, opened a SR, and engineering is looking into it. For us it also impacts message compose ( address completeion ) as well as opening mail. We have yet to identify a workaround. What we see is "roughly" a 3 second delay per shared address book, occuring intermittently after a period of the client being idle. We also see on the POA that periodically the client will login to these shared accounts, but instead of those logins happening quickly ( sub 1 second for all of them combined ).
This is not a constant problem for all users with the 2012 client, and seems to run in fits for a given user. We see it, perhaps 1 -3 times a day for a given user.
If you enable Verbose logging on the POA ( via the HTTP console ) and look for the IP address of the workstation with the problems, you should see a pattern of logins as follows:
Code:
1204poa.028:18:41:32 F059 C/S Login Windows ::GW Id=Kxxxxr :: 192.168.1.110
1204poa.028:18:41:35 F059 C/S Login Windows ::GW Id=Sxxxxk :: 192.168.1.110
1204poa.028:18:41:38 F059 C/S Login Windows ::GW Id=Exxxxr :: 192.168.1.110
1204poa.028:18:41:41 F061 C/S Login Windows ::GW Id=Sxxxxk :: 192.168.1.110
1204poa.028:18:41:44 F051 C/S Login Windows ::GW Id=Kxxxxr :: 192.168.1.110
1204poa.028:18:41:47 F061 C/S Login Windows ::GW Id=Dxxxxr :: 192.168.1.110
1204poa.028:18:41:50 F061 C/S Login Windows ::GW Id=Kxxxxr :: 192.168.1.110
( Using something like grep -i "GW Id" 1204poa.??? | grep -i "Login Windows" | grep x.x.x.x <== IP of the workstation when in /var/log/no*/gr*/POA_Log_Folder )
Note the 3 second delay between each of the shared account logins. This typifies the problem we are seeing. Under normal circumstances you would see these all happening with the same time stamp. Perhaps you can confirm this is the same looking issue.
I'll keep you apprised of our progress.
-- Bob