1.5

C# Driver Version 1.5 Release Notes

This is a major release featuring Typed Builders, enhanced LINQ support, and serialization of custom collections. There are significant serialization performance improvements, specifically when using class maps. In addition, there are a number of other enhancements and bug fixes.

File by file change logs are available at:

https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.5-Bson.txt
https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.5-Driver.txt

These release notes describe the changes at a higher level, and omit describing
some of the minor changes.

Breaking changes

• Any custom IBsonSerializer implementations utilizing the methods GetDocumentId, SetDocumentId, GetMemberSerializationInfo, or GetItemSerializationInfo will need to implement the corresponding interface to restore functionality; IBsonIdProvider, IBsonDocumentSerializer, IBsonArraySerializer

• A call to BsonSerializer.RegisterSerializer will now fail for types that implement IBsonSerializable

• The BsonDefaultSerializer methods IsTypeDiscriminated, LookupActualType, LookupDiscriminatorConvention, RegisterDiscriminator, and RegisterDiscriminatorConvention have been moved to BsonSerializer.

• ObjectId.TryParse will now return false instead of throwing an exception when argument is null

• BsonDocumentWrapper no longer ignores null, but wrather wraps it with a BsonNull.Value. Any code relying on BsonDocumentWrapper ignoring null will need to be evaluated.

• Custom collection/dictionary classes are now serialized by a collection/dictionary serializer instead of the class map serializer. This means that the items will be serialized instead of the properties and fields. Any code relying on the old behaviour will need to use BsonClassMap.RegisterClassMap with their custom collection/dictionary to preserve the old behaviour.

• The static Query class used to build queries has changed significantly. Users of this class can either modify their code or add a using statement alias to the old version. The DeprecatedQuery version will get dropped in version 2.0.

  using Query = MongoDB.Driver.Builders.DeprecatedQuery;
  

JIRA issues resolved

The full list of JIRA issues resolved in this release is available at:

https://jira.mongodb.org/secure/IssueNavigator.jspa?mode=hide&requestId=11900

High-Level Library Changes

Medium Trust

Support for medium trust is still not here. The communication protocol with a mongodb server is over TCP, which is dissallowed in vanilla medium trust environments. However, a slightly altered, custom medium trust permission system allowing sockets enables the driver to run fully. This can be done by copying the existing medium trust policy file and:

• adding the SocketPermission:

  <SecurityClass Name="SocketPermission" Description="System.Net.SocketPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
  

• adding an IPermission for the new SocketPermission security class:

  <IPermission class="SocketPermission" version="1" Unrestricted="true"/>
  

Support for Azure partial trust should work without changes. However, the default trust level for Azure is full, so this will only affect you if you have changed your Azure defaults.

Custom Collection Serialization

Classes that implement IDictionary or IDictionary<TKey, TValue> are now always serialized by a DictionarySerializer. Classes that implement IEnumerable ot IEnumerable< T > are now always serialized by a CollectionSerializer. We believe that a large majority of the time, classes implementing the collection interfaces intend for their items to be persisted rather than any properties (such as Count). This should enable the use of custom collection classes without any extra effort on your part.

Query Builder

We have rewritten the static Query class. The old Query class followed the odd query syntax of mongodb and was found to be somewhat unintuitive for those coming from traditional C# backgrounds and relational databases. In addition, as we completed the new typed Query< T > static class (discussed below) to aid the building of queries for classes that are using class maps underneath, we found that the difference in the old one and the new one was too stark.

In the older version, a complex query would be built as follows.

var query = Query.Or(
    Query.Exists("fn", true).NE("Jack"),
    Query.GTE("age", 20).LTE(40));

There are some implied "ands" for the two fields(name and age) that we wanted to remove so that the generated query was as predictable as possible. The new query syntax is a little more verbose, but we believe overall easier to understand.

var query = Query.And(
    Query.And(
        Query.Exists("fn"),
        Query.NE("fn", "Jack"))
    Query.And(
        Query.GTE("age", 20),
        Query.LET("age", 40)));

In many cases, you might find that you don't need to change anything, as the syntax is only different when a conjunction is chained. However, if you use this syntax a lot, then you can still use the old query builder by including a using statement in your files as follows:

using Query = MongoDB.Driver.Builders.DeprecatedQuery;

In version 2.0, we'll be removing the DeprecatedQuery class, so you'll need to update eventually.

Typed Builders

In conjunction with the new query builder, we have also included typed builders that mirror all the existing builders. So, Query has a corresponding Query< T > class, Update has a corresponding Update< T > class, etc... The huge benefit to this is that you can remove your "magic" strings from your code! In addition, anyone using custom serializers with class maps has support built-in for value based comparisons.

For instance, given that we have a Person class defined:

public class Person
{
    [BsonRepresentation(BsonType.ObjectId)]
    public string Id { get; set;}

    [BsonElement("fn")]
    public string FirstName { get; set;}

    [BsonElement("ln")]
    public string LastName { get; set;}

    [BsonElement("age")]
    public int Age { get; set;}
}   

Without the typed builder, a typical query might look like this:

ObjectId idFromUserInput = ...;
var query = Query.And(
    Query.NE("_id", idFromUserInput),
    Query.EQ("fn", "Jack"));

In the above query for a person, we need special knowledge to construct a valid query. First, that "Id" is "_id" in mongodb. Second, that "_id" is an ObjectId, even though our class exposes it as a string. And third, that "FirstName" is "fn" in mongodb. With the typed builders, you can specify this configuration information in one place, either as attributes or through the fluent configuration api, and never need to think about it again, as is demonstrated below, where the exact same query is generated as above.

string idFromUserInput = ...;
var query = Query.And(
    Query<Person>.NE(p => p.Id, idFromUserInput),
    Query<Person>.EQ(p => p.FirstName, "Jack"));

In addition, the typed query builders are type-safe, so you can't put an integer value where you have declared your property as a string. However, the biggest benefit to our internal refactoring is that you can now express your queries as predicates, making the above query even easier and more readable.

string idFromUserInput = ...;
var query = Query<Person>.Where(p => p.Id != idFromUserInput && p.FirstName == "Jack");

LINQ Enhancements

We continue to make Linq improvements. Thanks to all who report missing features and problematic queries. Linq is difficult to implement because IQueryable provides a lot of flexibility and operators that simply aren't supported in MongoDB. Where implementation makes sense, we will continue to enhance our linq implementations. As such, we have implemented a number of new operators:

• Added support for & and | operators when both sides evaluate to a boolean.

• Added support for the Any operator when the target is an enumerable of documents. This will generate an $elemMatch query. We do NOT support targets that are enumerables of primitives because the mongodb server does not support those. As soon as the server supports this, we will add this in as well.

• Using ToUpper or ToLower will generate a case-insentive query to mongodb using a regular expression.

• There are a number of times when certain queries will always evaluate to false. These queries will generate a special query that will utilize an index when possible, but still always evaluate to false on the server. Don't be surprised to see this query in your query plans: { "_id" : { $type : -1 } }. In addition, there are some queries that always evaluate to true. These will generate an empty query document: { }.

  // { "_id" : { $type : -1 } }
  
  var query = Query<Person>.Where(p => p.Name.ToUpper() == "Abc");
  

• Nullable Enums are now supported.

• ContainsKey on any typed impementing IDictionary or IDictionary<K,V> is now supported and will generate a query corresponding to it's serialization format.

• Contains can now be used on any type implementing IEnumerable or IEnumerable< T > and will be serialized to it's corresponding form. In the case of a local collection containing a field, this would generate an $in clause.

  var local = new List<int> { 1, 2, 3};
  
  // {"Age" : { $in : [1,2,3] } }
  
  var query = from p in people.AsQueryable()
          where local.Contains(p.Age)
          select p;
  

• Type queries either via comparison

  Query<A>.Where(a => a.GetType() == typeof(T)) 
  

  or in LINQ

  collection.AsQueryable().OfType<T>() 
  

  are supported for those of you using inheritance in your class maps. These will generate queries where the type discriminator is checked for the proper value.

GridFS Changes

In previous releases, download...

1.4.2

C# Driver Version 1.4.2 Release Notes

This minor release fixes a few issues found in the 1.4.1 release.

File by file change logs are available at:

https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.4.2-Bson.txt
https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.4.2-Driver.txt

These release notes describe the changes at a higher level, and omit describing
some of the minor changes.

Breaking changes

After 1.4.1 was released it was discovered that there were some minor breaking
changes. The breaking changes were in methods that we considered to be internal,
but that were not made private so that they leaked out into the public API.
Those methods have now been marked obsolete and will be made private in
a future release. The 1.4.2 release restores backward compatibility for these
methods (GetDocumentId and SetDocumentId in BsonDocument).

JIRA issues resolved

The full list of JIRA issues resolved in this release is available at:

https://jira.mongodb.org/secure/IssueNavigator.jspa?mode=hide&requestId=11409

BSON library changes

GetDocumentId/SetDocumentId marked obsolete

These methods were intended to be private. They have been marked as obsolete
and will be made private in a future release.

Driver changes

Query.All/In/NotIn

There was an issue with Query.All/In/NotIn that might have affected you. If you
cast a BsonArray to IEnumerable<BsonValue> before calling Query.All/In/NotIn
you would get an exception. This only happened when casting a BsonArray to
IEnumerable<BsonValue>. If you passed a BsonArray to the BsonArray overload or
passed an IEnumerable<BsonValue> that was not a BsonArray to the
IEnumerable<BsonValue> overload no exception was thrown.

RequestStart/RequestDone

Calling RequestStart when the connection pool was oversubscribed would often
result in a deadlock. This has been fixed in the 1.4.2 release.

Ping/VerifyState

These methods are usually called from a timer to monitor the state of the
server (or of multiple servers if connected to a replica set), but you can
also call them yourself. These methods now use a new connection instead
of one from the connection pool so that they are not delayed waiting for a
connection when the connection pool is oversubscribed.

1.4.1

C# Driver Version 1.4.1 Release Notes

This minor release fixes a few issues found by users of the LINQ support added
in v1.4 of the C# driver and also adds support for a few new LINQ query
operators and where clauses.

File by file change logs are available at:

https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.4.1-Bson.txt
https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.4.1-Driver.txt

These release notes describe the changes at a higher level, and omit describing
some of the minor changes.

Breaking changes

There are no breaking changes in this release.

JIRA issues resolved

The full list of JIRA issues resolved in this release is available at:

https://jira.mongodb.org/secure/IssueNavigator.jspa?mode=hide&requestId=11397

LINQ query support

The main purpose of this minor release is to fix some issues found by users of
the new LINQ support added in v1.4.

One bug that many have encountered is a NullReferenceException when writing a
query against an inherited property.

https://jira.mongodb.org/browse/CSHARP-418

You would hit this error if you had any queries that were similar to this:

public class B
{
    public ObjectId Id; 
}

public class C : B
{
    public int X;
}

var query =
    from c in collection.AsQueryable<C>()
    where c.Id = id // class C inherits Id from class B
    select c;

Another bug that a few users have encountered is an ArgumentOutOfRangeException
when writing a LINQ query that consists of a bare AsQueryable and nothing else:

https://jira.mongodb.org/browse/CSHARP-419

as in this sample:

var query = collection.AsQueryable<C>(); // no where clause

Normally a query would contain something else besides the call to AsQueryable
(like a where clause), but this is a legal query and is now supported.

BSON library changes

MaxSerializationDepth

The BSON serialization mechanism does not support circular references in your
object graph. In earlier versions of the C# driver if you attempted to
serialize an object with circular references you would get a
StackOverflowExpection. The 1.4.1 version now tracks the serialization depth
as it serializes an object and if it exceeds MaxSerializationDepth a
BsonSerializationException is thrown. The problem with StackOverflowException
was that it was fatal to your process, but the BsonSerializationException can
be caught and your process can continue executing if you choose.

The default MaxSerializationDepth is 100.

Interpretation of C# null vs BsonNull.Value

When working with the BsonDocument object model a C# null is usually ignored,
specially when creating BsonDocuments using functional construction. However,
when mapping between .NET types and the BsonDocument object model a C# null
will now be mapped to a BsonNull. For example:

var dictionary = new Dictionary<string, object> { { "x", null } };
var document = new BsonDocument(dictionary);
// document["x"] == BsonNull.Value

and when mapping in the reverse direction a BsonNull will map to a C# null:

var document = new BsonDocument { { "x", BsonNull.Value } };
var dictionary = document.ToDictionary();
// dictionary["x"] == null

Usually mapping between .NET types and the BsonDocument object model happens
automatically as needed, but if you want to invoke the mapping yourself you
can access the BsonTypeMapper directly:

var dictionary = new Dictionary<string, object> { { "x", null } };
var document = BsonTypeMapper.MapToBsonValue(dictionary);
// document["x"] == BsonNull.Value

or in the other direction:

var document = new BsonDocument { { "x", BsonNull.Value } };
var dictionary = (IDictionary<string, object>)BsonTypeMapper.MapToDotNetValue(document);
// dictionary["x"] == null

Serializing read-only properties

The class map based serialization support normally serializes only public
read-write properties (or fields). Sometimes it can be useful to serialize
read-only properties as well, specially if you want to query against them.
You can now opt-in your read-only properties so that they appear in the
serialized document. For example:

public class Book
{
    public ObjectId Id;
    public string Title;
    [BsonElement] // opt-in the read-only LowercaseTitle property
    public string LowercaseTitle { get { return Title.ToLower(); } }
}

Now when a Book is serialized the document will look like:

{
    _id : ObjectId("4f8d771dae879111d289dbc0"),
    Title : "For Whom the Bell Tolls",
    LowercaseTitle : "for whom the bell tolls"
}

During deserialization any elements in the serialized document that
correspond to read-only properties are ignored.

Driver changes

MongoServer

There is a new method called IsDatabaseNameValid that you can call to test if
a database name is valid.

MongoDatabase

There is a new method called IsCollectionNameValid that you can call to test if a
collection name is valid.

MongoGridFS

You can now disable computing the MD5 at the server when uploading a GridFS
file. You can also disable the client side verification of the MD5 that is
normally done on Upload or Download. The reason you might choose to disable
MD5 verification is that it is computationally expensive to compute the MD5.

LINQ OfType query operator

You can now use the OfType query operator in LINQ queries. For example:

var query = collection.AsQueryable<B>().OfType<C>();

this generates a query against the "_t" discriminator value that is used to
identify the actual type of a serialized document.

Additional expressions supported in LINQ where clauses

The following expressions are now supported in LINQ where clauses:

// d is the document
// p is a property of the document
// c is a character constant
// ca is an array of character constants
// s is a string constant
// i, j, k, n are integer constants

where d.p.Equals(constant)
where string.IsNullOrEmpty(d.p)
where d.p.IndexOf(c) == i
where d.p.IndexOf(c, j) == i
where d.p.IndexOf(c, j, k) == i
where d.p.IndexOf(s) == i
where d.p.IndexOf(s, j) == i
where d.p.IndexOf(s, j, k) == i
where d.p.IndexOfAny(ca) == i
where d.p.IndexOfAny(ca, j) == i
where d.p.IndexOfAny(ca, j, k) == i
where d.p[i] == c
where d.p.Length == n
where d.p.ToLower().Contains("xyz")
where d.p.ToLower().StartsWith("xyz")
where d.p.ToLower().EndsWith("xyz")
where d.p.ToUpper().Contains("xyz")
where d.p.ToUpper().StartsWith("xyz")
where d.p.ToUpper().EndsWith("xyz")
where d.p.Trim().Contains("xyz")
where d.p.Trim().StartsWith("xyz")
where d.p.Trim().EndsWith("xyz")
where d.p.TrimStart().Contains("xyz")
where d.p.TrimStart().StartsWith("xyz")
where d.p.TrimStart().EndsWith("xyz")
where d.p.TrimEnd().Contains("xyz")
where d.p.TrimEnd().StartsWith("xyz")
where d.p.TrimEnd().EndsWith("xyz")
where d.GetType() == typeof(T)
where d is T

// you can use any combination of ToLower/ToUpper/Trim/TrimStart/TrimEnd
// before Contains/StartsWith/EndsWith

In the 1.4 version of the C# driver the constant always had to appear on the
right of a comparison operator. That restriction is lifted in 1.4.1 so now the
following are equivalent:

where d.Height < 60
where 60 > d.Height

Type of in AsQueryable can now be deduced

The type of in the call to AsQueryable can now be deduced from the collection argument:

var collection = database.GetCollection<MyDocument>("mydocuments")
var query = collection.AsQueryable(); // <T> is deduced to be MyDocument

v1.4

C# Driver Version 1.4 Release Notes

The major feature of this release is support for LINQ queries. Some of the other
changes (e.g. new IBsonSerializer methods) are also in support of the new LINQ
implementation.

File by file change logs are available at:

https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.4-Bson.txt
https://github.com/mongodb/mongo-csharp-driver/blob/master/Release%20Notes/Change%20Log%20v1.4-Driver.txt

These release notes describe the changes at a higher level, and omit describing
some of the minor changes.

Breaking changes

There are some breaking changes in this release. Some of them are only breaking
at the binary level and are easily taken care of by simply recompiling your
application. Others require minor changes to your source code. Many of the
breaking changes are in low level classes, and these won't affect most users,
unless for example you are doing things like writing custom serializers.

Please read these release notes carefully before adopting the new 1.4 release
of the C# driver to determine if any of the breaking changes affect you.

LINQ query support

As stated previously, the major feature of this release is support for LINQ
queries. These release notes don't describe the new LINQ support, for that
please refer to the online LINQ tutorial at:

http://www.mongodb.org/display/DOCS/CSharp+Driver+LINQ+Tutorial

(Please note that the LINQ tutorial won't be available until several weeks
after the 1.4 release has been shipped. Sorry.)

CLS compliance

Both the MongoDB.Bson.dll and MongoDB.Driver.dll libraries have been marked
as CLS compliant, which should make them more useful from other .NET languages.
Most of the changes required to make the libraries CLS compliant are not even
visible in the public interface.

Release builds

Starting with the 1.4 version we are shipping Release builds of the DLLs.

Code formatting changes

In response to popular demand the code base has been reformatted using the
default Visual Studio C# code formatting settings. We have also adopted
the convention of prefixing instance field names with a single "_" and static
fields names with a double "__" (while this convention for static fields is
not common it is very useful). One of the nice benefits of these conventions
is that the drop down menu in Visual Studio that displays class members ends
up grouping all static fields first, followed by instance fields, followed by
the rest of the properties and methods.

BSON library changes

ArraySerializationOptions

This new class allows you to specify serialization options for array-like
members. Initially the only option available is to specify serialization
options for the items of the array. When using attributes to specify
serialization options any attributes that don't apply to the collection as a
whole implictly apply to the items of the collection.

BsonDateTime is now a pure BSON DateTime value

In previous versions the BsonDateTime class stored its value twice in two
different private fields: _millisecondsSinceEpoch (a long) and _value (a .NET
DateTime). The idea was that you could store a .NET DateTime without losing any
precision. However, that turns out to be confusing because as soon as you save
the BsonDateTime value to the database and read it back you are going to lose
precision anyway, so you might as well lose it right up front and not make
false promises.

BsonDateTime also has two new helper methods: ToLocalTime and ToUniversalTime.
These methods convert the BSON DateTime to either local or UTC .NET DateTime
values. There are also new AsLocalTime and AsUniversalTime properties in
BsonValues that can be used to convert BsonValues to .NET DateTime values (like
all AsXyz properties in BsonValue they throw an InvalidCastException if the
BsonValue is not actually a BsonDateTime).

BsonIgnoreExtraElements attribute

The BsonIgnoreExtraElements attribute has a new property called Inherited. If
this property is set to true then all classes derived from this one will
automatically inherit this setting, which makes it easy to set it for an
entire class hierarchy at once.

BsonIgnoreIfDefault attribute

This new attribute allows you to specify that you want a field to be ignored
during serialization if it is equal to the default value. This replaces the
SerializeDefaultValue parameter of the BsonDefaultValue attribute. By making
this a separate attribute you can specify that you want the default value
ignored without having to specify the default value as well.

BsonReader: CurrentBsonType vs GetCurrentBsonType

In previous versions the CurrentBsonType property had side effects. In general
it is bad form for the get accessor of a property to have side effects, as even
something as simple as looking at the value of the property in a debugger can
have unintended consequences. Therefore, in the 1.4 release the CurrentBsonType
property has no side effects. The previous behavior is now implemented in the
GetCurrentBsonType method. While this is mostly an internal change, if you
have written a custom serializer that used the CurrentBsonType property and
were relying on its side effects you will have to change your custom serializer
to call GetCurrentBsonType instead.

ConventionProfile new conventions

The ConventionProfile class has two new conventions: IgnoreIfDefaultConvention
and SerializationOptionsConvention. Also, the SerializeDefaultValueConvention
has been obsoleted in favor of the new IgnoreIfDefaultConvention.

DictionarySerializationOptions

This class has a new property called ItemSerializationOptions that can be used
to specify the options to use when serializing the value of the items in the
dictionary. When using attributes to specify serialization options, any
attributes that don't apply to the dictionary as a whole implicitly apply to
the value of the items in the dictionary.

ExtraElements

Previous versions of the C# driver allowed you to specify a field of the class
to be used to store any extra elements encountered during deserialization.
However, this field had to be of type BsonDocument, which meant introducing
a dependency on the driver into your data model classes (which some developers
don't want to do). You now have the additional option of declaring your
ExtraElements field to be of type IDictionary<string, object> instead.

IBsonSerializationOptions

The IBsonSerializationOptions has several new methods. ApplyAttribute is used
during the AutoMap process to apply an attribute to some serialization options
that are being built incrementally (starting from the default serialization
options). This provides an extensible mechanism for applying new attributes to
new serialization options classes. The Clone and Freeze methods are introduced
to allow serialization options to be converted to read-only once initialization
is complete to provide thread safety.

IBsonSerializer

The IBsonSerializer has several new methods. GetDefaultSerializationOptions
provides an initial set of serialization options that any serialization
attributes found can be applied against. GetItemSerializationInfo provides
serialization info about the items and applies only to serializers for
collection-like classes. GetMemberSerializationInfo provides serialization
info about members of a class. The last two are used in the implementation
of LINQ queries.

Image/Bitmap serializers

New serializers have been provided for the Image abstract base class and the
Bitmap class derived from it.

ISupportInitialize

The ISupportInitialize interface defines two methods: BeginInit and EndInit.
The BsonClassMapSerializer now checks whether the class being deserialized
implements this interface, and if so, calls BeginInit just before it starts
to deserialize a class, and EndInit just after it has finished. You can
use this feature to do any pre- or post-processing.

ObjectId/BsonObjectId creation

ObjectId (and BsonObjectId) have a new constructor that allows you to supply
the timestamp as a .NET DateTime value and it will automatically be converted
to seconds since the Unix Epoch. These new constructors are useful if you want
to create artificial ObjectIds to use in range based ObjectId queries (in
which case you will usually set the machine, pid and increment fields to zero).

There are also two new overloads of GenerateNewId that allow you to provide
the desired timestamp as either an int or a .NET DateTime. These new overloads
are useful if you need to create backdated ObjectIds. When generating backdated
ObjectIds there is a slight risk that you might create an ObjectId that is
not unique (but that risk is very small).

TimeSpanSerializationOptions

You can now choose any of the following representations for a TimeSpan: string,
double, Int32 or Int64. In addition, when using any of the numeric
representations, you can use the Units property to choose the units that the
numeric value is in (choose from: Ticks, Days, Hours, Minutes, Seconds,
Milliseconds and Nanoseconds).

Driver changes

Authentication support improved

Operations that require admin credentials previously required you to set the
DefaultCredentials of MongoServerSetttings to admin credentials. But that is
undesirable because it provides the client code full access to all databases,
essentially negating the benefit of using authentication in the first place.
In the 1.4 release all operations that require admin credentials have a new
overload where you can provide the needed credentials; you no longer have to
set the DefaultCredentials. Another option is to store credentials for the
admin database in the new MongoCredentialsStore.

Connection pool defaults changed

The default value of WaitQueueMultiple has been changed from 1.0 to 5.0 and the
default value of WaitQueueTimeout has been changed from 0.5 seconds to 2
minutes. These new values are taken from the Java driver, ...