Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Mongo 3.6 #71

Closed
ngbalk opened this issue Jun 10, 2019 · 10 comments
Closed

Support for Mongo 3.6 #71

ngbalk opened this issue Jun 10, 2019 · 10 comments
Labels

Comments

@ngbalk
Copy link

ngbalk commented Jun 10, 2019

MemoryBackend currently is coded to emulate Mongo 3.0.0 - any plans on supporting newer versions (3.6.0)?

This would require updating the OpCode handling as 3.6 introduces a new OpCode that is not currently supported (#2013)

@bwaldvogel
Copy link
Owner

Actually some time ago I started implementation for opcode 2013 (OP_MSG).

However, I de-prioritized the work since I’m currently not aware of use-case where you are able to notice the difference. If you have such a case, could you provide a minimal test case?

@ngbalk
Copy link
Author

ngbalk commented Jul 8, 2019

Thanks @bwaldvogel
We wanted to test how our application would perform with a "flaky mongo backend", i.e. we would wrap the existing backend with some logic that fails every n requests. The latest mongo-java-driver > 3.6 has retry-able writes, and mongo-java-driver > 3.11.0 has retry-able reads baked into the driver's code. We wanted to verify in a unit test that our application would be resilient and silently retry an intermittent failure.

The MongoClient asks the database for its "version" on initial connection so it knows which opcodes to use, but it also enables/disables client-side retries if the database is newer / older than 3.6.0. Perhaps there are other client-side features that are enabled / disabled depending on the backend version, but our team was particular interested in retryReads and retryWrites.

Hope that gives you some context :)

@freakbite
Copy link

freakbite commented Aug 20, 2019

On the topic of 3.6 support I was wondering about support for

{
   $lookup:
     {
       from: <collection to join>,
       let: { <var_1>: <expression>, …, <var_n>: <expression> },
       pipeline: [ <pipeline to execute on the collection to join> ],
       as: <output array field>
     }
}

Where let is optional.

@bwaldvogel
Copy link
Owner

bwaldvogel commented Sep 7, 2019

@freakbite: I’ve started to implement support for $lookup stages with pipelines in 59fb1f4.
Could you test your use-cases with the latest version?

@bwaldvogel
Copy link
Owner

@freakbite: The change is released in version 1.20.0

@snava10
Copy link
Contributor

snava10 commented Jun 5, 2020

@bwaldvogel I'm looking at implementing transactions which requires the implementation of OP_MSG. I'm happy to pick this up, if you have made any progress and have something to share I would appreciate it.

@bwaldvogel
Copy link
Owner

bwaldvogel commented Jun 6, 2020

I was finally able to finish my earlier work on support for OP_MSG (wire protocol version 6) in 26a681c.

Note that mongo-java-server currently does not enable wire protocol version 6 by default!

@ngbalk, @snava10:
I would be glad if you could test it. You can enable it manually with:

MemoryBackend backend = new MemoryBackend().version(ServerVersion.MONGO_3_6);
MongoServer mongoServer = new MongoServer(backend);

@ngbalk
Copy link
Author

ngbalk commented Jun 10, 2020

Awesome @bwaldvogel ! I'm excited to test this out!

@bwaldvogel
Copy link
Owner

bwaldvogel commented Jun 13, 2020

The change is available in version 1.30.0

@bwaldvogel
Copy link
Owner

bwaldvogel commented Nov 23, 2022

Closing since the wire protocol in version 6 (MongoDB 3.6+) is the new default since mongo-java-server version 1.42.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants