PRB: Chat Server Stops Responding When Extension Filter Is Installed (216860)


The information in this article applies to:

  • Microsoft Exchange Server 5.5
This article was previously published under Q216860

SYMPTOMS

After you add an Extension Filter to Microsoft Chat Server version 5.5 and later, the server may stop responding when commands are issued to the Extension Filter.

CAUSE

You may have created the Extension Filter as a Single Threaded Apartment (STA) COM object. The Extension Filter registers various callback routines with the Chat Server. If a callback routine invokes methods on the COM objects that the routine is given as parameters, a second callback may be generated. If the second callback routine attempts to reference any of the COM objects that it is passed (by getting properties, invoking methods, and so on), it can cause the server to lock.

Because all attempts to access STA objects are serialized by COM, the same thread is used to handle all callback routines. The first callback routine waits for the return of the method that triggered the second callback routine. The second callback cannot return until it finishes manipulating the COM object, which is waiting for the first callback routine to release the synchronization lock.

Both callback routines are blocked on the same synchronization object, which results in a deadlock condition. Because the same thread is used for all access to the Extension Filter object, any subsequent requests also block, which causes the server to appear to stop responding (hang).

RESOLUTION

There are two ways to avoid this problem:
  • Do not create the Extension Filter as a STA COM object.

    -or-

  • Do not generate a second callback.

    A callback is not typically generated when you get and set properties to the passed COM objects. If you invoke methods on the COM objects, however, a callback can be generated.

    For example, if the Close method is invoked on the IChatUser object during a callback, the OnCloseUser callback routine (if registered) is generated. This may lead to a deadlock if, during the OnCloseUser callback, one of the passed COM objects is referenced.
Microsoft strongly recommends that you do not create Chat Server Extension Filters as STA COM objects. You run the risk of deadlock as described above, and you may incur a severe performance penalty because all requests are serialized through a single COM object, which negates any benefit of concurrency by having a multithreaded server.

STATUS

This behavior is by design.

MORE INFORMATION

Steps to Reproduce Behavior

The following code sample, if it is a part of an Extension Filter that is created as a STA COM object, can lead to a deadlock condition: 
STDMETHODIMP CMyExtension::OnConfigureExtension(IChatUser *pUser, 
                                                BSTR bstrCommand) 
{
   pUser->Close(NULL, L"Bye, bye");
}

STDMETHODIMP CMyExtension::OnCloseUser(IChatUser* pUser)
{
   BSTR  szName = NULL;

   pUser->get_Nick(&szName);

   // Do something with the nickname....
}
In the code above, during the OnConfigureExtension callback, a second callback, OnCloseUser, is generated by explicitly closing the session for the IChatUser object. During the second callback, the extension attempts to retrieve the nickname of the IChatUser object.

The first callback routine has already obtained the synchronization object to the IChatUser object and is waiting for the second callback to return. The second callback routine, however, is waiting for the synchronization object to be released, so a deadlock condition is produced.

REFERENCES

  • Microsoft Exchange Chat Server Extensibility Software Development Kit (SDK).
  • Microsoft Exchange Chat Server Online Documentation.
Modification Type:MinorLast Reviewed:3/4/2004
Keywords:kbMsg kbprb KB216860
©2004 Microsoft Corporation. All rights reserved.