Parallel Script Tasks Using Same Connection Manager are Corrupted

Question

We're seeing a bizarre issues in our SSIS package.  We are using an HTTP connection manager in multiple script tasks running in parallel and the connections seem to be getting mismatched.  Here's the basic flow.
We have 6 containers that run in parallel.  Each container does the exact same work (they are copy/pasted) except we change the value of a variable representing the report to generate that is scoped to each container.  The container runs a query
(using a SQL connection manager defined in the package designer) and then uses a foreach container to enumerate the rows.  The variables inside the foreach container are scoped to it so we don't have a scoping issue.  Within the loop we write
the variable values to a log table, use a script task to generate an SSRS report and then write all the data and the report to an external system.  Everything is working fine except for the generation of the report.
Within the report script block we acquire a connection to a HTTP connection manager that is defined in the package (just like the SQL connection manager).  We then create a new HttpClientConnection with it and update the URL to include the necessary
parameters that SSRS needs to generate the report.  We then download the results and return it back to the container.  Here's the basic code we use
var httpConn = Dts.Connections["ReportServerUrl"];
var clientConn = new HttpClientConnection(httpConn.AcquireConnection(null));
var uri = new UriBuilder(clientConn.ServerURL) { Query = reportQueryInfo };
clientConn.ServerURL = uri.Uri.ToString();
clientConn.DownloadData();
The issue we are seeing is that when 2 of the scripts run at the same time the ServerURLs are getting cross wired such that we see 2 of the same report being requested rather than 1 of each type that we had requested (based upon the SSRS execution logs). 
It's almost like we are getting a shared HTTP client connection.  Provided the scripts don't run at the same time everything works correctly.  We are confident our variables are set correctly because we are storing them both before and after in external
tables and they are always correct.  The URL calculation logic is also correct because this problem only occurs when 2 requests are sent in parallel.
What am I missing here?
Michael Taylor
http://blogs.msmvps.com/p3net

Answer 1

Thank you for the feedback.  Before I go to Connect I'd like to provide some more info that may provide a better idea of what the problem is.
We broke things down trying to replicate the issue and it isn't a conn mgr problem after all I believe.  To clarify our package, we have 4 containers that execute the same logic (they were copy/pasted) except for the variable values that we set. The
containers are not linked together so they run in parallel. Each container executes a query using the ADO.NET conn mgr.  A foreach loop captures the value for the current row and then calls SSRS using a script block, forwards the report onto an external
resource and then updates a table indicating the row has been processed.  The only difference between them is the parameter we pass to the query and the value of the variables (that are scoped to the container or foreach loop).
The problem we have found is that the very first time through the foreach loop ALL containers are using the same row (from the first container's query).  Second and subsequent rows are fine.  We initially thought the queries were fine because of
our update at the end of the foreach loop but it is now clear that isn't the case.
We saw this problem when we moved our package to production.  We went back to Dev and was able to replicate it as well.  It happens every time and it is always the same row when given the same input set.   We started eliminating containers
and we found it only happens when you get to 3 containers or more.  2 containers had no problems.
I'll try to replicate it on a simpler solution but any thoughts on whether there is a race condition or something in SSIS would be helpful.