Keepalive - connection pooling returns incorrect results from different reduce views

I have a scenario that can be recreated with the java client, and at the moment have worked around this by using a separate httpclient to query views.

The scenario I’ve seen is as follows.

I have multiple views in the couchbase bucket.

Note that when fetching views in both cases the parameter stale=false was used.

When querying one view the data returned may look like (not actual data shown below, example data only):

{“rows”:[
{“key”:null,“value”:{“totalExample”:32,“totalAnotherExample”:6, “count”:38}}
]
}

When querying another view that contains different properties (but shared the count property by coincidence) the result returned looks like:
{“rows”:[
{“key”:null,“value”:{“totalExample”:null,“totalAnotherExample”:null,“count”:18}}
]
}

So what happens is that the properties that aren’t contained in the second view are set to null, and none of the unique properties from the second view are returned.

The same sort of thing occured on other views that did not share any property names as well.

In this case the shared property count is returned with the correct value for each respective view.

Now, when I request the data from the same view from a web browser (not the java client) it was returning the correct data for example:

{“rows”:[
{“key”:null,“value”:{“differentPropertyA”:10,“differentPropertyB”:8,“count”:18}}
]
}

I thought at first that this was the java client connection pooling, however was able to reproduce this in a web browser if requesting data for the first view and then immediately requesting data for the second view (even when introducing other query parameters).

It seemed as if the properties themselves from the first view where being applied to the properties of the second view, even though the second view did not contain those properties in their result.

After a bit of fiddling it seemed that the keep-alive http behaviour which kept the connection open seemed to be associated with the occurance of this odd behaviour.

By using a separate HttpClient and setting the Connection close header, as well as consuming all of the data from the entity, and aborting the client when done, I can now get consistent results and don’t encounter this type of issue anymore (but it means I don’t get the advantage of using the sdk client when querying views and have to manually translate data back into ViewResponse instances).

I still use the java client for accessing anything that has “include_docs” as this does not seem to have the same type of issue it only appears to occur with reduce views.

I’m wondering if anyone has observed the same type of problem?

I was experimenting with :
Version: 2.2.0 enterprise edition (build-821)
and the java sdk 1.2.0 (but I don’t think this issue is strictly related to the java sdk).

I’ll also be using :
Version: 2.1.1 community edition (build-764)