For those seeking employment in the Eastern Massachusetts area, there is a job opening for an Escalation Coldfusion Product Support Engineer, described as:

We are looking for a member of the ColdFusion Technical Support team to function as a Tier 3 (escalation) engineer. This is a senior-level technical position and the support delivered in this role is in English only. The product set being supported is associated with internet web applications. Client Server offerings include ColdFusion and JRun. ColdFusion is a HTML Tag based, proprietary server that works with databases and delivers dynamic contact to browser based users. JRun is a J2EE application server that runs applications based on industry standard JSP pages and/or Servlets. Other related technical skills include: Web Services, Java Literacy, dbms and SQL knowledge, LDAP, and general web application development and deployment.

The job posting is on Dice.com through a third party recruiter, although I'm not sure why its not listed on the Macromedia.com website. I was once in this escalation role for a year before I moved to "Gold" Support, and its definitely challenging. Are you up to it?

Please defer salary inquiries for the recruiter.

This entry was posted on November 29, 2005 at 7:31 AM and has received 26444 views. There are currently 0 comments.
Print this entry.

The ColdFusion MX error message "Request timed out waiting for an available thread to run" occurs specifically when a thread in the queued request pool times out while still in the queue, before it ever had a chance to make it to the running request pool. This blog entry revisits a topic previously blogged about here.

An example of the Java stack trace for the exception might look like this at the top:

ColdFISH is developed by Jason Delmore. Source code and license information available at coldfish.riaforge.orgjava.lang.RuntimeException: Request timed out waiting for an available thread to run. You may want to consider increasing the number of active threads in the thread pool. at jrunx.scheduler.ThreadPool$Throttle.enter(ThreadPool.java:116) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:425) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)1java.lang.RuntimeException: Request timed out waiting for an available thread to run. You may want to consider increasing the number of active threads in the thread pool.2 at jrunx.scheduler.ThreadPool$Throttle.enter(ThreadPool.java:116)3 at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:425)4 at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

The helpful hint provided in the exception message suggests increasing the active thread pool size, which would correspond to the Simultaneous Requests setting in the ColdFusion Administrator. While that might be a short term band-aid to the problem, in most cases this will simply delay the onset of the symptoms rather than truely solve the problem.

To back up for a moment, I'll take a look at some of the settings in the JRun server's jrun.xml configuration file, found in the SERVER-INF directory for a given server instance. The threadWaitTimeout setting in jrun.xml controls how long a thread
will wait in the queued request pool. The activeHandlerThreads setting is the same as the Simultaneous Requests setting in the CFAdmin, and this setting is the maximum size of the running request pool, or the maximum of how many actual requests could be actively processed at any given moment. The maxHandlerThreads is the maximum total thread limit as a sum of the running request pool size (activeHandlerThreads) plus the maximum allowed queued threads (which can be restated at the maxiumum number of queued threads is equal to maxHandlerThreads - activeHandlerThreads).

If you're getting this error, then the problem is most likely bottleneck requests that are shifting the throughput rate downward so that more threads are added to the queued request pool than can be reasonably processed by the running request pool. It's not necessary that the running request pool is completely occupied with bottleneck threads, but just enough of them to cause a noticeable increase in current number of threads in the queued request pool. This doesn't necessarily mean that the queued request pool has reached its maximum size, but just that the threads in the queued pool weren't getting a chance to run within the threadWaitTimeout period.

To better diagnose the problem, try to find out what's in the running request pool. I recommend taking a series of three thread dumps about 15-30 seconds apart at the time this error is being reported, and then looking for differences between the running threads across the span of the three thread dumps to identify any that might be 'stuck' on something. The running threads are usually identifiable by having a 'jrpp-' to the thread id number and a reference to one of your application templates in the stack such as those with a .cfm or .cfc extension.

Well known contributor to the ColdFusion community of developers, Dave Carabetta has just set up his own blog. One of the first things Dave wants to know is what brought you to ColdFusion or to web development in general? I met Dave last summer at CFUNITED in Maryland, where I learned that both of us arrived at ColdFusion after having studied or worked in the biological/medical sciences, although I already met him online through his interest in J2EE clustering for ColdFusion.

Welcome Dave!

This entry was posted on November 27, 2005 at 4:14 PM and has received 26091 views. There are currently 0 comments.
Print this entry.

The wsconfig utility that installs the webserver connector for ColdFusion MX tries to establish TCP connections to the JRun server on two ports for the installation process, the JNDI port and the RMI port. Here's how to control both.

First it will scan the port range 2900 - 3000 to find out whats listening, then it will begin to connect to each active port discovered in that range starting at 2900. The target port is referred to as the JNDI port that the JRun server listens on. A server's JNDI port is defined in jndi.properties such as with the following settingjava.naming.provider.url=localhost:2920

Second, upon successful communication with the JRun server on the JNDI port, the JRun server will instruct wsconfig to complete the second half of the communication on the RMI port. By default, this is a high *random* port. So this is where most Linux folks running a firewall go wrong. They allow for the JNDI port but don't know about the high random port for RMI.

All over the local business news, Cambridge Massachusetts company Brightcove, whose founder Jeremy Allaire is best known as the inventor of the ColdFusion application server, landed a $16M investment from AOL and Hearst Corporation. Brightcove plans to begin streaming television programs and video over the Internet next year.

I saw a recent post that expressed concern that a XMLSearch bug in ColdFusion MX 6/7 still has not been fixed in ColdFusion MX 7.01. I think its just a misunderstanding about how to reference namespaces, specifically the no-name namespace, and in fact there is no such bug.

To back up, I learned about this special case from a blog entry by Pete Freitag where Sean Corfield proposed the solution in the comments, so my blog entry here is just a reiteration of that solution.

Ok, final post for today. This one is also a follow up to a demonstration made by the instructor in my DB Design class that was intended to stress the importance of users setting Read permission on for Other on a common Linux server used by the class. Reposting here for benefit of those not on the internal class forum.

--

In last night's class Maria demonstrated the importance of having the read bit turned on for Other for your ColdFusion cfm files.

Initially she removed the read bit for Other and then refreshed the browser while expecting to demonstrate an error that she wants to protect you from. Instead the page worked as normal? So what happened?

Here's another post I made to the internal forum for my class on Database Design where I describe how requests are handled by ColdFusion and how the webserver connector works in general. Reposting here in case anyone finds it useful.

--

A question was asked in yesterday's class regarding the difference between making requests to the Apache port versus the ColdFusion port.

Effectively, the answer is that there is no difference for the purpose of this class.

ColdFusion MX has a built-in webserver that can be used in lieu of an external, production-quality webserver like Apache, Iplanet, or IIS. The default for this built-in webserver is port 8500, 8501, or 8300 depending on the type of installation and CF version, and that port is configurable.

In my Database Design class last night, the use of ColdFusion was introduced to the other students, and I posted the following message on the internal forum. I'm reposting here in case it helps anyone else new to ColdFusion.

--

Just to clarify the use of CFOUTPUT in the 11/15 class...

There were two examples of CFOUTPUT operating on a query result set in the handout.

In the earlier example it was demonstrated that a query which returned only one row could be output by nesting references to the queryname.column inside a CFOUTPUT tag. When CFOUTPUT is used without any attributes in the opening tag its behavior is to just evaluate ColdFusion variables to their values that are between it and the closing CFOUTPUT tag. So I could perform a simple addition such as [CFSET sum = 1 + 2> followed by [CFOUTPUT>#sum#[/CFOUTPUT> and the resulting output would be 3. This output gets added to the generated content buffer for the HTTP Response and eventually gets sent back to the browser for display.

I found the use of a scaleFactor variable very helpful in trying obtain an even distribution of tag sizes for a widely varying tag count. See the pod's inline comments about scaleFactor. You can also adjust which tags qualify for the tag cloud by the WHERE clause of the query. In the example below, I only select categories having more 10 or more posts.