Solution found. It turns out that if you use the Friendly URL (SES) and have files (images, css, javascript...) files loaded by the browser, the url of the file will be appended to the event if the file is declared relative. Take the example below;
<img src="/appname/gfx/icon_search.gif" alt="search" /> Will work perfectly. But if you declare it thus; <img src="gfx/icon_search.gif" alt="search" />, Not only will it not display the image, it will cause the browser to generate a get of the file with the event name embedded with the filename(ie: eventname/graphicFilename). Because the calls to retrieve files are gets, there is no form object to pass to the application and thus the original symptom appeared, which was database records being deleted but not rebuilt. I'm assuming this will be true with any other type of file (javascript, css) that are not addressed with the full web path name. Out of hundreds of calls to images in the app, turns out that there were three icons so defined. When I corrected them, the extraneous threads stopped being generated. This was discovered when I added the query string to the logging and it became apparent almost immediately. On Aug 12, 3:54 pm, "Peter J. Farrell" <[email protected]> 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/ -~----------~----~----~----~------~----~------~--~---
