I'm trying to connect to an instance of Azure Redis Cache from my local dev machine. I'm using StackExchange.Redis like so:
var lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
return ConnectionMultiplexer.Connect(
$"{redisServerUrl},abortConnect=false,ssl=true,password={redisServerKey},connectTimeout=10000,syncTimeout=10000");
});
When lazyConnection is called I get an InvalidOperationException with the message:
"role discovery data is unavailable"
and this one-liner stack trace:
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.get_CurrentRoleInstance()
Why is the exception thrown and how can I avoid it?
StackExchange.Redis tries to discover the RoleInstance name under the covers if you don't specify a ConfigurationOptions.ClientName value. It is odd that you are getting this error bubbled out to your code because the code in question handles all exceptions and defaults back to returning the Computer name.
I suspect that if you add ",name=XXX" to your connection string, the error will go away because you will avoid that code path.
Related
I have an error-handler passed to a service bus client "receive" function and it is firing after setup as follows:
const ns = Namespace.createFromConnectionString(connectionString);
const client = ns.createQueueClient(queueName);
const receiver = client.getReceiver();
receiver.receive(onMessageHandler, onErrorHandler, { autoComplete: false });
with the error:
UnauthorizedError: Unauthorized access. 'Listen' claim(s) are required to perform this operation.
The connection string being used uses the default root shared access key which has all claims (listen, send AND manage). Why am I getting this error / how to fix it? Thx.
I don't know if this helps anyone but in my case, I had the old azure-sb package still kicking around, and it may have been polluting my node_modules in some in explicable way. Getting rid of it seems to have gotten rid of the claims complaints.
We have been trying to use a SqlConnection within a TransactionScope. When we build the site and try this database call we run into an error:
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
The error involved occurs on the line cnn.Open().
using (var scope = new TransactionScope())
using (var cnn = new SqlConnection(connectionString))
{
cnn.Open();
int result = cnn.QuerySingle<int>("SELECT 1");
Console.WriteLine(result);
}
We created a console application to figure out what was wrong and discovered that by changing our connection string keyword 'Pooling' from 'false' to 'true' allows this to run in the console application and successfully return our result.
We made the same change to our site connection string, the same error as before returns.
Is there any reason this code is not working?
I was under the assumption that the web.config was law, as viewing the file through the Kudu service showed my expected connection string, but apparently this isn't the case in Azure.
I discovered that Azure Publish Profile is overriding our web.config connection string, this override still contained 'Pooling=false'.
Removing this now allows our code to run as intended.
This blog post explains more:
"When this code runs on a developer’s local machine, the value returned will be the one from the web.config file. However when this code runs in Windows Azure Web Sites, the value returned will instead be overridden with the value entered in the portal"
I am having problems getting the Microsoft.Azure.Documents library to initialize the client in an azure worker role. I'm using Nuget Package 0.9.1-preview.
I have mimicked what was done in the example for azure document
When running locally through the emulator I can connect fine with the documentdb and it runs as expected. When running in the worker role, I am getting a series of NullReferenceException and then ArgumentNullException.
The bottom System.NullReferenceException that is highlighted above has this call stack
so the nullReferenceExceptions start in this call at the new DocumentClient.
var endpoint = "myendpoint";
var authKey = "myauthkey";
var enpointUri = new Uri(endpoint);
DocumentClient client = new DocumentClient(endpointUri, authKey);
Nothing changes between running it locally vs on the worker role other then the environment (obviously).
Has anyone gotten DocumentDb to work on a worker role or does anyone have an idea why it would be throwing null reference exceptions? The parameters getting passed into the DocumentClient() are filled.
UPDATE:
I tried to rewrite it being more generic which helped at least let the worker role run and let me attached a debugger. It is throwing the error on the new DocumentClient. Seems like some security passing is null. Both the required parameters on initialization are not null. Is there a security setting I need to change for my worker role to be able to connect to my documentdb? (still works locally fine)
UPDATE 2:
I can get the instance to run in release mode, but not debug mode. So it must be something to do with some security setting or storage setting that is misconfigured I guess?
It seems I'm getting System.Security.SecurityExceptions - only when using The DocumentDb - queues do not give me that error. All Call Stacks for that error seem to be with System.Diagnostics.EventLog. The very first Exception I see in the Intellitrace Summary is System.Threading.WaitHandleCannotBeOpenedException.
More Info
Intellitrace summary exception data:
top is the earliest and bottom is the latest (so System.Security.SecurityException happens first then the NullReference)
The solution for me to get rid of the security exception and null reference exception was to disable intellitrace. Once I did that, I was able to deploy and attach debugger and see everything working.
Not sure what is between the null in intellitrace and the DocumentClient, but hopefully it's just in relation to the nuget and it will be fixed in the next iteration.
unable to repro.
I created a new Worker Role. Single instance. Added authkey & endoint config to cscfg.
Created private static DocumentClient at WorkerRole class level
Init DocumentClient in OnStart
Dispose DocumentClient in OnStop
In RunAsync inside loop,
execute a query Works as expected.
Test in emulator works.
Deployed as Release to Production slot. works.
Deployed as Debug to Staging with Remote Debug. works.
Attached VS to CloudService, breakpoint hit inside loop.
Working solution : http://ryancrawcour.blob.core.windows.net/samples/AzureCloudService1.zip
I'm trying to send a serviceBusQueue message from an API function in my Azure mobile-service and even though it successfully creates the queueService and the queue exists I get a nasty exception. Any clue how I fix this?
I've attached the send code and stack trace.
function sendBusMessage(request, params, message, success)
{
console.log(params);
var queueService = azure.createServiceBusService(params.namespace,params.key);
console.log(queueService);
if (queueService)
{
queueService.sendQueueMessage('worker', message, function (error)
{
if (!error)
{
success();
}
else
{
request.respond(statusCodes.INTERNAL_SERVER_ERROR,error);
}
});
}
}
Exception stack:
An unhandled exception occurred. TypeError: Cannot set property 'body' of null
at ServiceClient._performRequest.self._buildRequestOptions.operation (D:\home\site\wwwroot\node_modules\azure\lib\services\core\serviceclient.js:210:34)
at ServiceClient._performRequest (D:\home\site\wwwroot\node_modules\azure\lib\services\core\serviceclient.js:264:7)
at ServiceBusService.ServiceClient._initDefaultFilter.filter (D:\home\site\wwwroot\node_modules\azure\lib\services\core\serviceclient.js:534:7)
at ServiceClient._performRequest (D:\home\site\wwwroot\node_modules\azure\lib\services\core\serviceclient.js:261:10)
at ServiceBusServiceClient._buildRequestOptions (D:\home\site\wwwroot\node_modules\azure\lib\services\core\servicebusserviceclient.js:107:5)
at Wrap.signRequest (D:\home\site\wwwroot\node_modules\azure\lib\services\serviceBus\wrap.js:69:5)
at WrapTokenManager.getAccessToken (D:\home\site\wwwroot\node_modules\azure\lib\services\serviceBus\wraptokenmanager.js:76:5)
at WrapService.wrapAccessToken.finalCallback (D:\home\site\wwwroot\node_modules\azure\lib\services\serviceBus\wrapservice.js:98:7)
at ServiceClient._initDefaultFilter.filter (D:\home\site\wwwroot\node_modules\azure\lib\services\core\serviceclient.js:538:11)
at WrapService.wrapAccessToken.processResponseCallback (D:\home\site\wwwroot\node_modules\azure\lib\services\serviceBus\wrapservice.js:101:5)
Namespace
The namespace for configuring Node.js is the one visible under Service Bus tab (that is pretty straightforward).
Access Key
Unfortunately it can be easily confused with access keys defined for the specific messaging capability instances (such as queues). Providing an invalid access key may result in a stacktrace like the one in question.
The access key which should be used for configuring Node.js is the one accessible from the Connection Information window. To get there, you need to navigate to the Service Bus main tab (one with the cloud icon), then click Connection Information button available from the bar at the bottom. It is the Default Key right beneath the DEFAULT ISSUER section.
Configuring Namespace and Access Key
Both namespace and access key can either be passed to azure.createServiceBusService() function directly, or (when configuring a Mobile Service) set via AZURE_SERVICEBUS_NAMESPACE and AZURE_SERVICEBUS_ACCESS_KEY keys in the app settings configuration section.
Make sure you are using the top level configuration from the Service Bus->Namespace not anything deeper in the tree. An incorrect access key will not throw a useful exception (like "Can't use a queue key to access a namespace") but instead produces the problem above.
(I'm quite new to Windows Azure development, so I hope I'm using the right terms.)
We have an Azure Worker Role that is supposed to fetch data stored in Blob Storage.
Somehow we occasionally get the following error message:
Microsoft.WindowsAzure.StorageClient.StorageServerException: The server encountered an unknown failure: The remote name could not be resolved: 'XXX.blob.core.windows.net' ---> System.Net.WebException: The remote name could not be resolved: 'XXX.blob.core.windows.net'
This seems strange, since requests only a second before and/or after works as expected.
If I understand things correctly, the CloudBlob class has internal retry functionality. It seems that this is not considered as a "retryable" error. Is this perhaps handled by the Transient Error Handling Block (Topaz), or do we have to handle this specific error in some other way?