Timeout Expired

Hola, exacto, es como que no se liberaban conexiones :-S. Lo que hice en ese
momento ademas de poner el DAABF 3.1 es aumentar las del pool y hasta ahora
no me molesto mas eso.


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:

ah si? y que pasaba? no se liberaban las conexiones? crecían
indefinidamente
los SPIDs en sysprocesses?

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Maxi" wrote in message
news:

Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB en
unas pruebas que hice :(


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:
> Hola Maxi,
>
> aquí hay un artículo interesante sobre pooling:
> http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
>
> de todas formas, el pooling no debe ser problema porque mientras la
> conexión
> está en el pool no existe comunicación entre cliente y servidor;
> consume
> recursos en el servidor (mantener una conexión abierta), y en el
> cliente
> (mantener el objeto connection en memoria)
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "MAXI" wrote in message
> news:#
>> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho
>> de
>> banda hacia el servidor de datos :(
>>
>> Probar lo del pool es simple, sacalo de la cadena de conexion y

probamos

>>
>> Preguntas:
>>
>> 1) Estas usando Sp' o envias consultas desde la aplicacion?
>> 2) Tenes los service Pack instalados del Sqlserver y el SO?
>> 3) Podes medir el ancho de banda en que consumo esta?
>>
>> Empecemos por aca y vayamos descartando temas ;)
>>
>> Un abrazo
>>
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "hpmig" escribió en el mensaje
>> news:
>> > Mil gracias por responder. Te ampliaré un poco más el escenario:
>> > este
>> > módulo
>> > de ACD, forma parte de una solución CTI que se conecta, vía socket
> TCP/IP,
>> > a
>> > un servidor (Switch telefónico) que le envía paquetes con la
>> > información
>> > de
>> > la llamada arribante. El ACD con esta info. consulta al serv. de SQL
> para,
>> > también mediante un paq. vía red, indicarle al Switch cómo tratar la
>> > llamada.
>> > Cuando tuve que finalizar la aplicación, que es multithread (una

thread

>> > para
>> > mensajes de entrada y otra para los de salida), había procesado
> alrededor
>> > de
>> > 25 millones de mensajes de entrada y unos 12 millones de salida. En

un

>> > estimado, de los 25 millones de entrada, un 70% necesitan consultar

la

>> > base
>> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
>> > cierro
>> > conexiones después de toda actividad. Claro, el pool mantiene, se
> supone,
>> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> cierra
>> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no

me

>> > sería
>> > útil, pues cuando una llamada entra, debo contestarle lo más rápido
>> > posible:
>> > si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
> puedo
>> > saber si es un problema de pool? ¿Porqué después de manejar tantas
>> > consultas,
>> > de manera tan crítica, con un buen desempeño durante 2 semanas,
>> > súbitamente,
>> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te
>> > lo
>> > había
>> > mencionado: se colapsó el servicio de datos, pues mi aplicación se

pudo

>> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> mismo
>> > mensaje de error.
>> >
>> > "MAXI" wrote:
>> >
>> >> Hola, podria ser un problema de pool, tambien podria ser un
>> >> problema
>> >> de
>> >> red.
>> >> Probaste con aumentar el Timeout?
>> >>
>> >>
>> >>
>> >> Maxi
>> >>
>> >> Buenos Aires - Argentina
>> >> Desarrollador .NET 3 Estrellas
>> >> Microsoft User Group (MUG)
>> >>
>> >> "HPMig" escribió en el mensaje
>> >> news:
>> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
> ACD)
>> >> > de
>> >> > un
>> >> > call center que recibe en prom. 9000 llamadas diarias. Su

desempeño

>> >> > parece
>> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin

embargo,

>> >> > después
>> >> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> >> > expired.
>> >> > The timeout period elapsed prior to completion of the operation
>> >> > or
> the
>> >> > server
>> >> > is not responding". Lo extraño es que ocurrió alrededor de las

3:00

> am,
>> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de

conexión

> no
>> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
> timeout
>> >> > (30
>> >> > s). ¿podría ser un problema del pool?
>> >>
>> >>
>> >>
>>
>>
>
>

Hola para medir en ancho de banda podrias usar el monitor de sistema, o
quizas alguna herramienta de terceros que mida paquetes


Salu2
Maxi


"hpmig" escribió en el mensaje
news:

Saludos.

1. Utilizo exclusivamente stored procedures, tanto de consulta, como de
actualización. Para "llamarlos", hago uso de Data Access Application Block
(DAAB), en su versión p/.NET Framework 1.1 (mi apl. la desarrollé en C#
2003).

2. Tanto el servidor de SQL, como mi aplicación, "corren" en el mismo
equipo: W2K Server con SP 4, 2 procesadores Xeon 2.4Ghz (HT - es decir,
están
disponibles 4 procesadores), 3GB RAM. El SQL Server tiene instalado el SP
3a
( Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows
NT
5.0 (Build 2195: Service Pack 4) ).

3. ¿cómo puedo medir el ancho de banda?

Gracias.

"MAXI" escribió:

Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
banda hacia el servidor de datos :(

Probar lo del pool es simple, sacalo de la cadena de conexion y probamos

Preguntas:

1) Estas usando Sp' o envias consultas desde la aplicacion?
2) Tenes los service Pack instalados del Sqlserver y el SO?
3) Podes medir el ancho de banda en que consumo esta?

Empecemos por aca y vayamos descartando temas ;)

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

"hpmig" escribió en el mensaje
news:
> Mil gracias por responder. Te ampliaré un poco más el escenario: este
> módulo
> de ACD, forma parte de una solución CTI que se conecta, vía socket
> TCP/IP,
> a
> un servidor (Switch telefónico) que le envía paquetes con la
> información
> de
> la llamada arribante. El ACD con esta info. consulta al serv. de SQL
> para,
> también mediante un paq. vía red, indicarle al Switch cómo tratar la
> llamada.
> Cuando tuve que finalizar la aplicación, que es multithread (una thread
> para
> mensajes de entrada y otra para los de salida), había procesado
> alrededor
> de
> 25 millones de mensajes de entrada y unos 12 millones de salida. En un
> estimado, de los 25 millones de entrada, un 70% necesitan consultar la
> base
> de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
> cierro
> conexiones después de toda actividad. Claro, el pool mantiene, se
> supone,
> cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> cierra
> perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no me
> sería
> útil, pues cuando una llamada entra, debo contestarle lo más rápido
> posible:
> si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
> puedo
> saber si es un problema de pool? ¿Porqué después de manejar tantas
> consultas,
> de manera tan crítica, con un buen desempeño durante 2 semanas,
> súbitamente,
> cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
> había
> mencionado: se colapsó el servicio de datos, pues mi aplicación se pudo
> reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> mismo
> mensaje de error.
>
> "MAXI" wrote:
>
>> Hola, podria ser un problema de pool, tambien podria ser un problema
>> de
>> red.
>> Probaste con aumentar el Timeout?
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "HPMig" escribió en el mensaje
>> news:
>> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
>> > ACD)
>> > de
>> > un
>> > call center que recibe en prom. 9000 llamadas diarias. Su desempeño
>> > parece
>> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,
>> > después
>> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> > expired.
>> > The timeout period elapsed prior to completion of the operation or
>> > the
>> > server
>> > is not responding". Lo extraño es que ocurrió alrededor de las 3:00
>> > am,
>> > cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión
>> > no
>> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
>> > timeout
>> > (30
>> > s). ¿podría ser un problema del pool?
>>
>>
>>

¿Y has conseguido encontrar el posible fallo? Igual interesa reportar el
fallo para que los usuarios de la versión 2.0 conozcan el problema... lo
podemos postear en el workspace pero yo no he usado nunca DAAB por lo que de
poca utilidad puedo ser...

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Maxi" wrote in message
news:

Hola, exacto, es como que no se liberaban conexiones :-S. Lo que hice en

ese

momento ademas de poner el DAABF 3.1 es aumentar las del pool y hasta

ahora

no me molesto mas eso.


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:
> ah si? y que pasaba? no se liberaban las conexiones? crecían
> indefinidamente
> los SPIDs en sysprocesses?
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "Maxi" wrote in message
> news:
>> Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB

en

>> unas pruebas que hice :(
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Eladio Rincón" escribió en el mensaje
>> news:
>> > Hola Maxi,
>> >
>> > aquí hay un artículo interesante sobre pooling:
>> > http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
>> >
>> > de todas formas, el pooling no debe ser problema porque mientras la
>> > conexión
>> > está en el pool no existe comunicación entre cliente y servidor;
>> > consume
>> > recursos en el servidor (mantener una conexión abierta), y en el
>> > cliente
>> > (mantener el objeto connection en memoria)
>> >
>> > Eladio Rincón
>> > SQL Server MVP
>> >
>> > Solid Quality Learning (http://www.solidqualitylearning.com)
>> > "Comparte lo que sabes, aprende lo que no sepas", FGG
>> >
>> > Consulte el histórico del grupo en Google
>> > http://groups.google.com/groups?gro....sqlserver
>> >
>> > ¿Te interesa participar en las reuniones
>> > del grupo de Usuarios de SQL-Server y .NET
>> > Se harán en levante de España, (Alicante o Murcia)?
>> >
>> > "MAXI" wrote in message
>> > news:#
>> >> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho
>> >> de
>> >> banda hacia el servidor de datos :(
>> >>
>> >> Probar lo del pool es simple, sacalo de la cadena de conexion y
> probamos
>> >>
>> >> Preguntas:
>> >>
>> >> 1) Estas usando Sp' o envias consultas desde la aplicacion?
>> >> 2) Tenes los service Pack instalados del Sqlserver y el SO?
>> >> 3) Podes medir el ancho de banda en que consumo esta?
>> >>
>> >> Empecemos por aca y vayamos descartando temas ;)
>> >>
>> >> Un abrazo
>> >>
>> >>
>> >>
>> >>
>> >> Maxi
>> >>
>> >> Buenos Aires - Argentina
>> >> Desarrollador .NET 3 Estrellas
>> >> Microsoft User Group (MUG)
>> >>
>> >> "hpmig" escribió en el mensaje
>> >> news:
>> >> > Mil gracias por responder. Te ampliaré un poco más el escenario:
>> >> > este
>> >> > módulo
>> >> > de ACD, forma parte de una solución CTI que se conecta, vía socket
>> > TCP/IP,
>> >> > a
>> >> > un servidor (Switch telefónico) que le envía paquetes con la
>> >> > información
>> >> > de
>> >> > la llamada arribante. El ACD con esta info. consulta al serv. de

SQL

>> > para,
>> >> > también mediante un paq. vía red, indicarle al Switch cómo tratar

la

>> >> > llamada.
>> >> > Cuando tuve que finalizar la aplicación, que es multithread (una
> thread
>> >> > para
>> >> > mensajes de entrada y otra para los de salida), había procesado
>> > alrededor
>> >> > de
>> >> > 25 millones de mensajes de entrada y unos 12 millones de salida.

En

> un
>> >> > estimado, de los 25 millones de entrada, un 70% necesitan

consultar

> la
>> >> > base
>> >> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es

decir,

>> >> > cierro
>> >> > conexiones después de toda actividad. Claro, el pool mantiene, se
>> > supone,
>> >> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
>> > cierra
>> >> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout

no

> me
>> >> > sería
>> >> > útil, pues cuando una llamada entra, debo contestarle lo más

rápido

>> >> > posible:
>> >> > si no le contesto a la llamada en menos de 15 seg. se colgará.

¿Cómo

>> > puedo
>> >> > saber si es un problema de pool? ¿Porqué después de manejar tantas
>> >> > consultas,
>> >> > de manera tan crítica, con un buen desempeño durante 2 semanas,
>> >> > súbitamente,
>> >> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te
>> >> > lo
>> >> > había
>> >> > mencionado: se colapsó el servicio de datos, pues mi aplicación se
> pudo
>> >> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome

el

>> > mismo
>> >> > mensaje de error.
>> >> >
>> >> > "MAXI" wrote:
>> >> >
>> >> >> Hola, podria ser un problema de pool, tambien podria ser un
>> >> >> problema
>> >> >> de
>> >> >> red.
>> >> >> Probaste con aumentar el Timeout?
>> >> >>
>> >> >>
>> >> >>
>> >> >> Maxi
>> >> >>
>> >> >> Buenos Aires - Argentina
>> >> >> Desarrollador .NET 3 Estrellas
>> >> >> Microsoft User Group (MUG)
>> >> >>
>> >> >> "HPMig" escribió en el mensaje
>> >> >> news:
>> >> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo

de

>> > ACD)
>> >> >> > de
>> >> >> > un
>> >> >> > call center que recibe en prom. 9000 llamadas diarias. Su
> desempeño
>> >> >> > parece
>> >> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin
> embargo,
>> >> >> > después
>> >> >> > de un periodo de dos semanas obtengo el siguiente error:

"Timeout

>> >> >> > expired.
>> >> >> > The timeout period elapsed prior to completion of the operation
>> >> >> > or
>> > the
>> >> >> > server
>> >> >> > is not responding". Lo extraño es que ocurrió alrededor de las
> 3:00
>> > am,
>> >> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de
> conexión
>> > no
>> >> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
>> > timeout
>> >> >> > (30
>> >> >> > s). ¿podría ser un problema del pool?
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Hola, francamente no puede encontrar la causa y mucho menos saber si era
algo que estaba yo haciendo muy mal :(

Con la version 3.1 por ahora no he tenido ese problema, pero repito, quizas
no era el DAAB y alguna otra cosa que me costaba identificar :-S

pd: si no lo usas te lo recomiendo amigo, a mi me ha ayudado mucho, es mas
me hice una clase Cnn_man para ponerle las transacciones y los controles y
funciona muy bien :-D



Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

"Eladio Rincón" escribió en el mensaje
news:

¿Y has conseguido encontrar el posible fallo? Igual interesa reportar el
fallo para que los usuarios de la versión 2.0 conozcan el problema... lo
podemos postear en el workspace pero yo no he usado nunca DAAB por lo que
de
poca utilidad puedo ser...

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Maxi" wrote in message
news:

Hola, exacto, es como que no se liberaban conexiones :-S. Lo que hice en

ese

momento ademas de poner el DAABF 3.1 es aumentar las del pool y hasta

ahora

no me molesto mas eso.


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:
> ah si? y que pasaba? no se liberaban las conexiones? crecían
> indefinidamente
> los SPIDs en sysprocesses?
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "Maxi" wrote in message
> news:
>> Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB

en

>> unas pruebas que hice :(
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Eladio Rincón" escribió en el mensaje
>> news:
>> > Hola Maxi,
>> >
>> > aquí hay un artículo interesante sobre pooling:
>> > http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
>> >
>> > de todas formas, el pooling no debe ser problema porque mientras la
>> > conexión
>> > está en el pool no existe comunicación entre cliente y servidor;
>> > consume
>> > recursos en el servidor (mantener una conexión abierta), y en el
>> > cliente
>> > (mantener el objeto connection en memoria)
>> >
>> > Eladio Rincón
>> > SQL Server MVP
>> >
>> > Solid Quality Learning (http://www.solidqualitylearning.com)
>> > "Comparte lo que sabes, aprende lo que no sepas", FGG
>> >
>> > Consulte el histórico del grupo en Google
>> > http://groups.google.com/groups?gro....sqlserver
>> >
>> > ¿Te interesa participar en las reuniones
>> > del grupo de Usuarios de SQL-Server y .NET
>> > Se harán en levante de España, (Alicante o Murcia)?
>> >
>> > "MAXI" wrote in message
>> > news:#
>> >> Hola, mmm, para mi lo que estas teniendo es un alto consumo de
>> >> ancho
>> >> de
>> >> banda hacia el servidor de datos :(
>> >>
>> >> Probar lo del pool es simple, sacalo de la cadena de conexion y
> probamos
>> >>
>> >> Preguntas:
>> >>
>> >> 1) Estas usando Sp' o envias consultas desde la aplicacion?
>> >> 2) Tenes los service Pack instalados del Sqlserver y el SO?
>> >> 3) Podes medir el ancho de banda en que consumo esta?
>> >>
>> >> Empecemos por aca y vayamos descartando temas ;)
>> >>
>> >> Un abrazo
>> >>
>> >>
>> >>
>> >>
>> >> Maxi
>> >>
>> >> Buenos Aires - Argentina
>> >> Desarrollador .NET 3 Estrellas
>> >> Microsoft User Group (MUG)
>> >>
>> >> "hpmig" escribió en el mensaje
>> >> news:
>> >> > Mil gracias por responder. Te ampliaré un poco más el escenario:
>> >> > este
>> >> > módulo
>> >> > de ACD, forma parte de una solución CTI que se conecta, vía
>> >> > socket
>> > TCP/IP,
>> >> > a
>> >> > un servidor (Switch telefónico) que le envía paquetes con la
>> >> > información
>> >> > de
>> >> > la llamada arribante. El ACD con esta info. consulta al serv. de

SQL

>> > para,
>> >> > también mediante un paq. vía red, indicarle al Switch cómo tratar

la

>> >> > llamada.
>> >> > Cuando tuve que finalizar la aplicación, que es multithread (una
> thread
>> >> > para
>> >> > mensajes de entrada y otra para los de salida), había procesado
>> > alrededor
>> >> > de
>> >> > 25 millones de mensajes de entrada y unos 12 millones de salida.

En

> un
>> >> > estimado, de los 25 millones de entrada, un 70% necesitan

consultar

> la
>> >> > base
>> >> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es

decir,

>> >> > cierro
>> >> > conexiones después de toda actividad. Claro, el pool mantiene, se
>> > supone,
>> >> > cierto número de conexiones "dormidas". Cuando inhabilito el
>> >> > pool,
>> > cierra
>> >> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout

no

> me
>> >> > sería
>> >> > útil, pues cuando una llamada entra, debo contestarle lo más

rápido

>> >> > posible:
>> >> > si no le contesto a la llamada en menos de 15 seg. se colgará.

¿Cómo

>> > puedo
>> >> > saber si es un problema de pool? ¿Porqué después de manejar
>> >> > tantas
>> >> > consultas,
>> >> > de manera tan crítica, con un buen desempeño durante 2 semanas,
>> >> > súbitamente,
>> >> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no
>> >> > te
>> >> > lo
>> >> > había
>> >> > mencionado: se colapsó el servicio de datos, pues mi aplicación
>> >> > se
> pudo
>> >> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome

el

>> > mismo
>> >> > mensaje de error.
>> >> >
>> >> > "MAXI" wrote:
>> >> >
>> >> >> Hola, podria ser un problema de pool, tambien podria ser un
>> >> >> problema
>> >> >> de
>> >> >> red.
>> >> >> Probaste con aumentar el Timeout?
>> >> >>
>> >> >>
>> >> >>
>> >> >> Maxi
>> >> >>
>> >> >> Buenos Aires - Argentina
>> >> >> Desarrollador .NET 3 Estrellas
>> >> >> Microsoft User Group (MUG)
>> >> >>
>> >> >> "HPMig" escribió en el mensaje
>> >> >> news:
>> >> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo

de

>> > ACD)
>> >> >> > de
>> >> >> > un
>> >> >> > call center que recibe en prom. 9000 llamadas diarias. Su
> desempeño
>> >> >> > parece
>> >> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin
> embargo,
>> >> >> > después
>> >> >> > de un periodo de dos semanas obtengo el siguiente error:

"Timeout

>> >> >> > expired.
>> >> >> > The timeout period elapsed prior to completion of the
>> >> >> > operation
>> >> >> > or
>> > the
>> >> >> > server
>> >> >> > is not responding". Lo extraño es que ocurrió alrededor de las
> 3:00
>> > am,
>> >> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de
> conexión
>> > no
>> >> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
>> > timeout
>> >> >> > (30
>> >> >> > s). ¿podría ser un problema del pool?
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>