How do I configure HAYSTACK_SOLR_URL when using multiple cores?
I've set it to the address of core0, and that works, but only using one core…
The docs aren't that obvious to me… it just says
...
# ...or for multicore...
HAYSTACK_SOLR_URL = 'http://127.0.0.1:8983/solr/mysite'
What is mysite?
I'm actually running apache-solar-3.3.0/example with the multicore directory copied over the example directory, and the schema and conf files/directories updated.
Many thanks.
<cores adminPath="/admin/cores">
<core name="core0" instanceDir="core0" />
<core name="core1" instanceDir="core1" />
</cores>
So, you would search core0 by
http://127.0.0.1:8983/solr/core0/select/?q=*
If you had a core "mysite"
http://127.0.0.1:8983/solr/mysite/select/?q=*
Whereas if it were not multi-core
http://127.0.0.1:8983/solr/select/?q=*
assuming you named your solr app as "solr".
Do refer the multi-core docs in full. You can dynamically load/unload cores and even swap a live core with another without dropping requests.
in our project, we have 3 cores, called "cars" "homes" "jobs"
i settings i have:
CORE_HOUSE = http://localhost:8080/solr/homes/
CORE_HOUSE = http://localhost:8080/solr/cars/
CORE_HOUSE = http://localhost:8080/solr/jobs/
whenever you need them, you refer to the settings variable (where localhost:8080 is your solr installation address)
Related
I'm using Rails 4.1.2. I have some environments which are exact copies of my development environment. In other words, I created them by simply copying config/environments/development.rb to a file with a different name (e.g., destaging.rb). They differ only in the connection information in database.yml.
If I issue RAILS_ENV=destaging rails s or rails s -e destaging at the command line, everything works just as I desire, except that I get no SQL logging to STDOUT, which is a bummer.
Since my destaging environment is absolutely identical to my development environment except for different connection settings in database.yml, I suspect that something is looking for an environment named development and enabling SQL logging to STDOUT only if an environment with that name is active. How can I enable SQL logging to STDOUT for other environments launched through WEBRick?
For posterity, I've discovered how to do this. First, I'm running Ruby 2.1.2 with Rails 4.1.2. If that is not your environment, your mileage may vary, though I suspect the solution will be very similar.
So, first you must modify bin/rails. Open this file and change it as follows. (I have posted the entire file, minus the shebang, for clarity.)
begin
load File::expand_path("../spring", __FILE__)
rescue LoadError
end
APP_PATH = File.expand_path('../../config/application', __FILE__)
require_relative '../config/boot'
# Here comes the important part
require 'rails/commands/server'
class Rails::Server::Options
def parse_with_logging!(args)
options = parse_without_logging!(args)
options[:log_stdout] = true # Or whatever condition you want
options
end
alias_method_chain :parse!, :logging
end
require 'rails/commands'
Since require 'rails/commands' executes the server immediately, monkey-patching after that line does not work. It is simply ignored. If you try to monkey-patch it before you require the commands, it explodes because the Rails::Server::Options class has not yet been defined. Thus, we have to pre-emptively require rails/commands/server so we can alias its parse! method.
Monkey-patching should almost always be a last resort, IMHO. However, I see no alternative in this case. If anyone has a better idea, I'd love to hear it.
I also encountered this problem with the same versions of Rails and Ruby, using a non-standard environment name (in your case "destaging"). However I did not want it to affect all environments, nor lose any more time to not getting work done, so I simply changed the way I start the server:
(tail -F log/destaging.log &) && rails s
Then afterwards to restart the server, ctrl-c as usual and then rails s again. The tail will keep going in the background and for all intents and purposes the experience will be like it was before this stopped working.
I am working with a CF10 application and trying to define application specific classpaths to load JARs using the this.javaSettings feature introduced in CF10.
From Application.cfc:
THIS.javaSettings = {
LoadPaths = [".\java_lib\",".\java\myjar.jar"],
loadColdFusionClassPath = true,
reloadOnChange = false
}
This is working great, and I can define JARs on an application basis. However, every time I reload the application (for example, if I call applicationStop()) then CF seems to hold on to all the loaded JARs/classes at the same time re-loading them all - which means after a number of reloads I inevitably get an out-of-memory Perm Gen error.
Has anyone experienced this? I have tried the usual things by updating GC strategies to enable permgen collection:
-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
Ok, this was not an issue with the CF feature - turns out that the memory leak was originating in the groovy code that had been compiled in to a jar (you can read groovy details here: https://stackoverflow.com/a/17952925/258813)
It appears as though the CF10 hot-reloading of jars is working ok!
I have the following directory structure:
| SITES_FOLDER
|___ WEBSITE1
|___ WEBSITE_CFC
|___ CFC_DIR
WEBSITE1 contains an Application.cfc and some pages. Then I have a component ShoppingCart.cfc inside the WEBSITE_CFC directory that is instantiated on session start using this code:
createObject("component","WEBSITE_CFC.ShoppingCart").Init() />
This works.
Now I move ShoppingCart.cfc to the CFC_DIR directory and change my instantiate code to:
createObject("component","CFC_DIR.ShoppingCart").Init() />
Obviously this does not work because ColdFusion searches for a "CFC_DIR" directory under the root directory "WEBSITE1" and doesn't find it.
I thought this problem would be solved by using mappings so I go to the CFIDE administrator. Server Settings > Mappings.
Logical path: "CFC_DIR"
Directory path: "C:\some\folders\SITES_FOLDER\CFC_DIR"
No luck. So then I tried in Application.cfc:
<cfset THIS.mappings["/CFC_DIR"] = "C:\some\folders\SITES_FOLDER\CFC_DIR" />
This did not work either!
EDIT:
Maybe I understand: if I try to create the CFC from a cfm template, it works.
The error comes up when I try to create it inside the OnSessionStart Application.cfc's method:
Ensure that the name is correct and that the component or interface
exists. Message Could not find the ColdFusion component or interface
C:\some\folders\SITES_FOLDER\WEBSITE1|WEBSITE_CFC\ShoppingCart.cfc.
In other words, it keeps looking for it in the wrong dir.
WHY?
If you're changing the file to /CFC_DIR but it's still using /WEBSITE_CFC it sounds like the cache needs clearing.
Clear the Cache in CF Admin
Clearing the cache can be done manually in the ColdFusion Administrator. After login, the third item in "Server Settings" is "Caching". Scroll to the bottom of the page for buttons to clear the cache.
For development purposes you may want to consider disabling the various caching options on this page entirely - they can be useful for performance improvement on live servers, but are generally an unnecessary hindrance on your development machine.
Clear the Cache Programmatically
If you have an automated deployment, you don't want to have to login to the CF Admin on remote servers and press buttons. Fortunately, you can also clear the cache programmatically:
<cfscript>
createObject("Component", "cfide.adminapi.administrator")
.login("**replace with admin password**");
RuntimeService = createObject("component", "cfide.adminapi.runtime");
// Clear whole cache:
RuntimeService.clearTrustedCache();
// Clear cache for individual files:
RuntimeService.clearTrustedCache("/path/to/file1.cfm,/path/to/file2.cfm");
// Clear component cache:
RuntimeService.clearComponentCache();
</cfscript>
(Code adapted from Charlie's blog entry.)
The API for the Admin Runtime component can be found at http://www.cfexecute.com/admin-api-documentation/runtime-cfc/
We have a set of Coldfusion applications that all extended various parts of an application base. I'll provide a bit of code and then explain the issues we are having and see if anyone can shed light on the best way to trouble shoot this:
In our "OnRequestStart" in the app.cfc we have the following line to initiate a user:
if(!structKeyExists(SESSION, 'user'))
SESSION.user = CreateObject("component","cfcs.ds_user");
Then in the ds_user.cfc we call it like so:
component extends="cas.cas_user" displayname="basic_user"{
The application and all its parts run just like they should. However, in a seeming random manner after a while, the application will crash and I have to restart ColdFusion Service to get it running again. The error I get is:
Could not find the ColdFusion component or interface cas.cas_user.
So, for whatever reason after a while, my application decides it cannot find the path to the parent component. The mapping for that cfc is in the application.cfc at the top as so:
THIS.mappings["/cas"] = "#ReplaceNoCase(currpath,ListToArray(THIS.name,'_')[1],'cas30')#assets\cfcs\";
I want to be sure to say this, the application works perfectly as designed for a random amount of time and then it cannot find the parent component and will not find it again until I restart the ColdFusion Service on the server.
I figure this is somehow a memory leak or something, but I have no idea where to start looking to troubleshoot the issue. We have 6 or so other applications that are extended in the same way and work fine and never crash, but this one does.
EDIT: To be more clear on the mappings. Our applications are located:
root.com/app1
root.com/app2
We created mappings to grab cfcs from app2 while in app1 using the method above. The method, while I believe sort of strange, does work in all of our applications.
EDIT: The correct mappings that display for a while are:
/cfcs - D:\www\app1\assets\cfcs
/templates - D:\www\app1\assets\templates
/cas - D:\www\app2\assets\cfcs
/common - D:\www\app3\assets\common_elements
However once the Application goes in "crashed mode", the dump reveals the mappings are as follows:
/cfcs - D:\www\app1\assets\cfcs
/templates - D:\www\app1\assets\templates
/cas - D:\www\app1\assets\cfcs
/common - D:\www\app1\assets\common_elements
And here is how those mappings are defined at the start of the Application.cfc:
currpath = GetDirectoryFromPath(GetCurrentTemplatePath());
THIS.mappings["/templates"] = "#currpath#assets\templates";
THIS.mappings["/cfcs"] = "#currpath#assets\cfcs";
THIS.mappings["/common"] = "#ReplaceNoCase(currpath,ListToArray(THIS.name,'_')[1],'gum')#assets\common_elements\";
THIS.mappings["/cas"] = "#ReplaceNoCase(currpath,ListToArray(THIS.name,'_')[1],'cas30')#assets\cfcs\";
THIS.name = digisign_CAAAFACBFDFFE or
name_var = (arrayLen(meta_array) >= 2) ? meta_array[arrayLen(meta_array) - 1] & '_' : 'root_';
THIS.name = name_var & right(reReplace(hash(getCurrentTemplatePath()), "[^a-zA-Z]","","all"), 64 - len(name_var));
Where could it be failing. It seems the replace statement isn't working and therefore the appname in the path is not being changed from app1 to app2 when setting the mappings. is it possible this is related to this error we are currently working through: http://forums.adobe.com/message/4657868#4657868 We have yet to apply the Update 4 patch on production. However this problem we believe was happening before CF10. And while we have this issue, it only cropped up recently. This application in question has been crashing like this for a long time.
EDIT:
1. I guess when I say "crash" I mean the application gets into a state, where it will not declare the mappings correctly until I restart Coldfusion. I assume the error in our code causes the crash.
2.This is usually where the issue occurs, when doing this check of the SESSION.user var. I believe it has happened as well, it decides it cannot find our datasource. This is rare.
3. At first I thought yes, but actually no, not that many. Throughout our apps we have several names for common mappings. cas common cfcs templates etc. However D:\www\cas is where the application domain.com/cas30 is located. However a legacy version of that app is located at domain.com/cas. The mapping /cas should go to D:\www\cas30\assets\cfcs and works.
4.We have a dev setup and this never happens. (I assumed it was a load issue which is why it doesn't happen on dev). However, our dev environment is structred as so:
D:\www\deva\app1
D:\www\deva\app2
D:\www\devb\app1
D:\www\devb\app2
What we do (which I think is stupid) is we have a file located not in the same dir as the current app. This file is called application_base.cfc. All of the application.cfcs in the other applications extend from this application_base.cfc. They are not extended from other Application.cfc files. (hope that makes sense) In application_base is a init, onrequeststart, and an onerror. I'll post the App.cfc below. Also some setting are read from XML files both in the application base (to determine environment stuff) and at the application level. However we thought that might be causing the issue so the previous developer removed the xml file at the application level.
6.Yes. I'll post the app.cfc and the appbase.cfc so you can view both.
By reinitialize you mean call onapplicationstart or something. Not that I know of.
A few applications we have do:
currpath = GetDirectoryFromPath(GetCurrentTemplatePath());
app_path = ListToArray(currpath,'\');
THIS.name = app_path[ArrayLen(app_path)];
This one does:
meta_array = ListToArray(GetMetaData(this).name,'.');
name_var = (arrayLen(meta_array) >= 2) ? meta_array[arrayLen(meta_array) - 1] & '_' : 'root_';
THIS.name = name_var & right(reReplace(hash(getCurrentTemplatePath()), "[^a-zA-Z]","","all"), 64 - len(name_var));
A few others do this as well. Not sure if it was two different developers or something, but that is the way it is.
Once the app fails, it fails until I restart coldfusion. The app requires login from the domain.com/app page, so (not saying it cant change from request to request) but the request location is always the same where it's failing.
God I wish it wasn't this complex. I recently pulled our current CMS off of alot of this crazy stuff, but we have 7 or 8 applications that are so intertwined with each other and designed to work in dev/prod environments with different paths, its sometimes hard to tell what I can remove and what I can't.
I thought I tried dumping the applicationname from our error handler, but I thought it didn't work unless passed in. I passed through the mappings so I could see them which is how I know digisign is not changing to cas30 like it should in "crash" mode.
I think all the dynamic mappings were so the original developer could just use the same app.cfc template without changing anything. He liked to do stuff like var a = (b) ? (a-c) ? a-f+b : (a+b) ? d : d; : a; h; crap with no comments so it sometimes hard to just read the damn code let alone debug it.
EDIT
I feel like this issue and stackoverflow.com/q/14300915/1229594 issue may be related. I've posted some more details here as well: forums.adobe.com/message/5022377#5022377
First things first: why are you initialising session-oriented stuff in onREQUESTStart()? If you inited that in onSessionStart(), you'd not need to check for its existence every request, which - whilst trivial - is unnecessary overhead, and is simply the wrong code in the wrong place.
Secondly... you quote your error, but don't say where it's happening. Is it happening in that line in onRequestStart()?
If so, do me a favour: put a try/catch around it, and within that write the value of this.mappings to a log file, as well as the value of currPath. How is the value of that variable being derived, btw?
That said, I think if you just put that session.user init code in the right place, it'll solve your problem.
NB: frame this problem as almost certainly not a memory leak (ie: ColdFusion's fault), but your code doing something you did not anticipate (so... err... your fault ;-). This will help focus better on finding the problem. I'm not having a go at you, but "where is my code wrong" is a better approach than "it's probably something else". And more likely to be correct ;-)
Oh... and what version of CF are you on?
Take a look at this and see if it's relevant to your problem.
https://github.com/Mach-II/Mach-II-Framework/wiki/Application-Specific-Mapping-Workaround
If not, then it could have something to do with application specific mappings of the same name, on the same CF server, with those applications having different application names.
Some questions:
Are you assuming the crash is being caused by the code error, or that the code error is occurring because of the crash?
Is the instantiation of the session user the only line of code that you see these path errors?
Do you have any physical directories in your app that have the same name as the mapping names?
Does this occur in any other environments (dev/test)? Is this a clustered environment?
Are there multiple Application.cfc files extending this same Application.cfc?
Is there any code that is directly calling Application.cfc methods?
Are there any bits of code that cause the application to reinitialize itself?
What is determining the meta_array that is being used to derive the application name?
A few observations:
It seems to me that the application name is getting changed or that some other application is overwriting with the same name. This doesn't seem far-fetched as there's an awful lot of dynamic naming going on here. Starting with the application name, it's dependent on the current template's physical location, which could be different from request to request, depending on how the app routes requests. If the current template varies, the application name will vary, and cause the other app-specific mappings to change, which would cause a cascading effect to all the other mappings that use the app name to determine the physical location of those mappings.
Which begs the question: Why is all this dynamic evaluation of the application name and mapping locations even necessary? Can it be simplified or hard-coded? Can you instead use a server mapping? If it doesn't have to be this complex, simplifying it to its barest essentials will help troubleshooting and may clear up the issue entirely.
Finally, can you verify that the application name during normal operation is the same application name being referenced when the errors are occurring?
If they are different, then something is causing the application to execute within a different context (see my initial questions above for clues). A sudden change in the application name would invalidate any existing sessions and force the session user instantiation code to re-run. And because the user component paths are based in part on the application name, the paths may no longer be correct.
But if the application names are the same between normal operation and crash mode, then most likely the currpath variable is being affected by some part of the application being executed in a different physical path than expected. Since currpath is directly used in determining the rest of the mappings, that could certainly explain why an unexpected path could cause the component to go missing.
Because there are so many variables going into deriving these names, you would be well served to log those variables during normal operation and during crash mode. You'll want to see
GetCurrentTemplatePath()
GetDirectoryFromPath(GetCurrentTemplatePath())
THIS.name
meta_array
THIS.mappings
I suspect you'll find something significantly different in these variables when operating normally and when the crash/errors are occurring, and that difference should lead you closer to the answer.
What method should I use to determine if I'm on the dev system vs. production?
In this post from Ray Camden, he shows how to see what folder you're in, so that could be an indicator.
While in dev, I want to have error trapping turned off, missing template turned off, debug="yes" for cfstoredproc and cfquery, as well as always reload the components onRequestStart.
I have two approaches to this, both of which have served well. I'll start with the easiest approach first, which is what I'd call a "static". I use this when I don't have many environment-specific settings... maybe a small handful.
I'm assuming you have an Application.cfc or .cfm file for your app. In there, you could set a variable, something like "application.environment", and by default it'd be set to "dev". Throughout your app you could inspect that variable to determine where you are.
When you package your application for deployment, you could then change that Application.cfc file to read "" instead.
Now, that's going to get annoying, so I just use ant for this. I just use something like this in my build.xml, which lives in the same directory as Application.cfc:
<replace file="Application.cfc" token="DEV" value="PROD" casesensitive="true" />
And then zip the app for deployment:
<zip destfile="${zipdir}/MyApp-Production.zip">
<zipfileset dir="." prefix="MyApp" />
</zip>
Then I deploy the zip. If I'm working on a small project that uses FTP instead of some corporate enterprisey deployment hooey, then I'll just have an ANT task that FTPs files to my production server and it'll also perform that replace on Application.cfc and push that file, too.
For most of the apps I work on where I work, we use two database tables to manage environments. We do this because we have a lot of different environments, and each one has different settings, usually centered around filesystem and network paths that differ per environment (let's not talk about why they're different... totally separate discussion). So We have a table we call "AppLocations":
LocationID | LocName | LocDesc | Setting1 | Setting2 | Setting 3| ......
1 | Local | 'Localhost Environment' | whatever.....
2 | Dev | 'Development Environment' | whatever....
3 | Test | 'Test Environment' | whatever.....
and so on.
Then, we have another table named "AppLocationHosts"
LocationID | LocHostName
1 | 'localhost'
2 | 'devservername'
2 | 'otherdevservername'
3 | 'testservername'
3 | 'othertestserver'
and so on.
then, in Application.cfc, in onApplicationStart, we do this query
SELECT TOP 1 *
FROM AppLocations
WHERE LocationID IN (SELECT LocationID FROM AppLocationHosts WHERE LocHostName = <cfqueryparam value="#CGI.HTTP_HOST#" cfsqltype="cf_sql_varchar"/>)
And from there, once we know what location we're in based on the http_host match, we set those "Setting" columns into the application scope:
<cfloop list="#qryAppPathLocations.ColumnList#" index="ColName">
<cfset application[ColName] = qryAppPathLocations[ColName]>
</cfloop>
This approach isn't for everyone, but in our weird environment where consistency is unusual, it's been a very flexible approach.
Now, if you literally only have two environments, and one of them is "localhost" and the other is "www.myapp.com", then by far the easiest would be to just do a check on http_host in onApplicationStart and if you're in "www.myapp.com", then you do your production-specific setup. Perhaps here you set stuff like "request.querydebug = true" and then when you're in production, you turn that off. Then your queries could use that flag to determine whether to turn debug on or off for the cfstoredproc and query. Though I must say, I strongly recommend against that.
Can you just enable debugging in CFAdmin on your Dev box for your IP then use IsDebugMode()?
Dump the #server# scope and you'll see some keys that may help - eg the license mode of ColdFusion.
The solution we use is to set the IP of the current instance, and check it against our known "dev" IPs. Simple, easy, works.
A lot of good answers here - I'd like to mention using cgi.server_name , which can be combined with using a custom DNS to specify your dev environment. To get the localhost working, for IIS on Windows, set up hosts file like e.g. this:
C:\Windows\System32\drivers\etc\hosts - add entry:
127.0.0.1 myapp.dev.mydomain.com.au
Then in IIS map your server to this DNS.
Your systest and uat servers might be set up properly in your corp's DNS, such as
myapp.systest.mydomain.com.au - systest
myapp.uat.mydomain.com.au - uat
myapp.mydomain.com.au - production
Then, in my application.cfc I have a getEnvironment() that is called on every load for ease of use:
// get the environment based on cgi variables - top of application.cfc
this.stConfig = THIS.getEnvironment();
//... onApplicationStart
if (!stConfig.validEnvironment) {
writeOutput("Environment #cgi.server_name# not recognised");
return false;
}
// ...
public struct function getEnvironment () {
stConfig=structnew();
stConfig.validEnvironment = 1;
switch (cgi.server_name) {
// my dev environment
case "myapp.dev.mydomain.com.au": {
stConfig.env = "dev";
// +++
}
// my dev environment
case "myapp.systest.mydomain.com.au": {
stConfig.env = "systest";
// +++
}
// etc
}
return stConfig;
}
I will also copy stConfig to the request scope.
Now, I've got a lot of other stuff there too, and there's lots of ways to implement the storage of environments, e.g. but basically I find the combination of DNS and cgi.server_name particularly well suited to managing environments.
Fwiw, I will include ini files in application.cfc based on the environment name that I use for storing environment specific configurations. I find the getProfileSections() very useful for this, as the config files are very easy to work with. I have one common file that is shared between all environments, and then environment specific ones for those settings that need to be tailored to each environment.
Is it possible to get the directory of the currently running application?
Consider this directory structure for the different "instances" of your application:
/home/deploy/DevLevel.0/MyApp
Production Version
/home/deploy/DevLevel.1/MyApp
Preview or Staging Version
/home/deploy/DevLevel.2/MyApp
Development Version
If you can read the path to the current application, it's easy to find the integer after DevLevel. With that in hand (set as a global variable/constant), use it to change settings or behavior at runtime:
DevLevel == 0 means "Production"
DevLevel >= 1 means "Development"
For example, in the credit card authorization code:
if(DevLevel > 0)
enable_test_mode();
In error handling code:
if(DevLevel == 0)
send_error_to_log();
else
print_error();
Conclusion
The primary benefit here is that the code between the versions can remain 100% identical . No more "forgetting to enable this or disable that when moving code live".
Can this be implemented in ColdFusion?