Maximum number of simultaneous Template requests not editable

[Guest]

Hello everybody,

we have the following problem: We are running CF9.0.1 Standard Edition (Update Level chf9010001.jar) on a Windows 2008 R2 Server and we cannot change the Maximum number of simultaneous Template requests via the Request Tuning Page in the CF Administrator.

Here is what happens: Currently we have set a value of 50. If we change the value to 20 (just as an example) and submit the changes then the CF Admin Interface says "Server has been updated successfully" and the CF Admin Interface correctly shows the new value 20.  This new value is also automatically inserted in the Field for Maximum number of simultaenous Flash Remoting, Web Service and CFC Function requests (afaik they cannot be altered individually because we are running a standard installation of CF).

But... after a restart of CF, the new value is gone and it shows us the value 50 again!

I also checked the neo-runtime.xml. That is the file, which stores those settings right? Weird thing is, this file doesn't seem to reflect any of the changes either. The corresponding nodes in the xml are:

<var name="CFCLimit"><number>10.0</number></var>
<var name="webserviceLimit"><number>5.0</number></var>
<var name="flashRemotingLimit"><number>5.0</number></var>
<var name="requestLimit"><number>10.0</number></var>

So it shows neither our "old" value of 50 nor our "new" value of 20...? Instead it shows the default settings. But why is CF Admin showing us a value of 50?

We are very thankful for any ideas on that issue.

Greetings,
Steve

[Charlie Arehart]

That is really odd, Steve. I would wonder if the neo-runtime.xml file has permissions that are not allowing it to be edited by the user running CF. I assume you're running CF as a service. Check first to see what user the CF service is running under (it's an option in the properties for the service, in the Windows Services panel, which is in Control Panel>Administrative Tools).

The user will either be System (the default) or some other account that someone there has changed it to. Either way, make sure then that the xml file is indeed set to be edited by that user (right-click the file, choose properties, then "security").

Let us know if that helps.

/charlie

[Guest]

Hi Charlie,

thank for pointing that out. We checked the file permissions and it all looks good. CF is running as a service and the user belongs to the Administrators Group, so CF has full permissions on the directory where neo-runtime.xml is.

In fact, we can change other settings via the CF Administrator, just this particularly setting won't behave as exspected. So i think it's safe to say, that this is not a permission issue.

Steve

[Guest]

Hi everybody,

we did some more research and i would like to bring you all up to date:

We have more than one CF server and they are all installed the same way (about a month ago). We have this problem on one particularly server, so i tried to find the difference between the good and the bad servers. At first, we were wondering, which file actually saves the Maximum Number of simultaneous Template requests setting (like i already said neo-runtime.xml doesn't seems to store the values as it still contains the default values). We found out, that when we update the setting in the CF Administrator of a good server, it updates neo-runtime.xml but also

C:\ColdFusion9\runtime\servers\coldfusion\SERVER-INF\jrun.xml

This file shows the actual value of 50:

<attribute name="activeHandlerThreads">50</attribute>

This node is found under

<service class="jrun.servlet.http.WebService" name="WebService">

and also under

<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">

Perhaps somebody can sconfirm, that we're looking at the correct file now?

Next we checked, what happens, if we try to update the setting on the bad server. It updates the neo-runtime.xml but not the jrun.xml !! That's definitely a weird difference. Why would one server update that file upon saving and the other not? I checked the Last-Modified-Date of the jrun.xml on the bad server and it shows, that the file was not changed since last Monday (so its a week ago now). This matches the fact, that we just noted that problem and we were able to switch the value directly after the installation.

Sound really strange to me... does anybody have an idea??

Thanks in advance,

Steve