GW API hangs intermittently when shutting down

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" <PStephenson@gw.novell.com> wrote in message
news:4ABB8B69.07F1.0037.1@gw.novell.com...
> 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<davem@yaletech.com>
> 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