Author: Bilal Soylu

Since the beginning of computing there has been the struggle between available resources and the number of computing tasks to run on them. When we had 16KB of RAM our code looked very compact and we were critical of any extra bytes that we stored or computing cycles we ran.

When, today, we easily reach 16GB of RAM the level of individual byte analysis does not quite happen. More likely than not, we tend to worry less about do we have enough memory to run this operation and assume (to our chagrin) that things will work themselves out,… right until they don’t.

Which brings me to the problem at hand. Rather than running a process, thread, task and hoping things work, can we predictably make that decision instead?

In my case, this being ColdFusion I needed to find out whether I had a snowballs change in the Hot-Place to open an Excel file. Remember that ColdFusion uses the Apache POI library to read Microsoft Office documents. Works normally fairly transparently but the downfall here (it is documented as well, see POI docs) is that POI will grab big chunks of memory for processing any access to, say, a spreadsheet.

This, if not managed, gets us into an unconfortable situation of crashing the server with OutOfMemroy exceptions. Yep, not good.

So our solution was first determine a common estimation factor (spreadsheet size to JVM memory size), then use it to see whether we would have a chance of opening / loading this spreadsheet at all given the current memory envelope on the server.

Nice message to user if we had no chance, go ahead and process otherwise.

This eliminates unneccesary server crashes. Which is, indeed, a very good thing.

Here is the code snippet we used to determine available CF server memory:

The value here will have to be compared against the expected value of memory use for your operation. For example, if you expect your spreadsheet to occupy 100MB memory while loaded into JVM and want to have a margin on 50MB, you can only proceed with the operation if the return of the above function is a value of 150 or greater.

Cheers,

B.

One of the things I have always liked with working in ColdFusion is the ability to derive detailed debugging information. You get a good idea of what is going behind the covers and do have a good basis to hunt down bugs.
Unfortunatly, this all breaks down when you start to do any kind of remoting (invoking CFCs from another technology). Currently, this is for Flex and SOAP (Webservices) type calls. If anything goes haywire, or the calls themselves are complex, e.g. call on many other components and tags you fly in the dark more often then not.
The common response to this kind of issue from peers is to use the line debugger, set breakpoints etc. and this does work to a certain degree.
However, where I get a little agitated is that most of the time when problems occur you are nowhere near a line-debugger or IDE to capture the processing.
For standard .cfm pages I can use the Silent Debugger option.
So I was wondering if I could build something similar that worked with CFCs and remoting. I would add this to the Application.cfc and, bingo, I could capture the debugging output to file. Alas, many hours later I had nothing workable. To make a long story short it does not look like there is a way to capture cfc debug output, because no debugging session is seems running.

Unfortunatly, it looks like the auto-wiring that ColdFusion performs makes the decision not to initialize / start a degugging session in the ServiceFactory (coldfusion.server.ServiceFactory).
Thus the call for factory.getDebuggingService() will fail and my attempts to manualy start the debugging service failed for lack of insight into how CF actually does this (what classes and method in what order).
So I was back to square one.
After a little more thinking and tinkering I decided to go for the workaround solution. This happens to be practical enough for me as my remoted cfcs are only stubs, so not much functionality is implemented there.
I have several stub types and, thus, decided to rewrite the call from SOAP / FLEX remoted calls to HTTP Post (REST) calls.

So in the remoted call I would just turnaround and call the REST gateway if I detected that we were trying to debug stuff using the IsDebugMode() function.

This would allow me to use the Silent Debugging option and capture the debug output to file even for calls coming from SOAP and FLEX remoting. I would also need to translate the reponse back correctly for FLEX and SOAP clients to consume.

All this is more overhead but not drastically so, while allowing me to trace errors while they occur even for remoted CFCs. I can access this information afterwards for analysis.

Overall, I am disapointed that I was not able to hook into native CF processes to expose debugging results. Maybe in future iterations this will be possible. However, being able to get this insight is invaluable to me.

Feel free to experiment.

Cheers,
B.

Meant to provide feedback on the cfObjective conference in Mineapolis, MN.
The conference goes by the tagline of
“The Only Enterprise ColdFusion Conference”. Unfortunatly, this may be very true.
Anyways, here is the skinny as I see it (fully my opinion):

Even though this is the biggest CF conference that still is around, I was still disappointed by how small the crowd was. No knock on this conference as it comparitively has grown from last year, but with the demise of cfUnited, I was expecting a larger crowd to carry over to this one.

Conversations with fellow conference attendees lead to the insight that instead of one big conference there are many smaller regional ones that focus on this topic.
If this is the trend, the obvious question would be how CF is CF going to survive? Will many small conferences attract developers by the truck load or will they stay away? Adobe did not sponsor, I hear lots of politics involved. Not a good image if you are trying to convince new people to pick up CF and grow the community.

The location was OK. Downtown Minneapolis is not hot but you can make it work. Weather was a bummer (pretty nippy). The food was good, lunch was better than breakfast.

The presentations followed a similar pattern to cfUnited, the same people are doing the presenting. The quality was just a notch above what was available at cfUnited. I am personally getting a little tired of the same presenters, I think the community needs some fresh blood. Only so many times I can hear an extreme opinion presented as fact ;o)
Overall, still something I will attend, but maybe shorten the time for next year. Do only two days rather than three. The last day was just a rush to get out.

There you have it. Catching up on writing.
B.

If you run into this with ColdFusion, it probably will appear to come out of no-where.
One day everything will work fine and, the next, without any change you can think of, you see your site stop to respond.
Upon digging into the exception.log file you see something like this:

“Error”,”jrpp-0″,”04/20/10″,”17:33:53″,,”” The specific sequence of files included or processed is: C:\Webroot\Test4\TestFile.cfm” “
java.lang.StackOverflowError
at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2263)

This for me occurred when serializing/de-serializing data. But anytime you run into this you have to ask yourself one primary question.
Did this happen because of my logic? If yes, go revise your logic first.
If you are certain your stuff is solid, you need to increase the Stack Size by providing the -Xss directive to the jvm upon ColdFusion startup.

I would bump it four fold; while the default seems to be slightly different based on OS, it is normally in the 300-400kb range.

I bumped mine up first to 10MB, then, reduced it to find out exactly what was workable.

The -Xss argument can be specified in kb e.g. -Xss512k or in mb, e.g. -Xss1m.

here is an image with configured jvm:

Cheers,
B.