Izz I already log about everything there is to log related to this including the things you suggested.
Since no one seems to have an answer to this I have resorted to brute force. When I construct the URL I add a parameter that is a time stamp. Then in runNextReport I check for the time stamp and if it is more than 2 minutes ago I abort. This does solve the problem which is further proof that the same URL is firing twice. Bryan ---------- Forwarded message ---------- From: Izz <[email protected]> Date: Fri, Apr 2, 2010 at 8:49 PM Subject: [Mach-II] Re: A ghost is re-firing my URL To: Mach-II for CFML <[email protected]> Fair point using the var local=structNew() at the start of every cf function also something I practice right from the snippet. but still doesn't guaranty to keep its value from overwriting when looping within functions unless of course you re-structNew()- it again. So what happens if you make unique variables just for testing, and not use the local scope? By the way in cf9 local became a native scope. Oh! a striking light just came to say "ask him to put a log trace each time the schedule gets called to see who called it, like a http_referer may help figure out what ghost is calling your template." yes all that from the striking light. :) On Apr 1, 1:01 pm, "Bryan S" <[email protected]> wrote: > Thanks for trying to help Izz. > > At the top of every function where I use local. I do this > In cfcs > <cfset var local = structNew () /> > In this particular cfm > <cfset local = structNew () /> > > local is not a normal Cold Fusion scope. The whole point of doing this is to > ensure these variables are exclusive to this instance of the function call. > > >I think the local.variables are being cross-referenced trough either > > pieces of the code or other pages or threads. I've had this problem > before. I am new to machII and not sure if local. is part of framework's managed scopes if so then ignore my post. I think the local.variables are being cross-referenced trough either pieces of the code or other pages or threads. I've had this problem before. since structures are not unique variable locations in memory instead they are accessed by reference pointer. if that is the case use local=structnew() at the start of your code. or better yet, dont use the local scope for all this and make unique variables just for testing. I have a feeling you are using the local. in more than one page and since the code is running each minute there may be another page using the same local.variable at the same time. May help figure it out if you also add the code that is running under checkIfReportShouldRun are you by any chance using cfthread anywhere in the process? On Mar 30, 9:00 am, "Bryan S" <[email protected]> wrote: > I would really appreciate any help anyone can provide on this. > At CFTalk I've received extensive help on how to debug this problem but no > solution to the problem itself. I'm thinking it may be a Mach-II specific > problem. Based on the extensive logging I've added to my application, and > repeated testing, I am able to simplify it down to the following: > I have a scheduled task that runs an event I'll call checkIfReportShouldRun > that runs every minute. > At minute: > 1) It determines that it should start a report and constructs a url > that calls the event runNextReportInQueue, logs the url that it constructed, > and fires that url > 2) It determines that it should NOT fire an event and logs the fact > that it will not construct a url to run another report > 3) Same as minute 2 > 4) Same as minute 2 > 5) Same as minute 2 > HOWEVER, at minute 5 in spite of the fact that checkIfReportShouldRun > correctly determines that it should not start a report, a report does start. > This rogue report is started by the EXACT SAME url that fired at minute one. > I know this because when I have added a now() timestamp parameter to the url > to indicate when it is constructed in runNextReportInQueue and just before > checkIfReportShouldRun runs the url. I have included this code at the > bottom of this message. > This rogue report always fires exactly five minutes after the first report > fired. The second identical url DOES NOT fire IF the report that started at > minute 1 has completed, only if it is still running. > Although my application logging does not indicate that the duplicate url is > being fired the server logs do. This does not occur if I run > checkIfReportShouldRun manually in a browser. It does happen if > checkIfReportShouldRun is fired by a Cold Fusion Scheduled Task or by a > Linux Cron Job. > I have exhaustively ruled out the possibility that some other server is > firing either url. Logging shows conclusively that the line of code just > below <!---RUN THE URL---> in the code snippet at the bottom of this message > is causing both reports to start. How can this happen? > <cfset local.cfhttpStartTime > = now() /> > <cfset local.desiredEvent = > local.desiredEvent & "&cfhttpStartTime=" & local.cfhttpStartTime /> > <cfset local.logEntry = > "local.configNumber=#local.configNumber#-CFHTTP START > -local.cfhttpStartTime=#local.cfhttpStartTime#-local.configName=#local.confi > gName#-local.desiredEvent=#local.desiredEvent#CFHTTP START"/> > <cfset > logEntry("flexcomm-schedule-results","aa050-cfhttpLogging",local.logEntry) > /> > <!---RUN THE URL---> > <cfhttp method="get" > url="#local.desiredEvent#"> > <cfset > local.cfhttpCompleteTime = now() /> > <cfset local.desiredEvent = > local.desiredEvent & "&cfhttpCompleteTime=" & local.cfhttpCompleteTime /> > <cfset local.logEntry = > "local.configNumber=#local.configNumber#-CFHTTP > COMPLETE-local.cfhttpStartTime=#local.cfhttpStartTime#-local.cfhttpCompleteT > ime=#local.cfhttpCompleteTime#-local.configName=#local.configName#-local.des > iredEvent=#local.desiredEvent#CFHTTP COMPLETE"/> > <cfset > logEntry("flexcomm-schedule-results","aa050-cfhttpLogging",local.logEntry) > /> -- 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/ -- 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/ To unsubscribe, reply using "remove me" as the subject.
