Re: dumpy goodness
That's the first time you mentioned any of this, so I was going on your previous statement that the code was "causing a loop to create the error over and over again". In any event, if you try to serialize a gigantic struct, that will generate a really gigantic string. So if you keep reserializing it, or if the struct is very large and nested with lots of data, that string could easily end up triggering an out of memory error. I've seen the same thing happen trying to build up very large XML strings. On Nov 13, 2007 8:02 PM, Brad Wood <[EMAIL PROTECTED]> wrote: > I didn't pull that number out of thin air. I counted the errors. > The proc was looping over accounting line items and concatenating their > invoice codes together for display. Usually there are no more than 5 > items to iterate over. Due to some poorly configured pricing setup on a > test order, there were 439 items being looped over. The field holding > the concatenation was a varchar(255). The average item code was 8 > characters long, meaning it would have began erroring after the 32nd > item leaving exactly 407 items which would have errored with "string or > binary data would be truncated". So I think 400 is a pretty darn good > guess. > > When I ran the proc in query analyzer I confirmed that was about the > number of errors being returned. > > ~Brad > > === > > You're saying this as if you didn't just pull the number 400 out of thin > air. > > ~| Get involved in the latest ColdFusion discussions, product development sharing, and articles on the Adobe Labs wiki. http://labs/adobe.com/wiki/index.php/ColdFusion_8 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293281 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: dumpy goodness
> Ahh-- thanks for the explanation. So I take it that the > maximum amount of memory is allocated to each thread whether > it needs it or not and that's all it gets whether it needs > more or not. Wouldn't this be the opposite of how Windows > works-- where each process is only given what it needs at > first, but a process can ask for more memory from the OS? A fixed amount of memory is allocated to all Java threads. There's no maximum or minimum per thread. The same is basically true in Windows: http://msdn2.microsoft.com/en-us/library/ms686774.aspx While Windows programs can ask the OS for more memory, that's heap memory, not stack. > So, if I allow for 15 concurrent threads to execute, then I > would need for the heap size to be at least 15 times the > stack size? I'm sure it's more complicated than that though... No, the heap size is unrelated to the stack size. I would expect it to be significantly larger than the stack size per thread, because objects are stored in the heap. All the variables your programs create, among other things - that's all on the heap. In Java, primitive types are stored in the stack, but if I recall correctly, all CF's variables are actually Java objects. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Enterprise web applications, build robust, secure scalable apps today - Try it now ColdFusion Today ColdFusion 8 beta - Build next generation apps Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293269 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: dumpy goodness
I didn't pull that number out of thin air. I counted the errors. The proc was looping over accounting line items and concatenating their invoice codes together for display. Usually there are no more than 5 items to iterate over. Due to some poorly configured pricing setup on a test order, there were 439 items being looped over. The field holding the concatenation was a varchar(255). The average item code was 8 characters long, meaning it would have began erroring after the 32nd item leaving exactly 407 items which would have errored with "string or binary data would be truncated". So I think 400 is a pretty darn good guess. When I ran the proc in query analyzer I confirmed that was about the number of errors being returned. ~Brad === You're saying this as if you didn't just pull the number 400 out of thin air. ~| Create robust enterprise, web RIAs. Upgrade to ColdFusion 8 and integrate with Adobe Flex http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJP Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293260 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: dumpy goodness
Ahh-- thanks for the explanation. So I take it that the maximum amount of memory is allocated to each thread whether it needs it or not and that's all it gets whether it needs more or not. Wouldn't this be the opposite of how Windows works-- where each process is only given what it needs at first, but a process can ask for more memory from the OS? So, if I allow for 15 concurrent threads to execute, then I would need for the heap size to be at least 15 times the stack size? I'm sure it's more complicated than that though... ~Brad -Original Message- From: James Holmes [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 6:33 PM To: CF-Talk Subject: Re: dumpy goodness Stack is the memory each thread gets to itself out of the heap and a recursive function called many times (or a lot of other nested calls) will overflow the stack as you are seeing. Beware of increasing the stack - each thread takes this memory and if, for example, you double the stack size you will instantly double the memory requirement of your application for a given number of threads (which is fine as long as you can increase the heap size accordingly). ~| ColdFusion 8 - Build next generation apps today, with easy PDF and Ajax features - download now http://download.macromedia.com/pub/labs/coldfusion/cf8_beta_whatsnew_052907.pdf Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293259 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: dumpy goodness
> Even if I am talking about a structure nested > 400 levels deep, how big is that really? Bigger than is required by most programs, I suspect. > Heck, I could manually output a small structure > 400 times with pen and paper in less time than > half an hour. Could you also serialize/deserialize the WDDX in half an hour? That might make a mildly entertaining Youtube video. > Furthermore, call me crazy but I expect a well > coded application to be aware of its limits and > bow out gracefully rather than error. You are crazy. ColdFusion is better thought of as an application server - a glorified compiler - not an application in its own right. If it encounters an error, its job is to fail and report the error. It's your job, as an application programmer, to make your applications fail gracefully, not the compiler's job. > I assume you are _not_ referring to the heap > size? Your assumption is correct. Dave Watts, CTO, Fig Leaf Software ~| Create robust enterprise, web RIAs. Upgrade to ColdFusion 8 and integrate with Adobe Flex http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJP Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293181 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: dumpy goodness
On Nov 12, 2007 6:46 PM, Brad Wood <[EMAIL PROTECTED]> wrote: > > Naturally most everything has a limit, but I guess I would have expected > the limits of CF to not be so limited. Even if I am talking about a > structure nested 400 levels deep, how big is that really? With modern > computers and programming languages how long should it actually take to > recurse 400 levels? It ran for up to half an hour without returning > before I killed it. Heck, I could manually output a small structure 400 > times with pen and paper in less time than half an hour. Furthermore, > call me crazy but I expect a well coded application to be aware of its > limits and bow out gracefully rather than error. You're saying this as if you didn't just pull the number 400 out of thin air. Do you actually have any idea how large the variable you were attempting to dump actually was? If the error was causing infinite recursion, I would expect nothing BUT an out of memory error. What else could happen? ~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finder&productID=1522&loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293176 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: dumpy goodness
Stack is the memory each thread gets to itself out of the heap and a recursive function called many times (or a lot of other nested calls) will overflow the stack as you are seeing. Beware of increasing the stack - each thread takes this memory and if, for example, you double the stack size you will instantly double the memory requirement of your application for a given number of threads (which is fine as long as you can increase the heap size accordingly). On Nov 13, 2007 8:46 AM, Brad Wood <[EMAIL PROTECTED]> wrote: > > There are always limits. Why should this be any different? > > Naturally most everything has a limit, but I guess I would have expected > the limits of CF to not be so limited. Even if I am talking about a > structure nested 400 levels deep, how big is that really? With modern > computers and programming languages how long should it actually take to > recurse 400 levels? It ran for up to half an hour without returning > before I killed it. Heck, I could manually output a small structure 400 > times with pen and paper in less time than half an hour. Furthermore, > call me crazy but I expect a well coded application to be aware of its > limits and bow out gracefully rather than error. > > > I would guess that, like most other memory allocation in Java, you can > probably increase the stack size in jvm.config. > > Hmmm, that's an interesting idea to play with. I assume you are _not_ > referring to the heap size? > > ~Brad > > ~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finder&productID=1522&loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293175 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: dumpy goodness
> There are always limits. Why should this be any different? Naturally most everything has a limit, but I guess I would have expected the limits of CF to not be so limited. Even if I am talking about a structure nested 400 levels deep, how big is that really? With modern computers and programming languages how long should it actually take to recurse 400 levels? It ran for up to half an hour without returning before I killed it. Heck, I could manually output a small structure 400 times with pen and paper in less time than half an hour. Furthermore, call me crazy but I expect a well coded application to be aware of its limits and bow out gracefully rather than error. > I would guess that, like most other memory allocation in Java, you can probably increase the stack size in jvm.config. Hmmm, that's an interesting idea to play with. I assume you are _not_ referring to the heap size? ~Brad ~| ColdFusion 8 - Build next generation apps today, with easy PDF and Ajax features - download now http://download.macromedia.com/pub/labs/coldfusion/cf8_beta_whatsnew_052907.pdf Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293171 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: dumpy goodness
Brad, Regarding WDDX I have some (admittedly hazy) recollection as to its origin and development that I gained from using it to port stock quotes from CF to Java, ASP, Perl and PHP. Here's what I remember - but take it with a grain of salt since I'm pulling this out of my a...erear. WDDX is a pretty old standard going all the way back to CF 4. It was originally developed by the Allaire guy (an fellow who's name escapes me - I had great difficulty pronouncing it anyway:) who was responsible for most of the CF original engine. He used it in an ingenious fashion to marshal data back and forth between various internal modules of CF and decided it should be exposed externally so he implemented CFWDDX. Since it's original intent was superseded by advances in serialization I suspect that it is not longer used like that internal. It has not changed a great deal from those days. Certainly the standard is the same since the late 90s. It is a very useful and light weight way to retain objects in a flat format (exactly as you are using it) but I would not expect it to get much attention from the current development effort of CF. I suspect it's left in there as a legacy and I'm guessing that it frustrates some of the Java gurus tasked with porting the CF code from the old C++ days... It's just a guess :) Maybe Ben Forta or one of the other gurus who sometimes monitor this list can shed some lite on it or correct my foggy recollection. I like what you are doing with WDDX and I get the idea - I just think that WDDX itself might be a weak link in the chain. Having said that - the case you mentioned where an SP is throwing multiple nested errors certainly must be an exception. In most cases I think it would work quite well. -Mark -Original Message- From: Brad Wood [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 2:20 PM To: CF-Talk Subject: RE: dumpy goodness > My guess would be that the SQL code behind the error is quite large That much did turn out to be true. > pushes WDDX beyond it's buffer limit. In the old days you couldn't build a > packet bigger than 64k (or something like that). That sort of makes sense (but not really-- I would have expected more from CF than that). That wouldn't explain why dumping it gave me a 500 NULL unless it was SUUPER huge. I've dumped some meaty result sets before without trouble. I guess the different was how far it was nested-- several hundred levels deep. The individual structs weren't too big probably-- just deep. > Out of curiosity - what is the purpose of serializing the cfcatch object? Like I said-- for error logging. We have a pretty cool system of CFC's for logging errors as well as other processes in our system. We log Java errors (from our Java team's apps), CF errors, and JS errors (via JavaScript try catches that call an error logging web service). We capture who did it, when they did it, what server they were on, what version of browser they were using, the full cfcatch object (or JavaScript error object), the form and url scope and a couple of other things. A scheduled job E-mails out all of our application's errors every 15 minutes to a group of people to monitor them and put in bug fixes if necessary. That way we can report on who is getting errors, what they are, and when. Since cfcatch is a complex object, it needs to be serialized for storage in the database. ~Brad ~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finder&productID=1522&loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293169 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: dumpy goodness
> I'm just left with the question of-- Why couldn't CF handle > it? Is there a limit to how deep structures can be nested? > I'm still inclined to think that the > "java.lang.StackOverflowError" is more of a bug. Yes, yes-- > had better SQL error handling been in place, my errors > wouldn't have been so > large-- but who's to say I won't run into this again and have > a good reason for it? > > Thoughts? There are always limits. Why should this be any different? I would guess that, like most other memory allocation in Java, you can probably increase the stack size in jvm.config. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Enterprise web applications, build robust, secure scalable apps today - Try it now ColdFusion Today ColdFusion 8 beta - Build next generation apps Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293168 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: dumpy goodness
> My guess would be that the SQL code behind the error is quite large That much did turn out to be true. > pushes WDDX beyond it's buffer limit. In the old days you couldn't build a > packet bigger than 64k (or something like that). That sort of makes sense (but not really-- I would have expected more from CF than that). That wouldn't explain why dumping it gave me a 500 NULL unless it was SUUPER huge. I've dumped some meaty result sets before without trouble. I guess the different was how far it was nested-- several hundred levels deep. The individual structs weren't too big probably-- just deep. > Out of curiosity - what is the purpose of serializing the cfcatch object? Like I said-- for error logging. We have a pretty cool system of CFC's for logging errors as well as other processes in our system. We log Java errors (from our Java team's apps), CF errors, and JS errors (via JavaScript try catches that call an error logging web service). We capture who did it, when they did it, what server they were on, what version of browser they were using, the full cfcatch object (or JavaScript error object), the form and url scope and a couple of other things. A scheduled job E-mails out all of our application's errors every 15 minutes to a group of people to monitor them and put in bug fixes if necessary. That way we can report on who is getting errors, what they are, and when. Since cfcatch is a complex object, it needs to be serialized for storage in the database. ~Brad ~| Get involved in the latest ColdFusion discussions, product development sharing, and articles on the Adobe Labs wiki. http://labs/adobe.com/wiki/index.php/ColdFusion_8 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293149 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: dumpy goodness
My guess would be that the SQL code behind the error is quite large and pushes WDDX beyond it's buffer limit. In the old days you couldn't build a packet bigger than 64k (or something like that). I'm not sure if that is still a limitation but I suspect it is. Try dumping each of the individual cfcatch keys instead (cfcatch.type, cfcatch.message, cfcatch.detail etc). Out of curiosity - what is the purpose of serializing the cfcatch object? -Mark -Original Message- From: Brad Wood [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 11:45 AM To: CF-Talk Subject: dumpy goodness Something a little weird this morning. We use Fusebox and have a site-wide error handler which takes the cfcatch object, wddx's it and logs it to our database. This usually only takes a second or two to process. This morning SeeFusion E-mailed me about some long running requests. I looked into it and a user kept refreshing a page which was calling an erroring stored proc-- "string or binary data would be truncated". No biggie- we get that error often if some lazy SQL programmer doesn't check the column sizes of his temp tables. This was the weird thing though-the pages would run for up to half an hour processing this line of code: And when I tried to E-mail myself the cfcatch object by dropping a cfdump into a cfmail, I would immediately get a "500 NULL" reply. I've only gotten those when trying to serialize incredibly huge structures. My guess is, the cfcatch object is hideously huge-but how? Why?" Since when? Since I can't look at it, I don't know what's in it. I can cfloop over it as a collection and output the key names, but I think I have some sort of endless nesting which would take a recursive function to get at and would probably error just like the cfdump did. Funny thing is-memory usage isn't high at all. Not even remotely. A quick look at my server.log file showed this error: java.lang.StackOverflowError Ok, go figure. A glance at the SeeFusion stack trace showed this: The top of the trace said this: "jrpp-94" runnable - locked <283> (a sun.misc.Launcher$ExtClassLoader) - locked <284> (a sun.misc.Launcher$AppClassLoader) - locked <272> (a java.lang.Class) at java.lang.ClassLoader.loadClass(ClassLoader.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:282) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.beans.Introspector.instantiate(Introspector.java:1466) at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:406) at java.beans.Introspector.(Introspector.java:355) at java.beans.Introspector.getBeanInfo(Introspector.java:220) at java.beans.Introspector.getBeanInfo(Introspector.java:206) at coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:48) at coldfusion.wddx.WddxOutputStream.writeObject(WddxOutputStream.java:310) at coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:40) and was followed by *800* lines this: at coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:120) at coldfusion.wddx.WddxOutputStream.writeObject(WddxOutputStream.java:310) Any ideas on how I can determine what is causing an error detail structure so large it can't be serialized, or dumped without a stack overflow? Is that a bug in CF? How come this has never happened before that I have ever seen until today? I can reproduce it on more than one server. ~Brad ~| Get involved in the latest ColdFusion discussions, product development sharing, and articles on the Adobe Labs wiki. http://labs/adobe.com/wiki/index.php/ColdFusion_8 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293142 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: dumpy goodness
You probably have some kind of nested circular reference in what is being dumped, which essentially will generate an infinite loop. On Nov 12, 2007 12:45 PM, Brad Wood <[EMAIL PROTECTED]> wrote: > Something a little weird this morning. We use Fusebox and have a > site-wide error handler which takes the cfcatch object, wddx's it and > logs it to our database. This usually only takes a second or two to > process. > > > > This morning SeeFusion E-mailed me about some long running requests. I > looked into it and a user kept refreshing a page which was calling an > erroring stored proc-- "string or binary data would be truncated". No > biggie- we get that error often if some lazy SQL programmer doesn't > check the column sizes of his temp tables. > > > > This was the weird thing though-the pages would run for up to half an > hour processing this line of code: > > > > > > > > And when I tried to E-mail myself the cfcatch object by dropping a > cfdump into a cfmail, I would immediately get a "500 NULL" reply. > > I've only gotten those when trying to serialize incredibly huge > structures. My guess is, the cfcatch object is hideously huge-but how? > Why?" Since when? > > > > Since I can't look at it, I don't know what's in it. I can cfloop over > it as a collection and output the key names, but I think I have some > sort of endless nesting which would take a recursive function to get at > and would probably error just like the cfdump did. Funny thing > is-memory usage isn't high at all. Not even remotely. > > > > A quick look at my server.log file showed this error: > > > > java.lang.StackOverflowError > > > > Ok, go figure. A glance at the SeeFusion stack trace showed this: > > > > The top of the trace said this: > > > > "jrpp-94" runnable > >- locked <283> (a sun.misc.Launcher$ExtClassLoader) > >- locked <284> (a sun.misc.Launcher$AppClassLoader) > >- locked <272> (a java.lang.Class) > >at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > >at java.lang.ClassLoader.loadClass(ClassLoader.java:282) > >at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) > >at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > >at java.beans.Introspector.instantiate(Introspector.java:1466) > >at > java.beans.Introspector.findExplicitBeanInfo(Introspector.java:406) > >at java.beans.Introspector.(Introspector.java:355) > >at java.beans.Introspector.getBeanInfo(Introspector.java:220) > >at java.beans.Introspector.getBeanInfo(Introspector.java:206) > >at > coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:48) > >at > coldfusion.wddx.WddxOutputStream.writeObject(WddxOutputStream.java:310) > >at > coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:40) > > > > and was followed by *800* lines this: > > > >at > coldfusion.wddx.BeanSerializer.writeObject(BeanSerializer.java:120) > >at > coldfusion.wddx.WddxOutputStream.writeObject(WddxOutputStream.java:310) > > > > Any ideas on how I can determine what is causing an error detail > structure so large it can't be serialized, or dumped without a stack > overflow? Is that a bug in CF? > > How come this has never happened before that I have ever seen until > today? I can reproduce it on more than one server. > > > > ~Brad > > > > ~| Enterprise web applications, build robust, secure scalable apps today - Try it now ColdFusion Today ColdFusion 8 beta - Build next generation apps Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293137 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: dumpy goodness
Update on this. I ran the proc which was erroring in query analyzer and found there was not just one "string or binary data would be truncated" error-- There was several HUNDRED nested errors being returned. Looks like some bad data on this order (in large amounts) and lack of SQL try/catches (proc was originally developed in SQL Server 2000) was causing a loop to create that error over and over again. So, I guess this clears up why my error object was so big. I'm just left with the question of-- Why couldn't CF handle it? Is there a limit to how deep structures can be nested? I'm still inclined to think that the "java.lang.StackOverflowError" is more of a bug. Yes, yes-- had better SQL error handling been in place, my errors wouldn't have been so large-- but who's to say I won't run into this again and have a good reason for it? Thoughts? CFMX 7.0.2 Standard Linux. ~Brad -Original Message- From: Brad Wood [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 11:45 AM To: CF-Talk Subject: dumpy goodness Something a little weird this morning. We use Fusebox and have a site-wide error handler which takes the cfcatch object, wddx's it and logs it to our database. This usually only takes a second or two to process. ~| Get the answers you are looking for on the ColdFusion Labs Forum direct from active programmers and developers. http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid-72&catid=648 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293135 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
