GW API hangs intermittently when shutting down

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_2009__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


Tags:

  • 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_2009__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

  • 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_2009__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




  • "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.
    >



    I am still seeing this error occasionally. Does anyone have any insights to
    offer?

    Thanks


    Dave M


  • Dave M wrote:
    > "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.
    >>

    >
    >
    > I am still seeing this error occasionally. Does anyone have any insights to
    > offer?
    >
    > Thanks
    >
    >
    > Dave M
    >
    >

    Try removing the outlook connector and cleaning up mapi. I strongly
    suspect that from the dump you had. And if so, you are SOL, since the
    outlook connector appears to be Not Alive anymore supportwise.
  • Sorry, we couldn't find anything that would cause
    the hang. Without steps to duplicate, there is not
    anything we can do.

    >>> On Thursday, November 12, 2009 at 5:30 PM, Dave M<davem@yaletech.com>

    wrote:

    > "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.
    >>

    >
    >
    > I am still seeing this error occasionally. Does anyone have any insights

    to
    >
    > offer?
    >
    > Thanks
    >
    >
    > Dave M