Firebird AND Threads

[Abel Garcia]

Hola A todos tengo un problema en el que espero puedan ayudarme.

Un dia intentando probar el Acceso a una base de Datos de Firebird, realice la siguiente prueba en la misma aplicación cree dos Threads los cuales se ejecutarían al mismo tiempo cada uno con un Query y una transacción diferente, los arranque los dos al mismo tiempo, y mi sorpresa es que la aplicación se queda completamente colgada cuando se encuentran los dos, ósea no hay error de la aplicación o de comparición de recurso solamente se queda colgada. Ok Esto se puede arreglar por medio de Secciones Criticas o Semáforos Etc. En este caso en particular de dos Threads.

Esta solo fue una prueba que me enseño lo que pasaba. Bueno el problema que tengo es: Tengo una aplicación la cual tiene solo un Thread el cual esta realizando operaciones de lectura y escritura periódicamente, mientras que el hilo principal de la aplicación se dedica a hacer otras cosas, un dia tube la necesidad de que esta aplicación vigilara la escritura de una tabla por medio de un evento de Firebird y realizara algo al momento de la escritura en dicha tabla.
por medio de IBX use el componente de Eventos y lo bote en la aplicación principal, ahora debido al funcionamiento de este tipo de componentes los cuales se cuelgan del hilo principal de la aplicación. Al momento de lanzar un evento como era de esperarse, se pone en conflicto con el Thread de esta misma aplicación y de la misma forma que se quedaba la primera aplicación que les mencionaba se queda colgada. ahora como puedo salvar este problema usando Secciones Criticas o
Semáforos, alguien sabe por que se suscita este problema cual es la causa.

[Casimiro Notevi]

seguramente estás usando la versión superserver, prueba con la classicserver y nos cuentas qué tal

[Abel Garcia]

seguramente estás usando la versión superserver, prueba con la classicserver y nos cuentas qué tal

Hola que tal
Cual es mas o menos la Dif entre uno y otro, por que cres que esto prodria corregir este problema. Gracias:)

[Casimiro Notevi]

echa un vistazo a este enlace (http://www.firebirdsql.org/manual/es/qsg15-es-classic-or-super.html), quizás te sirva.

[rolandoj]

Hola,

Podrían comentar detalles de este problema ?. Tengo un problema similar que ya tiene mucho tiempo y sobre el cuál he venido trabajando un poco a ciegas, manejando las cosas a punta de prueba y error.

El escenario es el siguiente :

Tengo una aplicación, con un web server que es servidor ISAPI basado en WebBroker y un cliente Indy 8, ambos desarrollados inicialmente en Delphi 4, con BDE e Interbase 6, y Omnisecure como servidor.

Ese era un escenario prototipo para pruebas ya que al final estaremos con Oracle 10 (no lo tenemos aún disponible) y probablemente IIS

Las pruebas iniciales en ese escenario trabajaron bien.

Luego, por varios motivos, pasamos el escenario de pruebas a Delphi 2007 con dbExpress e Indy 10, y empezaron los problemas.

Concretamente, hay un problema de concurrencia, y esta aplicación si requiere soportar varios hilos simultáneos, por lo que el problema es preocupante.

Siguiendo algunos concejos, finalmente pasé a Firebird 2.0.3 SuperServer; pero el problema de concurrencia continúa. He aquí mis últimas pruebas:

1. Los hilos generados para ISAPI por la tecnología Webbroker parecen estar funcionando bien.

2. Cuando se accesa la Base de Datos, y los hilos son más o menos independientes (o sea, poco riesgo de que algunas operaciones colisionen), todo parece funcionar bien.

3. Cuando dos hilos accesan la Base de datos y sus operaciones internas trabajan frecuentemente sobre las mismas tablas, la aplicación se cuelga

4. Vale anotar que todo esto ocurre en un escenario de solo consulta; luego no existe la posibilidad de que una modificación en la Base de Datos pueda generar los problemas.

Estaba en camino de elaborar programas de prueba para analizar mejor el último caso, cuando me encontré este hilo que me hace suponer que definitivamente si hay problemas a nivel de las herramientas cuando se accesan simultáneamente las mismas tablas.

Aquí me aplican un par de preguntas:

1. El problema es el motor (interbase, firefird) ?

2. El problema es el driver dbExpress ?. Yo estoy usando el que viene para Interbase, supuestamente debería servir para Firebird.

Mucho agradecería si alguién pudiera documentar claramente esta situación.

[rastafarey]

Me parece que el problema lo tienes en la configuracion de las transacciones. O estas usando el suwt wait o noreadversion.

Por que si tienes configurado ReadVersion,commited,nowait.

Es servidor no se que da esperando por que otra transaccion termine.

Es mas si es un simple y mortal select menos qu emenos te daria ploblema.

Con decirte qeu si configuras bien las transacciones no veras jamas ni el gfamoso abrazo mortal (deadlock).

Ya que la data afecta sera la ultima guarda asi se ejecuten los dos al mismo tiempo. debido a que el procesador solo puede ejecutar un proceso a la ves (atomicamente).

Ahora no se si tu equipo tine doble procesador y estas trabajkando con una version d efirebird que tenga soporte para varios procesadores.

[rolandoj]

Me parece que el problema lo tienes en la configuracion de las transacciones. O estas usando el suwt wait o noreadversion.

Por que si tienes configurado ReadVersion,commited,nowait.

Es servidor no se que da esperando por que otra transaccion termine.

Es mas si es un simple y mortal select menos qu emenos te daria ploblema.

Con decirte qeu si configuras bien las transacciones no veras jamas ni el gfamoso abrazo mortal (deadlock).

Ya que la data afecta sera la ultima guarda asi se ejecuten los dos al mismo tiempo. debido a que el procesador solo puede ejecutar un proceso a la ves (atomicamente).

Ahora no se si tu equipo tine doble procesador y estas trabajkando con una version d efirebird que tenga soporte para varios procesadores.

Hola,

Ante todo, muchas gracias por los comentarios. Tengo unas dudas a ese respecto; pero, independientemente de ellas, no veo por qué la configuración de transacciones pueda incidir en mi problema.

Resulta que el bloqueo está ocurriendo en consultas. No hay nada que, ni siquiera indirectamente, implique modificar la Base de Datos. No se inicia explícitamente ninguna transacción desde el programa, ni hay riesgo que durante esas pruebas alguien invoque otro proceso que involucre el arranque de una transacción.

Lo otro sería que exista algún manejo automático de transacción por parte del motor o el driver; pero si es así, escapa a mis conocimientos al respecto.

Eso me conduce a la dudas que mencioné. Los parámetros de configuración a que te refieres no los encuentro, ni a nivel del servidor vía IBOConsole ni a nivel del componente TSQLConnection de dbExpress. Como los configuras ?. Yo pensé que eran manejo automático de dbExpress. Acaso es necesaria una herramienta distinta a IBOConsole ?.

Esa parte me interesa porque aún no hemos empezado pruebas intensas sobre transacciones.

Muchos gracias por todo

[xander]

Nop, no es el Firebird... yo ya pasé por estas mismas, y no es el firebird ni las transacciones el problema, sino los componentes que usas para conectarte... el mismo problema tendrán quienes quieran montar una web con estos, en cuanto dos usuarios solicitan información al mismo tiempo el servidor se bloquea.

Generalmente ni IBO, ni IBX, ni FIBPlus estan pensados para trabajar con multiples hilos en paralelo usando sus mismos recursos... los únicos componentes que encontré que funcionan bien en ese ambiente son los UIB (http://www.progdigy.com/modules.php?name=UIB) son los únicos ThreadSafe que conozco.

These components are "Thread-Safe" with any version of Interbase, FireBird and Yaffil and are working with Delphi, BCB, Kylix, Lazarus & FPC (Win32, Linux, FreeBsd).

[rolandoj]

Nop, no es el Firebird... yo ya pasé por estas mismas, y no es el firebird ni las transacciones el problema, sino los componentes que usas para conectarte... el mismo problema tendrán quienes quieran montar una web con estos, en cuanto dos usuarios solicitan información al mismo tiempo el servidor se bloquea.

Generalmente ni IBO, ni IBX, ni FIBPlus estan pensados para trabajar con multiples hilos en paralelo usando sus mismos recursos... los únicos componentes que encontré que funcionan bien en ese ambiente son los UIB (http://www.progdigy.com/modules.php?name=UIB) son los únicos ThreadSafe que conozco.
Hola,

Muchas gracias por la información.

Es un dato muy útil; pero, en este caso específico, no estoy usando ninguno de ellos. Yo trabajo con dbExpress. Tengo dos razones :

1. Por metodología, nunca trabajo con componentes específicos a una base de datos. Mi filosofía es que las aplicaciones deben ser portables, cambiar de motor debe ser tan fácil como cambiar un "Alias" a la base de datos, a lo sumo, en casos extremos, algún cambio mínimo en el código. En este caso en particular, es aún más cierto porque Firebird, y previamente Interbase, son ambientes de prueba. La versión de productivo estará en Oracle 10, y, por razones ajenas a mi voluntad, aún no dispongo de Oracle para tener un ambiente de pruebas ahí.

2. Siempre he usado BDE; pero al cambiar a Delphi 2007, parte de las razones fué porque se nos habló mucho de un superior rendimiento de dbExpres, algo de lo que aún no tengo evidencia. Lo anterior para decir que tengo poca experiencia con dbExpress.

Ahora, en vista de tú comentario, me asalta una duda que ya he expreasdo en otros hilos. El driver dbExpress para Interbase/Firebird es hilo seguro ?. No he encontrado nada concreto al respecto; pero, a estas alturas uno debería esperar que sí. De tú comentario, deduzco que no lo es. Es un hecho que tienes confirmado ?

Una vez más reitero las gracias

[jachguate]

Generalmente ni IBO, ni IBX, ni FIBPlus estan pensados para trabajar con multiples hilos en paralelo usando sus mismos recursos... los únicos componentes que encontré que funcionan bien en ese ambiente son los UIB (http://www.progdigy.com/modules.php?name=UIB) son los únicos ThreadSafe que conozco.

Hola xander.

Doy testimonio de haber usado IBX en aplicaciones multihilo contra firebird 1.5 y superiores, sin mayores contratiempos.

Un saludo.

;)

[rolandoj]

Hola xander.

Doy testimonio de haber usado IBX en aplicaciones multihilo contra firebird 1.5 y superiores, sin mayores contratiempos.

Un saludo.

;)
Hola.

Muchas gracias por la participación.

Quiero remitirme a la primera nota que he escrito en este hilo. Como puedes apreciar, el problema no es genérico. Al parecer ocurre bajo ciertas circuntancias que no he podido determinar con exactitud, aunque sigo acotándolo a medida que diseño más programas de prueba.

Pudiera ocurrir que exista algún problema que se dispara solo bajo ciertas circunstancias. Las consultas donde tengo el problema conforman un proceso muy complejo que incluye queries multitablas, y me viene a la mente uno de los primeros problemas que he tenido con Delphi 2007 y dbExpress : La necesidad de darle nombre explícito a campos Sum() o Count(), o constantes, en consultas.

Eso es un error particular. Quizás algo de eso está ocurriendo y por ello a unos les ha funcionado bien y a otros no.

Muchos saludos

[Chris]

A forma de opinión.

Concuerdo con rastafarey. (http://www.clubdelphi.com/foros/member.php?u=1833)
Ahora recuerdo. Cuando estaba iniciando el proceso de migración a Firebird, estove provando la configuración de las transacciones, en ese momento eran algo nuevo para mí, porque hasta entonces solo había trabajado con motores DB basados en archivos. No recuerdo exactamente que configuración era exactamente, pero había una que no me dejaba que dos hilos consultaran una misma tabla al mismo tiempo, el segundo siempre se quedaba colgado hasta que el otro terminara de "ver" los datos.

rolandoj (http://www.clubdelphi.com/foros/member.php?u=17906), a mi también me costó creer que una tonta configuración en la transacción pudiera impedir que dos clientes puedan visualizar una tabla al mismo tiempo. No sé si a algún compañero le ha pasado, pero es cierto, no estoy inventando.

Ahora, lo de configurar la transacción con dbExpress, no tengo ni idea.
Hola,
1. Por metodología, nunca trabajo con componentes específicos a una base de datos. Mi filosofía es que las aplicaciones deben ser portables, cambiar de motor debe ser tan fácil como cambiar un "Alias" a la base de datos, a lo sumo, en casos extremos, algún cambio mínimo en el código. En este caso en particular, es aún más cierto porque Firebird, y previamente Interbase, son ambientes de prueba. La versión de productivo estará en Oracle 10, y, por razones ajenas a mi voluntad, aún no dispongo de Oracle para tener un ambiente de pruebas ahí.
Puede que tengas cierto punto de razón, pero que tan a menudo uno cambia el motor DB de su aplicación. Creo que primero deberías de verlo por el lado del valance, entre tu productividad y la calidad de tu sistema.

Saludos.

[rolandoj]

A forma de opinión.

Concuerdo con rastafarey. (http://www.clubdelphi.com/foros/member.php?u=1833)
Ahora recuerdo. Cuando estaba iniciando el proceso de migración a Firebird, estove provando la configuración de las transacciones, en ese momento eran algo nuevo para mí, porque hasta entonces solo había trabajado con motores DB basados en archivos. No recuerdo exactamente que configuración era exactamente, pero había una que no me dejaba que dos hilos consultaran una misma tabla al mismo tiempo, el segundo siempre se quedaba colgado hasta que el otro terminara de "ver" los datos.

rolandoj (http://www.clubdelphi.com/foros/member.php?u=17906), a mi también me costó creer que una tonta configuración en la transacción pudiera impedir que dos clientes puedan visualizar una tabla al mismo tiempo. No sé si a algún compañero le ha pasado, pero es cierto, no estoy inventando.

Ahora, lo de configurar la transacción con dbExpress, no tengo ni idea.

Puede que tengas cierto punto de razón, pero que tan a menudo uno cambia el motor DB de su aplicación. Creo que primero deberías de verlo por el lado del valance, entre tu productividad y la calidad de tu sistema.

Saludos.
Hola,

Muchas gracias por los comentarios.

Lo que dices de las transacciones apoyando a rastafarey. (http://www.clubdelphi.com/foros/member.php?u=1833), me deja preocupado. La filosofía de una transacción es que se debe usar para impedir que alguién modifique (o incluso consulte, dependiendo de como estén configuradas), los datos protegidos en la misma.

Si, como tú estás confirmando, una configuración de transacción bloquea las simples consultas simultáneas, a pesar de que no hay una transacción explícita en progreso, el asunto es para pensarse. Ahora bien, en las pruebas que he hecho, eso no parece estar ocurriendo. El problema parece ocurrir con consultas complejas, aunque aún no puedo confirmarlo al 100%.

Adquiere más importancia entonces saber como hacer esa configuración para la combinación Firebird/dbExpress

Por último, en mi caso es relativamente frecuente el uso de diferentes motores de Bases de Datos, entre otras cosas porque trabajo independiente con varios clientes. De todas formas, aún si ese no es el caso, recomiendo fuertemente usar metodologías de portabilidad por el ahorro que representan para el cliente.

Una de mis mejores experiencias fué cuando una aplicación grande y vital, que tengo para una empresa importante, la pasaron de Oracle a SQL - Server. La tengo con BDE y solo necesité cambiar el Alias de la Base de Datos en el BDE, no se requirió ni una línea de código extra.

Michos saludos

[Chris]

rolandoj (http://www.clubdelphi.com/foros/member.php?u=17906), la configuración que mencioné algún proposito debe tener (mantenimiento por ejemplo), no es la predeterminada, que a como dije, llegué a ella traveseando con la configuración. No vayas a pensar que Firebird es un mal e inepto servidor.

Por otro lado, dices que sospechas que puede ser por la complejidad de la consulta, si tuvieras que darle una escala del 1 al diez, que le darías? Intenta ejecutar la consulta al mismo tiempo en dos o más clientes distintos exactamente al mismo tiempo, que notas en el tiempo de respuesta, hay un margen claro y constante? Por otro lado, los hilos de ejecutan en la misma PC? porque también el problema lo puede causar dbExpress. Haz la prueba que te digo en distintas PC* y fijate en todos los detalles, haz la consulta en parte y ve donde está el cuello de botella.

Por otro lado, te aconsejaría que hagas pruebas con componentes nativos, como IBX o MDO. Puede ser que este tipo de puebas te ayuden a encontrar donde puede estar tu problema.

* Recuerda:
... el procesador solo puede ejecutar un proceso a la ves (atomicamente).

Saludos.

[rolandoj]

rolandoj (http://www.clubdelphi.com/foros/member.php?u=17906), la configuración que mencioné algún proposito debe tener (mantenimiento por ejemplo), no es la predeterminada, que a como dije, llegué a ella traveseando con la configuración. No vayas a pensar que Firebird es un mal e inepto servidor.

Por otro lado, dices que sospechas que puede ser por la complejidad de la consulta, si tuvieras que darle una escala del 1 al diez, que le darías? Intenta ejecutar la consulta al mismo tiempo en dos o más clientes distintos exactamente al mismo tiempo, que notas en el tiempo de respuesta, hay un margen claro y constante? Por otro lado, los hilos de ejecutan en la misma PC? porque también el problema lo puede causar dbExpress. Haz la prueba que te digo en distintas PC* y fijate en todos los detalles, haz la consulta en parte y ve donde está el cuello de botella.

Por otro lado, te aconsejaría que hagas pruebas con componentes nativos, como IBX o MDO. Puede ser que este tipo de puebas te ayuden a encontrar donde puede estar tu problema.

* Recuerda:


Saludos.
Hola,

Muchas gracias por todo el apoyo.

Empiezo diciendote que las pruebas se han hecho con consulta simultánea desde dos PCs distintos a un servidor. Se trata de PCs ubicados en sitios físicamente distintos al servidor y con proveedores de Internet distintos. Claro está, desde ambos PCs, cuando no hay simultaneidad, o se trata de consultas que usan tablas distintas de la Base de Datos, o las mismas; pero en eaquemas relativamente simples (una tablas y pocas condiciones), trabaja bien; incluso, en la propia consulta del problema parece trabajar cuando el nivel de complejidad no está en sus máximos niveles.

Me explico mejor para que visualices la complejidad:

Estas consultas son creadas dinámicamente desde una interfase de usuario que permite escoger los campos a incluír (potencialmente cerca de 100) y las condiciones a colocar (algo así como un SQL guíado; pero el usuario no vé nada que parezca un lenguaje). Las condiciones también pueden ser numerosas; pero no tanto, aunque algunas condiciones pueden tener varios anidamientos. Dependiendo de los campos y las condiciones a incluír, se pueden ir agregando tablas a la consulta, generando bastantes uniones, e incluso otras complejidades de filtros que no pueden incluírse directamente en el Where, todo esto dinámicamente. A lo anterior, agrega que hay algunas consultas adicionales independientes que complementan el Query principal

Darle una calificación puede ser dificil; pero, dado que no se incluyen clausulas Group By o Having, yo lo pondría en 8, máximo 9

En cuanto al cuello de botella, cuando estas consultas se ejecutan solas, pueden tardar entre 10 y 20 segundos. Cuando se presenta el bloqueo, he llegado a esperar 20 minutos y siguen bloqueados. Eso podría hacer pensar en un cerrojo mortal; pero no veo por qué, dado que no hay transacciones explícitas.

Todo esto me lleva a una pregunta adicional. Hay alguna herramienta para monitorear problemas multihilo ?. Porque aquí el inconveniente es que siendo el código tan complejo, conteniendo en sí mismo varias Select, no conozco una manera de poder decir: el bloqueo se presenta al ejecutar la instrucción XXX.

Lo más lógico que pienso en este momento es que ocurre en la consulta más compleja del código; pero, no podría asegurarlo totalmente.

Muchos saludos

[rastafarey]

buenos amigos yop uso ibo y jamas he tenido esos problemas.

[Chris]

buenos amigos yop uso ibo y jamas he tenido esos problemas.
Como ya le había recomendado a rolandoj (http://www.clubdelphi.com/foros/member.php?u=17906) sería bueno que hiciera una prueba con componentes nativos para la conexión, hay que recordar que dbExpress adapta el Query para que sea compatible con la mayoría de las DBs.

[rolandoj]

buenos amigos yop uso ibo y jamas he tenido esos problemas.

Hola,

Agradezco mucho el aporte; pero, yo necesito que mis programas sean portables entre motores de bases de datos, luego no me sirven los componentes IBO.

Por otra parte, con las últimas pruebas, me asaltan dudas de que el acceso a la Base de Datos no sea el único problema. Veamos:

Una de las pruebas extremas que hice fué encerrar todo el código de una consulta en una sección crítica, y, para mi sorpresa, se bloqueó. Complementé la prueba implementando mi propia sección crítica para garantizar que no se ejecutará otra consulta mientras se estuviera ejecutando una llamada; y me funcionó bien.

La conclusión que saco es que algo pasa con el manejo del componente TCriticalSection y, por razones que desconozco, permitió que se ejecutara algo en "simultánea". Averigué algo y al parecer hay aspectos "oscuros" en el tema. La explicación dada en las ayudas de Delphi, y usualmente encontrada en ejemplos, puede no ser tan completa como podría esperarse, ya que encontré notas donde alguién advierte de problemas relacionados con ella e incluso dice que los variable compartidas TList deben ser protegidas con una clase diferente a TCriticalSection. Vean esta página: http://www.gothi.co.uk/2006/10/threading-in-delphi.html

El tema me interesa porque, por eficiencia, se manejan un objeto global para datos caches con varias listas descendientes de TStringList. No hay riesgo de que afecten las pruebas hechas porque durante las mismas nunca se han usado las opciones que modifican datos globales. Alguién sabe de algún hilo donde se trate a fondo este tema, o puede abrir alguno para ilustrarlo ?

Lo importante de este caso es que me ha hecho pensar en la posibilidad que el problema no esté en el propio acceso a la Base de Datos. El código de estas consultas es muy complejo y quizás se están llamando algunas rutinas de librería Delphi que no son hilo seguro. No lo había considerado antes porque tenía entendido que lo que no era hilo seguro eran los componentes visuales, y este es un DLL que no los usa; pero, quizás hay otras unidades que no lo son. Alguién puede sugerir como revisar esta posibilidad ?

[rolandoj]

Como ya le había recomendado a rolandoj (http://www.clubdelphi.com/foros/member.php?u=17906) sería bueno que hiciera una prueba con componentes nativos para la conexión, hay que recordar que dbExpress adapta el Query para que sea compatible con la mayoría de las DBs.

Hola,

No creas que he olvidado tú sugerencia. Lo que pasa es que, para que pueda servirnos, sería necesario reemplazar todo lo involucrado, ya que no tendría sentido estar probando con unas queries vía dbExpress y otras IBO en la misma consulta. Son bastantes llamadas, luego, aún si me funcionara todo bien, lo único que probaría sería que el problema es con dbExpress; pero no me diría si es configuración de dbExpress o algún error en su código, y ni siquiera me localizaría el punto del problema.

Por lo anterior, no he probado por ese camino; pero, de todas formas agradezco la idea.

De hecho, la idea que tengo ahora es esperar a Oracle; pero, en el intermedio, revisar lo que se pueda, siempre y cuando no represente demasiado esfuerzo

Saludos

[rolandoj]

Hola,

Empezando a ver lo de la sección crítica, me encontré una referencia a su uso en DLLs, que es mi caso. Me asaltan muchas dudas, ya que no había encontrado antes ninguna observación al respecto, dentro de lo que he leído; así que le abrí un hilo. Pueden verlo aquí:

http://www.clubdelphi.com/foros/showthread.php?t=54254

El punto es que si la cosas son como dice la referencia que encontré, deberé recodificar la parte de actualización de variables globales (Por cierto, no olviden que eso no afecta al problema actual, ya que en las pruebas realizadas aún no hemos usado datos globales)

[rolandoj]

Hola,

El problema parece solucionado, aunque aún persisten algunas anormalidades.

Les adelanto que sí tenía que ver con drivers, aunque no exactamente un error en ellos. Les explicaré bien en cuanto solucione algunos detalles aún oscuros.

Ahora les pido colaboración a ver si alguién puede aclarar algo que encontré como parte de la investigación de este problema. Es un detalle que había manejado hace tiempo y lo había pasado por alto; pero que me genera dudas.

Le abrí el siguiente hilo :

http://www.clubdelphi.com/foros/showthread.php?t=54401

[rolandoj]

Hola,

Les cuento que las pruebas para aclarar los otros detalles me han llevado a un punto donde requiero ayuda.

Recuerdan mis dudas respecto a TCriticalSection ?. Eran porque la concurrencia también fallaba en casos en los que una de las llamadas no involucraba acceso a Bases de Datos. Pués bien, todo parece indicar que es más bien un limitante o un problema de configuración con Indy. Es un caso
que técnicamente puede servirle a algunos. Le abrí este hilo:

http://www.clubdelphi.com/foros/showthread.php?t=54448