queueing system
18 views
Skip to first unread message
Niurka Perez Mitjans
Dec 14, 2016, 2:16:41 PM12/14/16
to improve-your-code
Hola Improve-your-coders,
Les escribo para pedir sugerencias sobre un sistema para Message Queue en .NET que me puedan recomendar.
La arquitectura que tenemos es de un REST API que se comunica con "pequenos" microservices que tambien son rest api. La forma que ahora ocurre esa comunicacion es de forma sincrona, un microservicio llama al proximo y espera la respuesta.
La idea es utilizar algun framework que nos permita tener esta comunicacion mas desconectada, creariamos colas para que cada servicio haga su parte y deja un mensaje en la cola para que el proximo servicio continue el flujo. Es decir cada servicio se inscribe a recibir notificaciones de la cola y hace el procesamiento cuando llegue su mensaje y asi sucesivamente.
Alguien ha tenido alguna buena (o mala) experiencia con algun framework para message queue ?
Saludos y Feliz naviadad !
Niurka
Oscar Enrique Fraxedas Tormo
Dec 14, 2016, 2:42:49 PM12/14/16
to improve-your-code
Hola Niurka,
En mi trabajo anterior cambiabamos la technologia de colas cada 18 meses.
Pasamos de "Red Hat MRG" a "Oracle AQ" a "SQL Server" y cuando me fui estaban cambiando de nuevo.
La experiencia con Oracle AQ es: buen performance y mala documentacion. Para Ops era un problema administrarla por la falta de informacion.
SQL Server tables: good enough para los casos donde los work items son pocos y se demoran mucho en procesar. Ops la administraba sin ningun costo adicional.
Yo no usaria ninguna de esas opciones hoy.
Tienes idea de la cantidad de mensajes que tienes que soportar y del tiempo de procesamiento de cada uno?
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Regards,
Oscar Fraxedas
Niurka Perez Mitjans
Dec 14, 2016, 2:57:02 PM12/14/16
to improve-your-code
Gracias Osky,
Es dificil de responder los numeros porque todavia el sitio esta en beta y no tiene muchos usarios.
En cada request de un usuario, se generarian como promedio 10-20 mensajes. Hay algunos que demoran milisegundos y otros demoran mas porque llaman a terceros servicios.
Dicen los duenos que vamos a tener millones de usuario but... not yet ;)
besitos
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
----Regards,Oscar Fraxedas
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Carlos A. Osoria
Dec 14, 2016, 3:09:16 PM12/14/16
to improve-...@googlegroups.com
Hola Niurkita
Si los micro-servicios todos corren en windows y estan escritos con las herramientas de Microsoft .NET, C, C++, entonces hechale un ojo a MSMQ, resuelve el problema, es rapido, facil de usar y tiene herramientas en windows que permiten monitorear las colas.
Si los micro-servicios estan escritos en varios lenguajes y corren en varias plataformas, creo que una de las mejores opciones seria usar ZeroMQ, quiza otras plataformas mas robustas como ActiveMQ o RabbitMQ tambien sirvan pero como dices micro-servicios la verdad lo mas simple quizas sea ZeroMQ
Aca un link con varias de estas technologias ...
Lo unico que aconsejaria es no meter las colas en sql server :( aca tenenos las colas en sql server y la verdad que es una complicacion, pues el modelo que usamos que es un modelo trivial siempre esta dando problemas de performance ... si se pudiera usar MSMQ es mucho mas facil, menos complicado y trabaja mucho mas rapido.
Saludos
Carlos
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--Regards,Oscar Fraxedas--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Carlos A. Osoria
Dec 14, 2016, 3:21:56 PM12/14/16
to improve-...@googlegroups.com
Niurka Perez Mitjans
Dec 14, 2016, 3:27:02 PM12/14/16
to improve-your-code
Gracias Carli, sí, todos los servicios son en .NET, estoy viendo los sitios que mandaste.
Saludos
Erich
Dec 14, 2016, 3:42:48 PM12/14/16
to improve-...@googlegroups.com
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Ernesto Freyre
Dec 14, 2016, 3:48:01 PM12/14/16
to improve-...@googlegroups.com
RabbitMQ, Apache Kafka, si quieres algo local, on-premises no están mal
Personalmente uso AWS SQS conectado a AWS Lambda y es muy eficiente y rápido.
Saludos
Ernesto
Personalmente uso AWS SQS conectado a AWS Lambda y es muy eficiente y rápido.
Saludos
Ernesto
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--Regards,Oscar Fraxedas
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Román Fresneda Quiroga
Dec 14, 2016, 3:56:40 PM12/14/16
to improve-...@googlegroups.com
Si todos los servicios están corriendo en una misma red, AWS SQS puede ser overkill. Ahora, es completamente administrado por AWS, así que te quitas doscientos dolores de cabeza. Total-cost-of-ownership también es importante!
Román Fresneda Quiroga
Dec 14, 2016, 4:01:12 PM12/14/16
to improve-...@googlegroups.com
Otra cosa, tus servicios forman una cadena o un grafo? Si decides usar una sola cola entonces tienes que tener un coordinador central, si te vas por una cola por servicio entonces es más fácil de entender pero más difícil de administrar.
Si en realidad lo que tienes es un 'workflow', entonces considera AWS SWF.
Jose Enrique Mariño Iglesias
Dec 14, 2016, 5:48:46 PM12/14/16
to improve-...@googlegroups.com
Mi granito de arena
Algo hice por aquí, no son servicios lo que venían al caso pero si envío de mensajes a colas y servidores con cluster y réplicas y demás. El objetivo? pasar ficheros xml (byte a byte con seguridad y demás) de un lugar a otro. Usamos inicialmente ActiveMQ pero tiene una restricción en cuanto a tamaño, y lo picábamos en porciones admisibles de bytes, luego alguien aconsejó RabitMQ y no estaba mal. Esto se puede poner en varios servidores y todos suscritos a ellos y sus colas, por temas y todo lo que quieras. No es complejo y sí te quita muchos dolores de cabeza como que si se desconecta alguien se garantiza persistencia y que el mensaje sea entregado etc. El Charlistón ya lo dijo, solo lo reafirmo, esto funciona bastante bien.
Saludos
Pepe
Ramon Araujo
Dec 14, 2016, 6:49:10 PM12/14/16
to improve-your-code
Hola Niurka,
Parece no venir al caso, pero, gracias a una pregunta-respuesta de Erlis conoci al magico Hangfire(.io). Es tan bueno que es usado hasta por los grandes bancos de aca.
Cuando decias "dejar un mensaje en la cola para que el otro servicio..." pense en dos cosas:
- Enviar "Notifications" (para que no halla que esperar a chequear cada cierto tiempo). Solucion antigua de ustedes
- Que cada servicio "dependiente" chequee la cola periodicamente (para esto Hangfire es el tipo)
Lo bueno de Hangfire es que esta preparado para correr varios "SERVERS", procesar QUEUES, JOBS, etc. Mirate un ejemplo de la configuracion de las colas aca:
Saludos,
Ramon Araujo
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Israel García
Dec 14, 2016, 6:53:26 PM12/14/16
to improve-...@googlegroups.com
Yo estoy desarrollando algo con arquitectura similar a eso y usamos rabbitmq, he leído que kafka es también muy bueno. Usamos rabbit porque nos da más opciones de enrutamiento y armar flujos con más elementos de configuración.
Ahora, hay unos frameworks que son como una capa más arriba que te facilita el proceso de comunicación y que normalmente se le conoce como Sevice Bus, este se comunica con el queue y así tú puedes usar cualquier queue soportado de forma transparente, yo he trabajado con dos: NServiceBus y MassTransit, ambos open source pero el primero hay que pagar por su uso comercial.
Bueno aprovecho para agradecer al grupo como siempre los aportes, hay mucho material para leer acá.
Saludos
Israel
Sent from my iPhone
Carlos A. Osoria
Dec 14, 2016, 7:15:27 PM12/14/16
to improve-...@googlegroups.com
Hola
Para mi lo atractivo de MSMQ en este caso particular (debido a que todos los componentes son .net o microsoft) es:
- Ya esta instalado (hasta Win7 tiene MSMQ instalado)
- El API esta instalado System.Messaging es parte de la plataforma .NET desde 1.1
- Facil de usar
- Super stable ... MSMQ es probablemente el producto mas estable que ha producido microsoft
- Maneja probablemente 1000 m/s (mensajes por segundo), quizas mas, la verdad que 200 m/s para los sistemas que tenemos es mas que suficiente.
- Existen librerias como NServiceBus, MassTransit, WCF que puedes integrar en caso que quieras complicarte la vida
- Ofrece caracteristicas y configuraciones que resuelven el 80% de los casos que encontraras en cualquier sistema
- store-forward,
- guarantee delivery
- transactional and non-transactional
- persistent and non-persistent
- routing
- multicast
- dead letter
- administration tools
- encryption
Saludos
Carlos
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Karel Alfonso
Dec 14, 2016, 8:13:04 PM12/14/16
to improve-...@googlegroups.com
Hola Niurka,
Timely question! Esta es la reciente tendencia que he visto en la arquitectura de microservices. Primero algunas preguntas:
- Cuantos microservices tienes?
- Cuantos niveles de integracion tienes entre los microservices: solo un nivel y luego puntos de integracion o tienes microservices que dependen on microservices?
- Los eventos son solamente para inter-microservice communication o para ser procesados ademas ene sistemas de analisis de datos?
- Tienes que mantener orden en el procesamiento de eventos?
- Puedes asumir la carga operacional de mantener este sistema de colas?
Hago estas preguntas pues en dependencia de tus use cases distintas soluciones pueden ser mas apropiadas. Si puedes responderlas quiza pueda ayudar con mas recomendaciones
En los proyectos reciente hemos usado AWS SQS, Azure Queue en situaciones de tareas complejas usando un patron de master/worker. RabbitMQ and a distributed commit log like Kafka/Confluent.io/Kinesis/Azure Event Hub is being recommended as a viable solution (I'm in contact with a startup here in Melbourne that decided to go full on from the start into using microservices with Kinesis as the event hub and despite having awesome, experienced devs they're struggling to show progress quickly due to a more complex architecture).
Mi recommendacion es:
- Start small, not too many microservices (this is what I'm recommending to my next team this Monday, though we're using SQS for long running tasks)
- Use synchronous communication at the edges as closed to the user as possible, even if it's an offline mobile app.
- Use business level events to communicate between microservices in an asynchronous way (synchronicity can lead to cascading failures if not properly load balanced across failure domains)
Of course, if you already have your microservices underway with teams working and deploying independently, then you have into considerations the concerns I raised before: operations (cloud managed/unmanaged, on-premise), event ordering, fault tolerance, delivery semantics (you have to chose "at least once" at least which most queuing system should give you but then you'll have to make them idempotent by handling duplicates)
Amongst the million, but highly recommended, links I've shared there's one compating AWS queueing systems architecture. I'll try to avoid on-premise setup for the operation overhead, if possible.
If you can share more of your use cases / architecture it will be good for learning experience.
Saludos,
Karel
PS1. Perdona el spanglish, estaba hablando en el trabajo mientras respondia este email y me cuestra trabajo cambiar de ingles a espan~ol and back :-)
|
|
|
|
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Niurka Perez Mitjans
Dec 14, 2016, 8:48:34 PM12/14/16
to improve-your-code
Hi .
Thanks all for the replies. @Karel, English is fine, specially cause I need to talk about it later in english :)
The architecture is pretty settled, we had the projects as libraries and we moved to microservices to be able to have more servers with a load balancer in those ones with heavier processing.
There is one main rest api and 4 microservices, most of the integration points happen in the main service but there is one internal dependecy.
Something like this:
So far, we have only discussed about micro-services communication, no estoy segura a que te refieres con lo de analisis de datos pero no creo que sea necesario.
The order of the events is very relevant.
Not sure about the last question but I'm guessing that yes, we would assume that, hopefully it won't be that bad :)
Thanks!
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Karel Alfonso
Dec 14, 2016, 10:23:18 PM12/14/16
to improve-...@googlegroups.com
Hola Nelyuska! :-)
Aqui van algunos comentarios basado en tu architectura y aclaraciones a las preguntas:
- If event ordering is important then you have to be aware of those queue platforms that don't guarantee it, i.e, AWS SQS, JMS based solutions like ActiveMQ, WebsphereMQ. You can still use these systems but you'll have to take care of ordering yourself. Distributed commit logs (AWS Kinesis, Kafka/Confluent, Azure Event Hub, Twitter ServiceBus) they guarantee order per partition.
- Operational load: not sure how much your team is following DevOps practices but being able to provision the infrastructure, install and configure a messaging platform can be very time consuming. So using a cloud queue based service will help with that and will guarantee HA (high availability), scalability (it doesn't seem too relevant to the traffic pattern in your system), fault tolerance, hopefully 0 data loss or at least once delivery semantics.
- HA, fault tolerance (zero data loss) are very important. Providing this in on-premises set ups is even more complicated and time consuming but achievable.
- From the architecture I can see two synchronous links between (M - P) and (S - C). How did you determine synchronicity vs asynchronicity in the communication paths? The only one that can raise concerns is (M - P) assuming that M is fronted by a Web/Mobile UI. If P goes down, then your UI is down (it may or may not be using offline storage on the client). But then again you mentioned all those services are load balanced, hopefully across failure domains (availability zones in AWS)
- Regarding data analysis, if there's a requirement to do analytics/reporting, etc, from the information that flows from your services, depending on the load you wouldn't want to do it on the source systems, so getting the data out from the databases that backed your microservices into an analytical data store is a better approach.
Hope this helps,
Hasta pronto,
Karel
Hi .
Thanks all for the replies. @Karel, English is fine, specially cause I need to talk about it later in english :)
The architecture is pretty settled, we had the projects as libraries and we moved to microservices to be able to have more servers with a load balancer in those ones with heavier processing.
There is one main rest api and 4 microservices, most of the integration points happen in the main service but there is one internal dependecy.
Something like this:
So far, we have only discussed about micro-services communication, no estoy segura a que te refieres con lo de analisis de datos pero no creo que sea necesario.
The order of the events is very relevant.
Not sure about the last question but I'm guessing that yes, we would assume that, hopefully it won't be that bad :)
Thanks!
On Dec 14, 2016 8:13 PM, "'Karel Alfonso' via Improve your code" <improve-your-code@ googlegroups.com> wrote:
Hola Niurka,Timely question! Esta es la reciente tendencia que he visto en la arquitectura de microservices. Primero algunas preguntas:- Cuantos microservices tienes?- Cuantos niveles de integracion tienes entre los microservices: solo un nivel y luego puntos de integracion o tienes microservices que dependen on microservices?- Los eventos son solamente para inter-microservice communication o para ser procesados ademas ene sistemas de analisis de datos?- Tienes que mantener orden en el procesamiento de eventos?- Puedes asumir la carga operacional de mantener este sistema de colas?Hago estas preguntas pues en dependencia de tus use cases distintas soluciones pueden ser mas apropiadas. Si puedes responderlas quiza pueda ayudar con mas recomendaciones
En los proyectos reciente hemos usado AWS SQS, Azure Queue en situaciones de tareas complejas usando un patron de master/worker. RabbitMQ and a distributed commit log like Kafka/Confluent.io/Kinesis/Azu re Event Hub is being recommended as a viable solution (I'm in contact with a startup here in Melbourne that decided to go full on from the start into using microservices with Kinesis as the event hub and despite having awesome, experienced devs they're struggling to show progress quickly due to a more complex architecture).
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Ramon Araujo
Dec 15, 2016, 1:40:39 AM12/15/16
to improve-your-code
Hola Niurka,
He aqui un slideshare acerca de microservices que hace mencion a Hangfire y otras tecnologias:
Saludos,
Ramon Araujo
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Ramon Araujo
Dec 15, 2016, 1:48:52 AM12/15/16
to improve-your-code
Hola Niurka,
Encontre el video ;) Fijate que tiene referencias a la bibliografia, los patrones y los challenges a la hora de disennar la arquitectura.
Saludos,
Ramon Araujo
On Thu, Dec 15, 2016 at 5:40 PM, Ramon Araujo <ramon....@gmail.com> wrote:
Hola Niurka,He aqui un slideshare acerca de microservices que hace mencion a Hangfire y otras tecnologias:Saludos,Ramon Araujo
Israel García
Dec 15, 2016, 2:00:38 AM12/15/16
to improve-...@googlegroups.com
Interesante, una pregunta sobre los queues que se usan en el CLOUD y como servicios...
Si yo quiero garantizar que los mensajes se manden siempre de A a B tendria que instalar un QUEUE local en A y en B que se encargue de enviar los mensajes cuando la conexion entre A y B se reestablezca, vaya, este es el escenario normal de como funciona MSMQ, ahora me pregunto, como funciona esto cuando el QUEUE esta como servicio??
A -> QUEUE -> B
En este caso si A pierde la conexion con el QUEUE, donde se guarda el mensaje?
Ellos te dan un agente que corre en cada cliente? O simplemente este caso no se considera?
Saludos.
Israel.
Karel Alfonso
Dec 15, 2016, 3:16:32 PM12/15/16
to improve-...@googlegroups.com
Hola Israel,
Los servicios de colas en el cloud que he usado o visto (AWS SQS, SNS, Azure Queue, Kinesis) no brindan un agente local a la aplicacion para comunicar con el servicio. Pero, al menos en el caso de AWS, los SDKs brindados en distintos lenguajes al menos brindan la funcionalidad de manipulacion de errores (rate limiting, exponential back off with bounded retries). Si al final del ultimo intento de envio aun recibes un error, tienes que implementar tu propio mecanismo de gestion de errores (request resend from the user, keep in storage for later sending, use the Circuit Braker pattern which lots of languages libraries already provide).
Esto es un problema mas general en sistemas distribuidos, especialmente cuando usas intermediarios no locales a tu aplicacion. Aun teniendo un proceso (agente) local corriendo al lado de tu aplicacion, en dependencia del mecanismo de comunicacion entre tu aplicacion y el agente local (TCP/IP, IPC), este problema se puede manifestar, i.e, si el proceso que ejecuta el agente falla por alguna razon. No se como maneja estos casos con MSMQ pues no lo he usado. En sistemas distribuidos es aconsejable ser lo mas pesimista posible.
Un buen articulo que olvide enviar en mi ultimo email es Disecting Message Queues que probablemente condensa todas la mayoria de las tecnologias de colas mencionadas en este thread.
Saludos,
Karel
|
Interesante, una pregunta sobre los queues que se usan en el CLOUD y como servicios...
Si yo quiero garantizar que los mensajes se manden siempre de A a B tendria que instalar un QUEUE local en A y en B que se encargue de enviar los mensajes cuando la conexion entre A y B se reestablezca, vaya, este es el escenario normal de como funciona MSMQ, ahora me pregunto, como funciona esto cuando el QUEUE esta como servicio??
A -> QUEUE -> B
En este caso si A pierde la conexion con el QUEUE, donde se guarda el mensaje?
Ellos te dan un agente que corre en cada cliente? O simplemente este caso no se considera?
Saludos.
Israel.
On Thu, Dec 15, 2016 at 1:48 AM, Ramon Araujo <ramon....@gmail.com> wrote:
Hola Niurka,Encontre el video ;) Fijate que tiene referencias a la bibliografia, los patrones y los challenges a la hora de disennar la arquitectura.Saludos,Ramon Araujo
On Thu, Dec 15, 2016 at 5:40 PM, Ramon Araujo <ramon....@gmail.com> wrote:
Hola Niurka,He aqui un slideshare acerca de microservices que hace mencion a Hangfire y otras tecnologias:Saludos,Ramon Araujo
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Israel García
Dec 15, 2016, 5:31:19 PM12/15/16
to improve-...@googlegroups.com
Graciasl Karel, lo voy a revisar.
En efecto MSMQ maneja esto, de hecho cuando usas MSMQ siempre que se envian los mensajes, este los mete en queue LOCAL que el crea solito y luego el MSMQ se encarga de comunicarse con la cola remota del destinatario, So MSMQ tiene que estar instalado en todos los puntos donde se envien o reciban mensajes.
Con RabbitMQ para lograr esto, tienes que instalar un Rabbit en cada entidad y mandar los mensajes a colas locales y bueno configurar el Rabbit para que transmita los mensajes hacia una cola remota. Pero aca tienes que configurarlo tu, o sea no es transparente como en MSMQ.
Es por eso mi pregunta, tal ves yo estoy tratanto de atacar un punto que no es considerable, simplemente porque se presume que siempre el QUEUE va a estar en tu red local y no deberias perder conexion con el.
Y bueno, finalmente la ventaja de algo asi es que tu mandas el mensaje y todo ese mecanismo de reintentos trabaja fuera del entorno de tu applicacion, tu aplicacion no se detiene ni consume recursos en esto, pero bueno volviendo a la oracion anterior, parece que no es tan necesario contemplar este caso.
Gracias por las opiniones, muy valiosas todas!
Israel.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
--
---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages