I deployed a WAR in a non-scaled app on OpenShift with JBoss AS7 and a Postgres DB and it works fine.
I deployed the same WAR in a scaled app (otherwise same set up) and it fails whenever it tries to talk to the DB.
The error is: org.postgresql.util.PSQLException: FATAL: database "/" does not exist
I had a sort of similar looking issue with the HAProxy configuration, since the haproxy.cfg assumes the domain root context (i.e. "/"), but the actual context includes the WAR file name (i.e. "/warname/"). Updating haproxy.cfg to fix the context solved that problem, and I'm guessing that there is a similar configuration solution to connect to the DB, which is in a separate gear since the app is scaled.
Can anyone steer me in the right direction?
Thanks
If you are running a scaled application, the port that PostgreSQL runs on it a non standard port, make sure that you are using all of the environment variables to connect to your database and it should be fine. SSH into your gear and run env | grep POSTGRES and you should see all of the environment variables you should be using. Also note that your host is now an FQDN instead of a local address.
It turns out that the OPENSHIFT_POSTGRESQ_DB_URL environment variable may or may not include a trailing "/" (for non-scaled apps it is not there, for scaled apps it is), so appending "/dbname" works for non-scaled apps, but doubles up the "/" for scaled apps, which is obviously wrong. By writing safer code to check for the presence of the trailing "/" the problem is solved.
Related
I have a Meteor App running on a Ubuntu Droplet on Digital Ocean (your basic virtual machine). This app was written by a company that went out of business and left us with nothing.
The database is a MongoDB currently running on IBM Compose. Compose is shutting down in a month and the Database needs to be moved and our App needs to connect to the new database.
I had no issues exporting and creating a MongoDB with all the data on a different server.
I cannot for the life of me figure out where on the live Meteor App server I would change the address of the database connection. There is no simple top level config file where I can change this?? Does anyone out there know where I would do this?
I realize that in the long term I will need to either rewrite or deprecate this aging app, but in the short term the company relies on it and IBM decided to just shut down their Compose service so please help!!
There is mostly the MONGO_URL and MONGO_OPLOG_URL that are configured as environment variable: https://docs.meteor.com/environment-variables.html#MONGO-OPLOG-URL
Now you don't set these within the code but during deployment. If you are running on localhost and want to connect to the external MongoDb you can simply use:
$ MONGO_URL="mongodb://user:password#myserver.com:port" meteor
If you want to deploy the app, you should stick with the docs: https://galaxy-guide.meteor.com/mongodb.html#authentication
If you use MUP then configure the mongo appropriately: https://meteor-up.com/docs.html#mongodb
Edit: If your app was previously deployed using MUP you can try to restore the environment variables from /opt/app-name/config (where app-name is the name of your app) which contains env.list (including all environment variables; thus your MONGO_URL) and start.sh which you can use to recreate the mup.js config.
I'm trying to deploy an infinisppan cluster (2 machines) using the domain mode. But I can't find any working example of domain.xml and host.xml config file.
This cluster would be used by keycloak as a cache server
Any luck one of you already work on this ?
You need to download infinispan 9.4.14 (or any 9.4) and start the bin/domain.sh [bat] script.
That's it you have a running domain with two servers.
If you want to add a second machine you need to copy the server and start the domain script by passing "--host-config=host-slave.xml" also you need to set "jboss.domain.master.address=" with "-D" to let the process know where the domain master is.
Anothe option is to move host-slave.xml-->host.xml and edit the domain-controller discovery-options.
More information can be found here -> http://infinispan.org/docs/stable/server_guide/server_guide.html#domain_mode
I have a php project which I want to test on localhost. I was suggested to use a no-ip domain name. I've done that and using this tutorial
and now I have a directory with a name same as the domain name on localhost. The project was previously connected a similar no-ip domain name(I wasn't present at that time) but then it expired and I'm setting it up again.
I have replaced every instance of the previous no-ip domain name in the code base with the no-ip domain name that I created and changed the project's Run Configurations in NetBeans but when I navigate to the domain name I don't see the obvious changes I've made in the development code.
When I test the connection it succeeds and when I save changes the Remote Log say that the changes have been saved and that the file has been received. When I navigate to localhost/shhasan.ddns.net I get a database error which points to Loader.php. I've checked Database.php and its the same setup which has worked before as the username, password, hostname is consistent with those on phypmyadmin. I've been stuck at this issue for 2 days now I would really appreciate help.
Your Loader.php is looking for a database/DB.php, but you only have a database.php.
I am trying to set up a local version of PostgreSQL for use with my Rails app on Heroku according to the instructions at https://devcenter.heroku.com/articles/heroku-postgresql#local-setup.
When I grep'd for different heroku configurations
(heroku config | grep HEROKU_POSTGRESQL)
I got the following return:
HEROKU_POSTGRESQL_AQUA_URL: postgres://mzqgqmkhlsgufo:Hk-Nu5SF6amY9mgl2n6u-Yi6U-#ec2-54-243-228-246.compute-1.amazonaws.com:5432/d8jndm2sub3lbt
HEROKU_POSTGRESQL_VIOLET_URL: postgres://nviwubpznhhgkv:siEYPLdOknBWOj1K3HePMn21DS#ec2-54-243-188-54.compute-1.amazonaws.com:5482/ddr1fm1ou7ha9s
Do the different colors have any significance? Would I be better served using one over the other or are they just random colors? Sorry if this is a silly question, but I wasn't about to find a question addressing this.
Without digging into it very much, I think the main difference for you would be the port they listen on. Aqua listens on the PostgreSQL default port of 5432; violet on 5482. They seem to have different IP addresses, too, which might or might not affect you. (I don't recall off the top of my head how apps connect to Heroku.)
If you're installing locally, and you've never installed PostgreSQL before, it will probably listen on the default port, 5432.
The color names don't mean anything to PostgreSQL. That just seems to be a naming convention Heroku uses in managing their services.
Short Answer:
They are random colors.
You only get these colors when you have more than one database added onto your application.
Quoting Heroku:
As part of the provisioning process,a DATABASE_URL config var is added
to your app’s configuration. This contains the URL your app uses to
access the database. If your app already has a Heroku Postgres
database and you’ve just provisioned another one,this config var’s
name instead has the format HEROKU_POSTGRESQL__URL (for
example,HEROKU_POSTGRESQL_YELLOW_URL).
SOURCE:
https://devcenter.heroku.com/articles/heroku-postgresql
I found couple of tutorials how to run multiple instances of JBoss on the same machine.
All of them mention uncommenting Service Binder and having separate service-binding.xml files for each server.
The question is why it's done like that? Is there any reason except adding additional layer of indirection?
It looks the same could be done by modification of ports in jboss-service.xml for each server. The only restriction would be that there won't be easy way to switch which instance of JBoss uses which set of ports.
You are right with modifying the ports in jboss-service.xml. This is the straightforward and genuine way to change the ports.
Unfortunately, ports are not only defined in that file, but also in other places like jboss-web's configuration etc.
Catching all those places can be error prone.
So the idea was to have a central file (service-binding.xml) that lives in the root of a server installation. You basically copy the 'default' config to server1, server2 etc and then via command line pass in the server name when starting so that the correct port-offset for all of the services is taken from service-bindings.xml and applied to the resulting runtime configuration.
JBossAS 7 takes this concept one step further to the ServiceBindingGroups, where the base ports are defined on a domain level and then per server you pick a basic group + just a port offset by name, so that there is even less work needed than in as4