We are running into a possible latency issue with Corda Token SDK and encumbrances. The encumbrance is not immediately recognized by DatabaseTokenSelection but after a sufficient wait it does. And this happens sporadically.
This is a little hard to diagnose but if you're able to pinpoint what's causing the latency please do make an issue on here: https://github.com/corda/token-sdk/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
if you don't hear back on the issue message me (#david) on slack.corda.net I can help kick the can along for you.
Some tips for how to debug this:
test the latency between the nodes with ping
make sure any cnames resolve with nslookup from some of your corda nodes
check if any flows are ending up in the flow hospital along the way: https://docs.corda.net/docs/corda-os/4.7/node-flow-hospital.html
Related
I have a question and I couldn't find any answer here.
I am using the NamedPipeClientStream/NamedPipeServerStream classes for bidirectional IPC communication in a .NET 5.0/.NET Framework 4.8 environment and it works fine, however I need to have a way of letting the client (immediately) know if the server is not running anymore and I am not sure what is the best way to achieve this.
Of course I can try on the client side to call Connect with a timeout every 3 seconds for example and if I get a TimeoutException, then it means the server is not available, however as far I as have read, doing this (for example with a timer and/or a background thread) is not very efficient. Are there better ways to do this (and still use named pipes)? Can someone point me in another (better) direction?
I had it solved before with WCF, however as .NET Core doesn't support it, it is not a solution anymore.
Thank you very much.
BR,
M.
You could do a twofold approach where if a server shuts down nicely you send a 'i am shutting down' message to the client. And also have the server send small heartbeat messages once per second to clients. This way clients can check if the last heartbeat is stale or the server has shutdown whenever they need.
Looking for a WCF replacement myself and came across your post ;-)
I was currently using Sapper and I just noticed a strange network behavior. As soon as I reload my page, all files are doubled included.
Is that normal?
Thank you and have a nice day
I think it might be because there is a service worker that intercepts the request.
You can find a good explanation about this here: Service worker sends two requests
Hey so I have three GCE instances set-up which all run the same code. They're cloned from the same snapshot so I'm pretty positive that they're exactly the same.
For some reason, only one of these GCE instances is able to receive connections from external sources. The other two can't. I keep getting a "Connection timedout" error in Firefox.
These instances all have the same network-tags, so they should have the same firewall rules. That is, if you're hitting this problem too, make sure you have the right firewall rules set in the networking tab of your google-cloud center before reading on.
Since they're running the same code and have the same ports open, I have no idea what the problem could be, or how to figure out what it might be.
I was wondering what the best way to debug this might be? I believe they were working earlier but now are no longer working.
Rebooting the instance seemed to fix this. This is not an adequate solution however. I'll update my answer over the coming weeks if it happens again.
In the last 3 weeks, we have been experiencing a huge number of socket timeouts from the Microsoft Band Cloud API. When this issue started, a few retries were sufficient, however, at this point, it seems like it would be a never-ending retry loop.
We integrate with several other cloud API's and this is the only one that is experiencing this issue and is actually one of our lighter used API's, so I don't believe that it is load induced or our system.
Is anyone else experiencing this issue? Any recommendations? Thanks!
The service was having some issues with it's DNS failover components, but should now be back up and running normally. Please let me know if it continues to happen.
I feel like I'm getting mixed reviews about SignalR and disconnection functionality and I'm trying to figure out who is right (these packages move so fast it's hard to tell what is right information these days since something you find online could be 2 months old and outdated).
I've seen many people setup pinging code to tell if a client is still connected. Yet I see others talking about the Disconnect() function that gets fired from the Hub when a client disconnects. Then I see some say the Disconnect() method isn't reliable?
Does anyone have the details on this as it stands today? Should I not be using the Disconnect() method because in some cases (which maybe I haven't ran into yet) it's not reliable? It's so confusing trying to search for information when these things change so often invalidating older information you find on the web about it.
There might be a couple of edge cases where you don't get timely notifications but in general it is reliable. Also, we raise disconnect events on the client as well and we have a keep alive functionality which ensures that if the client doesn't hear from the server within a specified timeout, we will try to reconnect and ultimately disconnect if reconnects fail. Therefore, you can take appropriate actions on the client.
You can read more about this here http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server#connectionlifetime