Alexander Malysh wrote:
nope and IMO it's not needed. just don't send ack/nack to bearerbox as long the message is not processed and bearerbox will do the job for free.
+1, did you have this inside your tree to addopt to cvs? It will require some work, since you have to make sure bearerbox does not inject the message for a second time, while still in "processing".
BTW, this brings again a more semantical question to the top. Should a "messaging node" try infinitly to deliver a message to the next node (the application layer in this case)? I don't think so. Actually it's the "fault" of the next node, if the HTTP server breaks and responds with HTTP 500. IMO, a node inside a communication path is not required to "cover" errors of the participating nodes. But I guess this is a "system architecture" religious question.
IMO if server responds then message processing is done, another story if http server is not reachable, in this case smsbox should re-try depending on 'http-request-retry' and 'http-queue-delay' config directives.
ok, so your opinion is. Current way of operations is what we intend to?
Stipe
mailto:stolj_{at}_wapme.de ------------------------------------------------------------------- Wapme Systems AG
Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0 fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------
