akshar

AppFabric Azure Caching : The remote name could not be resolved *.windows.net

2011-11-14T07:21:53Z

A lot of internal customers seem to face this issue since *.windows.net is not directly resolvable within corpnet. In this case you need to install Forefront TMG Client .

Another interesting case is when you deploy your web application which uses caching under an app-pool whose identity is a system account (like NetworkService, I think this is the default too), cache request/resolution might again fail. Looks like Forefront TMG client doesn't cater to non-domain accounts.

But there is a simple workaround : run ‘FwcTool /g /app:w3wp’
from TMG client installation folder. I believe this gives w3wp.exe access to network resources via TMG client regardless of account which runs the w3wp process.

AppFabric Azure Caching : Quota throttling errors

2011-06-03T10:39:00Z

(This article is focused and valid only for Azure AppFabric Caches and not for Windows Server AppFabric Caches.)

Azure AppFabric Caches come with quota limits. Quota limits are mentioned here.

Here are some of the reasons why you might be throttling on:

1. Bandwidth or Transactions: This means that you are actually in need of a bigger cache since your cache usage is pretty huge. (or need to re-architecture the app so that it uses less bandwidth & does fewer transactions)

2. Connections : This might point to a bug in your code, an erroneous setting in DataCacheConfiguration or may be just because you weren't aware of the connection quotas till now. Lets take the example of 128 MB cache. The allowed connection count is 5. For you to exceed this count, following are the possibilities:

a. DataCacheFactoryConfiguration.MaxConnectionToServer is set to value of more than 5 : In this case, whenever you instantiate a new DataCacheFactory and get a DataCache from it, you are essentially opening more than 5 connections to Azure AppFabric Cache service which would mean that you are exceeding the allowed count. Please note that it is okay to do multiple GetDefaultCache() on a single DataCacheFactory since only one instance of DataCache is created per instance of factory and GetDefaultCache() returns back the same instance each time.

Solution: Try setting the value to 1 and try again.

b. Several instances of DataCaches created from different DataCacheFactories: If in your code you are initializing several DataCacheFactories and do a GetDefaultCache() from each one of them, then each instance of DataCache you get from each factory is going to have it's own connections to the Azure cache service.

Solution: Create only a single instance DataCacheFactory (per cache endpoint) in your code and re-use it as much as possible. If you really need to have several instances of DataCacheFactories, please ensure to Dispose() them off, once they are not needed.

c. Several instances of application running with Windows Azure: It might also be a case that your application has several instances deployed and each one of them is using the same cache. In such a case you are exhausting the connections since each instance is creating connections to Azure cache service.

Solution: Upgrade your cache subscription.

d. Multiple applications / test applications sharing the same cache: Since the connection count is a server side property, if various applications use the same azure cache, each one of those applications are actually contributing to the connections count to that particular cache.

Solution: Use different caches for different apps unless apps are sharing the data.

Azure AppFabric Caching - ErrorCode:SubStatus : What to do?

2011-05-01T11:46:00Z

ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.)

You might encounter this error at some point during developing/deploying/testing your application which uses AppFabric Caching. Sadly, this is very generic and doesn't tell you a lot about what went wrong and who the culprit is. Fortunately, :-) we have a way to figure out the inner exception which might give us a some clue as to what happened. Before intializing the DataCacheFactory modify the DataCacheFactoryConfiguration.ChannelOpenTimeout of the dataCacheFactoryConfiguration instance that you are using to a larger value of 2 minutes. (can't use configuration to set the value, since 20 seconds in the allowed limit) . Also, this recommendation is only for debugging purposes and ideally should not be needed in production environments.

This lets the underlying layer to respond back with the actual error that occurred. Now, if you check the inner exception, you should see what caused the request to fail.

This is also valid for Connection Terminated error: Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode<ERRCA0028>:SubStatus<ES0001>:The connection was terminated possibly due to server or network problems. Result of the request is unknown.

If the inner exception when you do a Get() or a Put() (not valid for GetDefaultCache()) says "System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host" this would actually mean that your connections are idling out. Basically in azure, if a connection remains idle for more than a minute, it is dropped. Sometimes, the notification for dropped connection is not received by the channel layer and next time when a cache request comes in, it will fail since the connection is stale. We could avoid this if DataCacheFactoryConfiguration.TransportProperties.ReceiveTimeout is set to a value less than 1 minute (say 45 seconds). This will proactively refresh the connection before it gets closed by Azure. This recommendation can be used in production environment in case the cache usage is intermittent/sporadic.(with pauses of more than 1 minute or so.)

PS:

1. For this to work ensure that the dll version for Microsoft.ApplicationServer.Caching.Core.dll and Microsoft.ApplicationServer.Caching.Client.dll is at least 1.0.4009.0

2. This is specific to Azure AppFabric Cache only.

Changing the Windows Azure Web Host application pool identity

2011-05-01T11:25:00Z

Sometimes, need may arise to change the app pool identity of the azure web host you are working with locally on Development Fabric/Compute Emulator.

By default, the web host runs under a temporary application pool with NTAUTHORITY\NETWORK SERVICE account. This account may not have access to some key local/remote resources.(e.g. using the proxy server to resolve addresses or send messages). In that case, you can switch the current application pool identity using the snippet below.

You'll need to add a reference to Microsoft.Web.Administration.dll which is present in %SystemRoot%\system32\inetsrv for following to work. Note that this code should be called at WebRole.OnStart() before base.OnStart() is called.

using (ServerManager serverManager = new ServerManager())

{

string appPoolName = serverManager.Sites[RoleEnvironment.CurrentRoleInstance.Id + "_" + webApplicationProjectName].Applications.First().ApplicationPoolName;

var appPool = serverManager.ApplicationPools[appPoolName];

appPool.ProcessModel.UserName = appPoolUserName;

appPool.ProcessModel.IdentityType = ProcessModelIdentityType.SpecificUser;

appPool.ProcessModel.Password = appPoolPassword;

serverManager.CommitChanges();

}

BizTalk WCF Adapter: Require a "Disable Receive Location after failures" option

2010-11-15T11:40:00Z

When using WCF-Custom Adapter one can check the box ‘Disable Location on Failure’ under the ‘Messages tab’. While this is a useful functionality there might be cases when we wouldn’t want the receive location to get disabled for particular known faults or at least retry some times before disabling it. Say for example, when using WCF-Custom adapter with SqlBinding, a common problem might arise if the SQL server, which we poll, goes down or if there is a network disconnect for some time (> polling interval). We wouldn’t want the receive location to get disabled in such cases as such faults might be benign. What leads service host to faulted state, in such cases, is an exception thrown by a channel in the channel stack. An exception in a channel lead the corresponding channel listener communication object, and ultimately the service host, into faulted state.

In order to allow retrying before the receive location gets disabled, we can use WCF’s extensibilty to create a solution which would do the following:

1. Create a custom binding element (which will be the upper most element in the binding stack) which catches exceptions, maintains an exception counter, retries and throws only after specified number of exceptions have been thrown.

2. Create a custom endpoint behavior which modifies the binding stack of the endpoint binding by adding our custom binding element mentioned in 1.

By implementing BehaviorExtensionElement with our custom endpoint behavior we should be able to plug it into Biztalk WCF-Custom receive location”

The ExceptionCatcherBehavior can be downloaded from : http://biztalkserverteam.codeplex.com/releases/view/53456

WCF MessageID missing in void reply

2010-09-10T07:14:03Z

In WCF, if a contract operation has a void return and is not one way, there is no message ID attached to the reply. I didn't check this up with all bindings but it does happen with basicHttp and wsHttp bindings atleast. (http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/ defines this).

The problem doesn't arise if the communication is WCF-WCF. You might encounter this only with WCF- non-WCF SOAP (Websphere) communication.

A very simple solution is to have a custom message inspector which checks if the response message has an ID. If not, it inserts one.

The code sample is attached.

Promoting a WCF message header to BizTalk message context using WCF Adapter

2010-09-10T06:10:46Z

Sometimes there may arise a need where some of the custom headers that are specified in the WCF message are needed for routing purposes in BizTalk. Lets take an example, Say the client sends a message with a custom header which specifies the node in a ring to which the message has to be routed to. Let this header be 'RingRouteTo'. Now if you want to enable routing based on this header, this has to be promoted to the BizTalk message context.

Some background on how headers & properties are dealt with in WCF adapter:

1. All headers are written to the BTS message context.

2. Some of the well-known headers are always promoted. e.g. "To", "Action"

3. All the properties with 'http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties/Promote' namespace are promoted.

To promote custom headers to BTS message context, we will make use of point (3). In a custom message inspector, we will read the specified header and then add it as a property with the namespace specified above. We will also need to deploy the custom property schema which has the promoted properties in BizTalk.

Of course, you will need to use WCF-Custom adapter in order to use this behavior.

Attached is the code to achieve the same.

PS : Once you build and deploy the attached BizTalk project, the property appears as 'Microsoft.BizTalk.Adapter.Wcf.CustomPromotedProperty.PropertySchema.RingRouteTo' in BizTalk.\

When adding the header while sending the message using client, you can use any namespace for 'RingRouteTo'.

WCF Null binding

2010-09-10T05:19:00Z

I was testing some of my WCF code when I came up with this idea of using a 'Null binding'. Essentially, When you create a WCF service today, you also need a client which can send you message to get your service operations kicked off. The same is the case on the send side as well. When you want to check the client side functionalities you need to have a service to consume that message. This overhead of generating a test client/service and sending/receiving messages using them can sometimes be really time consuming.

Enter null binding. For testing purposes, this binding comes very handy. You can use this to receive automatically generate messages at specified time intervals. When sending WCF messages you can using this binding as a sink where all messages are just read and absorbed. You don't need to have an actual test client when testing your service.

This comes very useful with WCF adapter in BizTalk where we make use of * contracts.

Null binding is also useful for learning purposes. If you are new to WCF and looking for how to make a custom binding, this can give you a some ideas about how to implement one.

What more can be done:

On the receive side, add a string property which holds the schema for the desired body. At runtime, generate WCF messages using that schema.