I am using the latest build (from GitHub, not Cocoapods) of the signalr-objc client.
I am getting some (to me) non-deterministic errors while connecting.
After calling the /negotiate URL, the server responds with a connection ID and token.
After the client continues, the server will in 9 times out of 10 throw the "The ConnectionId is in the incorrect format" InvalidOperationException. However, for 1 out of 10 times (or so), it works and the client successfully connects and is able to send and receive messages.
I've tried putting some thread sleeps in the Objective C code to see if there's some sort of timing issue, but to no avail.
Does anyone know what's going on here? What could be causing this?
EDIT: I might add that I am successfully able to connect to the server using the .NET client.
I have solved this. It turns out (which wasn't documented anywhere) that signalr-objc does not work with the latest (2.0) version of the SignalR server.
I downloaded the 1.1.3 version (the last stable release before 2.0) and now everything works just fine.
Related
I'm having an issue with an Analytics API batch request that I am doing, it was working and now it isn't without me changing anything. I know Google are making changes to their batch endpoints and I believe this is what is causing my errors.
https://developers.googleblog.com/2018/03/discontinuing-support-for-json-rpc-and.html
I am using the .NET client library with the AnalyticsService. Having read through the link above I'm fairly certain I've done what is needed for my batching to continue to work.
Here is a screenshot of the .NET instructions
I've upgraded all Google libraries to the latest versions, I've checked the AnalyticsService object and can confirm the BatchURI is no longer the Global HTTP Batch endpoint www.googleapis.com/batch, it is showing as https://www.googleapis.com/batch/analytics/v3, but I am still getting 400 Bad Requests. Is there something else that I am missing, or do I have to wait until the 12th of August when Google say the switch will be complete?
Thanks
Update: I created an issue on GitHub, apparently it is an internal issue, currently waiting for a fix, see here to keep updated:
GitHub Issue on .NET client library
We have a secured & authenticated WCF service which cannot use service references. Thus, we provide the interface for the contracts and open client channel manually.
We have found out that as long we open it once, everything works fine. We can call several methods several times. However, if the channel is closed or just set to a new instance, the Login() (which happens to be required for first step prior to using the service), times out.
To make the matters even more mysterious, this only happens on our production server. If I run the same project locally, I am able to login many times as I want. Consuming the methods inside a web browser (even on a code-behind ASPX page) do not have this problem even with the production server. ONLY when it's a .NET client trying to open a client channel against the production server, do we have this problem.
We are not even sure where to start looking. Any advices would be greatly appreciated.
UPDATE:
As per #Rene's suggestion, we turned on logging on both sides. From client's log, there is a record of error which is basically the same timeout error we already got via the exception. Nothing meaningful. On the server's logs, there are records of service methods being invoked successfully even after 2nd login() and from server's POV, the request is served.
Additionally, I discovered that I could not even reproduce this issue on my machine using same test project to reproduce this problem. This reproduces on my developer's machine. I verified that we were at same version of .NET framework and Visual Studio. It has to be surely a client-side problem. What could be it?
In case anyone else is looking for answer, we finally found it -- the issue is due to the need to set on client's side System.Net.ServicePointManager.DefaultConnectionLimit to some higher value. The default value is 2 but in reality this allows only one proxy to be created and be usable. Setting it to 3 would allow 2 proxies to be created & be used.
I'm using web api self host inside a windows service and I've encountered a problem and after googling for couple of hours haven't found a reasonable answer.
One of the api controllers serves large stream of data (not really that large, couple of tens of MB). It takes some time to produce data so I've decided to use TransferMode.StreamedResponse to minimize the time client has to wait for response. I've also added a CompressHandler and custom CompressedContent (derived from HttpContent) mostly based on a following answer.
The controller returns an instance of IDataReader, which is then serialized by custom formatter which is lastly compressed inside CompressedContent that I've mentioned. The whole data passing is streamed so while the client receives data, a data reader on server side may still be reading rows from database. Everything works fine when client is acting nicely.
The problem occurs when a client drops connection while the data is still being serialized to the underlying network stream. I've tried to watch for IsFaulted task inside of ContinueWith delegate (in CompressedContent from the link) and dispose underlying network Stream. Unfortunately the CommunicationException (The specified network name is no longer available) is still being thrown when the control leaves my code. From the stacktrace it looks like the exception is thrown when the Web Api tries to close (end) the underlying network stream (http channel?). As it happens with unobserved exceptions it brings entire windows service down.
I've mitigated the problem by setting windows service recovery options but I would like to know if this failure can be handled in code.
Is there a way to setup a custom error handler (IErrorHandler presumably) inside web api self hosting service mode to prevent this kind of error?
I'm using Beta version, I will try to reproduce this error on RC but I somehow doubt that setting up this kind of error handler would change in any way
We had the same issue. I was able to submit a fix to MS and they have in turn released a nightly build that fixes this. They are looking at back porting the fix to the RTM. You can see the pull release here: http://aspnetwebstack.codeplex.com/SourceControl/network/forks/rdean79/issue284/contribution/3329
First off, let me clarify the platforms we are using. We have an ASP.NET 2.0 app calling a web service which was created and is hosted on webMethods (now SoftwareAG) Integration Server 7.1.2.
The issue we are experiencing appears to occur every 10-20 minutes under a moderate volume of attempts. The .NET app tries to call the web service and gets the "System.Net.WebException: The request was aborted: The request was canceled" error message. There are no errors logged on the Integration Server when this problem occurs.
Any help/suggestions would be much appreciated!
This seems like a nasty one... and little information.
I think you will have to analyze with other tools...
Can it be that the request is stopped somewhere along the way?
Maybe you can try and follow the request with wireshark?
Which logs have you checked on the Integration server and with log levels have you applied?
You could e.g. check if a HTTP connection could be established.
We've got a web system running SQL Server 2005 for the back end, and ASP.Net for the front end (using .net 2.0).
Every now and then, the system barfs out the error in the title: 'SQLOLEDB' failed with no error message available, result code: E_FAIL(0x80004005).
The web system runs just fine 24/7, and then every now and then will toss this out on a select or some such. I've tried re-running the exact select that throws the error, but (of course) it works fine when I do it. And, to answer the obvious follow-up question, no we haven't done any code changes or upgrades to speak of lately.
Has anyone ever run into this before? Nosing around on google seems to only turn up situations where Access has some kind of file issue (permissions, missing data file, etc.)
Firstly, it's probably not SQL Server throwing out the error, and if it is, it's probably not while running the SQL statement itself, but if it is, it's almost certainly going to be peculiar to a login that doesn't have permissions, not the SQL command itself.
The 0x80004005 error is a general permissions failure, and it can occur in just about anything, but it's most likely to be in another layer.
I've seen it in authentication when the account the application is running under does not have access to the network to open a connection to the SQL Server. The SQL Server never even sees the request, but the client will say that the server cannot be found.
If it's intermittent, that could point to an intermittent domain controller issue, but that would depend on how your Windows Servers and Active Directory are set up, and how your application is connecting to SQL Server.
To solve this one, your netadmins will need to really know their Windows logging functionality and track it down for you.