Issues that this hotfix rollup resolves
Issue 1Assume that you create a
System.Workflow.Activities.StateMachineWorkflowActivity class together with an
Activities property that specifies an
ActivitiesCollection list. The list contains many activities (for example, 300 or more activities) that include State and non-State activities.
In this situation, transitions to State activities that are near the end of the
ActivitiesCollection list take much more time to finish than transitions to State activities that are near the beginning of the list.
This hotfix removes unnecessary
ActivitiesCollection list traversals when it searches for the target State activity by name during a state transition. Therefore, less time is required to transition to State activities that are near the end of the
ActivitiesCollection list.
Issue 2Assume that you use WCF as a mid-tier client for a website or web service to communicate with a load-balanced back-end service over HTTP. Additionally, one of the back-end hosts is in a failed state that returns HTTP responses together with a "500" status code.
In this situation, the connection to the failed back-end host persists in the WCF
ChannelFactory connection pool because it returns valid HTTP responses and causes a high rate of failed requests. There is no mechanism available to remove a connection to a failed host that could lead to front-end requests failing.
To enable this hotfix, add the following line to
appSettings in your configuration file:
<appSettings>
<add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true"/>
</appSettings>
After this hotfix is enabled, each instance of
ChannelFactory that is created and that uses the HTTP transport will have a separate pool of connections. This lets developers partition their connections into separate pools through instantiating multiple
ChannelFactory objects. By doing this, a connection to a failed host can be dropped by closing the
ChannelFactory instance that is associated with the connection to the failed host. When a
ChannelFactory instance is closed, the connections in the pool do not have to be immediately closed because they are controlled by the pooling behavior of the
ServicePointManager class. It is important to set a low default idle time-out if many
ChannelFactory objects are being created and closed to prevent a situation in which many idle connections are in a pending closure state.
Issue 3Assume that you have a WPF application that opens a window in the main window. When you resize the second window, the application crashes and throws a null pointer exception.