Error: Check JRun web server configuration and JRun mappings on JRun server.

Viewing By Entry

Error: Check JRun web server configuration and JRun mappings on JRun server.

Apache can be configured to connect to an instance of JRun at the global level and/or at the Virtual Host level. If configured at the global level, any Virtual Hosts will inherit the ability to connect to the globally-defined JRun server, and any JRun settings in the Virtual Host directive can override that of Apache's global level. If all the Virtual Hosts use the same JRun server as defined at the global level, then they will be configured for the same Serverstore and Bootstrap. In this way you can configure Apache for ColdFusion/JRun in a many to one relationship.

However, you can also configure a Virtual Host for a different JRun instance to achieve a one to one relationship for each Virtual Host. To do this, first set up a jrunserver.store for the second instance by copying {jrun_home}/lib/wsconfig/1/jrunserver.store, then create a directory {jrun_home}/lib/wsconfig/2/ and paste the jrunserver.store copy there. Edit {jrun_home}/lib/wsconfig/2/jrunserver.store to list the host:proxyport for the second instance, noting that the proxy port for that instance can be obtained from either the JMC or jrun.xml. Finally, edit the Virtual Host directive in httpd.conf, and add the following (where JRun's home is /opt/jrun4/ and the JRun server:proxy port is 127.0.0.1:51003 in the example):

JRunConfig Serverstore /opt/jrun4/lib/wsconfig/2/jrunserver.store
JRunConfig Bootstrap 127.0.0.1:51003
JRunConfig Apialloc false

The JRunConfig Apialloc setting must be set in the Virtual Host for second instance, and must be set to false.

If not, one in every 4 or 5 requests will return an Apache Internal Server Error to the client with a 500 status code and the Apache error log will record a message such as:
[Thu Jun 24 15:09:33 2004] [notice] jrApache[1635] JRun will not accept request. Check JRun web server configuration and JRun mappings on JRun server.

Here is an example httpd.conf file from Apache 2.0.47 configured for the first ColdFusion instance on JRun at the global level, configured by default for the same ColdFusion instance on the first Virtual Host, and configured for a second ColdFusion instance in the second Virtual Host. Note that JRunConfig Apialloc false is set at the global level and in the second Virtual Host.

The JRun connector setting for Apialloc governs from where the connector allocates memory. The connector stub is written in C and when it needs to allocate memory it can either ask the operating system for memory (apialloc=false) or ask Apache for it (apialloc=true). Asking Apache for memory was probably quite safe in Apache 1.3x with just one instance of a JRun server, but its best to always set apialloc to false and let the stub work with the OS to manage memory.

posted on 16 July, 2004 at 2:28 PM.
ColdFusion | Comments (18)

Comments

THANK YOU! THANK YOU!

I have been trying to figure this problem out for months. It is the only thing stopping me from moving our main webserver over to multi instances of CF.

If you could get someone to update Brenda Parcella's otherwise excellent mutli instance article on macromedia.com (http://www.macromedia.com/devnet/mx/coldfusion/articles/multi_instances04.html) that might help solve this problem for other users.

Thanks again!

comment by Kurt Wiersma, posted at 7/16/04 3:26 PM

+1 to that BIG THANK YOU! I had the same problem you described where every x number of requests were returning the error, and I just couldn't figure it out.

As Kurt mentioned, I know a lot of us use(d) Brandon's article to get multiple instances working with Apache. If he can get this info into his doc, it will be a huge help.

comment by Rob Brooks-Bilson, posted at 7/16/04 4:58 PM

I let Brandon know about your feedback. Thanks.

comment by Steven Erat, posted at 7/16/04 5:01 PM

Thanks for the comments, I will get this integrated into the article.

comment by Brandon Purcell, posted at 7/19/04 5:39 AM

I just found this entry from a link on Brandon Purcell's blog.

I originally had a problem with exactly these symptoms and tracked it down to the JRun web proxy service not being started for each instance. Once I'd started it up, I found that it remembered the setting and I didn't have the problem again.

I don't have any JRun Apialloc settings in any of my virtual hosts, so I'm kinda wondering what's going on.

Any ideas?

comment by Spike, posted at 8/10/04 1:08 PM

So do you mean that some server instances which were configured for Apache virtual hosts had the JRun Proxy Service turned off in jrun.xml (deactivated=true) ? That would cause the Proxy Service to not start even though the ColdFusion web application would deploy. If the JRun Proxy Service is off, then Apache cannot communicate with the server instance in the first place.

I don't quite understand how Apache could be configured for a server instance and still handle requests when the JRun Proxy Service is disabled.

comment by Steven Erat, posted at 8/10/04 1:22 PM

Brandon notes in this blog entry that the article on multiple instances has been updated to account for the Apialloc setting information.

comment by Steven Erat, posted at 8/10/04 1:23 PM

Don't know what the setting was in jrun.xml, but when I went in via the JMC and had a look at the services section for each instance, the web proxy was shown as not active.

This is all going back 6 months or so, and it could be that the service wasn't connecting at all after I did the reinstall.

I'm more curious about why I'm not having any issues despite not having the Apialloc setting in each virtual host.

comment by Spike, posted at 8/10/04 1:29 PM

First, I assume that the global level in httpd.conf is configured for 'server1', for example, and that the global settings include Apialloc=false. I know that the Apialloc setting is required at the Virtual Host level only if that virtual host Bootstrap and Serverstore paths are different from the global JRun handler's Bootstrap and Serverstore path. So if the global level in httpd.conf is configured for JRun server1, then if you create a virtual host that does not include any bootstrap/serverstore info, then virtual host 1 inherits the server1 properties from the global level. If you create a virtual host 2 and you add bootstrap/serverstore parameters that point to JRun server 2, then virtual host 2 will not inherit any of the global JRun settings, and virtual host 2 would require Apialloc=false. Perhaps the virtual hosts were all pointing to the same bootstrap/serverstore path as the global level.

Also, if you don't have global settings for JRun, but define them only at the virtual host level, then you'll need to add all the JRun parameters (bootstrap/serverstore/apialloc) to each virtual host directive. The virtual hosts can't inherit from each other.

comment by Steven Erat, posted at 8/10/04 1:40 PM

Well, you got me there. I would have expected to see the error in that case.

Maybe the problem arises only if the Apialloc setting is different for different virtual hosts or global. What if Apialloc is true for the global level and left to the default value of true for the virtual host level. Then they all agree.

By default, the wsconfig utility configures the global JRun block to have Apialloc false. So if you had a virtual host for a different bootstrap/serverstore without Apialloc, then Apialloc would default to true. That would leave the instances at different levels where some would try to let the OS govern memory allocation, and others would let Apache do it. That could be where the conflict comes in.

I think the gist of Brandon's changes to the article is that its a good practice to explicitly set Apialloc both globally and at all virtual hosts, and set them all to false. They would all agree, and they would all let the OS manage memory allocation.

comment by Steven Erat, posted at 8/10/04 2:08 PM

What would you say if I get this error only on certain pages of a virtual host?

Example:
http://www.foo.com/ works fine.
http://ww.foo.com/products/* returns this mapping error.

Now I must disclose that I am using the Apache mod_rewrite to do some URL "tricks".

So http://ww.foo.com/products/54/ is what the user see's as the URL, but Apache should rewrite this request as http://ww.foo.com/products.cfm?id=54

I have been using this for sometime now on serveral sites. And it has worked fine with Apache/CFMX 6.1.

Just yesterday I reconfigured to the Multiple Instances setup, and also the CFMX updater.

This mod_rewrite technique is working on one virtual host, but failing on another and returning this mapping error.

I have the Apialloc false set on all virtual host entries.

Any ideas?

comment by ErikG, posted at 8/26/04 11:50 AM

It sounds sufficiently complex such that you might want to open a Macromedia Support ticket rather than address this through blog comments. Or write to Brandon, but he'll probably recommend the same.

comment by Steven Erat, posted at 8/26/04 7:05 PM

I'm having lots of trouble mapping to jrun servers with cf to a single web server instance. Is this even possible?

I tried adding two proxies to jrunserver.store, but the file always gets overwritten and my entries are gone.

What I would like is the following:
http://mysite.com/instance1/ and
http://mysite.com/instance2/

If anyone has any information on this, please let me know where I can find. It seems possible and easy to configure different instances to different virtual servers, but not to different directories.

Thanks.

comment by Tony, posted at 3/31/05 8:36 AM

Tony,

The jrunserver.store file is written dynamically at runtime by the connector. Any changes you make to the file will be overwritten, as you have observed.

The connector configuration parameter for bootstrap server is configurable by you. This should be the host:proxyport of the most reliable server instance if you can predict that. The connector will communicate with the bootstrap server to obtain information about that server such as if it participates in a cluster. If so, then the bootstrap server returns information to the connector about the name of the cluster and the host:proxyport of the other cluster members. The connector will determine if those other members are running and then write that information to jrunserver.store. If at any time the connector's list of servers known to be running changes, the jrunserver.store file is updated too.

Editing the jrunserver.store file is not the appropriate way to attempt to configure a cluster as of JRun4 Updater 3 and higher. I believe some people used that method in JRun 3.1 and JRun 4 original.

It is best if each server instance has the same context root. Do not use JRun clustering on a cluster where the context root varies. There are at least 3 problems with that. If you use the same context root then all you should need to do is 1) configure the cluster in JRun Admin, and 2) configure the webserver with wsconfig while choosing the name of the cluster instead of choosing the name of an individual server of the cluster. That's it. The key is in choosing the name of the cluster in wsconfig. If using the commandline options, use the -cluster switch, not the -server switch.

comment by Steven Erat, posted at 3/31/05 9:52 AM

For anyone reading this entry, see also another blog entry on jrunserver.store here

http://www.talkingtree.com/blog/index.cfm?mode=ent...

comment by Steven Erat, posted at 4/1/05 7:38 AM

Steven, thanks for your help. I got the clustering to work. I am now able to reach http://mysite.com/instance1 and http://mysite.com/instance2. The only problem I'm having now is that the instances seem to run the built-in JRun Web Server instead of apache as the web server. Is there any misconfiguration?

Also, I was not able to reach CFIDE through http://mysite.com/instance1/CFIDE.

Any times or help would be greatly appreciated.

Thanks,
Tony

comment by Tony, posted at 4/4/05 1:31 PM

Hi,

This is an IIS related question regarding the same topic. Hopefully someone may have some insight. We are trying to get JRun to run in an enviroment where the machine hosts a number of different applications (one of them is cold fusion). One requirement is that the ISAPI filter can't be installed at the root level of the web site, only at the virtual directory level. Therefore I added an Extension mapping for all extensions (*) and routed it the connector. The problem is that it isn't picking up all the files it needs to. For example, our static directory at the web share is:

/APPNAME/ (all JSPs, and everything get picked up by this and work fine)

Our Servlets are usually mapped by:

/appname/(servlet uri) Some servlets work this way, and others don't. I haven't quite found a reason why yet. If I Place the ISAPI filter at the root level, every thing works fine though.

Pete

comment by Pete, posted at 5/19/05 10:29 AM

What if I get the same internal server error and the same entry in the Apache log but I am not using clustering? I am using virtual hosts, and the wsconfig has does the configuration for me. I've deployed cfusion under the defauly server.

However, each .cfm page gives me that same error (not .jsp pages, though).

Anyone with any idea?

comment by Scott Arbeitman, posted at 5/30/05 4:16 AM

Calendar

Search This Site

This is an exact search only

About This Site

I live west of Boston and work as a Software Engineer with ColdFusion and Flex, specializing in Linux. Recently I graduated in Professional Digital Photography from CDIA.