My application requires that I am able to abort/close a URLLoader instance at any point in the post-connect stage; that is, regardless if I have connected and the file transfer has already begun, or whether I have connected, and the file transfer has yet to commence (the server has not begun sending the file yet).
Here is my code:
var myTextLoader:URLLoader = new URLLoader();
myTextLoader.load(new URLRequest("myText.txt"));
This is what I have noticed:
When I connect to a server, and the server starts sending the file immediately, DURING the actual file transfer, if I invoke myTextLoader.close(), it aborts immediately. This is expected. I can monitor this by executing the SWF in Firefox,and noticing that when I issue the close(), the network connecion goes from Pending to aborted.
However, if I connect to the server, and the file transfer has not actually begun yet (I have confirmed the connect event has fired, and the server has simply not begun sending the file), then myTextLoader.close() has no effect. Only AFTER the first bytes start being transferred from the server, will .close() have any effect. I can verify the connection is stuck in Pending in Firebug.. .close() has no effect until the transfer has started.
Any ideas how to work around this issue? I need to be able to invoke .close() and have the connection torn down regardless of the connection stage.
First thing I would think of, is create a bool "aborted" that is set to true where the close() method is invoked.
Like :
function abort():void {
_aborted = true;
myTextLoader.close();
}
Then check for its value anywhere in the onProgress event or any similar event, to actually call the URLLoader close() method again whenever its value is true...
function onProgress(evt:ProgressEvent):void {
if (_aborted) {
myTextLoader.close();
}
}
Its not a pretty thing and is an ugly workaround, but this could work, since when the first bits are actually received, you'll know if you already wanted to close it or not.
Did you find any bug report on that anywhere ?... I doubt it could be an intended behavior...
3rd party AS3 HTTPClient (https://github.com/gabriel/as3httpclient) appears to not exhibit this issue with close().
Related
I'm using a SharedObject to create a simple chat app. The SharedObject was created fine and my app could receive the sync event when other clients updates the data on the SO. However, the problem comes when my app tries to saves the data on the SO to signal other clients. I've verified that the data was changed using the following code:
trace("before:"+so.data.chatMessage);
so.data.chatMessage = msg.text;
trace("after:"+so.data.chatMessage);
It said "before:abc" and "after:def". Unfortunately no clients received the sync event after the data on the SO changed including the client that made the data change itself. So this means this client can receive other client's message but itself message never gets out.
Anybody has seen such issue before? Thanks,
Jack
You have to call flush():
If you don't use this method, Flash Player writes the shared object to a file when the shared object session ends — that is, when the SWF file is closed, when the shared object is garbage-collected because it no longer has any references to it, or when you call SharedObject.clear() or SharedObject.close().
or
use setProperty() to change the property:
Updates the value of a property in a shared object and indicates to the server that the value of the property has changed.
As you only change a property of the data object, there's no notification going on that this value has changed.
Calling so.flush() resulted in "Error: Error #2130: Unable to flush SharedObject." It did not print an internal error, though. So it seems the problem was the flush couldn't be successful... Any idea how could happen?
Take a look at this other question:
Error #2130 Unable to flush sharedObject
I've got an application that is downloading several large binary files and saving them to disk. On some machines it works fine and on some other machines every once in a while a download will proceed to 99.9% complete and the URLStream object will not fire Event.COMPLETE
This is almost identical to the issue that appears here:
Why does URLStream complete event get dispatched when the file is not finished loading?
I've tried using the 'Cache Bust' method described in one of the answers but still no dice.
Any help would be appreciated.
Here is some sample code to help illustrate what I am trying to do:
var contentURL:String = "http://some-large-binary-file-in-amazon-s3.tar";
var stream:URLStream = new URLStream();
stream.addEventListener(Event.COMPLETE, function(e:Event):void{
//This should fire when the file is done downloading
//On some systems this fails to fire once in a while
//On other systems it never fails to fire
});
stream.addEventListener(ProgressEvent.PROGRESS, function(pe:ProgressEvent):void{
//Write the bytes available in the stream and save them to disk
//Note that a download will reach 100% complete in terms of total progress but the 'complete' event might still not fire.
});
var urlRequest:URLRequest = new URLRequest(contentURL);
//Here we might add some headers to the URL Request for resuming a file
//but they don't matter, the 'Event.COMPLETE' will fail to fire with our without
//these headers
addCustomHeaders( urlRequest );
stream.load( urlRequest );
Imo this is a code meant to fail where you purposely give up any control on whatever is going on and just assume that everything would work by itself and go well. I never had any problems whatsoever with the URLStream class but here's basically what I never do:
I never not register all the different error event available (you don't register any).
I never use anonymous listeners. Even though they are supposed to not be GC until the download is complete this is imo an unnecessary unsafe bet especially since it's not rare for the URLStream to idle a little while loading the last bits. I would not be surprised if removing those anonymous listeners would actually fix the problem.
I am trying to work through connection issues at this stage of the app writing process. When the user leaves the game board, I call ...
void HelloWorld::onExit()
{
isMultiPlayer = CCUserDefault::sharedUserDefault()->getBoolForKey("MULTIPLAYER", false);
if(isMultiPlayer)
{
AppWarp::Client::getInstance()->disconnect();
CCUserDefault::sharedUserDefault()->setBoolForKey("MULTIPLAYER", false);
}
CCDirector::sharedDirector()->getTouchDispatcher()->removeDelegate(this);
CCLayer::onExit();
}
From here, if I try to re-join the lobby, I get a
onConnectDone .. FAILED with unknown reason..session=0
Error in my log file. It seems like I need to wait around 5 minutes or so before this error disappears. Am I doing something wrong with my disconnect code, or is this kind of behavior the norm?
#PWiggin - this issue has now been fixed in our SDK update. You can pick the latest release from our GIT repo. Here is the link
https://github.com/shephertz/AppWarpCocos2DX/tree/master/V_1.5.1
Created an windows service which saves all received and sent emails to my local drive and my service successfully does that.I have also resubscribed my streaming subscription onDisconnect event and Onerror event also.But my service stops responding after some time and there is no exception catched even though i have handled everything properly.Saw other forum and found the same issue people facing but there is not proper solution.
static private void OnDisconnect(object sender, SubscriptionErrorEventArgs args)
{
try
{
// Cast the sender as a StreamingSubscriptionConnection object.
StreamingSubscriptionConnection connection = (StreamingSubscriptionConnection)sender;
if (!connection.IsOpen)
connection.Open();
}
static void OnError(object sender, SubscriptionErrorEventArgs args)
{
// Cast the sender as a StreamingSubscriptionConnection object.
StreamingSubscriptionConnection connection = (StreamingSubscriptionConnection)sender;
if (!connection.IsOpen)
connection.Open();
}
Is this something to do with the Microsoft bug or it requires any settings on Exchange server for changing the limits for EWS subscription.
Even i checked below something related to throttling limit but no success:
http://msdn.microsoft.com/en-us/library/exchange/hh881884(v=exchg.140).aspx
Thanks a million in advance.
We have exactly same issue. And we do re-create whole subscription in OnError event just in case. It is also interesting that multiple application instances running on separate boxes exhibit identical behavior: at some point they just stop receiving notifications. Restarting any and all of them doesn't help; they do successfully subscribe but still no notifications other than OnDisconnect. Restarting Exchange Server is what really helps, though for a while.
I can see that the problem here is that you are trying to open the connection in the OnError handler. The problem here is that when OnError happen, the connection normally loses all the subscriptions, so you might need to consider creating the subscriptions again before opening them.
Observing FileReference.upload() I notice that if I'm uploading large file (big enough for upload to last for some time) and cut the connection (by pulling out LAN cable for example) in the middle of upload, Flash doesn't report an error... In fact it continues to fire Progress events all the way to "successful" completion.
Is this a bug? Shouldn't there be an exception thrown or error event fired?
Accordning to the documentation on FileReference.upload() it should invoke an IOErrorEvent when such a thing happens.
Try listening for an IOErrorEvent
yourFilereference.addEventListener(IOErrorEvent.IO_ERROR, error)
function error(e:IOErrorEvent):void
{
//Do something
}