Can you please share the WSDL you are trying to introspect or email me at rbhat @adobe.com
hi Radhakrishna, thanks for replying... i actually cannot post the wsdl sorry, but i know for a fact that the svc works... when i try to go to the wsdl directly in a browser, i can see my xml...
i also tried using wireshark while the introspection was trying to get the data, and according to wireshark it is getting all the data... im assuming the problem is with flash builder's xml parser... or somehign.... any ideas??
oh and the other day when i was trying to get my service it didnt work for 3 hours, but after that it randomly started working... and now im trying to update my service, and trying to get the service again, and its not working .... any ideas?? or is this a known bug???
ok so, now i dont get that error any more... but the introspect wizard is really slow! it took about 35 minits to get the data from my wsdl. is there a reason why this is happeneing?
I've just been bitten by this as well. The nutshell of what I found: Flash Builder is holding open connections too long. If you manually kill the hundreds of connections that are opened to www.w3.org, it completes faster. Details:
The symptoms in my case are identical to what others have experienced. Previously, my .NET WCF service took maybe 20 seconds at most to parse and generate the code. Now it’s taking well over 20 minutes – I thought Flash Builder had frozen until one time I left it and went for lunch and when I returned I found that it had finally finished parsing.
The WSDL and XSD URLs all come up instantly in my browser. I’m currently running Flash Builder v4.0.1 (build 277662) but this also occurred in the previous build (v4.0.0) as well. I upgraded only when I started experiencing this issue, hoping there would be a fix.
As an update, I ran Wireshark to watch the traffic that was going on. There’s a ton of activity going to www.w3.org:
This occurs fairly uniformly over a 1200 second (20 minute) period – Wireshark capture available. I’m not an expert on this, but it looks like these connections are being held open for a full 20 minutes (default TCP timeout period?). Once the timeout period expires, Flash Builder completes its processing. Note there are a few packets there where I manually connected via my browser which closed the connection properly. Aside from this, all the FlashBuilder-initiated connections seemed to close all at once after the 20 minutes.
With this information, I tried something else. Using TCPView from Sysinternals (running as Administrator), I watched FlashBuilder establish connections to www.w3.org (the IP address is shown as hans-moleman.w3.org). When a connection was established, I waited a second and then right-clicked on the connection and chose “Close Connection”. Using this procedure, I was able to reduce the time down from 20 minutes to under 5 minutes... the bulk of the time I think is taken up by all the manual work involved with this. If the connections had been closed automatically this might take a minute, tops.
After I wrote the above, I experimented a bit more with TCPView and found that a connection would close after being left alone for 90 seconds. If we assume that the connection should get closed after 1 second, this is taking 90 times as long as it should. If you divide the 1200 seconds it took by 90, this gives 13 seconds... about the time it used to take to introspect the service.
My workstation is running Windows Server 2008 (32 bit) if that matters.
Workaround found. Edit your hosts file (/etc/hosts on Mac/Linux or C:\Windows\system32\drivers\etc\hosts on Windows... for Vista/Win7/Win2008 run Notepad as Administrator, then open the file) and add the following entry:
Save the hosts file and restart Flash Builder. Your introspection will happen very quickly (went from 20 minutes to about 1 minute for me) because it will attempt to connect to www.w3.org and fail immediately. Alternatively, if you're introspecting a locally hosted web service unplug your network cable and it will be even faster.
I don't know if adding the above will break anything else, so when you're done introspecting you can re-enable normal connectivity to www.w3.org by changing that line to:
The # in front comments out the line so that it's ignored.
I hope this helps others who are experiencing the same issue.
Thanks for the detailed explanation of the problem you are facing. I have filed a bug to track this issue. https://bugs.adobe.com/jira/browse/FB-28592
Please add your comments to the bug.
I used Charles to check the traffic. It doesn't seem to have any connections opened to w3.org. If you cannot share your actual wsdl, can you please construct a sample WSDL where this behavior is seen and share with me?
Pardon me for tripple-posting this but since this seems to be a common problem I wanted to share my solution:
The problem as identified above is that when running the introspection, repeated calls to www.w3.org are taking a lot of time, so it appears the progress dialog has "frozen" when it fact it is working, only very slowly. This can be circumvented by using Fiddler, the web debugging proxy, instead of disabling network interfaces or manually killing connections. Fiddler has an autoresponder that can be used to respond instantly. Here's how you do it:
- Install Fiddler2 and start it. Remember that you need to start Fiddler as an administrator. Fiddler acts as a proxy for all HTTP clients on the computer when it's running, including Flash Builder. It removes itself as a proxy as soon as you turn it off.
- Start Flash Builder.
- In your project, select "Connect to Data/Service...", select "WSDL" and go through the first page of the wizard. Once the progress dialog shows up and apparently "freezes", look in Fiddler.
- You will notice there are calls to www.w3.org that are very slow. They take about 30 seconds each to complete. The four offending URLs are...
- Let the four URLs complete one response each. They must have a response that is HTTP 200 (OK), and a body length that is not -1. I've gotten 504 on rare occasions, and the body length is -1 until the request has completed.
- Click the "AutoResponder" tab.
- Check the box "Unmatched requests passthrough".
- Check the box "Enable automatic responses".
IMPORTANT 1: Do it in that order! "Unmatched..." first, "Enable..." second. Otherwise you might lose a few responses.
IMPORTANT 2: Do not check the box "Enable latency", because that's what we're trying to avoid here.
- Drag and drop - from left to right - the 4 offending requests. Fiddler will make 4 autoresponder rules that will respond instead of w3.org.
- Now just sit back and watch the process finish quickly.
Hope this helps.