vsivsi / gridfs-locks Goto Github PK

Hi, I was somehow left with the following lock document in the database: { "_id" : ObjectId("541931389adf5e2c3e5c53c4"), "files_id" : "54193138759128927df609c5", "read_locks" : 2, "reads" : 8, "write_lock" : false, "write_req" : true, "meta" : null, "expires" : ISODate("2014-09-17T07:28:53.018Z"), "writes" : 0 }

It is not possible to acquire a read lock with for this files_id anymore now, even though the lock expired some minutes ago and the configured lockExpiration is 10 seconds (timeout 20s, pollingInterval 0.2s). The query in https://github.com/vsivsi/gridfs-locks/blob/master/index.js#L441 does not seem to take expired locks with write_req: true into account, or am I missing something?

Using:

• gridfs-locks: 1.3.4
• mongodb: 3.5.5

Testing the example from the readme shows the following Mongo deprecation warnings:

(node:77851) DeprecationWarning: collection.ensureIndex is deprecated. Use createIndexes instead.
(node:77851) DeprecationWarning: collection.findAndModify is deprecated. Use findOneAndUpdate, findOneAndReplace or findOneAndDelete instead.

Any chance for a small update fixing this?

When running npm up-to-date gridfs-locks tests (v1.2.2) against MongoDB server 3.0.0-rc7, it fails:

  68 passing (1m)
  2 failing

  1) gridfs-locks lock expiration should allow a read request to proceed when a prior write request dies without releasing write_req:
     Error: timeout of 5000ms exceeded
    at [object Object].<anonymous> (/home/riccardi/tmp/nodejs/test/node_modules/gridfs-locking-stream/node_modules/gridfs-locks/node_modules/mocha/lib/runnable.js:159:19)
    at Timer.listOnTimeout [as ontimeout] (timers.js:112:15)


  2) gridfs-locks lock expiration should allow a read request to proceed when a prior write request dies waiting for a write lock without releasing write_req:
     Error: timeout of 5000ms exceeded
    at [object Object].<anonymous> (/home/riccardi/tmp/nodejs/test/node_modules/gridfs-locking-stream/node_modules/gridfs-locks/node_modules/mocha/lib/runnable.js:159:19)
    at Timer.listOnTimeout [as ontimeout] (timers.js:112:15)

When applying commit add3224, all the tests pass.

Could you please release master to npm, and upgrade gridfs-locks-stream dependency constraint?

The Node.js driver's GridStore constructor accepts either _id or filename, however gridfs-locks only accepts _id. I understand this is due to uniqueness since filename is not guaranteed to be unique - even in the case of GridStore.

I have a case where filename is unique in GridFS and is the primary field used when querying documents, as opposed to _id. Having the ability to lock based on filename will make operations better for concurrency and atomicity. Right now the application must look up the document by filename to retrieve it's _id (asynchronously, and in a cluster/distributed environment), and then perform the lock and read/write operations, all in series.

After reviewing the code, it appears that fileId can contain any arbitrary value. Perhaps the solution is to never limit fileId to being an instance of ObjectID in the future. However, the documentation describes that the ID must be an instance of ObjectID, rather than any other unique value.

Hi Vaughn,

gridfs-locks does not guarantee the order on processing the locks. Due to the timeout-mechanism it can happen, that:

• req1: createWriteLock
  -> req1: get lock
• req2: createWriteLock
• req3: createWriteLock
  -> req2: timeOut... lock held by req1... restart timer
  -> req1: done
  -> req1: release lock
  -> req3: timeOut... obtain lock

So it is possibe, that req3 will be scheduled before req2
Am I right?

Do you see any chance to include (maybe via second strategy) a way that schedules the locks in a FirstInFirstOut manner?

Cheers, Ralf