[.NET/IIS] Verschil in connectionpool IIS5 en 6?

[P_de_B]

We hebben een ASP.Net 1.1-applicatie die al heel lang op een IIS5 omgeving draait. Recentelijk hebben we een upgrade gedaan naar Windows Server 2003 en dus IIS6. We lopen nu tegen het probleem aan dat we na enige tijd een foutmelding krijgen over te weining beschikbare connecties in de pool ("The timeout period elapsed prior to obtaining a connection from the pool"). Op zich is de fout wel duidelijk, normaal is de oorzaak het niet correct afsluiten van een databaseverbinding zodat deze connectie niet weer teruggeven wordt aan de pool.

Het vreeemde vind ik echter dat het jaren op II5 goed gedraaid heeft, daarom denk ik eigenlijk dat het niet in de code zit.

Zijn er verschillen in instellingen of in de afhandeling van connectionpooling in IIS5 en 6? Ik heb al uitgebreid gezocht, maar er zijn veel hits op deze foutmelding, en de antwoorden zijn eigenlijk altijd dat je een connectie niet sluit.

In PRG omdat ik hoop dat hier meer ervaringsdeskundingen lopen

[whoami]

-> DTE

[whoami]

IIS 5 en IIS 6 hebben weldegelijk een paar verschillen, maar ik zie eigenlijk niet in wat ze in feite met DB connection pooling te maken hebben. Ben je zeker dat het over DB connecties gaat ?

IIS 6 heeft het concept 'Application Pools'. Tenzij je anders specifieert, zal je asp.net worker process (IUSR_xxxx) op IIS6 als ik me niet vergis, in de DefaultAppPool draaien.

Als het weldegelijk een probleem is met een connectie die niet wordt afgesloten, dan zou ik zowiezo de oorzaak er van aanpakken: opzoeken waar je een connectie niet afsluit, en deze afsluiten indien je ze niet meer nodig hebt. Ik maak altijd gebruik van try / finally blokken, waar ik connecties altijd in de finally sluit.

[P_de_B]

Ja, ik ben er zeker van dat het een db connectie probleem is. De stacktrace geeft ook aan dat de fout bij de SqlConnectionManager.GetPooledConnection methode optreedt.

We hebben voor deze 1.1 applicatie een aparte AppPool gemaakt.

Ik vind het alleen zo vreemd dat de fout op II5 niet optreedt. Als het een probleem in de code zou zijn, zal het toch ook moeten optreden op IIS5?

[whoami]

Ik zou zeggen; idd maar ...

Ik zit hier in eenzelfde situatie; ik ben een applicatie aan het ontwikkelen die gebruik maakt van SQL Server, ik heb remote - objects die onder IIS draaien en toegang hebben tot SQL Server.
Op m'n workstation draai ik nog IIS 5, en op de test- & productie-servers draait IIS 6. Ook daar heb ik een aparte App Pool gemaakt. Ik maak ook gebruik van connection pooling, maar hier heb ik dat probleem nog nooit gehad.
(Ook .NET 1.1 trouwens).

Wellicht dat het toch een probleem is in je code, maar dat IIS 5 er anders mee omgaat dan IIS 6 ?

[ Voor 9% gewijzigd door whoami op 08-03-2007 10:41 ]

[whoami]

kickje?
Ben je hier al verder mee geraakt ?

[ Voor 72% gewijzigd door whoami op 09-03-2007 15:42 ]

[P_de_B]

Nee, helaas nog niet. Ik ben vandaag vrij, maar het lijkt er toch op dat het wel in de code zit. Ik ga iig de vraag nog even bij MS neerleggen, maar ik ben bang dat we de applicatie toch bijlangs moeten. Waarom het op IIS5 wel goed gaat is mij nog steeds een raadsel.

[gorgi_19]

P_de_B schreef op vrijdag 09 maart 2007 @ 16:11:
Nee, helaas nog niet. Ik ben vandaag vrij, maar het lijkt er toch op dat het wel in de code zit. Ik ga iig de vraag nog even bij MS neerleggen, maar ik ben bang dat we de applicatie toch bijlangs moeten. Waarom het op IIS5 wel goed gaat is mij nog steeds een raadsel.

Heb je niet je web.config (je connectionstring) aangepast of machine.config waardoor de connection pooling anders is (lees: uit dan wel aan staat?