I'm pretty sure it has to do with the way coldfusion creates the java files when it compiles them. since it seems to run ok, other than the spurious threads, it's probably some 8 bit counter somewhere that gets clobbered. My boss thinks java classes are limited to 64k in the 32 bit world but I can't corroborate that yet. but running on the assumption that such a limit exists, whether known or not, removing a few dozen lines of code from the header file fixed the problem. since they were all css anyway, it was a simple test.
Seems so 1970s. Not sure how m2 assembles files when it loads them so I don't know if it is contributing or not. it's probably not relevant but do all the view files get appended or are they all run as a giant include model? I can see a case for assembling it in several different ways. the fact that the view files never seem to know what path they are in makes me wonder. In any case. it's nice to have this removed from the head scratching zone. Peter J. Farrell wrote: > Must be a large file. I think the limit is 100kb although it may differ on > version of Adobe CF being used. > -----Original Message----- > From: davee <[email protected]> > > Date: Wed, 12 Aug 2009 11:08:21 > To: Mach-II for CFML<[email protected]> > Subject: [Mach-II] Re: Spontaneous generation of events > > > > OK, it turns out that it's a jvm issue. There is a maximum size that a > java class can be. Since the cf is compiled into a java class, not > something you normally need to think about, it's interesting that the > CF engine can't tell you about it in some more friendly way. > interestingly, the cf engine will execute the code when the class gets > larger than the limit but it throws CF into a tizzy. I solved the > problem by moving some inline css to its final destination, a > dedicated css file. > > voila! the problem goes away! > > thanks for the moral support. > > > On Aug 12, 12:57 pm, davee <[email protected]> wrote: > >> UPDATE! >> >> Turns out to be a bug in the coldfusion engine. it's not a mach-ii >> thing and it's not something I'm doing. >> >> In the header file, I can place a cfabort in front of this tag >> >> <div id="adminHeader"></div> >> >> And it aborts as you might expect, but a cfabort after the tag, >> aborts, but triggers a second thread. >> >> <cfabort> >> <div id="adminHeader"></div> >> ==OK >> >> <div id="adminHeader"></div> >> <cfabort> >> ==Runs second thread >> >> This div holds an image in css and does nothing but contain an image >> and some positioning code. >> >> It looks like either the cfcompiler is producing bad bytecode or the >> java runtime engine is going bonkers. Still don't know if it's limited >> to just the cf dev server or the whole engine. My guess is that it's a >> pointer problem with the program the compiles coldfusion into java, >> but it's just a guess. >> >> On Aug 11, 11:06 am, davee <[email protected]> wrote: >> >> >>> I have an application that has an interesting problem that I have not >>> yet been able to get a handle on. Here is a synopsis; >>> >>> After an event has been completely executed, it is executed again >>> without the request scope. >>> >>> Specifically, when a form is submitted (happens on all browser >>> requested events), the event is processed normally, but after it is >>> finished, the event is triggered again, but this time, the form >>> variables do not exist at all, suggesting that the second instance is >>> being instantiated from within the mach-ii engine somehow. My >>> understanding of this that this should be impossible since the server >>> always passes the request scope to the back end engine. The fact that >>> there is no request scope and looking for the form structure which is >>> supposed to always be sent to the coldfusion engine turns up without >>> it seems impossible, but since it is happening, this is obviously not >>> true. >>> >>> What I have discovered so far is: >>> >>> * It's not in the filters >>> * It's not in the pluggins >>> * Almost every event gets triggered this way. >>> * it's not begin reported by the mach-ii logging tools (only shows >>> one instance being executed) >>> * it is being captured by the coldfusion cflog tag >>> * The only manipulation of the event queue is a redirect filter to >>> redirect events to a login and then to the original event. >>> * If I put a cfabort after processing the event (ie, inthe view >>> page or at the end of a function, the second instance never >>> occurs, so the workaround of putting a cfabort at the end of the >>> footer page would effectively stop this, but would also stop any >>> redirects or announces as well >>> * The other workaround is to put a check for the form variable into >>> each listener function and only call the gateway function if it >>> exists, but this only means that the application is doing things >>> we have no understanding of and that is not acceptable. >>> >>> I have disabled the filters and plugins by; >>> >>> * removing them from the config files >>> * renaming the functions inside so they can't be called >>> * forcing filters to ALWAYS return true >>> >>> I've run the skeleton and it does not exhibit this behavior so I know >>> it MUST be something I'm doing. >>> >>> The way I discovered it was using a function that deleted all records >>> associated with an event and rebuilt them based on the submitted >>> form. The first time, it deleted the records and created the new >>> records. Then it deleted the records and since the form structure, >>> normally in request scope didn't exist, it had nothing to create the >>> new records with and of course suggests that the whole process never >>> happened. but using cflog and cfabort, you can see that it is clearly >>> happening. >>> >>> My question is this; Before I spend a great deal of time running this >>> to ground, has anyone ever seen this behavior? >>> >>> Any help would be appreciated. >>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
