I've got a few questions and problems regarding SignalR.
1st question:
I've downloaded signalr like this: npm install #aspnet/signalr according to Npmjs (v1.0.3).
However, upon further inspection, my signalr files do not contain reconnect-functionality as can be found on the github:343 here.
As a matter of fact, it seems like these are two different repos. Why do they differ, both seem to be developed by microsoft?
these are the two repos: https://github.com/SignalR/SignalR
and https://github.com/aspnet/SignalR
2nd question:
I've tried to implement reconnect-functionality into my application with the limited functionality avaliable to me. This is my current approach (since i lack the reconnect-functions in the 1st repo) the code below produces this output on disconnect:
signalr.min.js:1353 Error: Connection disconnected with error 'Error: Server timeout elapsed without receiving a message from the server.'.
Uncaught TypeError: this.connect is not a function
at HubConnection.eval
trying to connect...
Uncaught TypeError: this.connect is not a function
at HubConnection.eval
trying to connect...
etc... etc...
Code:
this.connection.onclose(function (error) {
if (!this.isConnected) {
this.isConnected = false;
appService.emit("disconnected", true);
var intervalFunc = setInterval(function () {
console.log("trying to connect...");
this.connect();
if (this.isConnected) {
this.appService.emit("connected", true);
this.isConnected = true;
clearInterval(intervalFunc);
console.log("connection established");
}
}.bind(this), 5000);
}
});
I've also followed these resources in trying to implement reconnect-functionality:
https://stackoverflow.com/a/23407156/2902996
https://learn.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/handling-connection-lifetime-events#how-to-continuously-reconnect
https://github.com/davidfowl/UT3/blob/dac409886c1bb7aec7c150b74d4ce9a3e246f03c/UTT/wwwroot/js/utt.js#L141-L153
https://github.com/aspnet/Docs/issues/6757
Any help would be greatly appreciated.
There is a .NET version and .NET CORE version. At the top of each of the github's you linked it shows: Incredibly simple real-time web for .NET (first github) and Incredibly simple real-time web for ASP.NET Core (second GitHub).
Your second question may come down to determining if you mixed up which SignalR product (.NET or .NET CORE) and the Clients for each. They are not cross compatible, so you cannot use the .NET JS Client with the Client for .NET Core.
I would recheck what you have implemented and go from there.
If you check the .NET Core repo under issues and search for reconnect, it does appear that reconnect is not a function any longer in .NET Core. See issue 1611.
Related
From looking at my Cost Management reports for Application Insights, I've noticed a large spike in data ingestion related to Performance Counters.
Link to larger image
However, I'm not seeing any significant correlation in the number of requests spiking for the same period.
Link to larger image
What can I do to understand the root cause of this issue?
Additional Information
After some debugging, I was able to get to the bottom of this.
The usage spiked on Sep 7 and Sep 8 and then tapered off on the 9th and 10th.
The change that I made on the 6th Sept was to upgrade Microsoft.ApplicationInsights.AspNetCore from version 2.6.1 to version 2.7.1. Version 2.7.1 has ILogger integration baked in.
So, what I believe happened is that, after deploying the upgraded version of Microsoft.ApplicationInsights.AspNetCore, I may have had the Logging verbosity turned up too high for the performance counter telemetry data and subsequently changed it a couple of days later when I noticed it.
I hope this helps someone else who may run into this issue!
There is now a cleaner way to achieve the disabling of the PerformanceCounterModule (and other modules which cause excessive/unneeded logging);
services.AddApplicationInsightsTelemetry(options =>
{
options.EnablePerformanceCounterCollectionModule = false;
options.InstrumentationKey = configuration["ApplicationInsights:InstrumentationKey"];
});
Application Insights 2.7.1 has enabled ILogger captured by default, but it only captures Warning or above log messages. So unless you application is generating a lot of Warning or above level Ilogger logs, this should not result in a big spike in usage.
This behavior can be changed to filter logs further if too much logs are reported.
https://learn.microsoft.com/en-us/azure/azure-monitor/app/ilogger#control-logging-level
From the 1st screenshot you shared, it looks like performance counter is the only type which spiked - ilogger integration cannot explain this spike, as it only reports logs.
More logical explanation is the PerformanceCounter module itself which was NOT supported in versions earlier than 2.7.1. You can remove performance counter collection with the following snipped in ConfigureServices() method in startup.cs
using Microsoft.ApplicationInsights.DependencyCollector;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector;
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetry();
// The following removes PerformanceCollectorModule to disable perf-counter collection.
var performanceCounterService = services.FirstOrDefault<ServiceDescriptor>(t => t.ImplementationType == typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
services.Remove(performanceCounterService);
}
}
Facing a very strange issue.
Following this guide https://azure.microsoft.com/en-in/documentation/articles/app-service-mobile-xamarin-forms-blob-storage/ to implement File Sync in Xamarin Forms app.
The Get method in my service (GetUser, default get method in App service controller) is being called thrice & on the 3rd iteration it gives me a 404 resource not found error. First 2 iterations work fine.
This is the client call
await userTable.PullAsync(
null,
userTable.Where(x => x.Email == userEmail), false, new System.Threading.CancellationToken(), null);
If I remove the following line,
// Initialize file sync
this.client.InitializeFileSyncContext(new TodoItemFileSyncHandler(this), store);
then the code works just fine, without any errors.
I will need some time doing a sample project, meanwhile if anyone can shed some light, it will be of help.
Thanks
This won't be an answer, because there isn't enough information to go on. When you get a 404, it's because the backend returned a 404. The ideal situation is:
Turn on Diagnostic Logging in the Azure Portal for your backend
Use Fiddler to monitor the requests
When the request causes a 404, look at what is actually happening
If you are using an ASP.NET backend (and I'm assuming you are because all the File tutorials use ASP.NET), then you can set a breakpoint on the appropriate method in the backend and follow it through. You will need to deploy a debug version of your code.
this is sorted now, eventually I had to give it what it was asking for. I had to create a storage controller for User too, although I don't need one as I don't need to save any files in storage against the users.
I am testing the app further now to see if this sorts my problem completely or I need a storage controller for every entity I use in my app.
In which case it will be really odd as I don't intend to use the storage for all my entities.
So, I had a working xamarin forms app that used azure mobile services. I upgraded the server side to use mobile app service and upgraded the nugets in my client to use the latest and greatest client codes.
I manually updated my test/ios simulator sqlite db to use the proper column names for the system properties since they dropped the double underscore prefix.
When I finally got it all built and tried to run in the ios 6/8.3 simulator it ran fine until it hit the InitializeAsync method. It doesn't throw (its in a try catch) and I let it run for a long time and it just sits there.
I then tried to change the db name so it would make it from scratch, which it did but still just hung. So I then tried to simplify it to a single table and took out my delegating handler so it was as basic as I could get it and it still just hangs.
Has anyone else had this problem? I am at a complete loss because I don't get an error. Not sure where to start.
Thanks.
Edit, code added:
var store = new MobileServiceSQLiteStore(_localDatabaseName);
store.DefineTable<Profile>();
try
{
await _mobileService.SyncContext.InitializeAsync(store);
}
catch (Exception e)
{
Debug.WriteLine(e.Message);
}
I also tried with ConfigureAwait(false) as suggested but it made no difference.
I set breakpoints in the catch and the code that immediately follows this block but they are never hit.
Ok, so I poked around a bit more and found some info on deadlocked threads answered by Stephen Cleary, the guru of async/await.
It turned me onto looking upstream. The call into my azure init code looked like this:
var azureService = Container.Get<IAzureService>();
azureService.InitializeAzync().Wait();
Which was in the constructor of the calling component.
So, I changed it to this:
try
{
Task.Run(() => azureService.InitializeAsync()).Wait();
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
And the SyncContext.InitializeAsync() call worked fine and continued on.
So, I don't really know the answer for this, I guess the internals of the new azure client do something differently than the old code since using Wait() was how I did it before and never had a problem. But there was some sort of threading deadlock. Very odd and took days to get past, now I have to fix the next deadlock I hit. If Stephen is out there and can offer some clarification that would be great.
Had this same issue - changing to a Task.Run and ConfigureAwait(false) did fix it.
Very odd thing is the same code worked fine with Mobile Services, but broke when we upgraded to Mobile App Services.
I would like to configure Push notifications for a Xamarin Forms Windows 8.1 Silverlight project. Originally I was using MPNS but am attempting to switch over to WNS. Switching over I am now running into an error when I am attempting to call the method to register my device to Azures notification hub.
The line im calling that throws the error is:
await App.MobileService.GetPush().RegisterAsync(channel.Uri);
and the error thrown is:
The type name 'MobileService' does not exist in the type 'App'
I have the NuGet package Microsoft.WindowsAzure.MobileServices installed but apparently this doesn't contain the definition.
I am following the following guide to setup my push notifications (Under the section "Add push notifications to your app"):
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-windows-store-dotnet-get-started-push/
I've also looked up how to do this on other sites and I don't see much difference to the instructions, nor do I see what I might be missing...
Anyhow if anyone has any ideas what package or reference I might be missing (or what else might be wrong with that call) I'd appreciate the help! Thanks!
In case anyone runs into this issue I solved this problem adding:
public static MobileServiceClient MobileService = new MobileServiceClient(Utilities.Constants.ApplicationURL, Utilities.Constants.ApplicationKey);
and updating my call like so:
await MobileService.GetPush().RegisterNativeAsync(channelUri);
Hope this helps!
I have a chat room using SignalR Hub for its messaging. Occasionally I get reports from users where it 'freezes'. Now this can be interpreted as no messages are coming through, I suspect as they have been dropped from a group.
My question is, does the connection get re-subscribed back into its groups automatically, or do you have to do something yourself in the Reconnect method:
public Task Reconnect(IEnumerable<string> groups)
{
return Clients.rejoined(Context.ConnectionId, DateTime.Now.ToString());
}
Yes, in 1.0.0.0-alpha1 you can enable auto rejoining of groups by using the new AutoRejoiningGroupsModule pipeline module using the EnableAutoRejoiningGroups extension method for the hub pipeline you build. This feature was not available in previous versions of the framework.
So you would end up with this somewhere in your startup code:
GlobalHost.HubPipeline.EnableAutoRejoiningGroups();
UPDATE:
Please note that the final version of SignalR 1.0 made auto-rejoining of groups the default behavior and so EnableAutoRejoiningGroups was removed. You can see this answer for more details.