GW API hangs intermittently when shutting down

Question

I would welcome any insight into the following issue.
I have an application that uses the GroupWise Objects API to search users
mailboxes for new messages that fit certain criteria and generate XML that
describes them. This application is run as part of a batch process. On a
customer site, the application occasionally hangs, blocking the rest of the
batch process, leading to no end of grief!
The customer is using GroupWise 7.0.3 build 1068 - I have the same build on
my test system but have been unable to replicate the issue.
I have got the customer to run debug diagnostics to generate hang dumps on
the stalled process at 5 minute intervals. When we examined the dumps, we
found the application had hung at shutdown, sleeping waiting for a function
in gwenv1.dll to complete. Here is the relevant part of the output and
stack trace:
Type Description Recommendation
Warning The following threads in
GroupWiseConnector.exe__PID__3056__Date__09_23_200 9__Time_01_24_05PM__117__Manual
Dump.dmp are calling the Sleep API. The call to this API originated from
gwenv1!WpioTimeDelay+12.
( 0 )
25.00% of threads blocked
The duration of the Sleep call is 500 miliseconds. Short calls to the
Sleep API often occur inside of a tight loop, which will delay the
application and cause high CPU until the loop is exited.
Please follow up with vendor Novell, Inc. for problem resolution
concerning the following file: C:\WINDOWS\system32\gwenv1.DLL.
This thread is calling the Sleep API. The call to this API originated from
gwenv1!WpioTimeDelay+12.
Function Source
ntdll!KiFastSystemCallRet
ntdll!NtDelayExecution+c
kernel32!SleepEx+68
kernel32!Sleep+f
gwenv1!WpioTimeDelay+12
gwenv1!WpcomTCPClientSSL+27a6
gwenv1!SYM_CheckVersion+137
gwenv1!WpcomExit+33
gwenv1!WpeGlobalExit+5d
GWXPLT1!XPDmPrefCache::AreDefaultListsSame+178a9b
gwcma1!DllUnregisterServer+30b
gwcma1!DllUnregisterServer+380
gwcma1!DllUnregisterServer+32b62
gwcma1!DllUnregisterServer+32990
gwcma1+126e
gwcma1+4e3c
oleaut32!CStdDisp::Release+11
oleaut32!VariantClear+b1
Does anyone have any insight into why it is wating? (TCP SSL perhaps?)
What type of object is blocking?
What conditions might cause this to occur?
Is there any way to stop it?
Is this a GroupWise bug?
Dave M

Answer 1

I have implemented a brute force and ignorance work-around to this problem.
When the application is told to shutdown, I keep track of the time, and wait
5 minutes for the process to stop. If it doesn't shut down cleanly in that
time, I unceremoniously kill the process. Hardly elegant, but...
I would still like to understand what is causing the GW api to hang as I may
have an underlying issue, but time to move on.
Thanks
Dave M
"Preston Stephenson" <[email protected]> wrote in message
news:[email protected]...
> I'll pass the details onto another developer to see if he has
> seen anything like this.
>
>>>> On Thursday, September 24, 2009 at 11:35 AM, Dave M<[email protected]>
> wrote:
>> I would welcome any insight into the following issue.
>>
>> I have an application that uses the GroupWise Objects API to search users
>
>> mailboxes for new messages that fit certain criteria and generate XML
>> that
>
>> describes them. This application is run as part of a batch process. On a
>
>> customer site, the application occasionally hangs, blocking the rest of
> the
>> batch process, leading to no end of grief!
>>
>> The customer is using GroupWise 7.0.3 build 1068 - I have the same build
> on
>> my test system but have been unable to replicate the issue.
>>
>> I have got the customer to run debug diagnostics to generate hang dumps
>> on
>
>> the stalled process at 5 minute intervals. When we examined the dumps,
>> we
>
>> found the application had hung at shutdown, sleeping waiting for a
> function
>> in gwenv1.dll to complete. Here is the relevant part of the output and
>> stack trace:
>>
>> Type Description Recommendation
>> Warning The following threads in
>>
> GroupWiseConnector.exe__PID__3056__Date__09_23_200 9__Time_01_24_05PM__117__M
>
>> anual
>> Dump.dmp are calling the Sleep API. The call to this API originated from
>> gwenv1!WpioTimeDelay+12.
>>
>> ( 0 )
>>
>> 25.00% of threads blocked
>>
>> The duration of the Sleep call is 500 miliseconds. Short calls to
>> the
>
>> Sleep API often occur inside of a tight loop, which will delay the
>> application and cause high CPU until the loop is exited.
>>
>> Please follow up with vendor Novell, Inc. for problem resolution
>> concerning the following file: C:\WINDOWS\system32\gwenv1.DLL.
>>
>>
>> This thread is calling the Sleep API. The call to this API originated
>> from
>
>> gwenv1!WpioTimeDelay+12.
>>
>> Function Source
>> ntdll!KiFastSystemCallRet
>> ntdll!NtDelayExecution+c
>> kernel32!SleepEx+68
>> kernel32!Sleep+f
>> gwenv1!WpioTimeDelay+12
>> gwenv1!WpcomTCPClientSSL+27a6
>> gwenv1!SYM_CheckVersion+137
>> gwenv1!WpcomExit+33
>> gwenv1!WpeGlobalExit+5d
>> GWXPLT1!XPDmPrefCache::AreDefaultListsSame+178a9b
>> gwcma1!DllUnregisterServer+30b
>> gwcma1!DllUnregisterServer+380
>> gwcma1!DllUnregisterServer+32b62
>> gwcma1!DllUnregisterServer+32990
>> gwcma1+126e
>> gwcma1+4e3c
>> oleaut32!CStdDisp::Release+11
>> oleaut32!VariantClear+b1
>>
>>
>>
>>
>> Does anyone have any insight into why it is wating? (TCP SSL perhaps?)
>>
>> What type of object is blocking?
>>
>> What conditions might cause this to occur?
>>
>> Is there any way to stop it?
>>
>> Is this a GroupWise bug?
>>
>>
>>
>>
>>
>> Dave M