Windows Azure Cache Preview

Question

I'm having some trouble using Windows Azure Cache Preview.

I've add the Nuget Package here: http://nuget.org/packages/Microsoft.WindowsAzure.Caching and have configured my role for storing the ASP.NET sessions state as per the info on windowsazure.com

Problem is, I get No connection could be made because the target machine actively refused it 127.255.0.0:20004 when debugging. The dev IP used by Azure is 12.7.0.0.1:81

I'm not sure why, even the sample Windows Azure Caching (Preview) Session State and Output Caching Sample does the exact same thing.

Update: error from log:

w3wp.exe Error: 0 : ERROR: <SimpleSendReceiveModule> b4551065-941b-4bdb-9487-57d9207af308:Request - 1, result - Status=ChannelOpenFailed[System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 127.255.0.0:20004
   at Microsoft.ApplicationServer.Caching.AsyncResultNoResult.EndInvoke()
   at Microsoft.ApplicationServer.Caching.TcpClientChannel.ConnectionCallback(IAsyncResult result)] for end point [net.tcp://127.255.0.0:20004]

Also, more testing shows it is just not for session state storage, but all cache related tasks.

Answer 1

found the answer , in the webrole or workerrole properties, set the number of instances to minimum 2, this is the issue for me. got it resolved after 8 hours of debugging

Answer 2

I haven't seen this error personally so I'm taking a couple stabs in the dark...

Did you enable the caching preview in the role properties tab? That step sets up the "server" side of the caching solution.

You also need to make very sure that the names in the various configurations are consistent or the caching client won't be able to find the service. You should find one of these in the web.config in the dataCacheClient section. SPecifically the identifier attribute.

Answer 3

For others that have the same problem, there are two other possible solutions in case the resolution proposed by Sundara Prabu does not work:

1. simply reboot your computer, as suggested in this thread on MSDN forums;
2. in the Regional Settings of Windows change the Long Time format to HH:mm:ss. As I discovered myself by reading this SO answer, the cache emulator calls logman.exe for logging purposes and in particular, it uses the cnf parameter, that requires a duration in the format HH:mm:ss. The cache emulator instead formats this duration using the Long Time format found in the Regional Settings -- in my case, using Italian settings under Windows 8 the format used was HH.mm.ss, thus causing the problem described in the question.