PDA

Ver la Versión Completa : Error en hilos de ejecución


cmfab
16-03-2019, 15:17:19
Hola a todos!

Este tema se que se ha tocado varias veces, y por días he estado revisando todo lo que he encontrado. No es primera vez que he trabajado con hilos y me ha funcionado perfectamente. pero en esta ocasión ha sido diferente. Les comento:

Necesito ejecutar dos hilos en una aplicación para rescatar datos de dos tablas diferentes. para ello estoy usando los componentes Firedac, la conexión es ODBC a un proveedor externo.

Los hilos deben ejecutarse en un orden, osea primero uno hilo, después el otro, por lo cual lo que hago es que cuando termina el primer hilo lanzo el segundo.

acá la clase que crea los hilos

THiloCheque = Class(TThread)
Constructor Create(cone: TFDConnection; const SQL: String);
private
FSQL: String;
FConnection: TFDConnection;
FConsulta: TFDQuery;
Protected
Procedure Execute; override;
Public
property Consulta: TFDQuery Read FConsulta Write FConsulta;
End;

//cheques detalles
THiloChequeDet = Class(TThread)
Constructor Create(cone: TFDConnection; const SQL: String);
private
FSQL: String;
FConnection: TFDConnection;
FConsulta: TFDQuery;
Protected
Procedure Execute; override;
Public
property Consulta: TFDQuery Read FConsulta Write FConsulta;
End;


y por poner el ejemplo del primer hilo ya que ambos son idénticos, les dejo el código de creación y ejecución:

{ THiloCheque }
constructor THiloCheque.create (cone: TFDConnection; const SQL: String);
begin
inherited Create(false);
FConnection := cone;
FSQL := SQL;
end;

procedure THiloCheque.Execute;
begin
inherited;
CoInitialize(nil);
consulta := TFDQuery.Create(application);
With consulta do begin
try
ResourceOptions.EscapeExpand:=false;
ResourceOptions.MacroCreate :=false;
ResourceOptions.MacroExpand :=false;
Connection := FConnection;
SQL.Add(FSQL);
Open;
Except
on e:Exception do
errores('Error en la captura de cheques: ' + e.Message );
end;
end;
CoUnInitialize;
end;


Estos hilos se ejecutan cada 20 segundos aproximadamente y actualizan una grilla de datos, el código de la llamada sería este:

primero el hilo que me trae los datos del detalle de los cheques

With THiloChequeDet.Create(v_con, 'Select * from lineasCheck ') do
begin
FreeOnTerminate := true;
OnTerminate := TerminaHiloChequeDet;
end;

cuando termina este primer hilo se realizan dos operaciones:
1- Se asigna el valor de la consulta a un componente FDMmemTable, previamente creado.
2- Se lanza el segundo hilo

acá el código

procedure TFPrincipal.TerminaHiloChequeDet(Sender: TObject);
begin

if consCheqDet.Active then consCheqDet.close;

if THiloChequeDet(Sender).Consulta.Active then
consCheqDet.Data := THiloChequeDet(Sender).Consulta.Data;

THiloChequeDet(Sender).Consulta.Free;


With THilocheque.Create(v_con, 'Select * from check' ) do
begin
FreeOnTerminate := true;
OnTerminate := TerminaHiloCheque;
end;
end;

Cuando termina el segundo hilo básicamente se hace lo mismo, se actualizan los datos y se libera el objeto consulta que es el TFDQuery creado en el hilo<

Problema:

Lo que sucede es que esto se ejecuta cada x segundos programados en un TTimer, funciona bien pero al cabo de unas horas o el programa se queda congelado, o las consultas nunca terminan, o salta una excepción con memoria o recursos insuficientes. Entonces me pregunto porqué puede estar pasando esto si los hilos en buena teoría se deberían estar destruyendo al terminar el proceso y además el único objeto que se crea en el hilo como tal es "Consulta!, y lo destruyo cuando este termina de ejecutarse. por otro lado el segundo hilo se ejecuta cuando termina el primero.

Alguna idea?

Gracias

Casimiro Notevi
16-03-2019, 17:23:05
¿Cuántos registros aproximadamente devuelve la sentencia 'select * from lineascheck' y cuánto tarda en ejecutarse?

cmfab
16-03-2019, 17:40:46
Son pocos los registros que trae, en las pruebas que estoy haciendo no más de 5, y demora unos 3, 4 segundos

Casimiro Notevi
16-03-2019, 17:52:03
¿4 registros y 4 segundos?

¿Para qué se necesitan los hilos?

cmfab
16-03-2019, 18:01:39
Los hilos se necesitan porque la consulta puede ser mayor, además el tema es que esta aplicación va a conectarse a una base de datos de una empresa que está trabajando todo el tiempo con su plataforma y los registros que genere de cheques van a ser procesados por esta app externa. la idea es que trabaje en segundo plano sin intervención del usuario.

Neftali [Germán.Estévez]
18-03-2019, 11:41:51
¿Seguro que estás liberando todos los recursos creados?
Prueba a activar ReportMemoryLeaksOnShutdown (busca en los foros si no te suena) para ver si se te están quedando recursos "colgados".
¿Dónde están definidos los procedimientos: TerminaHiloChequeDet y TerminaHiloCheque?

cmfab
18-03-2019, 14:54:55
Buenos días.

Gracias por responder, les comento que sigo complicado con este asunto que parece tan sencillo.

He decidido crear una unidad aparte para probar la aplicación sin hilos y me doy cuenta que el uso de la memoria aumenta considerablemente hasta que se llega al out memory. acá dejo el código, solo creo un objeto TADOconnection y un TADODataset que se destruyen a ki entender correctamente.

Ya he activado el ReportMemoryLeaksOnShutDown := True y no me arroja ninguna violación de memoria.

procedure importaDatos(tipoTransaccion:Integer);
var
tabla: TAdoDataset;
cone: TAdoConnection;
begin
cone := TAdoconnection.Create(application);
cone.ConnectionString := cadenaConexion;
cone.LoginPrompt := false;
try
cone.Connected := true;
tabla := TAdoDataset.Create(application);
tabla.Connection := cone;

if (tipoTransaccion = 0) or (tipoTransaccion = 1) then begin
conecta.cheq.Close;conecta.cheqDet.Close;
try
tabla.close;
tabla.CommandText := 'Select * from checkLine ';
tabla.Open;
conecta.cheqdet.Recordset := tabla.Recordset;
Except
on e:Exception do
InsertaLog ('Error al capturar los detalles de los cheques ' + e.message);
end;
end;
Except
on e:exception do begin
InsertaLog('No se pudo establecer la conexion ' + e.Message);
cone.Free;
tabla.Free;
exit;
end;
end;
tabla.close;
cone.close;
tabla.free;
cone.free;
end;



Este código lo ejecuto cada unos 20 segundos en un Timer

cmfab
18-03-2019, 15:05:09
Bueno, sigo probando y con solo ejecutar el código de conexión a la Base de Datos comienza a subir el consumo de memoria. En buena teoría se ejecute o no la conexión al final debería destruirse el objeto.

try
cone.Connected := true;
Except

end;
cone.Free;

Neftali [Germán.Estévez]
18-03-2019, 15:51:27
Ya he activado el ReportMemoryLeaksOnShutDown := True y no me arroja ninguna violación de memoria.



Eso no te va a reportar ninguna violación de memoria.
Sirve para (como bien dice su nombre) reportar pérdidas de memoria (normalmente por recursos no liberados correctamente) al finalizar la aplicación.

Neftali [Germán.Estévez]
18-03-2019, 16:25:12
acá dejo el código, solo creo un objeto TADOconnection y un TADODataset que se destruyen a ki entender correctamente.


Personalmente creo que deberías utilizar try..finally para liberar recursos, en lugar de hacerlo en los try..except
Cada estructura tiene su función y el try..except se usa para capturar excepciones.
Mezclar la gestión de errores, con la liberación de recursos, no me parece buena idea.

AÑADO: Además veo que en algún caso, puedes estar intentando destruir cosas que aun no has creado (por ejemplo, si se produce algún problema al conectar).

mamcx
18-03-2019, 16:43:30
Como mides el consumo de memoria? Usar el task manager, no importa el OS, no es muy util porque los OS actuales cachean memoria que da loco y pueden reportar que "usan" el 90% de la memoria pero no es la que EN ESTE INSTANTE esta usando la app, es la que el OS le cachea en el tiempo.

Tienes que usar un profiler especializado, o mirar los contadores de windows para precision....

-----

Hay varias cosas que resaltan, pero estas son las mas sospechosas:

1- Lo PEOR: Usas referencias globales! MAXIMO ERROR EN MULTI HILOS! NUNCA usar globales en multi hilos. Nunca. Eso no solo crea contención, sino que GARANTIZA DEADLOOCKS en un lenguaje como Delphi.

2- Me late que el mayor problema es:


conecta.cheqdet.Recordset := tabla.Recordset;


Como le asignas un POINTER de un objeto a OTRO, usando una INTERFACE que es refcounted????

3- Usar un timer... ok, pero es mucho mas simple si usas un ciclo con un sleep. Luego mira como reestructuras el código para formar una maquina de estados. Eso debe hacer el código mas claro y eliminar bugs que da miedo. Esto ademas elimina el problema de que cuando tengas un error, vas a reintentar de forma infinita hasta que muera el programa, que asi es como esta...

4- O mejor usa una librería adecuada para eso, quizás http://docwiki.embarcadero.com/RADStudio/Seattle/en/Using_the_Parallel_Programming_Library.

cmfab
18-03-2019, 18:23:48
Muchas Gracias por la respuesta de todos, aún no me queda claro el tema, voy a revisar las propuestas y les comento, por ahora decirles que conecta.cheq es un TADOdataset que se representa en una grilla de datos, lo hago de esta forma pasando el Recordset del objeto tabla para poder abrir y cerrar automáticamente una conexión a una base de datos externa. No se si tienen otra idea, pensé en llenar los datos que devuelve el TADODataset Tabla en un TClientDataset, pero como no se la estructura de los campos(nombres y tipos) me complica un poco.

cmfab
19-03-2019, 15:39:12
Buenos días a todos.

usando la instrucción ReportMemoryLeaksOnShutDown := True;

obtengo el mensaje que adjunto (no supe como incrustarlo acá en el mensaje). Me pueden indicar como descifrarlo, porque no lo entiendo muy bien.

Gracias de antemano!

Neftali [Germán.Estévez]
19-03-2019, 17:38:22
Fíjate que los tres primeros hacen referencia a clases; TParameters, TList y Tbquix_hilo
Te está diciendo que al acabar el programa no has liberado elemento/s de esas clases.

Si escribes un programa con este código:


var
lista1:TList;
begin
lista1 := TList.Create;
lista1.Add(Sender);
// lista1.Free;


Lo ejecutas y lo cierras, obtendrás este mensaje:

https://i.imgur.com/26dYafF.png

Si descomentas la línea del Free y lo vuelves a ejecutrar, verás desaparece.

Por lo tanto en el que te da a tí, revisa los lugares donde estás creando elementos de esas clases para ver si los estás destruyendo correctamente. A medida que vayas corrigiendo los errores, deberían desaparecer de ese mensaje.

cmfab
19-03-2019, 18:27:22
OK. Muchas Gracias por la aclaración, voy a revisarlo de inmediato, comento los resultados

cmfab
19-03-2019, 18:56:40
Bueno, sigo sin poder resolver el problema. El consumo excesivo de la memoria está en el hilo, ya lo he reprogramado de muchas maneras, he usado un Timer sin el hilo y todo sigue mal. no veo que se queden sin liberar recursos, en el resultado de la instrucción ReportMemoryLeaksOnShutDown := True; lo que tengo en esta clase son 6 strings con contenidos SQL, no se porque me hace referencia a ellos. acá el código de la clase del hilo


Tbquix_hilo = Class(TThread)
Constructor Create(ConnectionString,SQL1,SQL2,SQL3,SQL4,SQL5,SQL6:String; tipoT:Integer);
private
FSQL1,FSQL2,FSQL3,FSQL4,FSQL5,FSQL6: String;
FConnection: String;
FTipoT:Integer;
Data1,Data2, Data3, Data4,Data5, Data6: TADODataset;
Protected
Procedure Execute; override;
public
Property DataCheqDet: TADODataset read Data1 write Data1;
Property DataCheq: TADODataset read Data2 write Data2;

Property DataFactDet: TADODataset read Data3 write Data3;
Property DataFact: TADODataset read Data4 write Data4;

Property DataCMDet: TADODataset read Data5 write Data5;
Property DataCM: TADODataset read Data6 write Data6;
End;


la definición del constructor

constructor Tbquix_hilo.Create(ConnectionString,SQL1,SQL2,SQL3,SQL4,SQL5,SQL6:String; tipoT:Integer);
begin
inherited Create(false);
FConnection := Connectionstring;
FSQL1 := SQL1;
FSQL2 := SQL2;
FSQL3 := SQL3;
FSQL4 := SQL4;
FSQL5 := SQL5;
FSQL6 := SQL6;
FTipoT := tipoT;
end;


y el método de ejecución

procedure Tbquix_hilo.Execute;
begin
inherited;
CoInitialize(nil);
if (FtipoT = 0) or (FtipoT = 1) then begin
Data1 := TAdodataset.Create(Application);
Data1.ConnectionString := FConnection;
Data1.commandtext := FSQL1;
Data1.Open;
end;
CoUnInitialize;
end;

y cuando el hilo termina lo único que hago es leer los datos de ADODataset y copiarlos a un TClientDataset, después libero los objetos con esta instrucción:

Tbquix_hilo(Sender).DatacheqDet.Free;

y así para las 6 consultas, parece muy básico y sencillo.

no tengo idea porque se dispara la memoria, no actualizo controles de la VCL en el hilo, no uso variables globales. Que puede estar pasando ?.

Neftali [Germán.Estévez]
20-03-2019, 11:41:57
Falta código y todavía quedan dudas...

¿Los elementos que creas en el hilo, dónde los destruyes? (por norma lo que se crea en un sitio se destruye en ese mismo sitio

¿Utilizas Shyncronize?
¿Porqué no usas elDestroy del hilo?
No me queda claro que hagas el CoUnInitialize y luego continues trabajando con el Dataset (yo lo pasaría al Destroy).

cmfab
20-03-2019, 17:57:22
Buenos días.

Cuando el hilo se termina el Dataset creado en el mismo se destruye con la instrucción que puse anteriormente.

Los hilos se crean con la instrucción FreeOnTerminate := True, por lo cual deduzco que la propia clase hace el trabajo.

No uso el método Synchronize, puesto que lo único que hago es cuando el hilo termina y me devuelve los datos de la consulta es insertarlo en un TClientDataSet

hal1967
20-03-2019, 19:24:37
Siendo que pasasen el constructor "TFDConnection"

realmente no se que más hay con esa conexión (otros dataset o grillas). Asegurate que solo se use en ese hilo,
o no la pases al constructor, solo creala dentro del hilo.


constructor THiloCheque.create (cone: TFDConnection; const SQL: String);


Puedes hacerlo como prueba, ignora el pase de parámetros y creala en el constructor, y la destruyes en el destroy.

cmfab
20-03-2019, 19:39:53
Ok, Gracias, revisaré como se propone. aunque hay acá al parecer otro tema después de tantos quebraderos de cabeza, y es que algo no anda bien con el propio ODBC del proveedor, cuando hago una sola conexión la app funciona mejor, pero cuando hago conexiones dinámicas y las destruyo, ahí consume más recursos. Estoy haciendo pruebas al respecto.

mamcx
20-03-2019, 20:18:27
El problema de fondo es que la estructuración que tienes no es la ideal para multihilos. La mayoría de los lenguajes no ayudan tampoco, incluido Delphi.

Yo haría lo siguiente:

- Anula por ahora lo de multihilos
- Convierte el código en una maquina de estados. Asegurate de PASAR DATOS(valores) y no POINTERS. En donde haces una transferencia, clona información.

Una vez tengas limpio el código y andando lo pones y te sugerimos como estructúralos para hilos...

hal1967
20-03-2019, 21:23:16
Recuerda una conexión a una base de datos no es Threadsafe. Es posible que estás a mitad de una consulta y entre otro hilo (o el principal) y se cruce. Al servidor llegaría algo como "SELECT * FROM UPDATE ...".


Eso no solo pasaría con ODBC, pasaría con cualquiera.



Los servidores son threadsafe por que cada conexión es un hilo, pero no deberías tener en la misma conexión varios hilos al menos que trabajes con sincronización o locks (lo cual puede ser frustrante).


A otro nivel, a mi me ha tocado trabajar con cientos de hilos y es espetacular cuando funciona bien y de forma eficiente. No tienes porque crear un hilo, consultar y destruirlo, lo puedes volver a utilizar, lo creas en pausa con todos sus conexiones y dataset, cuando lo requieras start, cuando cierres tu aplicación liberas los hilos (previamente detenidos). La otra forma es que tengas un ciclo dentro del hilo, y al cerrar tu app, terminas previamente los hilos.


Si optas por algo de esto, no olvides, todo hilo debe ejecutarse al menos una vez, caso contrario dejas memoria en mal estado.

Neftali [Germán.Estévez]
21-03-2019, 09:09:37
Cuando el hilo se termina el Dataset creado en el mismo se destruye con la instrucción que puse anteriormente.
... por lo cual deduzco que la propia clase hace el trabajo.



Has creado los Datasets usando como Owner, el objeto Application, por lo tanto deberías revisar ese comportamiento.

cmfab
21-03-2019, 20:36:35
Solución.

Bueno definitivamente el tema se ha solucionado (al menos en las últimas 24 horas) aumentando el tiempo de las conexiones de 20 a 60 segundos, por lo que al parecer el controlador ODBC requiere de tiempo quizá para liberar recursos. aún no he puesto la pregunta en la web de soporte del proveedor, pero casi seguro que por ahí anda el tema.

Gracias a todos por sus recomendaciones y opiniones.