(This message has been automatically imported from the retired mailing list)
First, you have put together a beautiful project here, very impressive.
Second, I am in the evaluation stages with Zatos and am trying to determine
how it would help solve our various messaging problems. Currently we have a
requirement for a handful of .NET client/server installations to act as a
service from within on-premise app servers usually running behind our
clients firewalls that can communicate with our apps running in the cloud.
The .NET app can already post outbound events to HTTP endpoints, but we now
need the .net app to participate in a more bi-directional way, and because
we aren=B9t usually in control of the network where this app is installed I=B9d
prefer the transport layer to =B3just work=B2 to the maximum extent possible
regardless of firewall configurations. Since our .net app already uses HTTP=
that seems like the way to go. We could use something like AWS SQS or
IronQueue, but since Zatos doesn=B9t have native channels for those message
queues and they will require manual administration and configuration I was
thinking it might be simpler just expose a vanilla Zatos service via HTTP
and use long polling to provide reasonably low latency push to the .NET app=
probably bridging an AMQP queue hosted inside our Rackspace cloud.
So first, does that seem reasonable in general? And second, is that
something Zatos would have any issues with, holding an HTTP connection open
for some period (say 20/30 seconds)? We=B9re mostly a ruby shop so I don=B9t
know much about gunicorn, but I believe I read that you are using its
evented workers, so I presume we wouldn=B9t starve the server of worker
processes using this approach? Are there any other Zatos specific caveats?
And when the .net app replies to a message it receives in this way (by
posting to another endpoint over HTTPS) can the reply be easily correlated
to the original request?
Thank you for your time,