next »

[perkiset]

Hey again BRose -

First, the 5 errors that I have listed with the exact same (or essentially same) conditions are 12029, 12030, 12031, 12152 and 12159. There is one other that happens occassionally that I do not have here, but these 5 are all the same.

Regarding FormBind and bind() I doubt that there would be a difference, if the way you describe it is understandable to me, because whether the initiation of the call is via the submit event on a document or by user/function call, the underlying code that executes the request would most likely be the same. But hell it is worth a try.

Although I am not enthusiastic, I am interested to hear if you get different results or even different symptoms with GET rather than POST. If this is true, it could be that we are looking in the completely wrong direction for the problem.

@Race: It may be a whole bunch easier for me to try the race stuff out because my code is really small, light and, cleverly, mine  - I have a pretty damn important application that needs this stuff and none-to-quick... so I'm going to see if I can work through some different ways of doing this tonight. I got a funny feeling in my stomach when I was typing that post and that's usually a good thing... there's something here and I wanna get on the hunt. BTW, if you want to seem my requestor it is in the Javascript code repository on this board. I change it up a bit, but that's essentially what I always use.

l8r,
/p

[perkiset]

Hey all -

given yesterday's discussion I kludged together a mod of my ajax requestor, but have put a 10ms delay between the 3 critical steps of dispatching the request... and as of yet, I have not gotten a single error - which is way out of normal for my testing.

I do not know if this is the deal yet, but I have a feeling that there is something here. I'll keep updating as I go.

The 3 critical steps I am seperating are:

    this.requestor.open('POST', theURL, true);

    this.requestor.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");   

    this.requestor.send(this.__postParams());

... these three steps are normally called in straight-ahead code... I'm doing a setTimeout between all three. I don't know what the sweet spot is yet (where I REALLY need the delay) but I will keep working. BRose - any progress on your side?

/p

[perkiset]

OK here we go:

I've now got it down to the need for a slight delay between the open call and the send call. Here's my test:

I modified my code (several times actually, but this is the one I like) so that I do all of the prep work on the XMLHTTPRequestor in one function EXCEPT for requestor.send(). This last part of the execution I delay with a simple setTimeout by 10 ms. When I have it set this way, I executed about 200 calls and got zero errors.

So I undid everything to make sure this was an accurate test. In 100 clicks I got 8 errors, which is about my standard rate in testing. Another interesting feature of my test was that af first I was not getting as many errors - so I put up another couple browsers, one that is JS intense and let them continually refresh, which definitely made the occurence more frequent. I think I missed this before because I was not putting a JS hurt on the machine... just a general processing hurt. I then re-implemented my changes but left the JS hurting browsers open and executed about another 100 calls and got zero errors again.

Unfortunately, this is simply science by vague observation, but it APPEARS that it is much better, and given IE's threading mechanism (which messes up DOM placement as mentioned before) all of these symptoms would make sense.

I'm going to clean up the code now and repost in the JS repository for those using my code, and hopefully others (such as you BlueRose) will know where to poke in terms of tidying up the challenges you are facing.

Let's hope we got'er nailed!

/p

[perkiset]

Notice: I have purposefully left the error checking (12030++) out of the new class because if it fails this way again, I want to know about it.

/p

[bluerose]

Wow, Perkiset - impressive that you got such an amazing turnaround...so we think it's a timing thing, eh?

Unfortunately I did not get a chance to effect those changes I was talking about - working in a corporate environment so I can't just keep releasing my app to the Test Integration Environment continually...also getting some pressure from above to have a WORKING DEMO ready over the next two weeks, which means I won't be able to try anything, even your lovely solution, for two weeks. :-(

I took an hour to sift through the Dojo code for all instances of those three critical lines you mentioned, and surrounded those lines of code with a timeout. I know two weeks will effectively flush this issue from everyone else's mind, but unfortunately that's about the speed we move here. *Grimace* I'll post back when I finally get a chance to try this out.

Thank you so much Perkiset! I'm glad YOU had an easily-accessible test environment to play with! :-)

I'll be around in the meantime, poking in every so often. Might migrate to other threads. Mayhaps to add some helpful hints where I can.

Again, thanks!

~Blue Rose

[perkiset]

As you might notice from my last post, the problem is between

    this.requestor.open('POST', theURL, true);

and

    this.requestor.send(this.__postParams());

... doing everything EXCEPT the .send is OK - it seems to only have problems when I open then send immediately... if I open (and do or do not do anything else...) and wait 10ms it works out OK..

Hope you'll stick around BRose!

/p

[perkiset]

One more update: I have found that, although I am now handling the 12xxx errors satisfactorily, the requestor still on occassion does not spit out the packets. I had timeout code in the original but it was not robust enough... so I've posted the AjaxRequestor class yet one more time with bug fixes to make sure that if the packet never goes out (or an answer never comes...) then it correctly timesout, aborts and redispatches the request.

The default timeout in the class is 2500ms - which is the timeoutMS property. I've modified this now in a couple applications (like credit card processing) where that is clearly not enough - but in most cases that is more than adequate.

/p

[bluerose]

Hmm...curious updates.

Well, I guess programming would be for everyone if it were easy or made sense all the time!

I had the opportunity to spend a couple days at JavaOne this week, and tried to talk to Eugene Lazutkin (I believe he is someone who has worked on Dojo's codebase) about Dojo's AJAX functionality and this issue. We didn't have enough time to go really in depth but he asked me to post it on Dojo's forum. I'll pretty much copy and paste my first post here, and maybe a couple of your replies (if you're okay with that) or else you can post stuff yourself on the Dojo forum, and hopefully he (or someone) will have some answers, or do some research on the issue.

In the meantime.............Google Web Toolkit. I wish to god I could use it here at work. I'm going to start pushing for it and see if I can't get it.

I LOVE GWT!!! More on that later when I start playing with it at home.

~BR

[perkiset]

I'm fine with you posting @ Dojo that we're discussing it over here... but I'd prefer that you didn't simply copy my posts because they might not get the context in which I wrote them... please let them know that we'd love to have anyone over there that is interested to pop there head in over here.

@ GWT - Please let us know what you like/dont and keep us informed of your progress! Love to hear it, and I don't think there's anyone here that is currently deep into it.

/p

[Dragonlaird]

OK here's a challenge:

Throwing a request from an XML ActiveX in Internet Explorer 6 when the protocol is SSL is a mess..

It seems that there is a spontaneous error that occurs - randomly and without warning. The error occurs either when you open or post the request - the status is "4" but your will get one of 5 different error codes - 12029, 12030, 12031, 12152 and 12159. These are none-standard errors codes and if you look at the Microsoft site about them, they claim that the server connection died - the implication being that the server cutoff in some way.

Try looking at my post in another thread, it might give you a bit of insight to the root cause of the problem and tips to work around it...

Post location changed - it is now the top of a new thread in the Ajax Discussion area entitled More about the 12030 problem

OK, a few weeks/months later I returned to edit this simply because my initial 'found the cause' post turned out to be only partly correct - in the interest of tidying up after myself, I've since posted more info in another thread with some code to hopefully help those with this specific problem... Take a peek here instead:

http://www.perkiset.org/forum/ajax/xmlhttprequest_ie6_ssl_and_12030_error_what_is_the_solution-t442.0.html

[michael]

I ran into similar issues with IE + SSL. Here's what I observed:

I would receive the 12030 stutus code about 50% of the time. I added "retry" code on in my onFailur method. This worked about half of the time.  Another chunk of the time, the request would take a long time to complete, but the server would receive the request, however the PHP code did not receive the contents of the post.

I considered using an IFRAME instead, but decided to try placing my post data into the URL instead.  This works consistently and I haven't been able to reproduce the 12000+ error.

I don't get it, but so far so good.

-Michael

URL Clipped

[perkiset]

Hello Michael and welcome to The Cache

Thank you for joining and your contribution - I must ask that you not post your URL here without consulting me first, thanks for your understanding.

Now back to our regularly schedule program:
I have not ever gotten past it. So I tell my clients that they must FireFox/Safari for my back office apps while I convert to the XRPC method I described here in another thread. And although I have continued to search, I have not yet found anyone that has a 100% fool proof answer.

Flippin' MS! Adjusting my stuff for IE is practically a career in itself...