Flash Remoting won't connect "NetConnection.Call.Failed"

Posted At : April 4, 2012 5:54 PM | Posted By : Jeffry Houser
Related Categories: Professional, Flex, ColdFusion

I've been doing some with for the Flextras promotions around 360|Flex. As part of the promotions I am creating a customized version of my Game; strictly for Flextras. It is going to allow people to login and will keep score on our server instead of internally to the app.

Since this is a Flash app; I'm using Flash Remoting to connect to our ColdFusion server. Everything worked fine on my local machine. Everything worked fine on my development server (AKA Staging). However, my production machine was giving errors that looked like this:

faultCode: "Client.Error.MessageSend"
faultDetail: "Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed: url:
faultString: "Send failed"

I've tried a lot of different things including not using http instead of https. I knew that Flash Remoting was working on the production server because I had other Flex apps working without problems. So, what was the problem?

I've been working on this on and off for about five days; so tried a lot of different things. In the end I discovered two things:

Make sure your Flash Remoting URL has a '/' at the end of it. 'https://www.flextras.com/flex2gateway' was not working. It appeared to add a JSessionID on it; which was causing the server to throw a 404 error; causing the whole call to fail. However, if I changed this to 'https://www.flextras.com/flex2gateway/' that problem went away.
Turn off the Flash Builder Network Monitor. The Flash Builder Network monitor was intercepting the call and causing it to fail. The calls appeared to work fine from a web browser with the Flash Builder Network Monitor enabled, but not from the mobile app.

I think--but am not completely sure--part of my issues related to using HTTPS on the server instead of HTTP. That could be the reason I had issues on the production server, but not my local or staging box.

Comments (9) |

Send |

del.icio.us |

Digg It! |

Linking Blogs | 3940 Views

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)

[Add Comment] [Subscribe to Comments]

The reason why the URL wasn't working is because of this :

If you have a Java based server, with session tracking, it will automatically add the jsessionID to the end of your url. This is not the default behavior of ColdFusion's JRUN, however it is the default for JETTY, Tomcat and Websphere.

When you make a RemoteObject (Flash Remoting / AMF3) call to your server, it is riding over HTTP. ColdFusion sets up a special J2EE application that handles all of these requests and routes them to CF to process. this is normally the /flex2gateway/ context. Anything after the / is ignored (assuming that you didn't load another context after that).

When you made the http://www.flextras.com/flex2gateway call, it appended JSessionID=xxxxxxx to the end, making the URL look like : http://www.flextras.com/flex2gatewayJSessionID=xxxxx which is, infact an invalid URL. Adding a / at the end will make it so that the jsessionID is ignored by the context handler...

# Posted By Nick Kwiatkowski | 4/5/12 10:35 AM

Nick,

That sort of makes sense. I actually use ColdFusion; with JRun.

But, I'm not sure why I would have had the jsessionId added on the production server, but not on my local machine, or my dev server.

# Posted By Jeffry Houser | 4/5/12 10:53 AM

This saved my co-developer and me a lot of time. Thank you for posting your findings!

# Posted By Anton Thorn | 4/26/12 7:14 PM

This article saved our bacon! We had been banging our heads against the wall on this.

# Posted By Nels Mickaelson | 7/18/12 8:09 PM

Thanks, my problem was also with this '/'... In the past I was using Flex with PHP (and Zend AMF) and never had this problem.

# Posted By Olivier | 10/22/12 10:30 AM

@Jeffry: I have been fighting this for days now, and could really use even the smallest bit of help. My question is simple - how come an AIR Mobile app can't talk to my CF server over HTTPS? I can make a simple CFC, and a simple mobile AIR client that just calls that method, and it fails [NetConnection.Call.Failed]. Over HTTP it works.

- The server uses a wildcard SSL cert
- I'm self-signing my AIR app
- The same app in a Flex form works fine with HTTPS
- The same mobile AIR app compiled as DEBUG mode WORKS with HTTPS

Could the self-signing of the CLIENT APP be the problem? I don't want to spend hundreds of dollars unless I need to, since this is just a small utility app.

I really just think this might be my limited understanding of what is required to make it work.

I've read just about everything about it on the Internet that it's all starting to sound the same now. I'm out of options.

Any pointers?

THANK YOU!

# Posted By PB | 3/2/13 4:40 PM

Self signing the AIR app (or not) should have no affect on that app's ability to make calls.

I would not expect the wildcard SSL cert to have any affect.

Unfortunately, beyond that you haven't said enough about your setup to even start to debug. You may try posting a detailed query on a site like StackOverflow or the Adobe Forums.

Or, I'm available as a consultant; we can get on the phone and/or screen share and attempt to debug the issue together.

# Posted By Jeffry Houser | 3/2/13 5:58 PM

Thanks Jeffry, yeah this has been up on StackOverflow for a while now (http://stackoverflow.com/questions/14970148/adobe-...)

I'm just uploaded a small sample (put link on SO) that anyone can run and see how easy this is to replicate - maybe that will help. Here is is again: https://www.dropbox.com/s/5nmilo3tbwr2k8d/HTTPTest...

I would be interested in paying to get this resolved, but it would have to be a set-bid because I'm barely making anything on this myself, and I'm pretty sure it's not a bug, just a limited understanding of how to deploy properly (aka the self-signed cert)

Thanks again Jeff!

# Posted By PB | 3/2/13 6:14 PM

@Jeffry: I finally figured it out. See my post mentioned above on StackOverflow if you are curious. Thanks again for your time.

# Posted By PB | 3/2/13 7:15 PM

[Add Comment]