Windows Server AppFabric Customer Advisory Team - All Comments

re: 4 Different ways to process an XLANGMessage within an helper component invoked by an orchestration Part 1

Paolo Salvatori — Fri, 21 Dec 2012 09:39:29 GMT

Well, I never said that the code I wrote is the only way to accomplish this operation. ;)

Ciao,

Paolo

re: 4 Different ways to process an XLANGMessage within an helper component invoked by an orchestration Part 1

Oleg Deribas — Fri, 21 Dec 2012 09:27:37 GMT

Hi Paolo,

Why don't you put generated CalculatorRequest type directly as argument for ProcessRequestReturnObject method? So it would look like this:

public CalculatorResponse ProcessRequestReturnObject(CalculatorRequest calculatorRequest)

It seems that code for deserizlizing XLANGMessage to CalculatorRequest is generated by biztalk 2010 compiler in this case.

re: We Have Moved to MSDN

Tudor — Thu, 15 Nov 2012 07:57:14 GMT

The url is broken - it point to Azure Mobile Services.

re: Best Practices for Instrumenting High Performance BizTalk Solutions

Dinesh Arora — Tue, 06 Nov 2012 09:37:43 GMT

Hi, Even after implementing the whole framework, I am not able to see any Logging in the events.

Kindly help!!!

re: AppFabric Cache - Peeking into client & server WCF communication

KALATGOP — Thu, 25 Oct 2012 13:59:59 GMT

HI,

I have a client machine where my client code to add/modify cache key sits and a server machine where the appfabric is running. The client is NOT on the same cache cluster as the server cache.Will i be able to add/delete the keys on the server cache from my client code??? My client user has all admin access on the server machine.

i am trying to do this with below code,

servers.Add(new DataCacheServerEndpoint("servermachine name", 22233));

DataCacheFactoryConfiguration configuration = new DataCacheFactoryConfiguration();

_factory = new DataCacheFactory(configuration);

_cache = _factory.GetCache("default");

but iam getting an error as

{Microsoft.ApplicationServer.Caching.DataCacheException: 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.) ---> System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host Servermachinename.

re: SQL Azure and Entity Framework Connection Fault Handling

Tom McCartan — Tue, 09 Oct 2012 20:36:20 GMT

It's been a long time a comment has been added on this post. I have a new question regarding when to wrap up a call in the retry wrapper. In the code below do you wrap the Linq statement, or the first call using the linq return object, or both? At what time will it go to the DB where the connection may fail?

var persons = from myPersons in Conn.Persons where myPersons.Gender == "Male" select myPersons;

int iCount = persons.Count();

re: Best Practices for Handling Transient Conditions in SQL Azure Client Applications

Valery M — Tue, 16 Aug 2011 03:28:22 GMT

Hi oliverbock,

We have a plenty of real-world examples of how to use the framework with Windows Azure queues and blobs in order to make storage operations more resilient to transient faults. Specifically, please review the following post and download the sample code.

windowsazurecat.com/.../implementing-storage-abstraction-layer-to-support-very-large-messages-in-windows-azure-queues

re: Best Practices for Handling Transient Conditions in SQL Azure Client Applications

oliverbock — Mon, 15 Aug 2011 06:13:52 GMT

I cannot find examples for how to use your framework for retrying Azure storage operations. Any hints?

re: Best Practices for Handling Transient Conditions in SQL Azure Client Applications

Valery M — Mon, 08 Aug 2011 22:47:31 GMT

Tamás,

Thanks for reaching out.

By default, the framework is not configured to handle the timeout errors. We believe that this type of exceptions is not something we will encourage the developers to compensate by a retry. Timeouts may have a very distinct nature and can be the result of poor schema design, lack of indexes, suboptimal query plans, blockings, timeout settings misconfiguration, and more. It is unwise to always retry when you get a timeout.

Instead, I would recommend looking into the queries being executed and try to determine the reasons behind timeouts. If you are 100% confident that your queries are generating a good execution plan, you have all the right indexes and everything is configured correctly, and you are still seeing timeouts, you have all the source code in your possession. The implementation of the SqlAzureTransientErrorDetectionStrategy class can be easily modified to catch the timeout exceptions. To re-iterate, this is not a general recommendation. We leave the timeout handling at your own discretion.

re: Best Practices for Handling Transient Conditions in SQL Azure Client Applications

Tamás Huj — Mon, 08 Aug 2011 11:11:33 GMT

I tried this RetryPolicy because I want a robust application.

I have the following code:

int MaxRetry = 5;

int DelayMS = 100;

policy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(MaxRetry, TimeSpan.FromMilliseconds(DelayMS));

Type = policy.ExecuteAction<string>(() => context.properties.First(p => p.Name == "not_exist_type_id").Value);

but it sometiomes throws exception:

"Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding."

The RetryPolicy is not working if the connection times out?

Best regards,

Tom