ASToperator error

I recently installed a developer version of CF9 along with the 9.0.1 update.  I noticed several things that didn't quite work right.  For instance in the CF administrator area I went to look at the log files and it bombed.  On the public side I loaded up a site for a recent gig I'm working on and got the following error:

Unable to find an operator implementation for coldfusion.compiler.ASToperator

I didn't find too much in the blog world on this error.  I did find some things on the error message that I got when trying to look at the log files.  There was a bug recorded on the Adobe site.  The work around was to reinstall CF and reapply the update.  After proceeding with that, which only took a few minutes, all was right with the world again.  All errors disappeared.

Moral of the story?  Maybe the update didn't install properly.  I do remember getting an error message saying that the update didn't complete and that next time I should remember to shut down the CF services before applying the update.  That could have been it.  Either way... it works now.

ActiveMQ: Channel your energy

I started noticing an error when trying to fill my queue with a large number of messages. The error was the following: Channel was inactive for too long. This would happen anywhere from one minute after the producer and channel were created to as long as ten minutes. It wasn't all that consistent. After doing a little research, I found a solution to turn off the inactivity check.

<cfscript>
connectionFactory = createobject(
'java','org.apache.activemq.ActiveMQConnectionFactory'
).init(
  '',
  '',
  'tcp://{host}:{port}
         ?jms.useAsyncSend=true
         &wireFormat.maxInactivityDuration=0'
  );
connection = connectionFactory.createConnection();
connection.start();

....

</cfscript>

By appending &wireFormat.maxInactivityDuration=0, it will turn off the inactivity check for the channel. You should also do this on the AMQ server side by doing the following in your ActiveMQ.xml:

<transportConnectors>
<transportConnector name="openwire"
uri="tcp://{host}:{port}/?wireFormat.maxInactivityDuration=0"
discoveryUri="multicast://default"/>

...

</transportConnectors>

If you are experiencing issues like this with your CF ActiveMQ gateways, you could likely add this to your gateway config file. However, I have yet to see this error in connection with the CF ActiveMQ gateway. For more info on connecting directly to ActiveMQ, see my post Straight talk with ActiveMQ.

ActiveMQ: Ghost consumers just in time for Halloween

I have been noticing some issues with the communication between ActiveMQ and Coldfusion the higher our load gets. We've got a large process that can cause a java heap space error in the environment. If that happens when there is a coldfusion gateway consuming messages, it can cause the current consumer to go into ghost mode and a new consumer is created. If this is allowed to persist, the communication between ActiveMQ and Coldfusion sometimes comes to a screeching halt. The only way we have found to remedy this battle of digital wills is to restart the Coldfusion service. This seems to properly reset the connections and things return to normal.

So, what is causing this behavior? It's a question I wrestled with for a few weeks. I could not replicate this in my local environment at all. It helped to get jconsole fired up so that I could see a little bit of what was going on behind the scenes beyond what the ActiveMQ web console shows. One thing I noticed with the actual filling of the queue is that if the MemoryLimit is not set high enough, the MemoryPercentUsage will be maxed at 100% and you can only put so many messages in the queue. A new message can only get added if one in the queue got consumed. This can be a really long Coldfusion task if you are max'd at 4000 messages and you have to fill it with 500,000. With jconsole you can edit some of the limits on the fly for the queue.



The queue size at the time was 5m. I started bumping it up to see what effect it would have. I went to 10m and the queue doubled in size, but still wasn't where I wanted it. I bumped it to 20m and wooosh, the queue filled with all 500,000 messages. There seems to be some threshold that needs to be hit in order for it to hold that many messages. With 500,000 messages in the queue, the MemoryPercentUsage is only at 43% or so. I'm sure an ActiveMQ guru could explain what is going on there. If you know, please leave a comment. Now rather than the Coldfusion process taking 12 hrs to fill the queue, it fills in 10 minutes.

So, let's make this MemoryLimit change permanent. Open up your activemx.xml in your /conf directory and adjust as needed:

<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry queue=">" memoryLimit="20mb"/>

I think the default memory limit for ActiveMQ off the shelf is 5m. If you are doing a higher quantity of messages over 5000, it seems that you will have to bump this number up.

Now the cool thing about this is that our hanging consumer issue has disappeared. This was an unexpected benefit. I decided to test it on my local environment by dropping the MemoryLimit down to 48k. This allowed a max of 42 messages in the queue. I then wrote the following code to create a java heap space error:

<cffunction name="javaheapspace" output="false" access="public" returntype="void">
   <cfset var myxml =  ''/>
<cfset var parsedxml =  ''/>
<cfset var i = 0 />
<cfset var j = 0 />  

<cfsavecontent variable="myxml">
   <rootnode>
   <cfloop from="1" to ="299999" index="i">
        <subnode> 
             <textinfo>with text in here</textinfo>
                  <mynumber>#i#</mynumber>
        </subnode>
   </cfloop>
   </rootnode>
</cfsavecontent>
<cfset parsedxml = xmlparse(myxml) /> 
</cffunction>

The loop count may have to be moved up or down depending on the amount of memory you have allocated to your JVM. I think mine is up around 512m. I wanted it just small enough to be able to finish the myxml variable creation and just big enough to die in the parse.

So in order to replicate this issue, I put in motion the process that would begin filling the queue and make sure the consumption begins. With jconsole open, I watched the MemoryPercentageUsage and waited until it hit 100%. Then I fired off the javaheapspace() call in another script. Once it bombed, I refreshed my jconsole view and, sure enough, the consumer count went from 1 to 2.



It doesn't work every time so you may have to try a few times. The more time it sits at 100% usage, the better your chances. I went into CFAdmin and shut off the gateway that was my consumer and the count went down to one. So it left a connection that cannot be managed. In fact if you try to kill that connection through jconsole, it will create another one it its place. The only way to kill it that I have found, is to restart the CF instance.

So the moral of the story is to keep your queue's MemoryLimit high enough so that your MemoryPercentUsage does not reach 100%. Otherwise you may be haunted by the "ghost of consumer past"

Blessings,
Terry

JConsole has consoled me

A long and hard battle was fought tonight and finally victory is mine! I set out to get a little further down the road of my understanding of ActiveMQ. I have read all over the place that you can monitor AMQ with jconsole. It should be so easy right?
Type jconsole at the command prompt and slap service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi in the remote process box and whamo.

Well "no soup for me". In the words of the Pirates who don't do anything, "nothing, zilch, nodda". At first I was getting a connection timeout and would get absolutely nowhere. After a flurry of changes, it would actually connect but I didn't see the org.apache.activeMQ in the list on the left.

I was looking through my activemq.xml in my conf directory and noticed this:

<managementcontext>
<managementcontext createconnector="false">
</managementcontext>

Ok... lets turn that puppy on. Now I start seeing this in the startup output of ActiveMQ:

WARNING: Failed to start jmx connector:
Cannot bind to URL[rmi://localhost:1099/jmxrmi]
:javax.naming.NameAlreadyBoundException:
jmxrmi [Rootexception is
 java.rmi.AlreadyBoundException: jmxrmi]   

So... at least I saw something remotely familiar to me that is supposed to go in the Remote Process box. But it seems that something else is on that port. I started thinking about what else on my system might be using jmx. I am running Apache Solr. Let's shut that down and see if it starts up. Nope. Nodda. Oh wait, how about Jrun. There was coldfusion and jrun stuff in the left pane of jconsole. After I shut down jrun and restarted ActiveMQ, finally it magically appeared. A thing of beauty.

INFO  ManagementContext - JMX consoles can connect
to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi

Now we still have an issue. Obviously if I'm going to be using coldfusion and ActiveMQ together, they need to learn to get along. All we have to do is add an attribute to the managementContext node in conf/activemq.xml:

<managementcontext>
<managementcontext createconnector="true" connectorport="1199">
</managementcontext>

Now restart ActiveMQ and start coldfusion back up and you should be able to view ActiveMQ behind the scenes through jconsole. Now were cookin with gas.

Ultimately I'd like to be able to connect to JMX via java in CF to get things like queue count and connection status. We've been seeing some strangeness when CF dies due to java heap space errors that CF and AMQ will just stop talking to each other after the instance comes back up. If I cycle the CF instance, then consumer counts go back to normal and they start talking again. Communication is key to any good relationship, especially when clients are riding on it.

Speaking of communication, how has your's been with Jesus? Your eternity is riding on it.

Blessings,
Terry

CFCatch me if you can

One thing that really annoys me with the cfcatch struct/object (or whatever its pretending to be) is trying to use one of the keys and have it not exist. There have been a few times where I simply want to log cfcatch.detail and it's undefined, throwing a hard error. To me, if it's documented that it is going to be available, it should at least be available as an empty string. I set out this morning looking for a clean way of param'ing some of the keys in cfcatch. Since it doesn't seem to be a true struct, you can't simply do:

<cfparam name="cfcatch.detail" default="" />

That would be way too easy. I found a couple places that suggested using duplicate() to make it act like a struct. I tried that too, and you still can't do a cfparam on it. The key simply won't exist.

After much googling, I came across this post by Isaac Dealey. So using that idea, I created the following function:

<cffunction name="structifyCatch" returntype="struct">
   <cfargument name="catch" type="any" required="true"/>

   <cfset var err = structnew() /> 
   <cfset structappend(err,arguments.catch,true) />

   <cfreturn err />

  </cffunction>

then to implement it, you call the following:

<cftry>
   ... some code ...
   <cfcatch>
     <cfset cfcatch = structifyCatch(cfcatch) />
     <cfparam name="cfcatch.message" default=""/>
     <cfparam name="cfcatch.detail" default=""/>
     <cflog text="There was an error in somecode().
        Message: #cfcatch.message# Detail: #cfcatch.Detail#"
       application="yes">
   </cfcatch>
 </cftry>

Hopefully this will save you a little bit of angst.
There are some interesting behaviors documented here too:
cfcatch was born a struct, then it wasn’t but now it’s back

Blessings,
Terry

Straight talk with ActiveMQ

I found that filling an ActiveMQ queue through a cfml gateway was extremely inefficient when sending a large number of messages at once. Here is the code to send messages directly to the queue via java. This was a little difficult to find this documented anywhere. I had to pull in bits an pieces from different code examples.

<cfset mess = structnew() />

<cfquery name="rs" datasource="dsn">
select id from mytable
</cfquery>

<cfscript>
 connectionFactory = createobject(
           'java'
           ,'org.apache.activemq.ActiveMQConnectionFactory'
 ).init('','', 'tcp://#amqServer#:#amqPort#?jms.useAsyncSend=true');

 connection = connectionFactory.createConnection();
 connection.start();
 // createSession(transacted, session.auto_acknowledge)
 javasession = connection.createSession(false, 1);
 destination = javasession.createQueue("queuename");
 producer = javasession.createProducer(destination);
</cfscript>

<cfloop query="rs">
<cfset mess.agentid = rs.id />
 <cfwddx action="cfml2wddx" input="#mess#" output="strMess">

 <!--- Send message to activeMQ through our opened channel --->
 <cfscript>
    message = javasession.createTextMessage(strMess);
    producer.send(destination,message);
 </cfscript>
</cfloop>

<!--- close up connections with activeMQ now that we are done with the channel --->
<cfscript>
 producer.close(); 
 javasession.close();
 connection.close();
</cfscript>

Blessings,
Terry

Lost in translation: The Encoding Experience

I had written an undelivr folder viewer about a month back. We started testing some special chars through our mailing app recently and found that Programów was becoming Programów. We figured it had something to do with encoding. I checked the cfadmin setting for the default mail encoding and it was UTF-8. That should have been ok. I tried hardcoding charset="UTF-8" in the cfmail tag to see if that would help. Same results.

So then I switched gears to my local dev server and wrote up this quick script.

<cfset str ="Programów"/>
<cfmail from="a@b.com" to="a@c.com" subject="1.0" charset="utf-8">
#str#
</cfmail>

This works perfectly fine in my local dev. When I threw this script on the server it still got mangled. So now we're dealing with an environment issue. I'm running Ubuntu locally and we are running windows on the server. So I started digging into the settings in cfadmin. I took the settings summary from both servers and threw it into Kompare. One of the differences I saw right away was the Java File Encoding. On the server it was set to cp1252 and on my Linux it was UTF-8. After much searching, I was able to track down how to change the JVM's default file encoding here: Java's file.encoding property on Windows platform. After adding -Dfile.encoding=UTF-8 to the jvm's server.args (typically found in jrun4/bin/jvm.conf), I restarted the instance and re-ran the test. Bingo, the special chars were preserved.

There must be an issue with some special chars moving from UTF-8 to cp1252 or vice versa. I just ran a test and this does affect all emails if you are spooling to disk. My assumption is that under the covers, java is writing the file using the default JVM file encoding, not the default coding set for the cfmail tag. This makes the cfmail default setting a little misleading. At any rate, setting the JVM encoding to UTF-8 did the trick.

Blessings,
Terry

Hot under the hotfix..

We ran into an error today on one of our dev servers.

coldfusion.runtime.J2eeSessionScopeStub cannot
be cast to coldfusion.runtime.J2eeSessionScopeStub

We had recently patched that server with "Cumulative Hot Fix 3 for ColdFusion 8.0.1" That was really the only thing that changed with the server before getting the error. I went into JRun4\servers\{instancename}\cfusion.ear\cfusion.war\WEB-INF\cfusion\lib\updates and removed chf8010003.jar. After restarting the instance, things came up normal. I thought that maybe the file we downloaded was corrupt so I grabbed a fresh copy. That file didn't work either. The head scratcher in this is that we installed the patch on other instances with no problems. Not sure what is so unique with this instance, but it just doesn't jive with the new hotfix.

here is the stack:
18840 java.lang.ClassCastException: coldfusion.runtime.J2eeSessionScopeStub cannot be cast to coldfusion.runtime.J2eeSessionScopeStub
18841 at coldfusion.runtime.SessionTracker.getSession(SessionTracker.java:76)
18842 at coldfusion.runtime.AppHelper.setupJ2eeSessionScope(AppHelper.java:528)
18843 at coldfusion.runtime.AppHelper.setupSessionScope(AppHelper.java:592)
18844 at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:235)
18845 at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
18846 at coldfusion.filter.PathFilter.invoke(PathFilter.java:86)
18847 at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
18848 at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:74)
18849 at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
18850 at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
18851 at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
18852 at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
18853 at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
18854 at coldfusion.CfmServlet.service(CfmServlet.java:175)
18855 at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
18856 at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
18857 at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
18858 at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
18859 at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
18860 at jrun.servlet.FilterChain.service(FilterChain.java:101)
18861 at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
18862 at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
18863 at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
18864 at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
18865 at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
18866 at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
18867 at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

Eclipse Annoyance

I truely appreciate eclipse as the ide for CF development. I've had a slight annoyance with it though since recently moving to a linux dev environment. In short, everytime I did a text search.... I would get an annoying little error box popping up saying:



Looking at the details of the error... I see the following:
"resource is out of sync with the file system"

After digging around a bit on google I found that this generally occurs when a file is changed/added outside of eclipse and it has, just as the error states, become out of sync with the file system. The solution is to refresh the project so that it picks up the changed/new files. If outside processes frequently change files outside of your eclipse, you can have eclipse automatically refresh the project by going to Window > Preferences and in General > Workspace. Check the box that says "Refresh Automatically". We use the fusebox framework which compiles the code into the parsed folder. So in development mode, the parsed folder has changed/new files all the time.

Well... I made this change and it still didn't work for me. I don't know if its something unique with linux or just a bug or what, but refreshing the parsed folder and setting refresh automatically did absolutely nothing to resolve the issue.

Then I had a duh moment. For my text search, I have it search in a working set. Why don't I just exclude the parsed folder from the working set. I don't really need to look in the parsed folder anyway. Sheesh, sometimes we can make things way harder than they need to be. So... Search > File... (or Cntrl-H for me) Then on the "Working set:" line, click "Choose...". I'm working with "Selected Working Sets". I edited my working set and under the "Working set contents" area I drilled down to the parsed folder in the relavent resource and unchecked it. Bingo... no more errors.

Hope this helps...
God Bless

Coldspring stopped me cold..

We just recently upgraded to Coldspring 1.2 and it wasn't long before I came to a grinding halt the next time that I needed to restart my CF instance. I got the following error:

Object Instantiation Exception
An exception occurred when instantiating a Java object.
The class must not be an interface or an abstract class. Error: ''.

The error occurred in C:\websites\coldspring\beans\AbstractBeanFactory.cfc: line 253

Our beta system wasn't having the same issues, so I decided to look at what might be different in the two environments. I found that I was still on 8.0.0 (doh!). So I went to http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403277&sliceId=1 and upgraded.

That worked right? Wrong! Though it was good for me to get up to speed with the proper version, it did nothing in getting me back to productivity. I browsed some more on some blogs with pieces of the error message and came across a blog that seemed to think this error happend when some nulls were being thrown around when it expected actual values. I looked at this line in the loadFrameworkProperties method in Coldspring/beans/AbstractBeanFactory.cfc:

<cfset local.fileStream = CreateObject('java', 'java.io.FileInputStream').init(arguments.propertiesFile) />

... which caused me to look in the initial code or the AbstractBeanFactory.cfc file here:

<!--- ColdSpring Framework Properties --->
<cfset variables.instanceData.frameworkPropertiesFile
       = "/coldspring/frameworkProperties.properties" />
<cfset variables.instanceData.frameworkProperties
       = loadFrameworkProperties(ExpandPath(variables.instanceData.frameworkPropertiesFile)) />

So I looked for the .properties file in the /coldspring directory and found nodda. I plugged an empty file into the coldspring directory by the name of frameworkProperties.properties and I was back in business.

Hope this helps.

Blessings...

I shot the session...

I was reading across a couple of old blogs recently about the need to kill a session immediately rather than waiting for it to timeout. If you are using J2EE sessions, the session will be orphaned when the browser is closed but the session still lives on until it eventually times out according to the time set for your application. There may be a need to clear out some of those sessions when you're sure they are orphans. Maybe you have a user that is logging in from another workstation and would like to clear out the other session so that you don't have the same user logged in twice. Whatever your reason, there is a way to immediately clear out the session and still have the onSessionEnd execute in your Application.cfc. Try this little piece of code:

<!--- get the session id by working with the session tracker --->
   <cfset _sessionid =  '74306b9b10b4c354a8db101f73246434611b'/>
   <cfset  killSession(application.applicationname,_sessionid)/>
  
   <cffunction name="killSession" output="false"
         access="public" returntype="void">
       <cfargument name="appName" required="true" type="string" />
       <cfargument name="sessionid" required="true" type="string" />
     
       <cfset var st = 
        createobject("java","coldfusion.runtime.SessionTracker") />  
       <cfset st.cleanUp(arguments.appName,arguments.sessionid) />
         
   </cffunction>

If you do not have J2EE sessions enabled, you can call cleanUp(application.applicationName, _cfid, _cftoken).
Note: I haven't tested this one yet.

This will successfully remove that session. It will also execute any onSessionEnd code that you have to take care of any cleanup scripts that you have. This is an undocumented method of sessionTracker so use with caution knowing that things could change. I'm not sure if this works in versions before CF8. I would be interested in knowing, if someone would be so kind as to test it.

Blessings...

Undocumented Goodness

In working on a project the other day, I needed to allow users to interact with data in such a way that they were not tripping over each other. This led me down the path toward a proof of concept with monitoring sessions for a particular application. The problem is that when you "touch" the sessionScope methods it will reset the session timeout and keep dead sessions alive. This can be countered by calling the methods using reflection like so:

<cfset tracker=createObject("java","coldfusion.runtime.SessionTracker")>
<cfset sessions=tracker.getSessionCollection(application.applicationname)>
<cfoutput>
<cfloop item="loopSession" collection="#sessions#">
Idle Time:
#getSessionProxy(sessions[loopsession],'getTimeSinceLastAccess')#<br/>
</cfloop>
</cfoutput>

<cffunction name="getSessionProxy"
output="false" access="public" returntype="string">

<cfargument name="session" required="true" type="struct" />
<cfargument name="method" required="true" type="string" />

<cfset var _a = arrayNew(1)/>
<cfset var _sessionClass =
_a.getClass().forName("coldfusion.runtime.SessionScope") />

<cfset var _method = ''/>
<cfset var _value = ''/>
<cftry>
<cfset _method =
 _sessionClass.getMethod(arguments.method, _a) />
<cfset _value = _method.invoke(arguments.session, _a)/>
<cfcatch><!--- Do Nothing ---></cfcatch>
</cftry>
<cfreturn _value />
</cffunction>

That works great and is very valuable data, but what if you need to find out what the session.idofuser is on one of those sessions or another session variable that you need access too? There really is no reflected function that gives you access to those variables without touching the session timeout. You could do sessions[loopSession].idofuser but that would trip the session. Even a cfdump of the sessions collection trips the session. I couldn't find this documented on blogs or anywhere else, but there is a new sessionScope method going by the name of "getValueWIthoutChange". This must be new in CF8. I'm guessing one reason it was added is for the server monitor which gives you access to this info without touching the session timeout. If you google this method, you get absolutely 0 results. When I saw that in the dump of the sessionScope class, I knew there was hope. Important to note too is that Java is very case sensitive. Notice that the W and I are capped in "WIthout". Typo that made it through? Anywho, my next challange was finding the correct casting and such to be able to pass a var into the reflected getValueWIthoutChange method from CF. I flailed on this for about a day before I took this to a co-worker that was a java guy in a past life. He had it nailed down for me in a 1/2 hour or so. Long story short, we ended up with a method that will allow you to get any session var without touching the sessions. This is a beautiful thing and opens up all kinds of possibilities.

<cfset tracker=createObject("java","coldfusion.runtime.SessionTracker")>
<cfset sessions=tracker.getSessionCollection(application.applicationname)>
<cfoutput>
<cfloop item="loopSession" collection="#sessions#">
Idle Time:
#getSessionProxy(sessions[loopsession],'getTimeSinceLastAccess')#<br/>
User ID:
#getSessionValue(sessions[loopsession],'idofuser')#<br/><br/>
</cfloop>
</cfoutput>

<cffunction name="getSessionValue"
output="false" access="public" returntype="any">
<cfargument name="session" required="true" type="struct" />
<cfargument name="key" required="true" type="string" />

<cfset var a = arrayNew(1)/>
<cfset var valueMethod =  ''/>
<cfset var value =  ''/>
<cfset var sessionClass =
a.getClass().forName("coldfusion.runtime.SessionScope") />

<cftry>
<cfset a[1] =
CreateObject("java","java.lang.String").GetClass()/>
<cfset valueMethod =
sessionClass.getMethod("getValueWIthoutChange",a) />
<cfset a[1] =
CreateObject("java","java.lang.String").Init(arguments.key)/>
<cfif findnocase(arguments.key,structkeylist(arguments.session))>
<cfset value = valueMethod.invoke(arguments.session, a)/>
<cfelse>
<cfset value = ''/>
</cfif>

<cfcatch><!--- Do Nothing ---></cfcatch>
</cftry>
<cfreturn value />
</cffunction>

<cffunction name="getSessionProxy"
output="false" access="public" returntype="string">

<cfargument name="session" required="true" type="struct" />
<cfargument name="method" required="true" type="string" />

<cfset var _a = arrayNew(1)/>
<cfset var _sessionClass =
_a.getClass().forName("coldfusion.runtime.SessionScope") />

<cfset var _method = ''/>
<cfset var _value = ''/>
<cftry>
<cfset _method =
 _sessionClass.getMethod(arguments.method, _a) />
<cfset _value = _method.invoke(arguments.session, _a)/>
<cfcatch><!--- Do Nothing ---></cfcatch>
</cftry>
<cfreturn _value />
</cffunction>

Now, as an important note and as has been echoed on other blogs, this is an undocumented method and the farm should not be bet on it. There is no guarantee that it will live on in other versions of CF so use wisely.

With that said, praise God for technology and go change the world.

Blessings...

RegEx broke my phone

We had a bug turned in on a form that was not accepting valid phone numbers, or so it seemed. The number used was something like 233-122-2323. Looks like a valid phone number right? I dug into the form field and found that it was a cfinput tag utilizing the validate="telephone". We recently moved to CF8 and I was wondering if this was a CF8 issue that was somehow unique. I looked at the generated source in order to evaluate the resulting js that is used to validate the form on submit. That led me to this code:

//form element phone 'TELEPHONE' validation checks
if (!_CF_checkphone(_CF_this['phone'].value, true))
{
alert(_CF_this['phone'].value)
_CF_onError(_CF_this, "phone", _CF_this['phone'].value, "A valid phone number is required.");
_CF_error_exists = true;
}

We can find the code for _CF_checkphone buried in this file, depending on your instance:

\JRUN4\servers\[instance]\cfusion-ear\cfusion-war\CFIDE\scripts\cfform.js

Finding the function in this file revealed the regular expression that is being used to validate phone number.

/^(((1))?[,\-,\.]?([\\(]?([1-9][0-9]{2})[\\)]?))?[,\-,\.]?([^0-1]){1}([0-9]){2}[ ,\-,\.]?([0-9]){4}(()((x){0,1}([0-9]){1,5}){0,1})?$/

1-800-322-5544 or 220-122-2323 (the number used on the form)

Now I'm not a regex guru nor do I work with it every day, so color coding is a definite help for me. There are some nice tools out there that can help you test regex both pay and free. I've been playing with RegExBuilder (free) lately. It doesn't have all the bells and whistles like being able to switch the regex engine, but it works for what I need right now. Anywho, let's break this down:

**- the ? makes the 1 optional

**- this has to be a digit between 1 and 9, never 0

**- two digits that are between 0 and 9

**- any character that is not 0 or 1. Surprisingly, this allows non digits

**- two digits that are between 0 and 9

**- four digits that are between 0 and 9

So according to the test number that was entered in the test, it violates rule **.
The funny thing is that we could have entered anything else besides 0 or 1. I tested 701-B86-5566 and it worked. But anywho… I think this form is performing as expected, unless of course there are valid phone numbers with the ** being 0 or 1. I wouldn’t know where to find that info and a brief google session didn’t turn anything up. I gave up quickly because didn't feel like digging into that right now. I'll leave that up to a more ambitious person. But the question to be answered is whether or not this should be reported as a bug and request Adobe to fix that regex in CF8 to be more accurate on the [^0-1] test. Why not [2-9]?

Blessings...

16 thread pile-up...

We have been having issues with one of our servers going down. The offending action seemed to be happening in the middle of the night some time. One of the symptoms was a sql table that was locked and the site would just spin when trying to access it. It was either that or the cf service was plain dead in the morning. After further review in the logs, I found these scattered throughout:

06/05 23:49:53 Error [jrpp-57] - Error Executing Database Query.[Macromedia][SQLServer JDBC Driver]Connection reset by peer: socket write error The specific sequence of files included or processed is: X:\xxx\xxx\xxx.xxx, line: 348
removeOnExceptions is true for xxx. Closed the physical connection.

followed by a bunch of

java.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)

Notice that the connection to sql was being reset when CF was attempting a sql execution. It didn’t look like the same line of code every time, but there is one line that is showing up more often. While researching the error in google, I came across a couple of possible causes. One was a possible flaky network that was dropping the attempted sql. While I was checking on the sql server box for a record of possible network issues in the sql log, I found that there were some sql errors that were occurring at the exact same time as our CF woes. Here they are:

Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 17066
Date: 6/5/2008
Time: 11:49:50 PM
User: N/A
Computer: xxxxxx
Description:
SQL Server Assertion: File: , line=9421 Failed Assertion = 'NULL == m_lockList.Head ()'. This error may be timing-related. If the error persists after rerunning the statement, use DBCC CHECKDB to check the database for structural integrity, or restart the server to ensure in-memory data structures are not corrupted.

Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 3624
Date: 6/5/2008
Time: 11:49:50 PM
User: N/A
Computer: xxxxxx
Description:
A system assertion check has failed. Check the SQL Server error log for details

Event Type: Error
Event Source: SQLSERVERAGENT
Event Category: Alert Engine
Event ID: 318
Date: 6/5/2008
Time: 11:49:55 PM
User: N/A
Computer: xxxxxx
Description:
Unable to read local eventlog (reason: The parameter is incorrect).
(Link: http://go.microsoft.com/fwlink/events.asp.
)

After looking at a couple of these errors on google, I saw one instance where it was solved by moving to SP1 for SQL2k5. We recently upgraded to SQL 2K5 and are still on SP0. There may be an issue with sp0 where it doesn’t handle locks correctly and it may be dumping there. Notice this line… SQL Server Assertion: File: <lckmgr.cpp>, line=9421 Failed Assertion = 'NULL == m_lockList.Head ()'. The lock isn’t being handled correctly for some reason.

We have opted to try to up to SP1. Think we can trust it? Its only been out since 2006 ;). We'll see what happens.

UPDATE (6/10/08): our server has been up for 2 straight week days with no issues at all. In fact, the site has been reported to be responding much faster. A lot of SP1's updates were efficiency related so things should naturally respond better after upgrading.

CF Mail Spooler Woes...

We have been having some issues with our mail server recently. Mail hasn't been going out and this is what we noticed in the logs:

"Error","scheduler-4","06/03/08","10:33:24",,"Could not connect to SMTP host: xxx.xxx.xxx.xxx, port: 25; nested exception is: java.net.ConnectException: Connection refused: connect"
javax.mail.MessagingException: Could not connect to SMTP host: xxx.xxx.xxx.xxx, port: 25;
nested exception is:
java.net.ConnectException: Connection refused: connect

and

"Error","scheduler-1","04/02/08","03:30:56",,"A problem occurred when attempting to deliver mail. This exception was caused by: coldfusion.mail.MailSpooler$SpoolLockTimeoutException: A timeout occurred while waiting for the lock on the mail spool directory.."

From what I found, this occurs for two reasons:

1. Bombage from sending a huge email
2. Insufficient disk space

Reference: http://www.talkingtree.com/blog/index.cfm?mode=entry&entry=67FD4A34-50DA-0559-A042BCA588B4C15B

We did notice a message the other day claiming that we were running low on disk space.
There is a recent hotfix from Adobe that supposedly helps this that was released in April '08 that supersedes a previous hotfix in this area. That hotfix can be found here: http://kb.adobe.com/selfservice/viewContent.do?externalId=kb402001&sliceId=1
We applied the hotfix today and cleared some disk space so we'll see happens.

Update: after getting our hands dirty today, KP found that there was a backup of 10,000+ emails in the inetpub/mailroot/queue directory. Something is getting hosed at that level. He found this by telnet'ing to the server's port 25 and sending a message. It told him that the message had been queued for delivery. He never did get the message which told us that the bottleneck was at the queue. We've got a ticket opened up to check it out.