I'm trying to get a Play (2.1) app with ReactiveMongo (0.9) working on the app's test server. However, when our application is run on my dev box, is able to store image metadata just fine, even pointing to the mongo 2.2 install on the mongo test server. Even ran it with "play stage", then run directly with java 1.6.0. However, run the same way, also with Java 1.6.0 on the test server, the app continuously logs this error:
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
And not just during initialization... it repeats indefinitely. I've seen this error mentioned elsewhere, but I don't think those solutions apply to this. From the app's test server, I'm able to telnet to port 27017 on the mongo test server successfully. I see both my local install and the test server install of the app log that it's using the same mongodb url.
So based on what I said, I believe I can eliminate:
Blocked port
Mongo server down
Pointing to wrong mongo server
Mongo version mismatch
Java version mismatch
I'm going through the reactivemongo source but it seems the error is spewed when the MongoChannels are not set as authenticating or ready state (usable). I'm planning to try remote-debugging to see where it's going wrong, but I'm running out of time on this, so I'm hoping for a troubleshooting tip or two if I can get any.
Thanks!
Alright, figured it out. We're running Casbah/Salat on the same app, for now. There's a mongodb.uri in the config file that gets read in by both. However, ReactiveMongo seems to only work if the database name is included, which according to the mongodb "connection string uri" spec:
http://docs.mongodb.org/manual/reference/connection-string/
... you only need to include the database if you have credentials you need to authenticate with. In our case, we don't have credentials, so Casbah wasn't including the database. I added it in anyway... casbah ignored it safely, and reactivemongo worked. I neglected to do the same in the test config file, so even though it was showing the correct host, it wasn't about to work correctly.
I see how the host url + db name in one string replaces the two fields "mongodb.servers" and "mongodb.db", but it can be confusing if not conforming to mongo's similar spec.
Related
For this project, I am using a prisma / Postgres database. I have made no changes to my code, and I have pulled a coworkers working version of the code to no avail. I am unable to do anything with the database, I cannot migrate, I cannot run mutations, and I cannot even open the psql console, as every command is met with
P1001: Can't reach database server at localhost:5432
Please make sure your database server is running at localhost:5432
I am not sure what I could have possibly done, I don't know enough about ports or even the contents of app.json well enough to have messed anything up. Now, no mutations can go through.
Interestingly enough, this all happened after I ran npx primsa migrate deploy on the deployed database which is on a EC2 VM from AWS. Since then, the native app associated with the database refuses to work, though it is worth nothing that the webapp connects to the deployed database just fine. This being said, nothing works locally, as the database / Port / Server don't exist anymore according to my machine, which makes no sense. I have no idea how to try to re-spin it, or why every single query / mutation from my Native App now ONLy returns Response not successful: Received status code 400 despite it having the same exact syntax it did when it worked, as well as the WebApp having the same syntax and server (ExpressJS). Does anyone have any ideas what could be causing this?
The error code 400 refers to a bad request coming from the client: too large request, malformed syntax, invalid request message framing, etc.
First step: make sure that your database server is indeed running. Try connecting to it with other SQL Clients or Libraries. Sometimes Prisma is just being difficult.
Second thing: are you hosting the database on the local server? I can assume you are because of the localhost. Make sure no other programs are using this port or maybe waiting for it.
Sorry if this doesn't help. Good luck!
I've been using Mongo for a while now, and I never had any kind of errors. But today, I tried running the mongo command in my terminal and I got the following error:
Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
I have my PATH variable for Mongo properly configured in my environment variables as follows:
C:\Program Files\MongoDB\Server\4.4\bin
so I doubt that is the issue. I remember going through my task manager yesterday and I accidentally terminated a program running in the background related to Mongo, but I can't seem to remember exactly what it was called, and I really think that that's the root of my problem, because before having terminated that Mongo program in my task manager I had never ran across this connection problem before.
By terminating a program in the background, I'm going to assume you didn't just end process, otherwise a simple computer restart would fix your issue. And in some cases, that same program would've relaunched when you launched MongoDB. But if you disabled a service and need to find which service needs to be running to be able to connect to your MongDB then I would suggest going through your Windows Services list and seeing which ones you disabled and looking one relating to TCP or SNMP.
This is because MongoDB Wire Protocol is a simple socket-based, request-response style protocol. You communicate with the database server through a regular TCP/IP socket and since you can't remember which one you "terminated" and any number of services related to networking can cause a dependency to be absent, I can't be more specific in helping you determine which one you need to turn back on and you'll have to do it through trial and error but I can at least offer you some guidance, hopefully.
Specifically you can either
Run system configuration using
msconfig
In a run box, navigating to the Services tab, order the list by Date Disabled to find the service that was disabled which correlates with when you when snooping through task manager, or
Run Task manager and navigate to the Services Tab, then Open Services, and order them by Status or by Name, and look for any service that includes TCP/IP, COM+, Port direction, etc. to see which one is disabled and change the configuration from anything but Disabled and then stat it manually and run MongDB again.
It's about as specific as I can get without knowing anything more than you terminated some program running in the background but I hope it helps.
The background process (daemon) for MongoDB is called 'mongod'. It's an executable in your bin directory inside your mongodb installation. You can just execute it in the terminal.
Run:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe
I'm trying to set up Geoportal 1.2.4, running on Apache Tomcat 8.5.6, Postgres 9.0.6_1, JDK 6, and jdbc(postgresql-9.1-901.jdbc4.jar). I cannot log into the Geoportal, When I log in using admin details (),I
get this error
"A database communication error has occurred"
Checking the Apache logfiles, I see there's a severe error
I have tried a range of different entries in the config for the jdbc, but it always comes back to that error.
That is just my latest attempt. I have seen conflicting posts all over the net about exactly what the url should look like.
I checked the rest of the config files carefully, and the editing within them was minimal and probably has no play on the error.
If anyone could point out my mistake it would be appreciated.
I moved a mongoDB from one atlas cluster to a different account/different cluster.
To do this I did a dump from the source db and a restore to the new account's cluster.
I did NOT have a problem restoring the db - that went fine - I can visually confirm that the hashes in the new db ARE the same as the old.
When I try to login to my app (pointed to the source) I get in fine, when I change my db setting and point to the new db I get a log in failed.
The api code is the same - running locally, the only thing that is different is the connection string.
I am using bcrypt to hash the passwords - but because the api is sitting on my local machine, that kind of takes any application layer variable out of my problem list.
With the exception of the connection string - I was using the 3.1 driver connection string to connect to the 'old' version, and I decided to try the 3.6 driver version to connect to the 'new'.
Can someone confirm that moving a db from one cluster to another, using the dump and restore method SHOULD not effect hashed password matching.??
And maybe offer suggestions on where to look for answers?
so the only difference on the code is this:
// Old
DB_URI=mongodb://u***:p***#dev0-shard-00-00-1xxx.mongodb.net:27017,dev0-shard-00-01-1xxx.mongodb.net:27017,dev0-shard-00-02-1xxx.mongodb.net:27017/db?ssl=true&replicaSet=Dev0-shard-0&authSource=admin
// new
DB_URI=mongodb+srv://n***:h***#prod-xxx.mongodb.net/test?retryWrites=true
Ok, So I finally got around to playing with stuff, and since the URI was the only change, I switched back to the 3.4 driver syntax (that long ungodly string), and it works fine.
For the record, all my "open" (non-authenticated) API calls, such as with signup, or requesting a forgotten password. and a slew of drop down lookup, all processed thru the api with the 3.6 driver, I also signed up and logged in fine - the only issue is logging in with an account that was created in the previous cluster, with the new driver connection string.
And as confirmation - now that I switched the connection string back to 3.4 - I cannot log into the account I created with the 3.6 connection string.
I'm using the datanucleus mongodb maven plugin and "access platform" for connecting my java app to mongodb using JPA.
I've followed the instructions on http://docs.mongodb.org/manual/tutorial/deploy-replica-set/
on a ubuntu VM, added db1.mongo, db2.mongo and db3.mongo into the hosts file on both the guest vm and the host (Mac OS X).
I got a simple java app connecting to the servers, (as described in http://www.datanucleus.org/products/accessplatform_3_0/mongodb/support.html).
When I connect the app to the primary (connection url: mongodb:db1.mongo:27017/ops?replicaSet=rs0) everything works just fine, but when I add the other two mongodb's to the connection url, so it becomes mongodb:db1.mongo:27017/ops?replicaSet=rs0,db2.mongo:27018,db3.mongo:27019 I get the exception:
com.mongodb.MongoException: can't find a master
at com.mongodb.DBTCPConnector.checkMaster(DBTCPConnector.java:503)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:236)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:216)
...
I've searched for this error, but the ones I have found concerns use of localhost/127.0.0.1. I tried to mitigate that by running mongodb on a separate VM and thus a non-local IP as well as adding the names to the hosts file.
The primary goal with trying mongodb is to achieve availability so replication and being able to failover is extremely important. Transactions and consistency between nodes in case of failure is not a problem, neither are we concerned about loosing an update or two once in a while so mongodb looks like a good alternative using JPA (I'm utterly fed up with mysql :-)
Thanks in advance for your help!
I used multiple MongoDB servers when I originally wrote that support and worked back then. Not got time now, but you can look at the DataNucleus code that parses your datastore connection URL and converts it into MongoDB java API calls. Should strip the servers apart and then call "new Mongo(serverAddrs);". If its passing it in correctly (debugger?), then the problem is possibly Mongo-specific, as opposed to what DataNucleus does for you.
Also make sure you're using v3.1.2 (or later) of datanucleus-mongodb
I think you've misformatted your MongoDB URI. Instead of this:
mongodb:db1.mongo:27017/ops?replicaSet=rs0,db2.mongo:27018,db3.mongo:27019
Do this:
mongodb:db1.mongo:27017,db2.mongo:27018,db3.mongo:27019/ops?replicaSet=rs0