I am creating an AIR application which downloads file from a server. I am using URLstream object with complete, progress, IOError, security error and HTTP status events. I am not getting an event if the network is disconnected when the download is in progress. Please can anyone tell me which event is dispatched?
Thanks,
Anahas
You should get the IOError event in case the network gets disconnected. If you're not getting it, you either didn't add a listener for that event, or you added it on the wrong object, or there's a framework/Flash bug.
There is also a separate set of events that AIR uses to communicate connectivity status. They can monitor services, servers or just "connectivity" ( do I have network ). Monitoring network connectivity
I agree with bug-a-lot though, at some point you should get an IOError but you might have to wait for a timeout to occur.
is there way to change the time-out for IOError while loading using urlstream ?
sometimes even though network is disconnected i dont get the event but its not very definitive.
Related
I am using SignalR in my web api to provide real-time functionality to my client apps (mobile and web). Everything works ok but there is something that worries me a bit:
The clients get updated when different things happen in the backend. For example, when one of the clients does a CRUD operation on a resource that will be notified by SignalR. But, what happens when something happens on the client, let's say the mobile app, and the device data connection is dropped?.
It could happen that another client has done any action over a resource and when SignalR broadcasts the message it doesn't arrive to that client. So, that client will have an old view sate.
As I have read, it seems that there's no way to know if a meesage has been sent and received ok by all the clients. So, beside checking the network state and doing a full reload of the resource list when this happens is there any way to be sure message synchronization has been accomplished correctly on all the clients?
As you've suggested, ASP NET Core SignalR places the responsibility on the application for managing message buffering if that's required.
If an eventually consistent view is an issue (because order of operations is important, for example) and the full reload proves to be an expensive operation, you could manage some persistent queue of message events as far back as it makes sense to do so (until a full reload would be preferable) and take a page from message buses and event sourcing, with an onus on the client in a "dumb broker/smart consumer"-style approach.
It's not an exact match of your case, but credit where credit is due, there's a well thought out example of handling queuing up SignalR events here: https://stackoverflow.com/a/56984518/13374279 You'd have to adapt that some and give a numerical order to the queued events.
The initial state load and any subsequent events could have an aggregate version attached to them; at any time that the client receives an event from SignalR, it can compare its currently known state against what was received and determine whether it has missed events, be it from a disconnection or a delay in the hub connection starting up after the initial fetch; if the client's version is out of date and within the depth of your queue, you can issue a request to the server to replay the events out to that connection to bring the client back up to sync.
Some reading into immediate consistency vs eventual consistency may be helpful to come up with a plan. Hope this helps!
I am building a messaging application using NATS C# API. I have set all event handlers, but I have a problem in DisconnectedEventHandler. In the Github page, they have shown how to handle the event. I did exactly the same but whenever DisconnectedEventHandler is triggered, args.Conn.ConnectedUrl shows nothing. I just want to know which server is disconnected. Can anybody please help me on this?
Thanks in advance.
Cheers
J
If you are disconnected, but definition you are not connected to any server, so it makes sense that ConnectedUrl() returns nothing. You could save the URL you are connected to on success and then use that when getting disconnected.
I'm not sure if I'm doing this right.
Our orchestration looks like this:
ReceiveOrder
TryScope (Long Running)
AcknowledgementScope (Atomic)
ConstructOrderAckMessage
TransformOrderToAck (using a map)
SendOrderAckToMessageQueue
AtomicWebServiceScope
ImportOrderToDBExpression
Construct and send message to another process
CatchException
ConstructErrorExpression
HandleExceptionStartOrchestration
When we tested this with about 6000 orders, we noticed that all of them resulted in an acknowledgment message (SendOrderAckToMessageQueue). The acknowledgment is a simple XML based on a schema provided by the crew that sends the order to this orchestration.
However, not all of them got imported into the database (ImportOrderToDBExpression) (about 45). In fact, there are no errors or failures or suspended instances of any kind. There's nothing unusual about the orders that did not get imported. If it failed, it did so silently.
Please note, that the AcknowledgementScope portion is something added recently; prior to that all the orders got imported successfully.
Is this because I have the Scope set incorrectly in this orchestration? Where else could the problem be? Is there a better way to send acknowledgment in a fool proof way? Thanks for any advice.
You don't mention any Catch Blocks. Do you have Catch Blocks on all your Scopes?
If there is an Exception without a Catch Block or a Catch Block that does not log the Exception, it will appear to silently fail.
Yes, the main thing you are doing wrong is calling an external DLL to insert records into a database.
Unless that DLL is very well written to be multi-threading capable including limiting the number of concurrent connections and has good retry and error handling capabilities then it can encounter an error and silently fail.
Even if you do have errors being logged in the DLL to the Event Log, you then have to give permissions for the Application name that the DLL uses to write to the event logs, otherwise the DLL will fail in it's catch blocks trying to write to the event log.
What you should be doing is using a Send Port with the appropriate Adapter to send records to the database.
Also there are very few situations in which you need an atomic scope. With an atomic scope it is up to the developer to implement any rollback. Also you probably do not need a long running scope unless you expect your Orchestration to take a long while and that is should dehydrate while waiting for a response.
Sending the Acknowledgement after the BizTalk Orchestration has received the message is fine, as long as you can then somehow resume a failed message in BizTalk, so you need to have some sort of retry mechanism.
Title sums it up. Same question is here. Posting on SO to see if I can get any help. I also made an almost minimal project to demonstrate the problem I'm facing, so links that follow point to the piece of code being mentioned.
Nothing fancy on what I'm currently doing:
My watchface is notified that the bluetooth connection with the phone is up, using .pebble_app_connection_handler.
In that bluetooth callback I set up, I send a message to the phone using app_message_outbox_send(). When BT connection is up, of course.
My Android app has a BroadcastReceiver that listens to these messages and calls an IntentService.
This IntentService calculates the data, pushes it to the watch and sets itself to run again after some time.
What I expect:
When the BT connection is up, the connection handler to be called.
app_message_outbox_send() return a value telling if the message initiation had any errors. Normally, this is APP_MSG_OK, but it can be APP_MSG_BUSY, and I'm perfectly aware of that.
The app message callbacks (app_message_register_inbox_received and friends) be called to indicate if the asynchronous process of sending message to phone really worked. This is stated in the docs.
What I'm seeing:
The expected steps happen when the watchface is loaded, because I trigger the update manually. However, when the update is triggered by a BT connection event, expected steps 1 and 2 happen, but not the step 3.
This is particularly aggravating when I get APP_MSG_OK in step 2, because I should reasonably expect that everything on the watch went OK, and I should prepare myself to receive something inside the app message callbacks. Basically, I'm told by the docs to wait for a call that never arrives.
This happens 100% of the time.
Thank you for any help. I have another solution that works, using the watch to keep track of the update interval, but I believe this one allows me to save more battery by making use of recent Android features.
From documentation :
To also be notified of connection events relating to any PebbleKit
companion apps associated with this watchapp, also assign a handler to
the pebblekit_connection_handler field. This will be called when the
status of the connection to the PebbleKit app changes.
Maybe it is what you need
I am using Signalr in an application I'm writing and storing all the user connections in a concurrent dictionary
ConcurrentDictionary<string, User> _users = new ConcurrentDictionary<string, User>();
e.g.
https://github.com/SignalR/SignalR/blob/master/samples/SignalR.Hosting.AspNet.Samples/Hubs/ShapeShare/ShapeShare.cs
I have implemented the IDisconnect interface on my Hub and I'm removing users from the dictionary when they disconnect
I am wondering how reliable the Disconnect method really is?
Does it capture all the different ways that a user could diconnect?
I dont want the dictionary to grow and grow indefinitely
I was thinking of maybe having a timer to periodically traverse the dictionary and remove users who havent had any recent activity
Is this necessary? Can I rely on the disconnect method?
Check out https://github.com/SignalR/SignalR/wiki/Configuring-SignalR , there are settings for :
DisconnectTimeout
KeepAlive
& Heatbeat interval
These could all be applied to help in maintaining your dictionary.
In my experience a graceful disconnect seems to work perfectly on signalR (still problems with win-apps) , if it ungracefully disconnects in a few minutes the connection will timeout and the disconnect method will fire and remove it from your dictionary like Drew said.
You could create a method that sends a message to all clients and log the returned connection ID and then remove any entries that are old, but in practice the disconnect method does work/work itself out, I would only implement the heartbeat interval if you really need to keep a very close eye on the connections.
If it doesn't fire it's a bug and you should report an issue to the SignalR project on GitHub. Here's a list of open issues with Disconnects at this time.
Be aware that diff. transports have diff. disconnect detection logic and so, depending on which transport the user is using, you will see diff. patterns of when the Disconnect fires, but it SHOULD fire eventually for all transports.