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

Douglas C. Schmidt schmidt at dre.vanderbilt.edu
Wed Jul 15 08:19:20 CDT 2015


Hi Sukumar,

   Thanks for using the PRF.

>     ACE VERSION: 5.3.0.0

You are using an ANCIENT version of ACE.  Please upgrade to
ACE+TAO+CIAO+DAnCE x.3.1 (i.e., ACE 6.3.14), which you can download from

http://download.dre.vanderbilt.edu

The DOC group at Vanderbilt University only provides "best effort"
support for non-sponsors for the latest release, as described in

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html

Thus, if you need more "predictable" help for earlier versions of ACE, I
recommend that you check out

http://www.dre.vanderbilt.edu/support.html

for a list of companies that will provide you with ACE commercial
support.

Thanks,

        Doug


>  
> 
>     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\                                                            f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\os.i @ 1390 + f
> ace\os.i @ 1390 + f]
> 
> aced!ACE_Mutex::acquire+10 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\                                                            f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch.i @ 164 + 9
> ace\synch.i @ 164 + 9]
> 
> aced!ACE_Process_Mutex::acquire+12 [f:\views\isitepacs\trunk\thirdparty\                                                                 f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\process_mutex.inl @ 25
> ace_wrappers\ace\process_mutex.inl @ 25]
> 
> aced!ACE_Guard<ACE_Process_Mutex>::acquire+11 [f:\views\isitepacs\trunk\                                                                 f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 9 + a
> thirdparty\ace_wrappers\ace\synch_t.i @ 9 + a]
> 
> aced!ACE_Guard<ACE_Process_Mutex>::ACE_Guard<ACE_Process_Mutex>+21 [f:\views\                                                            f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 36
> isitepacs\trunk\thirdparty\ace_wrappers\ace\synch_t.i @ 36]
> 
> aced!ACE_WFMO_Reactor::register_handler+37 [f:\views\isitepacs\trunk\thirdparty                                                          f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\wfmo_reactor.i @ 493 + f
> \ace_wrappers\ace\wfmo_reactor.i @ 493 + f]
> 
> aced!ACE_Reactor::register_handler+52 [f:\views\isitepacs\trunk\thirdparty\                                                              f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\reactor.i @ 247 + 28
> 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\                                                          f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 1989 + 1c
> log_msg.cpp @ 1989 + 1c]
> 
> aced!ACE_Log_Msg::log+1c98 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\                                                            f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 1888 + 16
> ace\log_msg.cpp @ 1888 + 16]
> 
> aced!ACE_Log_Msg::log+20 [f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\                                                          f:\views\isitepacs\trunk\thirdparty\ace_wrappers\ace\log_msg.cpp @ 876 + 14
> 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.
> _______________________________________________
> ace-users mailing list
> ace-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-users


More information about the ace-users mailing list