I had previously been using the SendAsync method to call my SignalR Core hub with no problems. I realized that if there is an error on the server that I will never know about it from the client with SendAsync, so I decided to use InvokeAsync with the exact same arguments. When InvokeAsync is called, I can tell that my hub is called and it processes correctly, but the call on the client side ("await InvokeAsync") freezes. It just locks up and never makes it to the next line of code. This is a WPF application. What could be going on? await SendAsync returns immediately and has never locked up in this way.
I found the issue. It turned out it was because the message being sent from the WPF app was also being received by the WPF app, which caused a blocking issue when I tried to update the UI upon receiving a message. I updated my receive code to use Dispatcher.BeginInvoke, instead of Dispatcher.Invoke, and now it works. This was not an issue when I was calling SendAsync from the SignalR client.
Related
I had made a whole chat application using signalr as a socket with the online and offline facility. I am facing a few problems,
Signalr connection is always time out after some time, to overcome that I had condition if hubconnection is not connected then create new hubconnection (onResume app), but still it get hubconnection._callback got increased when sending message and not moving to server side socket. Again need to refresh whole app.
Can someone tell me whether this is problem because there are lot of operations going on and so signalr loses its connection as flutter is single thread and it cannot handle much? or should I use Isolate or inherit widget.
Summary problem:
I cannot send message in chat after sometime. It stores all message in hubconnection._callback and not going for server.
Is anything better solution to keep alive in both Android+iOS.
I had used https://pub.dev/packages/signalr_netcore package.
Please do not mention about firebase.
Any other logic suggestion is appreciable.
Thank you.
I've been using a different package, https://pub.dev/packages/signalr_core, which works fine without any particular issues what I have observed at the moment.
I'm only running about 10 listeners simultaneously, not sure if that is more or less than you. In the package I'm running you can establish connection with automatic reconnect. It looks like this:
HubConnectionBuilder().withAutomaticReconnect().withUrl(....)
It seems like your package have the same functionality... Have you tried that?
I'm building my first CloudKit application, and am using CKFetchRecordZoneChangesOperation on startup to get any new records changed while the current device was offline.
I am also calling CKFetchRecordZoneChangesOperation when I receive a subscription notification of changes.
It is possible the subscription notification could come in before the startup call finishes. I am currently using a lock to prevent the 2nd call from starting until the recordZoneFetchCompletionBlock handler is called, signalling that the first one is done. This works, but it also smells a bit hacky.
For some client side procedures, I implement remote logging to log the calling of the procedure. The log is printed several times with different thread id, even though the procedure is only called once. Some rpc requests are sent to the sever a few times which causes some database session problem. Is it normal? Is there anyway to avoid it?
Thanks
This is not normal, and suggests there is a bug on your client causing it to send the same call more than once. Try adding logging on the client where you invoke the RPC call, and possibly add breakpoints to confirm why it is being called twice.
My best guess with no other information would be that you have more than one event handler wired up to the same button, or something like that.
--
More specifically, your servlet container starts multiple threads to handle incoming requests - if two requests come in close succession, they might be handled by different threads.
As you noted, this can cause problems with a database, where two simultaneous calls could be made to change the same data, especially if you have some checks to ensure that a servlet call cannot accidentally overwrite some newer data. This is almost certainly a bug in your client code, and debugging it should start there.
I'm developing an app that uses Bluetooth to communicate with Smart Devices.
It needs to authorise iPhone with such scheme:
Scanning devices with some filters of services UUIDs
Connecting to a device, discovering services, discovering characteristics
Calling read operation to retrieve public keys
Exchange received public keys (using ECDH)
Generate token
Write encrypted token (using AES) to device using writeValue
That's all, after that I have stable connection and able to interact with my Smart Device (writing values to protected properties).
The question is that when I restart my app and do all of the steps above, except Step_5 (because I have my token generated and validated previous time), on Step_6 delegate method didWriteValueFor: doesn't even get called, instead of this delegate method didDisconnectPeripheral being called with Error Domain=CBErrorDomain Code=0 "Unknown error." UserInfo={NSLocalizedDescription=Unknown error.} and I can't write values to protected characteristics.
I can't get what I'm doing wrong. Any help would be nice.
UPD[0]: Sometimes I can get a callback for didWriteValueFor: on Step_6 but IMMEDIATELY (like less than a 0.5 sec) iPhone is being disconnected with an error from above.
UPD[1]: Also I was trying to cancelPeripheralConnection() before closing my app because Smart Device does not handle multiple connections in hardware reasons, but no luck here.
UPD[2]: Well, after three days of searching for information, I realized that I was digging in the wrong direction at all. The problem was that I interrupted the application with the “Stop” button in Xcode, and didn’t close it manually via iPhone, therefore, willTerminate was not called, and even if it was called, it had a very limited amount of time to execute all the processes that were supposed to be executed, as a result, the connection didn’t interrupt (the cancelPeripheralConnection method was not called), and the next time I started the App, I tried to establish a connection with a device that already has a connection to my App.
At least it started connecting often, but I'm still getting this error sometimes. The main question is: how properly disconnect from the device? For now I’m unsubscribing from all the properties that have isNotify: true (setting to false) and call cancelPeripheralConnection. Do I need to wait the “unsubscribe” process before disconnecting?
UPD[3]: It doesn't matter if I wait for unsubscribe finished or not. At least it have no effect.
Well, I found the reason why disconnects are appears:
Since Smart Device has several characteristics of public keys that need to be read, encrypted and then sent back, the order keys I read and write was important. Since writeValue and readValue are asynchronous, my order went astray. As soon as I began to keep order, everything worked like a clock.
I am developing an app in C++ that uses UIAutomation to receive notification of significant events related to user interaction. I have tried anevent handler by calling AddAutomationEventHandler to listened for window opened events, but I am having problems stopping the notification and cleaning up before exiting. If the user has launched certain applications, such as Firefox, the call to RemoveAutomationEventHandlerhangs. (Calling RemoveAllEventHandlers also hangs in this case.) Note that all calls to add or remove event handlers are done in the context of the same non-UI thread.
Note: I am seeing this behavior on Windows 7 and on Windows 8.
Any ideas on why this is happening or how to fix it? What makes the structure changed event different from all the others?
Window open/close events are implemented via the kernel WinEvent handlers; the structure change events involve the client app. Does your non-ui thread pump messages? UI Automation needs to pump messages to get cross-process communications working.