Outbound SQL Connections

Hello Everyone,

I have two SQL 2005 clusters, one at a Corporate HQ and another at a hosting site. On each cluster there are several SQL instances each tied to a seperate Cluster Group meaning that there is a virtual cluster IP address assigned to the cluster group which should translate to the instance.

The issue that I am seeing is that in the connection manager, the IP addresses aren't listed correctly and there is sometimes just junk in there -- up to 10 IP addresses listed. There are many replication and service broker jobs running between the clusters all tied to specific IP addresses and ports which map to NAT and ACLs on the firewalls.

Here is the crux of it: While I can change the listening port and IP in the connection manager, how to I ensure that the outbound replication traffic is coming from the right source? If I add the correct IP address into the connection manager for the instance and disable the others, will it send from that IP address?

I have inherited this system and we are making the first strides into intagling this mess, but I am trying to surgically fix this rather than opening up all kinds of security holes in the interim.

Suggestions?

Ryan

Moving to Availability folder.

Outbound SQL Connections

Hello Everyone,

I have two SQL 2005 clusters, one at a Corporate HQ and another at a hosting site. On each cluster there are several SQL instances each tied to a seperate Cluster Group meaning that there is a virtual cluster IP address assigned to the cluster group which should translate to the instance.

The issue that I am seeing is that in the connection manager, the IP addresses aren't listed correctly and there is sometimes just junk in there -- up to 10 IP addresses listed. There are many replication and service broker jobs running between the clusters all tied to specific IP addresses and ports which map to NAT and ACLs on the firewalls.

Here is the crux of it: While I can change the listening port and IP in the connection manager, how to I ensure that the outbound replication traffic is coming from the right source? If I add the correct IP address into the connection manager for the instance and disable the others, will it send from that IP address?

I have inherited this system and we are making the first strides into intagling this mess, but I am trying to surgically fix this rather than opening up all kinds of security holes in the interim.

Suggestions?

Ryan

Moving to Availability folder.

Out of connections... or am I?

I'm getting the classic message "The timeout period elapsed prior to obtaining a connection from the pool" etc when connecting to my SQL Server 2005 Express from a .Net application.
Then I try connecting, simultaneously, from a simple ASP.net thing I wrote just for testing and this works fine. So, then the connection pool can't be full, can it? Or, does each application have its own pool??The application has its own pool. I have run into this before. Check through the .net application to make sure you closed all the connections.|||Check through the .net application to make sure you closed all the connections.I thought .Net did all this for you?|||From what I've understood, the Garbage Collector closes connections, but it might take some while before it does it. And I'm not sure that it can take care of all the relevant connections.

About my problem; it seems to work now after having changed the application to log in as an other user. Could it have been caused by some other error in the user/login setup?|||I imagine the Garbage Collector will close connections after the application exits, but when does a web application exit? The connections are sitting in the pool, and the close connection is what releases the connection back to the pool to be used again. Another annoying thing to note is that a connection is only reusable by other connection objects only if they share the same connection string. I think under ADO differences in the order of attributes made for two separate connection pools, but I am not sure, now.|||I noticed now that as soon as I re-save the config file read by IIS for this application, the application removes all the sleeping connections and it works fine, until a 100 connections limit is reached again. (Increasing the 100 threshold would just postpone the problem.)
Killing all the processes from within SQL Server doesn't help.|||what I learned from my brief stint as a java programmer was to never trust the garbage collectors and to always DIY. people poke fun at me for explicitly dropping temp tables in SQL but it all comes from this experience.

I wonder if this has some connection to a limitation with SQLExpress. I do not know for certain.