You accuse FF, in the browser, with the candlestick? (Re: FF3.6 Stack output from Too Much Recursion)
"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:hmj4g8$gd6$1@news-01.bur.connect.com.au...
Hi Stefan,
"Stefan Weiss" <krewecherl@gmail.com> wrote in message
news:Cc2dndQJg7yhyRHWnZ2dnUVZ8uednZ2d@giganews.com...
On 02/03/10 00:17, Richard Maher wrote:
Sorry for labouring on this but I upgraded to FireFox 3.6 and managed
to
get
a bit more useful output that might ring a bell with somebody. The
following
is a dump of the exception properties that was thrown from the code
below
(Search for "4" to locate the source): -
I don't have FF 3.6 available for testing, but I've experienced this
error sporadically in FF 3.0. In my case, I had suspected Firebug (I
think we talked about this before, not sure), but it could easily have
been something else. By the time I reactivated Firebug, it had been
updated, and the problem had disappeared: correlation, but not
necessarily causation.
The very first thing I would try: disable *all* Firefox add-ons, and I
mean really disable and restart.
Done, but still no joy I'm afraid :-(
A few weeks ago, I spent most of an
afternoon tracking down a weird JavaScript error ("e is not defined"),
and when I finally found the source, it turned out to be a typo in the
NoScript add-on. If you can eliminate the possibility of an error
outside your own code, that would help narrow it down. If you could
reproduce the error with Java disabled, that would be even better, but I
don't know if that's possible in your application.
Jorge was good enough to try that (see below for details) but
unfortunately
when the JAVA applet is removed from the equation it all seems to work. It
looks like I'll have to try and come up with a scaled-down Applet
reproducer.
Any ideas what's happening? FF2 is fine, IE and Chrome do not exhibit
this
problem :-(
1) Is "canvas" now a dodgy reserved word?
No.
OK, with HTML5 support appearing I thought I'd clutch at that straw :-)
2) Is setTimeout with zero millises some sort of optimized "inline"
call
and
does not place a *non-recursive* event on the Event Dispatching
Thread?
Don't know how to answer that, because I can't look into your applet and
browsers don't have an EDT (well, maybe HotJava does). I don't know what
you mean by "optimized inline call", there's no such thing in
JavaScript.
I was dreaming that a setTimeout(x.0); was being optimized to x();
resulting
in "x" being executed inline and that might possibly explain the recursion
that I am yet to see! Ridiculous perhaps but I'm running short of options.
Calling window.setTimeout with 0 as the second argument
should result in the function being called "at the earliest
opportunity", after the main (=only) JS thread has become idle (and any
other functions queued with setTimeout have been called, if necessary).
Yes. So: -
function x(){
setTimeout(x,0); //Along the lines of what I'm doing
}
Does not induce any bloody form of recursion unlike: -
function x(){
x(); // This will crap out at 3000 (reported stack depth) on FF3.6
}
Which is what I'm *not* doing.
I guess I just wish someone who could read the Mozilla code could tell me
what FF3 considers a recursive check/condition (especially given the
"stack"
property in the Exception that I included earlier) Once again the code
*with
Applet* works fine with only one EmpPicker() selected/instantiated but
when
another (up to 5) is introduced the "recursion" is trapped at around 153
iterations. The code is also happily chugging away on Chrome as we speak.
Why would multiple concurrent (Jorge's code can not induce the 1.5sec
delay
my server can) timers flag a false recursion flag/exception when a sigle
one
does not? And why only after 153 successful iterations?
--
stefan
Thanks for your continued interest and advice!
Cheers Richard Maher
Here's Jorge's "working" code (replacing the Applet bits in
Tier3Client.js): -
"Jorge" <jo...@jorgechamorro.com> wrote in message
news:c68468b5-3b99-44e6-9654-2a620f355683@e37g2000yqn.googlegroups.com...
****FROM HERE****
On Jan 30, 11:01 am, "Richard Maher" <maher...@hotspamnotmail.com>
wrote:
(...)
Removing the applet and the back-and-forth between Java-JS the
resulting java-less version seems to run fine:
http://jorgechamorro.com/cljs/095/
<script type="text/javascript">
function Tier3Client () {
(this.chan= {}).rendezvous= function () {
console.log("this.chan.rendezvous(), "+ (+new Date()));
};
this.chan.send= function (msgCandidate, msgBody, async) {
var r=
"31abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst?
u
vwxyz";
if (async) {
setTimeout(function () {
console.log("this.chan.send(async===true)");
msgCandidate.dispatcher(r, 0, 0);
}, (2e3*Math.random())|0);
} else {
console.log("this.chan.send(async===false)");
msgCandidate.dispatcher(r, 0, 0);
}
};
this.chan.appendConsoleMsg= function (p) {
console.log("appendConsoleMsg: "+ p);
};
}
(Tier3Client.prototype = {}).send= function (msgBody, callback,
async) {
var chan = this.chan;
var callbackArgs = [];
var i = 0;
var msgCandidate = {
dispatcher : function (responseMsg, msgSlotId, msgSeqNum) {
callbackArgs[0] = responseMsg;
callback.apply(this, callbackArgs);
},
rendezvous : function () {
console.log("msgCandidate.rendezvous(), "+ (+new Date()));
return chan.rendezvous();
}
};
for (i=3; i<arguments.length; i++) {
callbackArgs[i - 2] = arguments[i];
}
return chan.send(msgCandidate, msgBody, async);
};
Tier3Client.prototype.appendConsoleMsg= function (msg) {
console.log("Tier3Client.prototype.appendConsoleMsg(), "+ (+new
Date()));
this.chan.appendConsoleMsg(msg);
};
</script>
--
Jorge.
****TO HERE****
I will put in the not insubstantial effort to come with (hopefully) a small
reproducer, but in the mean time here's a couple of bits of information that
might lead someone to explain to me why FireFox 3 is giving me "too much
recursion".
The architected JAVA and Javascript behaviour is as follows: -
Page Load:-
1) Javascript invokes an Applet Method (Creates a Tier3Client instance)
2) The Applet init() method does many things including create a Socket and a
Thread that reads from the socket
EmpPicker() Javascript Object (1 to 5 created on demand by the user): -
1) setTimeout(sendRequest,0)
2) sendRequest calls an Applet method specifying "callback" and then "wait"s
in Applet
3) Thread reading socket calls the Javascript callback routine
4) When ready, the Javascript "rendezvous()" method calls back into the
Applet and "notify"s the original sending thread that it can exit back to
Javascript
5) The callback routine then setTimeout(fadeIt,fadeInterval)
6) If we're still fading schedule another fade else schedule another READ
5b) The sendRequest is ready to recieve control back from the Applet but the
new JAVA plugin waits until the callback has returned to JAVA thus
preserving "conceptually, the single-threaded nature of today's modern
browsers".
For more JAVA/Javascript threading behaviour info, please see: -
http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/index.html#JS_J_THREADING
C'mon guys/gals, I bet you have the answer and can have a whole weeks House
supply of vicodin if you can just come up with a semi-resonable diagnosis!
(Not me dick-head, the problem :-)
a) FireFox II is perfectly fine with it!
b) FireFox3 doesn't have any issues until more than one instance of
EmpPicker() is active.
c) Chrome have 5 EmpPickers going simultaneously for 20,000 iteractions and
no signes of distress
d) 148 is no where near 3000
So is something else using up the Stack space? It certainly doesn't report
as being corrupt.
Has FF3 introduced some too-clever-by-half stack monitor/walker thread to
proactively pounce on errant Javascript
Anyone seen a half-relevant release note?
Go on, take a shot, make a name for yourself, and most importantly save a
patient :-)
Cheers Richard Maher