[JAVA-2542] Issue with collection drop Created: 19/Jun/17  Updated: 27/Oct/23  Resolved: 19/Jul/17

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: pedrum jalali Assignee: Ross Lawley
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 16 lts



 Description   

so I have a piece of code for dropping collections. It works on windows but not when its run in ubuntu.

 MongoDatabase database;
        database = mongoClient.getDatabase("mydb");
        MongoCollection<Document> _col =       database.getCollection("collName");
        _col.drop();
        mongoClient.close();

I think it might be a bug

Thanks
Pedrum



 Comments   
Comment by Ross Lawley [ 19/Jul/17 ]

Thanks - glad you were able to figure out the cause.

Ross

Comment by pedrum jalali [ 18/Jul/17 ]

Just need to confirm that I was no longer able to reproduce the error. I believe the issue had something to do with the fact that I was creating a new mongo client for each thread in a multi-threaded application rather than passing a reference of the client to the different threads. You can mark it resolved now.

Comment by Ross Lawley [ 29/Jun/17 ]

From the logs:

2017-06-28T09:55:44.183-0400 D COMMAND  [conn7] run command ISCX2014.$cmd { drop: "training" }
2017-06-28T09:55:44.183-0400 D REPL     [conn7] Waiting for write concern. OpTime: { ts: Timestamp 0|0, t: -1 }, write concern: { w: 1, wtimeout: 0 }
2017-06-28T09:55:44.183-0400 I COMMAND  [conn7] command ISCX2014.$cmd command: drop { drop: "training" } numYields:0 reslen:104 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { W: 1 } } } protocol:op_query 0ms
2017-06-28T09:55:44.188-0400 D NETWORK  [conn7] Socket recv() conn closed? 127.0.0.1:53806
2017-06-28T09:55:44.188-0400 D NETWORK  [conn7] SocketException: remote: 127.0.0.1:53806 error: 9001 socket exception [CLOSED] server [127.0.0.1:53806] 
2017-06-28T09:55:44.189-0400 D NETWORK  [conn6] Socket recv() conn closed? 127.0.0.1:53804
2017-06-28T09:55:44.189-0400 D NETWORK  [conn6] SocketException: remote: 127.0.0.1:53804 error: 9001 socket exception [CLOSED] server [127.0.0.1:53804] 

I can see there was a socket exception straight after the drop command on the same connection. It's reporting that the connection has been closed. Interesting, conn6 is also marked as closed and raises an exception.

1. Can you include debugging logging from the Java side? I'd be interested to see what is happening from the perspective of the drivers connection pool.
2. Can you confirm the Java driver version?

All the best,

Ross

Comment by pedrum jalali [ 28/Jun/17 ]

I've uploaded the logs in gdrive. Before preparing the logs I deleted all previous logs. So what you are seeing are the logs for the following:

1- service mongodb restart
2- db.setLogLevel(5)
3- The very first bit of code I wrote at the top.

Thanks in advance

https://drive.google.com/file/d/0BwFUfWkiqC7VbHBscXk2OFRVNjQ/view?usp=sharing

Comment by Jeffrey Yemin [ 28/Jun/17 ]

The documents in the list do not hold a reference to the collection, so clearing it will have no effect on the success or failure of the collection drop.

If you can provide server logs we can proceed further with root cause analysis.

Comment by pedrum jalali [ 28/Jun/17 ]

So I did some more testing. Apparently the issue was that I had previously done some query and converted to a list and I did not clear the list. The list was holding reference to the collection and hence the delete operation was not going through:

List<document> _temp = database.getCollection("collName").find(new Document()).into(new ArrayList<Documents>)
)

It might be good to explicitly note in the documents that the above collection needs to be freed with the command

_temp.clear()

Comment by Jeffrey Yemin [ 22/Jun/17 ]

In order to proceed I'd like to see the mongod logs for the drop command, for both the successful and unsuccessful case. It will look something like this:

2017-06-22T12:50:26.552-0400 I COMMAND  [conn257] command dbcert.$cmd appName: "MongoDB Shell" command: drop { drop: "foo" } numYields:0 reslen:89 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { W: 1 } } } protocol:op_command 0ms

You may have to boost the log level on the MongoDB server to ensure that the command is logged. Please include some context around the logging of the command in case there are any errors reported.

Comment by pedrum jalali [ 20/Jun/17 ]

Hi, Thanks for the response.

1- Not it just silently fails to drop the collection

2- The java application is running on the same machine as the mongo server however as a separate application. I've tried the following setups:
Mongodb: On remote Ubuntu Java application: On local windows
MongoDB: on remote Ubuntu Java application: On same machine as mongodb (remote ubuntu)
Mongodb: On local windows Java application: On local windows (Same machine as mongodb)

The first and last work. The second fails. I believe there is something wrong with the linux java driver.

3- Sure. The following is when both the application and mongodb are on the same machine on remote ubuntu:
2017-06-20T10:15:09.343-0400 I NETWORK [conn14] received client metadata from 127.0.0.1:47736 conn14: { driver:

{ name: "mongo-java-driver", version: "3.4.2" }

, os:

{ type: "Linux", name: "Linux", architecture: "amd64", version: "4.4.0-79-generic" }

, platform: "Java/Oracle Corporation/1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11" }
2017-06-20T10:15:09.423-0400 I NETWORK [conn15] received client metadata from 127.0.0.1:47738 conn15: { driver:

{ name: "mongo-java-driver", version: "3.4.2" }

, os:

{ type: "Linux", name: "Linux", architecture: "amd64", version: "4.4.0-79-generic" }

, platform: "Java/Oracle Corporation/1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11" }

and the following is when mongodb is on remote ubuntu but java app is on local windows:
2017-06-20T10:12:40.895-0400 I NETWORK [conn2] received client metadata from 10.169.38.18:65137 conn2: { driver:

{ name: "mongo-java-driver", version: "3.4.2" }

, os:

{ type: "Windows", name: "Windows 10", architecture: "amd64", version: "10.0" }

, platform: "Java/Oracle Corporation/1.8.0_131-b11" }
2017-06-20T10:12:41.305-0400 I NETWORK [conn3] received client metadata from 10.169.38.18:65138 conn3: { driver:

{ name: "mongo-java-driver", version: "3.4.2" }

, os:

{ type: "Windows", name: "Windows 10", architecture: "amd64", version: "10.0" }

, platform: "Java/Oracle Corporation/1.8.0_131-b11" }

and this is stuff that comes before. Its the same for both runs:
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] MongoDB starting : pid=8104 port=27017 dbpath=/var/lib/mongodb 64-bit host=psserver
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] db version v3.4.5
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] git version: 520b8f3092c48d934f0cd78ab5f40fe594f96863
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] allocator: tcmalloc
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] modules: none
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] build environment:
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] distmod: ubuntu1604
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] distarch: x86_64
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] target_arch: x86_64
2017-06-20T10:12:15.389-0400 I CONTROL [initandlisten] options: { config: "/etc/mongod.conf", net:

{ port: 27017 }

, security:

{ authorization: "enabled" }

, storage: { dbPath: "/var/lib/mongodb", journal:

{ enabled: true }

}, systemLog:

{ destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log", quiet: true }

}
2017-06-20T10:12:15.412-0400 I - [initandlisten] Detected data files in /var/lib/mongodb created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2017-06-20T10:12:15.413-0400 I STORAGE [initandlisten]
2017-06-20T10:12:15.413-0400 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2017-06-20T10:12:15.413-0400 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2017-06-20T10:12:15.413-0400 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=39746M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten]
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** WARNING: You are running on a NUMA machine.
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** We suggest launching mongod like this to avoid performance problems:
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** numactl --interleave=all mongod [other options]
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten]
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten]
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2017-06-20T10:12:15.599-0400 I CONTROL [initandlisten]
2017-06-20T10:12:15.602-0400 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/var/lib/mongodb/diagnostic.data'
2017-06-20T10:12:15.602-0400 I NETWORK [thread1] waiting for connections on port 27017

Comment by Jeffrey Yemin [ 19/Jun/17 ]

It works on windows but not when its run in ubuntu.

To clarify, I have some questions:

  1. Is there a stack trace that you can post, or does it silently fail to drop the collection?
  2. Is that when the Java application is run on Ubuntu, or the MongoDB server?
  3. Can you attach the MongoDB server logs?
Generated at Thu Feb 08 08:57:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.