Well, I set the server to use J2EE sessions and the issue happened again. This time, it happened while I was monitoring the system closely.
My system has a number of processes that take a long time to execute and use a lot of system resources. To make sure that these processes don't time out and/or overload the system by executing simultaneously, I created a queuing system to ensure each process gets handled one at a time. In short, I can add entries to a database table containing the component, method, and arguments to be executed. Then I created a cfm that grabs an entry from the list marked as "Waiting", then marks it as "Running", executes it, and then marks it as "Successful" or "Failed". If there are more "Waiting" items in the queue (and nothing is currently "Running", the cfm will use cflocation to redirect to itself. Otherwise, it will wait 5 minutes and then check the queue again. The cfm is requested by a windows batch file that runs in an infinite loop on a 5 minute timer (using "timeout /T 300"). The batch uses WGet to execute the following command: c:\programs\wget\bin\wget --max-redirect=1000 --no-check-certificate --spider --timeout=0 http://domain.com/controller.cfm?event=executeProcessQueue The other night, I was monitoring the queuing system while it went through about 30 entries with each entry taking anywhere between 1-10 minutes to execute. I had to do that batch about 3 times before everything came out right. At the end of each batch, seemingly immediately (as I was refreshing a page in my system showing the status of the queue), the session problem described in this thread happened. Looking through the batch execution console window, I could see that IIS reported one or two "500 Internal Server Errors". Checking the Event Viewer revealed these were due to IIS timing out. Not that big of a deal since my application, running on Tomcat, has its own really long timeout and continued to let the operations execute. Upon receiving the 500 error, the cfm assumes that the process has finished and redirects to itself again despite the process still running on Tomcat. I figure I should include this information for completeness, but it's entirely possible that IIS timing out has nothing to do with creating the problem. I should also note that this problem has only occurred on a brand new server, and I forgot to crank up the timeout in IIS when I reinstalled like I had on my old server. It's also possible that the source of the issue is simply inherent in WGet and self-redirection. Next thing I'm going to try is increasing the timeouts in IIS (however, it seems quite odd that a simple timeout can cause session mixup). If that doesn't work, I might have to figure out a different method of executing my process queue. Any feedback, suggestions or opinions are always appreciated. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
