You can clone with
No one assigned
I have been trying out SignalR 1.1.0beta using Mono Runtime and hosting on XSP. Older versions cause any first negotiation requests that make SignalR hang and not respond to those requests. Using the beta, and/or latest git revision at this date, seems to have different behavior. The following is the response I get when I try to "connect" to SignalR hub/persistant connection from a web browser:
System.InvalidOperationException: Operation is not valid due to the current state of the object
at System.Diagnostics.PerformanceCounter.set_RawValue (Int64 value) [0x0001c] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.9\mcs\class\System\System.Diagnostics\PerformanceCounter.cs:273
at (wrapper remoting-invoke-with-check) System.Diagnostics.PerformanceCounter:set_RawValue (long)
at Microsoft.AspNet.SignalR.Infrastructure.PerformanceCounterWrapper.set_RawValue (Int64 value) [0x00000] in :0
at Microsoft.AspNet.SignalR.Transports.TransportHeartbeat.AddConnection (ITrackingConnection connection) [0x00000] in :0
at Microsoft.AspNet.SignalR.Transports.LongPollingTransport.ProcessReceiveRequest (ITransportConnection connection) [0x00000] in :0
at Microsoft.AspNet.SignalR.Transports.LongPollingTransport.ProcessRequest (ITransportConnection connection) [0x00000] in :0
at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest (Microsoft.AspNet.SignalR.Hosting.HostContext context) [0x00000] in :0
at Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequest (Microsoft.AspNet.SignalR.Hosting.HostContext context) [0x00000] in :0
at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke (IDictionary2 environment) [0x00000] in <filename unknown>:0
at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke (IDictionary2 environment) [0x00000] in :0
at Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute () [0x00000] in :0
2 environment) [0x00000] in <filename unknown>:0
at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke (IDictionary
This doesn't seem to be a web-exception. I think it has something to do with Mono Runtime, as using the .NET runtime, everything works fine; but I'm not sure if this is absolutely something that Mono is doing something wrong (just started learning about Mono). This happens with the stable and beta Mono Runtime versions.
To note: Ping requests from the client, SignalR seems to respond fine to that; this confirms that it doesn't hang like in the previous versions.
Is there some sort of configuration I need to do in order for this work properly using the Mono Runtime?
Not really, we just fix bugs as they come in for mono. We don't actively test it. Looks like we just need to handle a few more API that aren't implemented.
Thanks for your quick reply! :)
Yea, I did notice there was some handling on calls against NotImplementedExceptions.
I've been looking into this more. The InvalidOperationException that gets thrown is due to the PerformanceCounter being set to readonly internally, even though SignalR explicitly tells it to not be. So, Mono is forcing the PerformanceCounter to be readonly; I don't know exactly why, but this is what I have come up with:
Mono PerformanceCounter Sourcehttps://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/PerformanceCounter.cs
Looking at Mono's source shows an external call to GetImpl which one of the output parameters is is_custom. If is_custom is false, readonly forcefully gets set to true.
Mono PerformanceCounter C Sourcehttps://github.com/mono/mono/blob/master/mono/metadata/mono-perfcounters.c
Since GetImpl is an external call, looking at the C code here indicates a 'possibility' that "custom" is not getting set to "TRUE" because the PerformanceCounter Category, "SignalR", isn't in the category list.
I have resolved this issue in two ways:
Invoke PerformanceCounterCategory.Create with the CategoryName and the possible counter names (or the attribute.Name's) before the creation of the PerformanceCounter(s). I'm assuming this puts the category in the list, and is_custom will return true; though, I feel weird about this as you might need to check to see if the PerformanceCounter exists first by calling PerformanceCounterCategory.Exists. Looking at previous revisions of PerformanceCounterManager had issues when checking to see if the PerformanceCounter exists causing it to hang (may be why I saw hanging in the older versions).
Disable PerformanceCounting on Mono entirely.
Not sure what the best way to handle this issue is, but I hope this will aid you. Resolving it either way, I can finally run SignalR successfully on Mono with round-trip communication of messages. :)
I have the same issue. I try the stockticker demo under mono (2.11.0) in ubuntu arm.
Can you details how can resolve the issue?
How I can disable performance counting in mono or how (and where) I should invoke PerformanceCounterCategory?
Thanks a lot.
How? Change the source code. This bug isn't being worked on right now and isn't set for any milestone.
Ok, I resolve change the PerformanceCounterWrapper.cs in Infrastructure directory in SignalR master.
After the changes, SignalR works great under linux ubuntu arm (olinuxino a13) with Mono 220.127.116.11.
PerformaceCounter have only a monitor purpose? Remove this "counter" have no effects on the correct working of SignalR?
Thanks a lot.
Fixed in dev 57e1c98