I have been having a problem on a sandboxed CFMX7 server where by clients would get the following error unless a sandbox is created for their site.

 

Security: The requested template has been denied access to <domain name>.

 

The actual cf error you will get in the debug output is

 

access denied (java.net.SocketPermission <domain name> resolve)

 

The reason for this error is because they have enabled session management in their application.cfm, exactly why this would result in a SocketPermission error I do not know, but here Is the work around.

 

You should have a default (top level) security sandbox where you are disabling certain tags and functions by default for the WWWROOT or wherever your web sites are stored. In this sandbox you need to explicity allow the IP address of the server on port 80 under the Server/Ports tab. The the error will no longer occur and you will no longer need to setup a security sandbox just to allow session management.

 

You may find that this error also occurs when making connections to other resources, like database servers (I have a similar issue with MySQL connections on this same server), and adding the server IP and port for the remote server shoudl also work in the same way.

Well my first CFDevCon is now over, and i'm glad to announce it was a big success.

I have received lots of positive feedback and praise so far and plenty of people have told me they will definitely come next year, so it was worth all the hard work and late nights.

 

The turnout reached my expectations which was around 200 people, which resulted in a nicely packed venue with the main room being about 3/4 full with room for a few tables for people to sit with their laptops, which was mainly the speakers tweaking their presentations, or actually writing them at the last minute (no names mentioned Alex).

 

New Atlanta and Charlie Arehart seemed very happy with the event and the turnout, so i'm really glad the trip was worth their while too. 

I just wish I was able to sit still long enough to watch everyones talk myself. 

 

The after party was also great fun, although only about half the delegates were able to stick around due to the need to catch trains and drive home, but those who did stay polished the tequila with gusto. The magician (Hugh Nightingale) also went down great and amazed everyone with his tricks. You always think that if you see these guys tricks face to face you will be able to suss out how they do it, but you can't. How he managed to turn my £10 note into a $50 bill I have no idea.

 

The only disapointment for me was the conference centres own hotel, which was a total dive. Thankfully it wasn't the only hotel, and most people I spoke to ended up staying at the Jury's inn instead, which luckily was right next door. If I hadn't had all my boxes of t-shirts and goody bags with me, I would have moved to the Jury's Inn as well, but I didn't fancy having to move it all just for the sake of 2 nights.

So if your ever in Croydon DO NOT stay at the Fairfield Hotel. The Fairfield Conference centre itself though is great. 

 

As some other people have already started reviewing the event on their blogs, i'll just post their links here as I find them.

 

Mark Drew has posted a PDF of his presentation HERE and his photos  HERE.  Most of the pics of me are at the party, but I did actually wear a proper shirt and tie during the conference honest.

 

Andy Jarrett's review and pics

Alan Williamson's review

Trond Ulseths review

Nick Tong  

 

 

 

 

Have you ever just received this useless error from any of your cfm pages

"Application Error"

And nothing else, no debug output, nothing except a blank page.

Well I just found one reason for this today while trying to use CreateObject(java) when this function is disabled in the sites security sandbox. Specifically I was using "getPageContext().forward("#attributes.URL#");"
It seems CF doesn't like to give you any error at all in this situation, so I presume the same may apply to other tags/functions that are disabled by a security sandbox.

So be sure to check all your tags and fucntions are enabled if you get this error.

Also note that if you are calling such code via a custom tag, it also causes the page to take a very long time to return the error or timeout altogether. In FusionReactor the page will just hang and show in "Running Requests" indefinitely and you cannot kill it. 

 

 

This is a problem I have had a few times in the past, but last night was probably the most drastic action I have had to take so far to get it working. So I thought I would document the procedure, this is the cut down version as it actually took me 4+ hours to resolve the problem.

Client had ColdFusion MX 7 running fine for 2 weeks, then mysteriously it stopped working. Turns out the CFIDE folder had gone, so had all the JRUN connector files (<cfroot>/runtime/lib/wsconfig/1).

On attempting to re-install, the installer could not complete, reporting that ports may be blocked by a firewall or some other 3rd party application.  This was of course not the case, as there was no firewall on the server.

The only part of the installation left to complete is the final part where the connectors are created and you open the CFADMIN, the ODBC services are created, and the final CF site of the setup occurs.

So I tried to create the connectors using WSCONFIG, and got this error (the same one showing in the logs as well)

Could not connect to any Jrun/ColdFusion servers on host localhost.
Possible causes:
Server not running
-Start Macromedia JRun4 or ColdFusion MX server
Server running
-JNDI listen port in jndi.properties blocked by TCP/IP filtering or firewall on server
-host restriction in security.properties blocking communications with server

 

So I use "netstat -an" command to see what ports are open and listening.
The JNDI port 2920 was there, but the proxyservice port  51011 was not, indicating that it is not open and listening.

So I opened the <cf-root>\runtime\servers\coldfusion\SERVER-INF\web.xml file and changed the default proxyservice port. See code below.

Change "deactivated" to false
Change "port" to a new value of your choice

<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
    <attribute name="activeHandlerThreads">8</attribute>
    <attribute name="minHandlerThreads">1</attribute>
    <attribute name="maxHandlerThreads">1000</attribute>
    <attribute name="mapCheck">0</attribute>
    <attribute name="threadWaitTimeout">300</attribute>
    <attribute name="backlog">500</attribute>
    <attribute name="deactivated">true</attribute>
    <attribute name="interface">*</attribute>
    <attribute name="port">51011</attribute>
    <attribute name="timeout">300</attribute>
    <!-- set this to false for multi-hosted sites -->
    <attribute name="cacheRealPath">false</attribute>
    <!--
    <attribute name="keyStore">{jrun.rootdir}/lib/keystore</attribute>
    <attribute name="keyStorePassword">changeit</attribute>
    <attribute name="trustStore">{jrun.rootdir}/lib/trustStore</attribute>
    <attribute name="socketFactoryName">jrun.servlet.jrpp.JRunProxySSLServerSocketFactory</attribute>
    -->
  </service>

The new port I had entered now showed up in netstat so I knew it was listening and not blocked.

WSCONFIG would still however not locate JRUN and connect to it. Then I found the below info over at brandon  Purcell's blog , which I have slightly modified here to apply to a standard CFMX7 installation.

When wsconfig first runs it does a port scan from 2900-3000 to list any JRun servers that are running.  In some cases it will hang when the port scan occurs.  In the GUI this occurs when you click the add button.  In the command line version it occurs when it searches for the servers and the prompt never returns.  To test if this is the problem try the following command

wsconfig -host localhost -list  (using the executable version)
C:\CFusionMX7\runtime\jre\bin\java -jar C:\CFusionMX\runtime\lib\wsconfig.jar -host localhost -list

This command should provide a listing of all running servers if it does not return to the command prompt and hangs then you can follow the procedure below

By narrowing the ports that are scanned by wsconfig you can prevent the hang.  By default CFMX7 uses port 2920 for the jndi port.  This port can be found in C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\jndi.properties under the entry java.naming.provider.url=localhost:2920. If you are running multiple instances of JRun then you can look in each servers SERVER-INF\jndi.properties file for the range of jndi ports to scan.

To reduce the ports that are scanned use the following java arguments

-DWSConfig.PortScanStartPort=startport -DWSConfig.PortScanCount=portrange

So If I had 1 instance and the JNDI ports are 2920  then I would use the following command to list the jrun instances.

C:\CfusionMX7\runtime\jre\bin\java -DWSConfig.PortScanStartPort=2920 -DWSConfig.PortScanCount=1 -jar C:\JCFusionMX7\runtime\lib\wsconfig.jar -host localhost -list

To run the GUI and only scan those ports enter the following command:

C:\CFusionMX\runtime\jre\bin\java -DWSConfig.PortScanStartPort=2920 -DWSConfig.PortScanCount=1 -jar C:\CfusionMX7\runtime\lib\wsconfig.jar

Modify the ports to your range of JNDI ports and the GUI should work without hanging.

Here are a few other articles that can help with wsconfig debugging
http://www.macromedia.com/support/jrun/ts/documents/tn18287.htm
http://www.macromedia.com/support/coldfusion/ts/documents/connector_install_faq.htm

 

I just came across an interesting article by Mike Schierberl that shows that locally scoped variables in your application may not be cleaned up the garbage collection at the end of the request as expected and may persist in memory.

Memory Leaks: Part II - variables scope leak

Mike has also provided some handy information on how to profile your application and identify such memory leaks.

ColdFusion Memory Leaks: Part I - profiler introduction

 

This certainly explains a lot of problems where your application has been eating memory like a fat guy in a cake shop for no reason and I will certainly take note of this issue in my own coding from now on. Unfortunately I don't think it will help me too much on a day to day basis at CFMXHosting as I deal with servers containing hundreds of sites, and I don;t think I could identify this problem for each and every clients site, that would be a lot of profiling.

 

NOTE: This problem appears to related to a JVM bug and will probably only effect people using the same JVM version as Mike. Upgrading your JVM to a new version should cure this issue.