MongoSocketOpenException when starting MongoClient with mongo-java-driver - java

I'm running a java web server on Windows with a local MongoDB database using
mongo-java-driver 3.2.2
When starting the server I create a new MongoClient:
MongoClient mongoClient = new MongoClient("localhost:27017", options);
(options contain some CodecRegistries)
Right after running the server I get the following log:
com.mongodb.diagnostics.logging.SLF4JLogger info
INFO: Exception in monitor thread while connecting to server localhost:27017
com.mongodb.MongoSocketOpenException: Exception opening socket
...
But then, after a few seconds, the server starts and I get the following log:
com.mongodb.diagnostics.logging.SLF4JLogger info
INFO: Opened connection [connectionId{localValue:2, serverValue:1}] to localhost:27017
com.mongodb.diagnostics.logging.SLF4JLogger info
INFO: Monitor thread successfully connected to server with description
ServerDescription{address=localhost:27017, type=STANDALONE,
state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 2,
0]}, minWireVersion=0, maxWireVersion=4, maxDocumentSize=16777216,
roundTripTimeNanos=1691281}
I couldn't find a reason why the client would fail to connect for the first time and then recover but this behavior seems consistent with every run.
Did anyone come across similar behavior? If so, how could I solve the problem?
I'll provide any additional information if needed.

turn off mongodb logger in log4f.properties like:
log4j.logger.org.mongodb = OFF
notice it is org.mongodb not com.mongodb

Related

Failed to connect Azure servicebus topic using JMS - Java

I followed steps as mentioned in Azure ServiceBus JMS Sample with below properties
spring.jms.servicebus.connection-string=Endpoint=sb://test-dt.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=key
spring.jms.servicebus.topic-client-id=12345
spring.jms.servicebus.idle-timeout=18000
spring.jms.servicebus.pricing-tier=Standard
however I get below error
ERROR 43904 --- [ntContainer#0-1] org.apache.qpid.jms.JmsConnection : Failed to connect to remote at: amqps://test-dt.servicebus.windows.net:-1
ERROR 43904 --- [ntContainer#0-1] o.s.j.l.DefaultMessageListenerContainer : Could not refresh JMS Connection for destination 'test-topic' - retrying using FixedBackOff{interval=5000, currentAttempts=6, maxAttempts=unlimited}. Cause: handshake timed out after 10000ms
On the other hand, I followed steps as mentioned in ServiceBus without JMS and added transportType as AmqpTransportType.AMQP_WEB_SOCKETS then I am able to connect.
We want to implement using spring boot starter and listener method, instead of calling from (public static void main) method.
Please guide on what am I missing when following first link
ERROR 43904 --- [ntContainer#0-1] org.apache.qpid.jms.JmsConnection : Failed to connect to remote at: amqps://test-dt.servicebus.windows.net:-1
To resolve above error, try as suggested by Anand Sowmithiran:
Check if port 5671 is blocked:
telnet <yournamespacename>.servicebus.windows.net 5671
Note: Clients that use AMQP connections over TCP require ports 5671 and 5672 to be opened in the firewall. Along with these ports, it might be necessary to open additional ports if the EnableLinkRedirect feature is enabled.
You can refer to Troubleshooting guide for Azure Service Bus, AMQP outbound port requirements and Port 5671 Blocked :(. What are other options?

Cant run index.jsp from web aplication

I made Java Enterprise app using Java 15.0.2 and GlassFish 4.1.1.
This is what I got in glassfish output:
`C:\Users\s\Documents\Java\glassfish4\glassfish\bin\asadmin.bat start-domain domain1
Attempting to start domain1.... Please look at the server log for more details.....
C:\Users\s\.jdks\openjdk-15.0.2\bin\java.exe -Dfile.encoding=windows-1252 -classpath C:\Users\s\AppData\Local\Temp\classpath1367306742.jar com.intellij.javaee.oss.process.JavaeeProcess 64094 com.intellij.javaee.oss.glassfish.agent.Glassfish31Agent
[2021-03-19 09:07:21,872] Artifact demo:war exploded: Waiting for server connection to start artifact deployment...
Detected server admin port: 4848
Detected server http port: 8080
`
Unable to ping server at localhost 4848
Use the ping-connection-pool subcommand in remote mode to test if a connection pool is usable. For example, if you create a new JDBC connection pool for an application that is expected to be deployed later, you can test the JDBC pool with this subcommand before the application is deployed. Running a ping will force the creation of the pool if it hasn't already been created.
Before You Begin
According to Oracle Glassfish admin guide
Before you can contact a connection pool, the connection pool must be created with authentication, and the server or database must be running.
Ensure that the server is running.
Remote subcommands require a running server.
Ping a connection pool by using the ping-connection-pool(1) subcommand.

Can't connect to postgres db with jdbc

Note: I'm calling the security service the problem service here, but I doubt I can connect to the DB with any service- security is just the first one that has to do it.
I'm trying to modify a java application to use postgres instead of oracle, I'm getting connection issues, and my logs are not helpful.
The database is on a remote server, but it is being accessed successfully by other applications. I can connect with the postgres client without issue.
Any ideas where I should look?
The errors:
from the service I'm calling:
2020-08-11 14:47:37 INFO AuthenticationService:32 - Rest Services - starting authentication...
2020-08-11 14:47:38 ERROR AuthenticationService:119 - GetUserInfo: trying to connect to the Rest Serrvice, attempt 1, HTTP Error Code: 500
2020-08-11 14:47:38 ERROR AuthenticationService:120 - Response message: Internal Server Error
2020-08-11 14:47:38 ERROR AuthenticationService:146 - Problem getting User Info: Problem getting User Info 500, message: Internal Server Error
2020-08-11 14:47:38 ERROR AuthenticationService:62 - Problem getting User Info: Problem getting User Info 500, message: Internal Server Error
From the underlying problem service:
2020-08-11 14:47:38 INFO SecurityService:67 - Rest Services - getUserInfo
2020-08-11 14:47:38 INFO SecurityService:87 - Getting User Info from DB...
2020-08-11 14:47:38 ERROR SecurityService:110 - Couldn't establish connection to Database
My context.xml for problem service (resource section is identical in both services):
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/PhoenixSecurity" docBase="PhoenixSecurity"
crossContext="true" reloadable="true" debug="1">
<Resource name="jdbc/CtsRest" auth="Container"
type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://CORRECT-IP:5432/phoenix"
username="validUser" password="validPassword" maxActive="100" maxIdle="100" maxWait="-1"/>
</Context>
In troubleshooting these sorts of problems check the following in order:
Can you connect to PostgreSQL from another machine on the LAN? If not, it may not be listening on the address?
Can you connect locally? Is it even running?
Now in the case where the second succeeds and the first fails, here are things to check in order:
listen_address in postgresql.conf
firewall rules
Anything in between that might interfere with the network connections.
*Sometimes when you pass localhost in the jdbc url this will be mapped to ipv6 address. Try specifying the the ip4 address explicitly.
Turns out my issue was assuming that the jdbc driver for postgres could create a connection the same way as the one for oracle. It can't. Lesson learned.

Why my spring Application keep on opening a new connection to cloud atlas mongoDB?

These are the logs that i am getting repeatedly after application Started
2020-01-22T12:55:34,811 INFO [cluster-ClusterId{value='5e27f56499adc55f60198441', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:429, serverValue:273700}] to x:27017
2020-01-22T12:55:34,856 INFO [cluster-ClusterId{value='5e27f56499adc55f60198441', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:428, serverValue:275417}] to x:27017
2020-01-22T12:55:35,168 INFO [cluster-ClusterId{value='5e27f56499adc55f60198441', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Monitor thread successfully connected to server with description ServerDescription{address=x:27017, type=REPLICA_SET_PRIMARY, state=CONNECTED, ok=true, version=ServerVersion{versionList=[4, 2, 2]}, minWireVersion=0, maxWireVersion=8, maxDocumentSize=16777216, logicalSessionTimeoutMinutes=30, roundTripTimeNanos=181132909, setName='x-0', canonicalAddress=x:27017, hosts=[x:27017, x:27017, x:27017], passives=[], arbiters=[], primary='x:27017', tagSet=TagSet{[Tag{name='region', value='AP_SOUTH_1'}, Tag{name='nodeType', value='ELECTABLE'}, Tag{name='provider', value='AWS'}]}, electionId=7fffffff000000000000003e, setVersion=2, lastWriteDate=Wed Jan 22 12:55:30 IST 2020, lastUpdateTimeNanos=180151204451076}
2020-01-22T12:55:29,659 INFO [cluster-ClusterId{value='5e27f56499adc55f60198441', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:424, serverValue:276311}] to x:27017
2020-01-22T12:55:30,054 INFO [cluster-ClusterId{value='5e27f56199adc55f60198440', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:425, serverValue:273700}] to x:27017
2020-01-22T12:55:33,603 INFO [cluster-ClusterId{value='5e27f56199adc55f60198440', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:426, serverValue:278143}] to x:27017
2020-01-22T12:55:34,663 INFO [cluster-ClusterId{value='5e27f56199adc55f60198440', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:427, serverValue:275417}] to x:27017
2020-01-22T12:55:34,742 INFO [cluster-ClusterId{value='5e27f56199adc55f60198440', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Monitor thread successfully connected to server with description ServerDescription{address=x:27017, type=REPLICA_SET_PRIMARY, state=CONNECTED, ok=true, version=ServerVersion{versionList=[4, 2, 2]}, minWireVersion=0, maxWireVersion=8, maxDocumentSize=16777216, logicalSessionTimeoutMinutes=30, roundTripTimeNanos=133861489, setName='x-0', canonicalAddress=x:27017, hosts=[x:27017, x:27017, x:27017], passives=[], arbiters=[], primary='x:27017', tagSet=TagSet{[Tag{name='nodeType', value='ELECTABLE'}, Tag{name='provider', value='AWS'}, Tag{name='region', value='AP_SOUTH_1'}]}, electionId=7fffffff000000000000003e, setVersion=2, lastWriteDate=Wed Jan 22 12:55:30 IST 2020, lastUpdateTimeNanos=180150777860085}
2020-01-22T12:55:34,811 INFO [cluster-ClusterId{value='5e27f56499adc55f60198441', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:429, serverValue:273700}] to x:27017
2020-01-22T12:55:34,856 INFO [cluster-ClusterId{value='5e27f56499adc55f60198441', description='null'}-x:27017] com.mongodb.diagnostics.logging.SLF4JLogger: Opened connection [connectionId{localValue:428, serverValue:275417}] to x:27017
The cluster is M0 from cloud mongo atlas.
Whenever we whitelist some ip, the connections spikes above 100 which is the max.
The connections drop once we remove that IP from the whitelist.
The strange part is even if we are not making any connections through the web-server on that I.P., the connections spike up.
Is is something related to monitor thread trying to reconnect even thought it gets connected.
We had a similar issue before, where the connections spiked even if we just whitelisted an IP. It was a strange issue, because we didnt make any connection from that whitelisted IP still the connection spiked.
But the solution was pretty strange, we restarted one of the developers system.
What we could suspect was, he had previously had many connection through, NoSQL Booster, terminal or through the local debug deployments itself.These connections didn't close by themselves and came up whenever his laptop connected to any whitelisted IP.
Pretty simple solution to the weird situation. Maybe you can try restarting the system.

MongoDB trying to connect to localhost, Why?

I am currently developing a Java application connected to a remote MongoDB databse.
I have implemented the authentication methods fallowing the mongo guides:
MongoCredential credential = MongoCredential.createScramSha1Credential(username, credentialDatabase, password.toCharArray());
MongoClient client = new MongoClient(new ServerAddress(hostname, port), Arrays.asList(credential));
mongoDatabase = client.getDatabase(database);
The app connect properly to the database but there is a thing i can't understand.It connects well to the remote server,but I don't know why it try to connect to localhost:27017.
2016-03-07 16:13:29.662 INFO 12507 --- [*.*.*:25015] org.mongodb.driver.connection : Opened connection [connectionId{localValue:1, serverValue:29}] to *.*.*.*:25015
2016-03-07 16:13:29.687 INFO 12507 --- [*.*.*:25015] org.mongodb.driver.cluster : Monitor thread successfully connected to server with description ServerDescription{address=*.*.*.*:25015, type=STANDALONE, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 2, 3]}, minWireVersion=0, maxWireVersion=4, maxDocumentSize=16777216, roundTripTimeNanos=24485426}
2016-03-07 16:13:30.062 INFO 12507 --- [ main] org.mongodb.driver.cluster : Cluster created with settings {hosts=[localhost:27017], mode=SINGLE, requiredClusterType=UNKNOWN, serverSelectionTimeout='30000 ms', maxWaitQueueSize=500}
2016-03-07 16:13:30.220 INFO 12507 --- [localhost:27017] org.mongodb.driver.cluster : Exception in monitor thread while connecting to server localhost:27017
com.mongodb.MongoSocketOpenException: Exception opening socket
So, how can I tell it I don't want to connect to localhost ?
Thanks
You can exclude Mongo auto connect/(localhost:27017) by adding below annotation on spring boot Application.java.
#EnableAutoConfiguration(exclude={MongoAutoConfiguration.class})
public class Application {
// ...
}
I'm not sure if this will help.
If you are using SpringBoot 1.4 and you will not have a bean for MongoClient in the context auto configuration will create MongoClient using default configuration.
#Configuration
---->#ConditionalOnClass(MongoClient.class)<----
#EnableConfigurationProperties(MongoProperties.class)
#ConditionalOnMissingBean(type = "org.springframework.data.mongodb.MongoDbFactory")
public class MongoAutoConfiguration {
...
#Bean
---->#ConditionalOnMissingBean<----
public MongoClient mongo() throws UnknownHostException {
this.mongo = this.properties.createMongoClient(this.options, this.environment);
return this.mongo;
}
...
So you have 3 options:
Exclude auto configuration for mongo.
Expose MongoClient as a bean in context.
Use default way of configuration for SpringBoot/Mongo and relay on auto configuration to create MongoClient for you:
spring.data.mongodb.host=
spring.data.mongodb.port=
spring.data.mongodb.database=
spring.data.mongodb.username=
spring.data.mongodb.password=
That's Spring Boot's Auto Configuration kicking in. You can disable it by extending your #SpringBootApplication annotation like this:
#SpringBootApplication(exclude={MongoAutoConfiguration.class})

Categories

Resources