[ace-users] DON’T_CALL instead NULL_MASK solved the issue

[Gudugunta, Sukumar]

    ACE VERSION: 5.3.0.0

    HOST MACHINE and OPERATING SYSTEM:
        Windows server 2008 r2
    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:

    COMPILER NAME AND VERSION (AND PATCHLEVEL):
        VS 2008 compiler

    AREA/CLASS/EXAMPLE AFFECTED:
    [What example failed?  What module failed to compile?]

    DOES THE PROBLEM AFFECT:

        OTHER (please specify)?
        Our application is hanging


    SYNOPSIS:
    DON’T_CALL instead NULL_MASK  solved the issue

    DESCRIPTION:
      We are using ACE_Reactor pattern to register and take the reaction on certain handles.
We are using remove handler with NULL_MASK to remove the handle forcefully at destructor  from ace internal handler as follows
HttpCommand::~HttpCommand()
{

        thePReactor->remove_handler(this->m_shutDownEvent->handle(),ACE_Event_Handler::NULL_MASK);
      }
int HttpCommand::handle_close (ACE_HANDLE handle, ACE_Reactor_Mask close_mask)
{
      UNREFERENCED_PARAMETER(close_mask);
      UNREFERENCED_PARAMETER(handle);

    ACE_DEBUG((LM_DEBUG,"HttpCommand::handle_close \n"));
      m_safeToDestructEvent.signal();
    return 0;
}

The call back handle_close() should be invoked when we remove handler with NULL_MASK. In one of the use case this doesn’t happen and our application is hanging  as shown in below  call stack
and we don’t see that call back gets invoked at these times(When app hangs)

Changing the reactor mask type to DONT_CALL has fixed this issue. I don’t see hanging any more .  Can you please let me know what happens in background when the reactor type is NULL_MASK and the reason for app hang?
Does this wait for any process mutex to invoke handle_close callback.?

When we use DON’T_CALL instead NULL_MASK it solved the issue but we need to know what’s the issue in depth. Please let us know if you have any information on same




KERNELBASE!WaitForSingleObjectEx+98

kernel32!WaitForSingleObjectExImplementation+75

kernel32!WaitForSingleObject+12

aced!ACE_OS::mutex_lock+2b [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\os.i @ 1390 + f]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\os.i @ 1390 + f

aced!ACE_Mutex::acquire+10 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch.i @ 164 + 9]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch.i @ 164 + 9

aced!ACE_Process_Mutex::acquire+12 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\process_mutex.inl @ 25]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\process_mutex.inl @ 25

aced!ACE_Guard<ACE_Process_Mutex>::acquire+11 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 9 + a]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 9 + a

aced!ACE_Guard<ACE_Process_Mutex>::ACE_Guard<ACE_Process_Mutex>+21 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 36]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 36

aced!ACE_WFMO_Reactor::register_handler+37 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\wfmo_reactor.i @ 493 + f]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\wfmo_reactor.i @ 493 + f

aced!ACE_Reactor::register_handler+52 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\reactor.i @ 247 + 28]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\reactor.i @ 247 + 28

logd!LoggerFileConfiguration::RegisterStatisticsHandler+5bc3

logd!LoggerFileConfiguration::RegisterStatisticsHandler+9778

logd!LoggerFileConfiguration::RegisterStatisticsHandler+233fc

aced!ACE_Log_Msg::log+83 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 1989 + 1c]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 1989 + 1c

aced!ACE_Log_Msg::log+1c98 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 1888 + 16]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 1888 + 16

aced!ACE_Log_Msg::log+20 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 876 + 14]

f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 876 + 14



    REPEAT BY:
[What you did to get the error; include test program or session
transcript if at all possible.  ]

    SAMPLE FIX/WORKAROUND:
[If available ]
      When we use DON’T_CALL instead NULL_MASK it solved the issue but we need to know what’s the issue in depth. Please let us know if you have any information on same





From: Gudugunta, Sukumar
Sent: Tuesday, July 14, 2015 4:33 AM
To: 'ace-users at list.isis.vanderbilt.edu'
Subject: Need help to resolve the hang with ACE Reactor usage

Hi All

We are using ACE_Reactor pattern to register and take the reaction on certain handles.
We are using remove handler with NULL_MASK to remove the handle forcefully from ace internal handler as follows

thePReactor->remove_handler(this->m_shutDownEvent->handle(),ACE_Event_Handler::NULL_MASK);
int HttpCommand::handle_close (ACE_HANDLE handle, ACE_Reactor_Mask close_mask)
{
      UNREFERENCED_PARAMETER(close_mask);
      UNREFERENCED_PARAMETER(handle);

    ACE_DEBUG((LM_DEBUG,"HttpCommand::handle_close \n"));
      m_safeToDestructEvent.signal();
    return 0;
}

The call back handle_close() should be invoked when we remove handler with NULL_MASK. In one of the use case this doesn’t happen and our application is hanging  as in attached call stack
and we don’t see that call back gets invoked at these times(When app hangs)

Changing the reactor mask type to DONT_CALL has fixed this issue. I don’t see hanging any more .  Can you please let me know what happens in background when the reactor type is NULL_MASK and the reason for app hang?
Does this wait for any process mutex to invoke handle_close callback.?

When we use DON’T_CALL instead NULL_MASK it solved the issue but we need to know what’s the issue in depth. Please let us know if you have any information on same

Thanks in advance

Regards
Sukumar


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/ace-users/attachments/20150715/f83f8210/attachment-0001.html>