Joseph McCarthy de IBM Irlanda ha escrito un tutorial llamado "Using Comet for asynchronous user notification of autonomous server thread progression" sobre como usar polling y Comet (long polling) para informar al usuario de forma asíncrona a través de web sobre la progresión de un hilo autónomo (no ligado a los procesos web) que está realizando una tarea que conlleva mucho tiempo.
El problema elegido Joseph es el cálculo del número PI a través de la serie de Gregory-Leibniz, esta serie converge en teoría en el número PI. Un hilo en el servidor es creado con la finalidad de obtener un valor aproximado del número PI a través de un gran número de iteraciones. En el ejemplo de Joseph el criterio de parada del algoritmo es cuando el valor obtenido por aproximación es suficientemente igual (con un error dado) al valor de PI que conoce Java (Math.PI).
La obtención de un valor muy preciso de PI requiere muchas iteraciones que conllevan un tiempo significativo, si este cálculo lo hacemos en una aplicación web en un simple request, el tiempo requerido supera fácilmente la "paciencia" del usuario al ver una página que no termina de cargar, por otra parte es interesante conocer cual es la evolución del algoritmo más allá del valor final.
El tutorial consta de dos partes coincidentes con las dos estrategias usadas:
1) En la primera parte se usa la técnica "polling" con AJAX para informar al usuario sobre la progresión del cálculo que está realizando el hilo autónomo servidor. A través de AJAX con una periodicidad dada por un temporizador, el navegador pregunta al hilo del servidor por donde va el cálculo y para saber por supuesto si ya ha terminado.
2) En la segunda parte se utiliza Comet en su variante long-polling utilizando el soporte de Comet de ItsNat. Usando Comet el navegador del cliente es notificado de los eventos que ocurren en el servidor en el instante que ocurren, sin necesidad de que el navegador pregunte con una cierta frecuencia. La inspiración del artículo de McCarthy y especialmente esta parte del artículo se encuentra en este pequeño tutorial que escribí para Comet Daily, en donde se muestra cómo un hilo autónomo notifica eventos al usuario web cuando dichos eventos ocurren, este ejemplo también se encuentra algo más completo y en vivo aquí.
En este caso se usa el objeto CometNotifier de ItsNat, cuando el hilo que calcula el número PI quiere informar de su progresión (o de si ya ha acabado el cálculo) al usuario via web, sólo tiene que llamar al método CometNotifier.notifyClient(), dicha llamada genera un evento "Comet" especial en el servidor en el que un listener modifica el DOM en el servidor, dichos cambios se manifiestarán automáticamente e "instantáneamente" en el DOM cliente.
NOTA IMPORTANTE: el tutorial tiene importantes problemas de formateo visual y hay partes cortadas. Para poder leerlo completamente recomiendo usar Internet Explorer 6 (7 y 8 no valen) o FireFox quitando los estilos de la siguiente forma: menú View/Page Style/No Style.
Etiquetas: j2ee, comet, threads, web, itsnat
Con el debido respeto, pero incluso sin entrar en lo de escribir Java a porrillo en las JSP, ese código en Java es bastante bastante mejorable.
Imagino que te refieres al ejemplo de polling, en favor de Joseph hay que decir que su objetivo era mostras las ideas de una forma lo más compacta posible, está claro que sentencias tipo:
out.println("< html>< head>< title>Calculate Pi< /title>< /head>< body>Pi Estimated at: " + piEstimate + "< /body>< /html>"
y el código Java dentro de los JSPs dañan a la vista, pero la alternativa era crear más JSPs y más clases Java (para sacar el código fuera de los JSPs) incluso meter un framework web (Struts o similar), lo cual lo complica todo y hace que lo que pretende ser un tutorial demostrativo de "se puede hacer desde cero" sin gran parafernalia al final se convierta en un pequeño monstruo con montones de páginas. En el caso de Comet/long-polling utiliza ItsNat porque el ejemplo que propone se hace en dos patadas y la alternativa "desde cero" doy fe que sería muy muy costosa.
Saludos,
me gustaría que "greeneyed", fuera un poco mas explícito en el codigo Java mejorable. Sencillamente lo digo para mejorar al mismo tiempo mi propio código y saber en que defectos no debo caer. La opinión de un experto es siempre para mi bien recibida.
Gracias
Eduard
Por comentar algunos detalles sin extenderme, que tampoco es plan:
.- El código no es thread-safe, lo cual en una JSP clama al cielo.
.- ¿StringBuffer en vez de StringBuilder, a estas alturas de la película?
.- ¿Declarar con paquete completo las clases de java.lang?
... y montones de detalles "tontos" como...
piThread = (PiThread)getServletContext().getAttribute("piThread")if(piThread != null) {... // No se modifica piThread
}
// ¿¿Alguien me explica para que sirve la siguiente linea??
servletContext().setAttribute("piThread", piThread);.- O ¿para que sirve meter piThread y piThread.getPiEstimate() en el request, no basta con uno? ¿Y si al recuperarlos no devuelven lo mismo? ¿Y por que esos setAttribute estan repetidos en montones de sitios? ... ifs anidados con condiciones repetidas... el código en sí no es correcto por que no abre/cierra los tags del JSP donde toca...
Excepto la cuestion de que no sea thread-safe, son más detalles de "estilo" que otra cosa, pero, por favor, un codigo de ejemplo es para que la gente lo lea y aprenda. Si hacemos código chapuza por que es un ejemplillo y es más rápido, lo que conseguimos es que la gente que aprenda de él acabe haciendo código chapuza.
Dios mio, ha usado StringBuffer en vez de StringBuilder!!!!!!!!!
Dios mio, ha usado StringBuffer en vez de StringBuilder!!!!!!!!!
Dios mío, ha cogido UNO de los muchos detalles y lo ha sacado de contexto!!!!!!!!!!
@greeneyed: El código no es thread-safe, lo cual en una JSP clama al cielo.
La parte con ItsNat SI es thread safe cuando es código controlado por ItsNat aunque esa parte tiene algún problemilla de concurrencia de hilos en alguna variable compartida aunque la probabilidad de que falle es muy muy baja (aunque existe).
Lo del StringBuffer quizás sea influencia mia, pues para el ejemplo seguramente ha tomado código del Feature Showcase y/o del manual que es compatible JVM 1.4.
http://lab.arc90.com/experiments/readability/es/
o
mmm,
Creo que el articulo es acerca de Comet, no de Codificacion en Java.
tiene algún problemilla de concurrencia de hilos en alguna variable compartida aunque la probabilidad de que falle es muy muy baja (aunque existe).
Eso es como decir que una chica esta embarazada, pero no pasa nada por que sólo un poco. :)
Creo que el articulo es acerca de Comet, no de Codificacion en Java.
Nah, olvidadlo. Como si no hubiera dicho nada. A mi me importa un rábano, que yo ya sé no hacer esas barbaridades. A mí mejor, que luego me pagan por arreglar cosas así.
Con lo bien que estaba yo con mis vacaciones de jH, procuraré no molestaros más, tranquilos.
greeneyed: Eso es como decir que una chica esta embarazada, pero no pasa nada por que sólo un poco. :)
Je je. El error es cuando se pulsa el botón Stop el cual hace que cometNotifier sea null, sin embargo el hilo calculador cuando termina también tiende a terminar el cometNotifier, hace antes un chequeo de si es null, el problema es que si el Stop pone a null el atributo cometNotifier inmediatamente después del chequeo de cometNotifier si es null del hilo calculador, las llamadas a stop y a notifyClient fallarán con un null pointer exception, ahora bien la probabilidad de que ocurra esta situación es tremendamente baja y mi impresión es que errores mucho más gordos se encuentran en las aplicaciones que usamos todos los días :)
if (cometNotifier != null) { cometNotifier .notifyClient();
cometNotifier .stop();
}
La solución de este "improbable" fallo sería lo siguiente:
CometNotifier notifierTmp = this.cometNotifier;
if (notifierTmp != null) { notifierTmp.notifyClient(); notifierTmp.stop(); }Los métodos stop() y notifyClient() son tolerantes a un CometNotifier ya parado por lo que no darán error si fuera parado a la vez por el otro hilo (el del Stop) y además son multihilo.
Y relájate que te echamos de menos, ya sabes que desde el anonimato se puede ser muy atrevido :)
Tenía curiosidad de conocer la diferencia de rendimiento entre StringBuffer y StringBuilder y he hecho el siguiente microtest:
long t1 = System.currentTimeMillis();
for(int i = 0; i < 100; i++)
{
StringBuffer str = new StringBuffer();
for(int j = 0; j < 1000000; j++)
{
str.append("Hola");
}
}
long t2 = System.currentTimeMillis();
System.out.println(t2 - t1);
Idem con StringBuffer.
La diferencia es que con StringBuffer tarda un 20% por ciento más (usando Java 1.6), se ve que Java hace un buen trabajo con la "uncontended synchronización", es decir la sincronización de un método cuando no hay más hilos intentando entrar en dicho método tiene un coste afortunadamente bastante bajo (el caso de StringBuffer).
Notar que este ejemplo no es real pues estamos metiendo el mismo String "Hola" evitando crear objetos, un ejemplo más real sería:
long t1 = System.currentTimeMillis();
for(int i = 0; i < 100; i++)
{StringBuilder str = new StringBuilder();
for(int j = 0; j < 1000000; j++)
{ str.append(new String("Hola"));}
}
long t2 = System.currentTimeMillis();
System.out.println(t2 - t1);
En este caso apenas he encontrado un 2.6% de diferencia, el cual mide mejor la diferencia de rendimiento de StringBuffer y StringBuilder en un uso real. En una aplicación cualquiera en donde el tratamiento de strings es una cosa entre otras muchas tengo mis dudas de que la diferencia entre el uso de StringBuffer y StringBuilder llegue al 1% globalmente.
En definitiva, mejor usar StringBuilder claro pero no cambia la vida a nadie.
Si ya sé que no cambia la vida a nadie, igual que la llamada al método ese que no sirve para nada, o poner java.lang.* como si el paquete lang no estuviera importado por defecto... simplemente me pareció que como "código para enseñar al mundo" dejaba bastante que desear.
De todas formas, cualquier experto en rendimiento te dirá que esos microbenchmarks no valen practicamente para nada, puesto que la optimización del compilador, el tiempo de arranque etc. hacen que las medidas sean poco fiables. No digo que la diferencia sea mayor, podría ser menor, sólo que esos números son poco fiables.
Ah, y el fallo de sincronización que yo decía no es ese, es en la JSP del tutorial. Igualmente, eso de "la probabilidad es muy baja y hay fallos peores" me suena a "mal de muchos, consuelo de tontos" ;P.
Y yo "relajao", pero entre que esto cada vez esta menos movido y menos interesante y lo "interesante" que le añaden los anónimos, mejor estoy viendo la tele o machacando monigotes en el BloodBowl ;).
La tecnica comet es realmente interesante para cierto tipo de aplicaciones, sobre todo aplicaciones colaborativas (¿habeis visto google wave?, si gmail popularizo ajax...), y de momento es una tecnica un tanto desconocida por lo que articulos en este sentido son siempre bienvenidos.
Lo malo de comet es que es un tenica que hay que usar con ojo por los problemas de escalabilidad que puede presentar (thread suspendidos y conexiones "pilladas"), pero si tenemos claro estos problemas y encaja en nuestro contexto es una tecnica viable (una chapuza claro, como todo el desarrollo web, pero ya vivimos con esto :P).
Y el código es bastante regulero si, a mi me matan los if-else-if (polimorfismo!). Pero bueno el objetivo del ejemplo es mostrar el uso de comet, cojes las ideas y ya lo pones en bonito.
@remoh: por los problemas de escalabilidad que puede presentar (thread suspendidos y conexiones "pilladas")
Je, je, ese tema lo hemos discutido ya a muerte, pero si estás pensando en que las alternativas NIO son mejores, la realidad es que NADIE, NADIE, NADIE ha contradicho claramente y con datos las investigaciones de Paul Tyma sobre escalabilidad de NIO vs IO que publiqué en aquel artículo sobre su implicación en Comet.
En más de un artículo en Internet en donde se ha citado de refilón este tema he hecho a propósito algun comentario cuestionando alguna de las afirmaciones que se hacen sobre esto, no contrastadas con datos, con el fin de crear un debate con el asunto y el resultado fue el silencio...
Es más, el padre del núcleo de comunicaciones (basado en NIO) de GlassFish, Jean Francoise Arcand, reconoció en algún sitio que el "throughput" (rendimiento) de NIO es menor que IO lo cual es algo conocido desde hace tiempo, y sobre la escalabilidad desde el artículo de Tyma yo no he vuelto a leer NADA con datos sobre qué pasa con alto nivel de concurrencia, cuales son los límites.
A esto hay que añadir los miles y miles de conexiones que se pueden hacer en un test de laboratorio alabando la grandiosa escalabilidad del programa de turno, no valen para nada en el mundo real porque el ordenador está ya frito porque hay muchas cosas más que hacer en una aplicación Comet (o de cualquier otro tip) que las comunicaciones con el cliente (por ejemplo "miles" de accesos concurrentes a base de datos).
Asi que cada uno que llegue a sus conclusiones.
Je, je, leyendo novedades por Internet me acabo justamente de encontrar un artículo calentito sobre el tema.
Dice acerca de IO:
Cons: you need one thread by connection, but one thread means one stack (*) and one entry in the scheduler, not very scalable.
Acerca de NIO:
Pro: you can have more clients that the number of threads.
Como si no pudieras cambiar el flag de número máximo de threads. Yo creo que el problema de fondo es que la gente cree que los threads son como los núcleos del ordenador, que hay pocos y no puede haber más, cuando un thread no es más que un trozo de memoria, el stack, y trozo de código en el kernel del sistema operativo que se encarga de hacer un swap de vez en cuando de los registros del procesador para cargar los de otro thread. Es más o menos el mismo trabajo que hace el thread NIO cuando conmuta entre clientes NIO.
Si yo estaría encantado en que NIO fuera un 25% superior en escalabilidad que IO, para no tirar a la basura años de desarrollo en esa tecnología, pero mi impresión, espero equivocarme y que esto no lo lean los gurus que están detrás de Tomcat, GlassFish, WebLogic, Jetty etc, es que al final los esfuerzos en NIO han servido para poco más que para tener una herramienta de marketing y como mucho para ahorrar un poco de memoria de pila (a costa de complicar la programación).
Si la introducción de soporte de Comet en NIO en ItsNat fue en su momento una gran prioridad... hasta que leí el artículo de Paul Tyma, entonces pasó a tener una muy baja prioridad.
Es francamente curioso que el mismo Paul Tyma que tanto te gusta mencionar dice en su mismo blog, preguntado sobre si esa circunstancia se aplica a aplicaciones tipo chat, que...
Thats an excellent question because chat servers are an interesting use case. Many open connections, rare data flow - tons of receives as compared to writes.
Using NIO would be very viable there as you could possible exhaust threads or ram or something with a threadperconnction model.
Casualmente el mismo estilo de caso-de-uso que se suele utilizar con comet. Muchas conexiones abiertas (muchos clientes diferentes web) y relativamente poco tráfico... lo cual básicamente significa desperdiciar mucho tiempo los recursos reservados y eso nunca ha sido particularmente eficiente en ninguna arquitectura.
El apoyo a esta suposición de que es correcta por que este señor es muy listo y trabaja en Google... pues anda que no hay gente igualmente lista que trabaja en otros sitios que cree que NIO si escala mejor en algunas circunstancias, así que por ahí no cuela.
De igual forma y como recomienda el propio Mr. Tyma, los mitos sobre rendimiento hay que probarlos para el caso en partícular y en este caso tú para "derribar un mito", usas las medidas de otro señor, lo cual es "otro mito", así que básicamente cambias una suposición por otra suposición y la cuestión se queda en un mero "pues yo me fío más de este" o "mejor me fío del que me da los resultados que más me interesan".
Básicamente, ni IO ni NIO son lo mejor para todas las situaciones, así que cambiar un mito por otro es igual de simplista.
Lo que no veo claro del ejemplo es que se creen nuevas threads a pelo desde Java.
Hasta donde yo se, ¿no decía la especificación de JEE que el código del usuario no puede crear nuevas threads?¿Que los threads las maneja el propio contenedor creandolos,destruyendolos,etc cuando él lo considera necesario.?
Pensaba que para dejar código ejecutandose en el servidor debías usar JMS/EJB de Mensajes. De forma que desde el Servlet se hacía una llamada no bloqueante al proceso de larga duración (JMS/EJB de Mensajes) y en paralelo por un lado se acababa la petición del Servlet y por otra el proceso de larga duración seguía ejecutándose.
Eso es para aplicaciones Java EE, lo cual "no se aplica" en simples contenedores de servlets :).
En mi opinión es una recomendación muy generalista, pero claro, viendo el código que corre por el mundo a lo mejor se queda corta y todo :P.
Yo lo digo pq codigo que crea threads podria dejar de funcionar en algun servidor JEE logongas
greeneyed: El apoyo a esta suposición de que es correcta por que este señor es muy listo y trabaja en Google... pues anda que no hay gente igualmente lista que trabaja en otros sitios que cree que NIO si escala mejor en algunas circunstancias, así que por ahí no cuela.
Yo no se si Paul Tyma es muy listo o lo suficiente, si es guapo o feo, simpático o desagradable, el que trabaje en Google no lo convierte automáticamente en poseedor de la verdad, lo que diferencia la "opinión" de Paul de muchas "opiniones" que leído durante estos dos últimos años (y que durante un tiempo me tragué porque era la "verdad" aceptada), es que este señor se ha molestado en probar a través de test que hay de cierto "en lo que se dice por ahí", y a través de un test sencillo en donde únicamente cuentan las comunicaciones, demuestra con PRUEBAS que en sus tests, que insisto son intensivos en comunicaciones, intentando evitar cualquier otro tipo de procesos, el modo NIO queda detrás de IO en transmisión total de datos por unidad de tiempo, NO sólo en el caso de una conexión (1 hilo), sino en toda una serie de tests hasta un total de 1000 conexiones concurrentes, lo que en el caso de IO se traduce en 1000 HILOS CONCURRENTES.
No sólo se molesta en probar esto en un ordenador convencional sino que también le pide a un amigo en Azul Systems que haga lo mismo en un supercomputador con montones de núcleos, y creo recordar que la conclusión no sólo era la misma, además la diferencia era aún mayor.
No estamos hablando de opiniones "cree que NIO si escala mejor", la realidad es que no hay ningún estudio público que haya probado lo contrario, yo tengo la referencia de uno que no quiero sacar de nuevo porque parecería que estoy en contra de alguien (lo cual no es verdad), pero en ese estudio se probaban dos servidores de servlets, uno NIO y otro IO, y ganaba el NIO en escalabilidad con una victoria pírrica, "victoria" que por otra parte era discutible que se pueda atribuir a la "ventaja" de NIO sobre IO porque hay en juego muchos más factores y un servidor de servlets era la evolución mejorada del otro.
Somos de ciencias, y como hombres de ciencias el "principio de autoridad" tiene muy muy poco valor, en ciencias el "principio de autoridad" está unido al "principio de la vagancia" es decir, "me fio porque este tio me ofrece confianza y me da pereza verificarlo por mi mismo" pero nada más. El único aspecto que valoro de su trabajo en Google es el factor "veracidad", y el estudio citado fue presentado en un congreso representando a Google, y no juega mucho a tu favor el mentir o el presentar un estudio cuya pésima metodología da lugar a conclusiones erróneas.
La frase "Using NIO would be very viable there" yo la entiendo más como un "a lo mejor quien sabe lo mismo NIO funciona mejor en ámbito concreto", ahí él mismo entra dentro de la especulación "condescendiente", y la especulación es eso especulación, la antesala del conocimiento, no el conocimiento.
Y respecto a los recursos yo no nunca he dicho que IO consuma menos recursos que una solución NIO, pero te aseguro que el número de stacks que puede reservar en memoria una máquina convencional supera muy ampliamente el número de clientes razonable que la aplicación va a poder gestionar sin aburrir al usuario, ya sea en NIO, IO o PIOPIO. Yo mismo tengo el recuerdo hace años de hacer un test Java de 3000 hilos concurrentes en un trasto de 1 GHz y 500 Mb de RAM corriendo Windows XP usando el tamaño de stack por defecto de la JVM.
Finalmente si te preocupa la opinión de este señor sin tapujos lee ésto.
For the geeks out there, this is still of course a highly-multithreaded java implementation often running 4000 simultaneous threads. Pure Java I/O (not that stinky and slow NIO.
La palabra "stinky" no me atrevo a traducirla aquí, mi Babylon dice cosas muy feas.
Es su opinión, no la mia, cuando meta (si lo consigo) NIO en ItsNat a través de Atmosphere tendré mi propia opinión, que no creo que sea de escalabilidad sino más bien sobre programación y ya me estoy imaginando lo que tendré que poner en el manual, algo así como:
"El programador que use Comet a través del CometNofier con ItsNat en modo NIO ha de tener cuidado en el tipo de tareas que realiza en los eventos Comet, pues el hilo usado en dichos eventos es el hilo NIO que utiliza el servidor de aplicaciones para despachar eventos a otros clientes, el programador deberá evitar bloquear dicho hilo durante un tiempo significativo o realizar cualquier tarea en general costosa en tiempo pues tendrá un gran impacto en el rendimiento del sistema. Es recomendable crear un nuevo hilo o utilizar un hilo de un posible pool creado por el usuario y delegar a dicho hilo las tareas a realizar teniendo en cuenta que si el evento Comet termina, cualquier cambio en el servidor via DOM no se manifestará en el cliente, por lo que inevitablemente las acciones con impacto visual en el cliente han de hacerse en hilo del evento Comet o bien bloquear dicho hilo mientras se realizan estas acciones para que el hilo del evento Comet automáticamente envíe los cambios visuales realizados a través de ItsNat por el programador".
A lo mejor estoy confundido y no entiendo bien el funcionamiento los motores de comunicaciones NIO, pero me huelo que esta es una de las implicaciones.
Con este panorama ¿cómo crees que puedo ser entusiasta de las maravillas de las comunicaciones asíncronas aplicadas a long-polling? ¿que ventaja tiene una hamburguesa del McDonnalds que vale más cara que un solomillo?
Por cierto. Esto del comet, que tal se lleva con los proxis?
Entiendo que el comet, es mas o menos dejar abierto el socket para seguir mandando cosas. Me da la impresión de que o los proxis esto no les debe gustar un pelo.
Pues quedaremos de acuerdo en que no estamos de acuerdo, pero personalmente, pura opinión, creo que entiendes lo que quieres entender y sólo eso. Pero vamos, no tengo acciones de NIO ni nada parecido, así que ni me va ni me viene.
Por cierto. Esto del comet, que tal se lleva con los proxis?
La técnica long-polling se lleva muy bien porque en long-polling se abren y cierran continuamente conexiones y los proxies al menos obedecen a algo tan bestia como que una conexión se cierra, al parecer lo que no funciona bien es el Comet usando la técnica de streaming, con esa técnica que sería la ideal (el long-polling es un "hack") los proxies dan problemas porque son un caché que hay en medio que no controlas, el problema del streaming va más allá de proxies los propios navegadores dan problemas o directamente no lo soportan. En streaming no tengo experiencia personal, son referencias de otros, por eso es una técnica que no me interesa, porque no funciona en cualquier configuración, respecto al long-polling que doy fe que funciona en los navegadores más inimaginables, hasta en la basurilla del Pocket IE y los proxies responden ante eventos tan extremos como "nueva conexión", "conexión cerrada" o por lo menos yo no he oído nada al respecto.
creo que entiendes lo que quieres entender y sólo eso
Daniel si entiendo tu opinión de que a lo mejor en el caso de un número inmenso de conexiones en donde probablemente la memoria RAM de los stacks de los hilos sea excesiva (aunque siempre se puede ajustar a la baja hasta cierto límite funcional), "a lo mejor" una solución NIO puede ser la única opción, el problema es que el número de hilos necesarios para saturar la memoria de una máquina es TAN grande que en fin me cuesta "especular" con ese caso.
Y respecto al número de hilos no te preocupes, no creas que es algo esencialmente diferente a los selectores (uno por conexión) que gestiona un motor NIO, mi impresión es que creemos que un hilo es un recurso hardware cuando, insisto, no es más que un trozo de memoria, al igual que un selector NIO con la gestión del estado que conlleva es también un trozo de memoria, y al igual que un hilo puede dormir el sueño de los justos cuando está bloqueado y da muy poca guerra al scheduler, un selector puede estar tranquilito sin generar eventos de datos.
El problema es que aquí ya estamos especulando los dos y "los expertos que creen que NIO escala mejor en ciertas circunstancias" no salen a la luz más que con vaguedades genéricas y maximalistas que encima no son verdad, nunca con datos tipo "estudio de rendimiento y escalabilidad de un mega-chat con comunicaciones NIO y IO".
Casualmente he encontrado un ejemplo de Comet real con ItsNat del tipo descrito en el artículo.
Es de una casa de subastas de Barcelona (España).
En este caso se genera un PDF dinámicamente y se pone en un directorio tmp en el servidor, el usuario ve el seguimiento de la generación del mismo a través de un % de generación. Cuando termina la generación se añade dinámicamente un link con el URL del PDF a descargar.
La primera vez que se ejecuta se ve mejor porque al estar "frio" es algo más lento, las demás veces la generación es más rápida y apenas se ve el cambio en el porcentaje. Un vistazo al código fuente de la página muestra cual es el template inicial y se constata el uso de Comet.
Escribe tu comentario